运维技术方案.docx

上传人:b****6 文档编号:3058026 上传时间:2022-11-17 格式:DOCX 页数:55 大小:76.49KB
下载 相关 举报
运维技术方案.docx_第1页
第1页 / 共55页
运维技术方案.docx_第2页
第2页 / 共55页
运维技术方案.docx_第3页
第3页 / 共55页
运维技术方案.docx_第4页
第4页 / 共55页
运维技术方案.docx_第5页
第5页 / 共55页
点击查看更多>>
下载资源
资源描述

运维技术方案.docx

《运维技术方案.docx》由会员分享,可在线阅读,更多相关《运维技术方案.docx(55页珍藏版)》请在冰豆网上搜索。

运维技术方案.docx

运维技术方案

服务方案

服务目标、范围和任务

服务任务

服务需求定义了服务商需提供服务的边界,是指运维工程师针对“项目的运维支持对象"所包含的应用系统部署情况和系统运行维护特点,为保障系统正常运行,及时解决问题,预防故障发生,所提供的支持服务内容,主要包括被动支持服务、主动支持服务和支持保障三部分。

在项目执行过程中根据运维业务特点,为配合业务需求的改变,服务内容和工作规程会适当调整,合同执行和验收标准以调整后的服务工作内容、工作规程和服务指标为依据。

被动支持服务工作是指日常工作中针对各级用户通过运维平台或者电话反映的应用系统使用过程中出现的一般、疑难、紧急、重大问题提供的技术支持,及时解答问题、分析问题、定位问题、解决问题、反馈解决结果、记录并归纳的过程。

被动支持服务工作包括问题受理和一般问题处理、问题回访与确认、数据维护、程序问题确认、需求问题确认、紧急问题处理、问题协同解决、系统迁移、现场支持等内容.

主动支持服务工作是指根据系统自身特点,结合以往的经验,定期对支撑应用系统运行的主机系统、数据库系统和中间件等进行日常检查和健康检查,根据系统运行情况进行资源优化、对应用系统数据质量进行检查和评估,定期备份数据和软件,以避免小隐患引发大问题,防患于未然,最大程度地预防应用系统故障的发生.

支持保障工作是指为做好被动支持服务和主动支持服务工作而开展的质量控制、技术保障等工作.运维基础保障工作包括补丁发布、配置管理、知识提取与维护、应用系统运维培训等。

服务方案

项目理解

XXXXXX系统所采用的技术

XXXXXX系统是基于采用J2EE三层次技术路线,基于XML的数据表示,基于SOA的应用系统开发架构所开发的系统.具体技术如下:

基于J2EE三层次技术路线

为了充分满足系统在安全性、实用性、可移植性、易扩操作、易维护性等方面的要求,系统采用基于Java平台的J2EE技术体系,系统构建于B/S三层应用体系结构之上,并采用JSP、javaServlet、EJB、XML等编程技术和面向对象程序设计方法,将复杂的业务逻辑、流程控制逻辑和数据存取逻辑通过在不同的技术层面上实现,在应用服务器之上,实现业务逻辑的快速部署和灵活调整,充分保证数据库系统的安全可靠访问。

J2EE是目前业界公认的企业级信息系统的支撑体系结构,是各个系统和系统内部各个组成部分之间的粘合剂。

J2EE提供了跨平台的解决方案,提供了通用的JDBC数据库访问接口,无缝支持通过XML进行系统间和系统内部的数据传递。

在J2EE体系结构中,所有的技术都是开放的,得到业界主流支持的,所以统一使用J2EE体系架构,有利于系统之间的整合,避免重复投资,降低IT的管理和建设成本。

选用三层结构具有以下优点:

●系统管理简单,大大减少客户机维护工作量。

基于B/S结构的应用模式无需客户端维护工作;基于“瘦客户/服务器"结构的客户端可以实现自动更新下载,也无需客户端维护工作。

具有灵活的硬件系统构成对于各个层可以选择与其处理负荷和处理特性相适应的硬件,方便的实现负载均衡。

清晰、合理地分割三层结构并使其独立,可以使系统构成的变更非常简单。

因此被分成三层的应用基本上不需要修正。

提高程序的可维护性三层B/S结构中,应用的各层可以并行开发,各层也可以选择各自最适合的开发语言.

●进行严密的安全管理

涉密的关键应用的安全管理非常重要。

在三层B/S结构中,识别用户的机构是按层来构筑的,对应用和数据的存取权限也可以按层进行设定。

例如,即使外部的入侵者突破了表示层的安全防线,若在功能层中备有另外的安全机构,系统也可以阻止入侵者进入其他部分.

J2EE提供了一套企业级Java应用框架(一种标准),是一种利用Java2平台来简化企业解决方案的开发、部署和管理相关的复杂问题的体系结构。

基于XML的数据表示

数据交换是一个开放的电子政务系统的基本功能,如果数据交换使用的数据格式千差万别,则需要复杂的数据编码和解码工作,因此统一数据交换使用的数据封装格式是进行电子政务平台建设的首要任务.

XML(eXtensibleMarkupLanguage,可延伸性标示语言)是目前国际上流行的数据表示标准,因为它的简单性、开放性、可扩展性、灵活性、自描述性等特性,XML在数据和信息管理、数据交换、Web应用、电子商务、应用集成等诸多领域有着重要用途,已经得到了工业界的普遍支持,也是我国电子政务采用的标准。

采用XML方式对系统要交换的数据进行表示,既可以便于系统的间的数据交换,又可以方便的进行扩充,因此系统技术平台的交换数据表示全部采用XML格式来表示.

系统基于SOA的应用系统开发架构

面向服务的架构(SOA)被认为是用于下一代应用系统开发的架构。

帮助人们在开发应用的时候能够寻找并使用已有的服务而不必重复开发某些功能;能够方便集成异构系统;能够更容易地扩展已有系统.服务是一个组件的集合,它们向外界提供某个接口,能够完成某种业务功能。

在面向服务的架构中,服务的实现可以放在网络的任何位置,只需要对外发布这个服务的描述,其他的系统(或者服务)就可以发现并且使用这个服务。

不同的服务可能采用不同的开发语言、组件模型、硬件环境、数据库,而在这个架构中它们无缝地集成在一起。

这种方式消除了异构的分布的环境对应用系统的影响,开发者可只考虑系统的业务逻辑,关注某个部分业务功能的实现,并将它们包装成为合适的服务,不需要考虑和其他服务之间的互操作性问题,减少了系统的开发风险和成本.

服务和组件的不同在于服务更多地从业务角度出发进行设计,向用户提供一个完整的业务的实现,而组件可能只提供完成某个业务的部分功能。

在面向服务的架构中,一个系统实现了客户需要的某些业务过程,其中每个服务实现了业务过程中的某个活动。

从软件开发的过程来看,面向服务的架构更加符合业务的视角,设计人员可以方便地根据已经获得的业务需求进行设计,采用服务实现各部分的业务需求,并将它们组装为应用系统。

总的来说,面向服务的架构可以尽可能地利用组织中的现有资源,保护已有投资。

它通过将实现的细节和业务逻辑分离,使得系统可以更好地被复用、扩展和维护。

2.3。

2管理子系统特点分析

根据社保费的需求来源,总局业务组提供的需求是对业务流程、规范的明确,确定业务框架和方向,各省提供的组间联系单是根据基层实践工作对总局的业务流程、规范的补充完善,而各省单独提出的差异需求则是为满足基层实际工作需要,在用户体验、数据质量控制方面的具体要求.因此XXXXXX系统的功能呈现整体功能结构统一,功能各地差异化的特点.

2.3。

3业务场景

XXXXXX社保费子系统要立足于快速建立全国税务系统社保费征缴管理的统一规范,遵循金税三期建设标准进行设计,内容包含登记、认定、申报、证明等业务域,满足各地区基本的、核心的社保费征缴管理工作需要,同时,也满足职工个人明细申报、城乡居民虚拟户管理等新业务的实现.坚持数据标准统一、业务处理流程规范、数据处理逻辑一致,坚持税费同征共管,坚持与税收发展同向同频同步,不断提升社保费征管的现代化水平。

在保障社保费征缴管理工作全国的通用性、基础性业务实现基础上,尊重各地已取得的社保费征管体系建设成果,同时,为实现个性化、差异化特色业务预留了业务接口,为实现征缴政策平移、业务规范统一、系统迭代开发奠定基础.

2.3。

4业务模块

XXXX系统包括6大业务模块。

具体包括社会保险费参保缴费关联登记、社保缴费认定、社保费申报、社保费结算、社保费对账、社会保险费管理.

服务内容

系统运维

(1)运行环境监控保障采取人工与监控软件相结合的形式定期对应用及数据库服务器操作系统、中间件、数据库、网络连接进行监控和检查,做到对运行环境风险的提前判断、风险预警,并采取对应措施及时规避风险;通过对性能数据、事件数据、报警数据的收集和分析,并根据实际监控情况,定期出具系统监控报告,展现系统当前性能状况,包括系统监控情况描述,根据监控情况提出系统优化建议,并进行系统优化。

(2)系统故障分析处理

对于出现的系统故障,及时定位和解决问题;故障处理主要包括故障定位、故障解决和故障总结.故障处理是针对独立案件而提出的服务请求设置。

每一个作为服务请求提出的故障解决要求,都要经过技术支持服务体系管理,最终获得故障的解决。

故障处理的服务范围包括但不限于:

a。

在系统运行、升级期间出现的故障须及时到现场进行处理、解决;

b。

在系统出现非停机性质的故障如系统运行缓慢时的处理;

c。

涉及操作问题、环境问题(指与应用软件相关的支撑平台问题,包括数据库、操作系统、硬件设备及网络)、软件问题(指业务需求范围内因操作软件失误而引发的问题)或其它问题,经过初步处理后而无法排除故障的,提供故障定位和咨询,并协助相关技术支持人员分析故障原因;

d。

对于紧急故障,提供工作时间以外的应急技术支持和故障分析。

(3)系统升级测试

根据总局、省局运维要求,在版本发布前在预生产环境升级测试,对于测试中出现的问题应及时处理,并形成测试用例及测试报告。

(4)系统发布验证

根据总局、省局运维要求,及时对应用系统进行版本发布和应用部署,为了避免版本升级、环境部署、硬件扩容、数据库优化等对生产环境带来影响,拟定验证方案,并安排人员非工作日在生产环境进行真实业务验证工作;对验证出的问题当天必须反馈问题处理情况,不能及时处理的问题必须给出应急方案,升级发布前须做好应用系统和数据库的备份工作。

(5)系统优化

a.定期对系统数据库进行分析,并进行性能优化,形成数据库性能分析报告;

b。

定期对应用程序进行优化,结合实际情况调整执行时间和方式;

c.对系统和各功能模块的运行效率、性能进行分析,并根据分析结果进行程序优化(含底层开发平台的优化)、参数调整、结构扩展、重新部署等。

(6)接口联调

XXXXXX系统与征收子系统及特色业务结合紧密,运维人员必须积极与核心征管及特色业务运维人员加强配合,不得因为个人原因使第三方运维秩序受到影响;其他应用系统接入时,需按金税三期工程的联调接入流程,先向西藏自治区税务局局和应用总集成备案,按XXXXXX工作集成联调流程进行。

(7)安全管理服务

根据《网络安全法》及税务系统数据安全管理的相关要求,在对XXXXXX系统运行维护期间,合理设置运维岗位,遵守安全管理制度,无条件接受运维审计及监督,对XXXXXX系统所涉数据做到有效的保护工作。

安全管理服务包括:

环境安全管理、资产管理、介质管理、安全监控、网络安全管理、系统安全管理、网络入侵响应、大规模病毒爆发响应。

(8)环境安全管理

规范办公环境人员行为,包括:

工作人员调离办公室应立即交还该办公室钥匙、不在办公区接待来访人员、工作人员离开座位应确保终端计算机退出登录状态和桌面上没有包含敏感信息的文件等。

(9)资产管理

编制并保存与信息系统相关的资产清单,包括资产责任部门、重要程度和所处位置等;规定信息系统资产管理的责任人员或责任部门,并规范资产管理和使用的行为。

对信息分类与标识方法做出规定,根据资产的重要程度对资产进行标识管理,并对信息的使用、传输和存储等进行规范化管理.

(10)介质管理

确保介质存放在安全的环境中,对各类介质进行控制和保护。

对介质在物理传输过程中的人员选择、打包、交付等情况进行控制,对介质归档和查询等进行登记记录,并根据存档介质的目录清单定期盘点。

对存储介质的使用过程、送出维修以及销毁等进行严格的管理,对带出工作环境的存储介质进行内容加密和监控管理,对送出维修或销毁的介质应首先清除介质中的敏感数据,对保密性较高的存储介质未经批准不得自行销毁.

根据数据备份的需要对某些介质实行异地存储,存储地的环境要求和管理方法应与本地相同。

对重要介质中的数据和软件采取加密存储,并根据所承载数据和软件的重要理度对

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 法律文书 > 调解书

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1