1.1.1. 服务目标、范围和任务 1.1.1.1. 服务任务
服务需求定义了服务商需提供服务的边界，是指运维工程师针对“项目的运维支持对象”所包含的应用系统部署情况和系统运行维护特点，为保障系统正常运行，及时解决问题,预防故障发生，所提供的支持服务内容，主要包括被动支持服务、主动支持服务和支持保障三部分。
在项目执行过程中根据运维业务特点，为配合业务需求的改变，服务内容和工作规程会适当调整，合同执行和验收标准以调整后的服务工作内容、工作规程和服务指标为依据。
被动支持服务工作是指日常工作中针对各级用户通过运维平台或者电话反映的应用系统使用过程中出现的一般、疑难、紧急、重大问题提供的技术支持,及时解答问题、分析问题、定位问题、解决问题、反馈解决结果、记录并归纳的过程。被动支持服务工作包括问题受理和一般问题处理、问题回访与确认、数据维护、程序问题确认、需求问题确认、紧急问题处理、问题协同解决、系统迁移、现场支持等内容。
主动支持服务工作是指根据系统自身特点,结合以往的经验，定期对支撑应用系统运行的主机系统、数据库系统和中间件等进行日常检查和健康检查，根据系统运行情况进行资源优化、对应用系统数据质量进行检查和评估，定期备份数据和软件,以避免小隐患引发大问题，防患于未然，最大程度地预防应用系统故障的发生。
支持保障工作是指为做好被动支持服务和主动支持服务工作而开展的质量控制、技术保障等工作。运维基础保障工作包括补丁发布、配置管理、知识提取与维护、应用系统运维培训等。
1.1.2. 服务方案 1.1.2.1. 项目理解
1.1.2.1.1. XXXXXX系统所采用的技术
XXXXXX系统是基于采用J2EE 三层次技术路线，基于 XML 的数据表示，基于 SOA 的应用系统开发架构所开发的系统.具体技术如下： 1.1.2.1.1.1. 基于 J2EE 三层次技术路线
为了充分满足系统在安全性、实用性、可移植性、易扩操作、易维护性等方面的要求， 系统采用基于 Java 平台的 J2EE技术体系，系统构建于 B/S 三层应用体系结构之上，并采用JSP、java Servlet 、EJB、XML等编程技术和面向对象程序设计方法，将复杂的业务逻辑、流程控制逻辑和数据存取逻辑通过在不同的技术层面上实现,在应用服务器之上，实现业务逻辑的快速部署和灵活调整,充分保证数据库系统的安全可靠访问。
J2EE是目前业界公认的企业级信息系统的支撑体系结构，是各个系统和系统内部各个组成部分之间的粘合剂。J2EE 提供了跨平台的解决方案，提供了通用的JDBC数据库访问接口，无缝支持通过XML进行系统间和系统内部的数据传递.在J2EE体系结构中,所有的技术都是开放的， 得到业界主流支持的， 所以统一使用 J2EE体系架构,有利于系统之间的整合， 避免重复投资， 降低 IT 的管理和建设成本。
选用三层结构具有以下优点:
系统管理简单，大大减少客户机维护工作量。
基于 B/S 结构的应用模式无需客户端维护工作；基于“瘦客户／服务器\"结构的客户端可以实现自动更新下载, 也无需客户端维护工作.
具有灵活的硬件系统构成对于各个层可以选择与其处理负荷和处理特性相适应的硬件,方便的实现负载均衡。清晰、合理地分割三层结构并使其独立 ， 可以使系统构成的变更非常简单。因此被分成三层的应用基本上不需要修正。
提高程序的可维护性三层 B/S 结构中，应用的各层可以并行开发 ， 各层也可以选择各自最适合的开发语言。
进行严密的安全管理
涉密的关键应用的安全管理非常重要。 在三层 B/S 结构中 , 识别用户的机构是按层来构筑的, 对应用和数据的存取权限也可以按层进行设定.例如，即使外部的入侵者突破了表示层的安全防线，若在功能层中备有另外的安全机构，系统也可以阻止入侵者进入其他部分。
J2EE 提供了一套企业级Java 应用框架（一种标准）,是一种利用 Java 2 平台来简化企业解决方案的开发、部署和管理相关的复杂问题的体系结构。 1.1.2.1.1.2. 基于 XML 的数据表示
数据交换是一个开放的电子政务系统的基本功能,如果数据交换使用的数据格式千差万别，则需要复杂的数据编码和解码工作，因此统一数据交换使用的数据封装格式是进行电子政务平台建设的首要任务。
XML（eXtensible Markup Language，可延伸性标示语言）是目前国际上流行的数据表示标准，因为它的简单性、开放性、可扩展性、灵活性、自描述性等特性，XML在数据和信息管理、数据交换、Web应用、电子商务、应用集成等诸多领域有着重要用途，已经得到了工业界的普遍支持，也是我国电子政务采用的标准。
采用 XML方式对系统要交换的数据进行表示，既可以便于系统的间的数据交换， 又可以方便的进行扩充, 因此系统技术平台的交换数据表示全部采用XML格式来表示。
1.1.2.1.1.3. 系统基于 SOA 的应用系统开发架构
面向服务的架构(SOA）被认为是用于下一代应用系统开发的架构。帮助人们在开发应用的时候能够寻找并使用已有的服务而不必重复开发某些功能；能够方便集成异构系统; 能够更容易地扩展已有系统。服务是一个组件的集合，它们向外界提供某个接口,能够完成某种业务功能.在面向服务的架构中, 服务的实现可以放在网络的任何位置，只需要对外发布这个服务的描述，其他的系统（或者服务）就可以发现并且使用这个服务。不同的服务可能采用不同的开发语言、组件模型、硬件环境、数据库，而在这个架构中它们无缝地集成在一起。这种方式消除了异构的分布的环境对应用系统的影响， 开发者可只考虑系统的业务逻辑， 关注某个部分业务功能的实现， 并将它们包装成为合适的服务， 不需要考虑和其他服务之间的互操作性问题, 减少了系统的开发风险和成本。
服务和组件的不同在于服务更多地从业务角度出发进行设计，向用户提供一个完整的业务的实现，而组件可能只提供完成某个业务的部分功能.在面向服务的架构中，一个系统实现了客户需要的某些业务过程，其中每个服务实现了业务过程中的某个活动。从软件开发的过程来看，面向服务的架构更加符合业务的视角，设计人员可以方便地根据已经获得的业务需求进行设计，采用服务实现各部分的业务需求,并将它们组装为应用系统。
总的来说,面向服务的架构可以尽可能地利用组织中的现有资源,保护已有投资。它通过将实现的细节和业务逻辑分离，使得系统可以更好地被复用、扩展和维护。
1.1.2.1.2. 2。3。2管理子系统特点分析
根据社保费的需求来源，总局业务组提供的需求是对业务流程、规范的明确,确定业务框架和方向，各省提供的组间联系单是根据基层实践工作对总局的业务流程、规范的补充完善，而各省单独提出的差异需求则是为满足基层实际工作需要，在用户体验、数据质量控制方面的具体要求。因此XXXXXX系统的功能呈现整体功能结构统一,功能各地差异化的特点。 1.1.2.1.3. 2.3。3业务场景
XXXXXX社保费子系统要立足于快速建立全国税务系统社保费征缴管理的统一规范，遵循金税三期建设标准进行设计，内容包含登记、认定、申报、证明等业务域，满足各地区基本的、核心的社保费征缴管理工作需要,同时，也满足职工个人明细申报、城乡居民虚拟户管理等新业务的实现。坚持数据标准统一、业务处理流程规范、数据处理逻辑一致，坚持税费同征共管,坚持与税收发展同向同频同步,不断提升社保费征管的现代化水平。
在保障社保费征缴管理工作全国的通用性、基础性业务实现基础上,尊重各地已取得的社保费征管体系建设成果，同时，为实现个性化、差异化特色业务预留了业务接口，为实现征缴政策平移、业务规范统一、系统迭代开发奠定基础。 1.1.2.1.4. 2。3。4业务模块
XXXX系统包括6大业务模块。具体包括社会保险费参保缴费关联登记、社保缴费认定、社保费申报、社保费结算、社保费对账、社会保险费管理.
1.1.2.2. 服务内容 1.1.2.2.1. 系统运维
（1）运行环境监控保障采取人工与监控软件相结合的形式定期对应用及数据库服务器操作系统、中间件、数据库、网络连接进行监控和检查，做到对运行环境风险的提前判断、风险预警，并采取对应措施及时规避风险；通过对性能数据、事件数据、报警数据的收集和分析，并根据实际监控情况,定期出具系统监控报告，展现系统当前性能状况，包括系统监控情况描述,根据监控情况提出系统优化建议，并进行系统优化。
（2）系统故障分析处理
对于出现的系统故障,及时定位和解决问题;故障处理主要包括故障定位、故障解决和故障总结.故障处理是针对独立案件而提出的服务请求设置.每一个作为服务请求提出的故障解决要求，都要经过技术支持服务体系管理，最终获得故障的解决。故障处理的服务范围包括但不限于:
a。在系统运行、升级期间出现的故障须及时到现场进行处理、解决; b。在系统出现非停机性质的故障如系统运行缓慢时的处理；
c。涉及操作问题、环境问题（指与应用软件相关的支撑平台问题,包括数据库、操作系统、硬件设备及网络）、软件问题（指业务需求范围内因操作软件失误而引发的问题)或其它问题，经过初步处理后而无法排除故障的，提供故障定位和咨询，并协助相关技术支持人员分析故障原因；
d。对于紧急故障,提供工作时间以外的应急技术支持和故障分析。 （3）系统升级测试
根据总局、省局运维要求，在版本发布前在预生产环境升级测试，对于测试中出现的问题应及时处理，并形成测试用例及测试报告。
（4）系统发布验证
根据总局、省局运维要求，及时对应用系统进行版本发布和应用部署,为了避免版本升级、环境部署、硬件扩容、数据库优化等对生产环境带来影响，拟定验证方案，并安排人员非工作日在生产环境进行真实业务验证工作；对验证出的问题当天必须反馈问题处理情况，不能及时处理的问题必须给出应急方案，升级
发布前须做好应用系统和数据库的备份工作.
（5)系统优化
a.定期对系统数据库进行分析,并进行性能优化，形成数据库性能分析报告； b.定期对应用程序进行优化，结合实际情况调整执行时间和方式； c。对系统和各功能模块的运行效率、性能进行分析,并根据分析结果进行程序优化（含底层开发平台的优化）、参数调整、结构扩展、重新部署等。
（6）接口联调
XXXXXX系统与征收子系统及特色业务结合紧密,运维人员必须积极与核心征管及特色业务运维人员加强配合，不得因为个人原因使第三方运维秩序受到影响；其他应用系统接入时，需按金税三期工程的联调接入流程，先向西藏自治区税务局局和应用总集成备案,按XXXXXX工作集成联调流程进行.
（7）安全管理服务
根据《网络安全法》及税务系统数据安全管理的相关要求，在对XXXXXX系统运行维护期间,合理设置运维岗位，遵守安全管理制度，无条件接受运维审计及监督，对XXXXXX系统所涉数据做到有效的保护工作。
安全管理服务包括：环境安全管理、资产管理、介质管理、安全监控、网络安全管理、系统安全管理、网络入侵响应、大规模病毒爆发响应.
（8）环境安全管理
规范办公环境人员行为，包括：工作人员调离办公室应立即交还该办公室钥匙、不在办公区接待来访人员、工作人员离开座位应确保终端计算机退出登录状态和桌面上没有包含敏感信息的文件等。
(9）资产管理
编制并保存与信息系统相关的资产清单,包括资产责任部门、重要程度和所处位置等；规定信息系统资产管理的责任人员或责任部门，并规范资产管理和使用的行为.
对信息分类与标识方法做出规定,根据资产的重要程度对资产进行标识管理,并对信息的使用、传输和存储等进行规范化管理。
（10）介质管理
确保介质存放在安全的环境中，对各类介质进行控制和保护。
对介质在物理传输过程中的人员选择、打包、交付等情况进行控制，对介质归档和查询等进行登记记录，并根据存档介质的目录清单定期盘点。
对存储介质的使用过程、送出维修以及销毁等进行严格的管理，对带出工作环境的存储介质进行内容加密和监控管理，对送出维修或销毁的介质应首先清除介质中的敏感数据,对保密性较高的存储介质未经批准不得自行销毁。
根据数据备份的需要对某些介质实行异地存储，存储地的环境要求和管理方法应与本地相同.对重要介质中的数据和软件采取加密存储，并根据所承载数据和软件的重要理度对介质进行分类和标识管理。
(11)安全监控
对通信线路、主机、网络设备和应用软件的运行状况、网络流量、用户行为等进行监测和报警，形成记录并妥善保存。对监测和报警记录进行分析、评审，发现可疑行为，形成分析报告，并采取必要的应对措施.对设备状态、恶意代码、补丁升级、安全审计等安全相关事项进行集中管理。
（12)网络安全管理
根据网络安全相关要求对应用及数据库服务器操作系统、中间件、数据库进行安全配置,并根据网络安全检查的结果及采购方提供的官方补丁，针对发现的各类漏洞进行修复，避免个人所得税相关信息系统发生网络安全事件；配合采购方组织的网路安全攻防演练
（13)系统安全管理
根据业务需求和系统安全分析确定系统的访问控制策略.定期进行漏洞扫描，对发现的系统安全漏洞及时进行修补。
安装系统的最新补丁程序，在安装系统补丁前，首先在测试环境中测试通过，并对重要文件进行备份后，方可实施系统补丁程序的安装。
依据操作手册对系统进行维护，详细记录操作日志,包括重要的日常操作、运行维护记录、参数的设置和修改等内容，严禁进行未经授权的操作。
定期对运行日志和审计数据进行分析，以便及时发现异常行为.
对系统安全策略、安全配置、日志管理和日常操作流程等方面做出具体规定.网络入侵响应入侵响应(Intrusion Response,IR）是指,对检测工具（如 IDS）检测出的入侵行为采取适当的响应，达到阻止攻击和最大程度保护系统资源的安
全目的。根据安全模型可以看出，响应是其中不可缺少而且尤为重要的环节。不仅如此，由检测部分传递过来的，除了大量的事件数据信息外，还有大量的告警信息，这些告警信息里包括常规的和误报的；及时、高效地处理这些信息，并保护好系统资源。
（14)大规模病毒爆发响应
广义的计算机病毒：随着 Internet 技术的发展，计算机病毒的定义正在逐步发生着变化，与计算机病毒的特征和危害有类似之处的“特洛依木马”和“蠕虫”,从广义的角度而言也可归为计算机病毒。特洛伊木马(Trojan horse)又称为黑客程序，是一种潜伏执行非授权功能的技术，它在正常程序中存放秘密指令，使计算机在仍能完成原先指定任务的情况下,执行非授权功能。“蠕虫”(Worm）是一个程序或程序序列,通过分布式网络来扩散传播特定的信息或错误,进而造成网络服务遭到拒绝并发生死锁或系统崩渣。
大规模病毒爆发后，为减少损失，应遵循如下的处理措施： a。断开网络
当遭遇病毒入侵之后，先分析所有的异常状况,在确定严重的情况启动安全事件应急流程,通知相关负责人,得到许可后当机立断断开中病毒服务器的网络连接，以避免病毒的进一步扩散。
b。文件备份
但为了防止杀毒软件误杀或是删除还没有处理完的文档，应该首先将它们转移备份到其他储存媒体上。
c。借助杀毒软件
应适当引入杀毒软件以应对病毒入侵，由于杀毒软件在开发时侧重点不同、使用的杀毒引擎不同，各种杀毒软件都有自己的长处和短处，交叉使用效果较理想。
d。安全处理
包括登录网络的用户名、密码、邮箱和数据库密码等，防止黑客已经在上次入侵过程中盗了你的密码。另外因为很多蠕虫病毒发作后会向外随机发送你的信息，所以适当地更改是必要的。 1.1.2.2.2. 局端技术支持
（1)问题处理
通过运维管理平台、QQ 群、电话、微信等渠道接收基层系统使用人员所提交的问题并进行及时、有效的处理。提供的问题解答处理建议均以前台操作为主,能够通过前台操作完成的，不允许通过后台调整。问题解答的服务范围包括但不限于以下内容:
a.应用系统操作、配置咨询解答； b.异常流程处理咨询解答；
c。针对各系统的业务处理方法、业务处理原理及流程等在软件功能上反映的问题提供及时全面的解答,辅助业务人员完成应用系统的运行操作；
d。在线解答通过运维平台上报的应用系统问题，对问题进行归类分析，纳入知识库，并定期进行更新维护.
e.对于用户反馈的操作中出现的常见问题，统一由技术支持人员收集、汇总和整理
后形成常见问题解决手册。 (2）文档编写
社保费征管信息系统系统面向群体广泛，问题受理渠道多样化，对此需通过对用户类型、问题性质、软件版本、问题描述、解决方案等维度进行全面记录存储，不定期对操作知识、技术标准、常见问题和典型案例等内容进行总结撰写，提供高级用户和支持服务人员自助解决问题的途径;另每月底负责进行本月运维报告的整理，月度运维报告的内容应包括但不限于：当月业务情况、历史月份业务情况、代扣代缴系统申报情况、历史月份申报情况、系统运行情况、问题处理情况及必要的分析等。
（3)培训指导
为了更好地让税务相关人员操作好XXXXXX系统系统，提高税局技术和业务骨干的技术和业务处理能力,根据采购方的要求,提供全年不超过 15 场次(不限人数）免费技术培训师资团队，培训老师需熟悉XXXXXX系统的操作流程及对个人所得税相关政策有比较全面的了解.
a.培训对象：税务人员。 b.培训方式：现场、视频均可。
c.培训内容：社保费征管信息系统相关系统操作使用、故障诊断、维护管理等方面，使之能适应系统正常运行的需要。
d。培训组织分工: 培训实施 具体步骤 税务局 师资团队 配合整理 培训对象梳理 确定名单 培训前准备 培训资料准备 内容审核及印刷 配合制作培训材料 培训场地联系 确定场地 培训通知 培训签到 会议主持 确定培训时间 \\ 作重要讲话 \\ \\ \\ 配合检查场地情况 \\ 引导签到，并提交签到情况 配合 现场辅导 现场授课 收集满意度,并提交给组织方 会议实施 现场辅导 现场授课 收集满意度 （4）数据查询统计
按采购方的需求，协助配合提供系统数据查询、数据整理的工作，运维人员及时响应分析、解决用户通过运维平台上报或技术支持电话反映的查询统计问题;根据省局处室提供数据统计、分析、出具报表服务服务包括：按照数据统计的要求或者报表的内容进行业务分析，确定各个数据项的统计口径，明确数据统计或报表内容的可行性；根据数据统计要求或者报表内容编写数据统计脚本;与数据保障管理人员确认统计脚本的执行安排,以保证统计结果按照要求的时限生成；根据数据统计结果或者报表的反馈意见，分析调整统计结果或者报表的相关内容。
1.1.2.2.3. 问题管理
(1）问题管理流程
系统进入正常运维阶段后，对运行保障提出了更高的要求。为进一步强化应用系统运行维护管理工作、提高效率，确保应用系统稳定、安全、高效运行，将使用运维管理平台对系统问题进行统一管理。
（2)问题管理流程说明
运维人员或税务人员在运维平台服务管理系统中录入问题单,当录入的问题单在省内或一线人员解决不了需要二线人员或三线人员解决时，各省将这类问题单通过运维平台填写好相关信息后上报到运维平台服务管理系统的问题流程中形成问题单，省级转派到二线运维岗进行评估分析，此时问题单的状态标志位为“待解决”。
二线人员对问题原因进行分析,如果可以直接处理，则处理问题后继续执行运维平台处理流程;如果属于程序类问题，需要由三线开发人员对系统开发层面进行调整优化，则将问题下发三线,此时运维平台中问题单的状态标志位为“已分派”。已分派的问题单可以继续在运维平台中流转。对已经下发三线的问题单，在运维平台中导出 ZIP 包，并在问题平台中导入,将问题信息录入到问题平台且转派三线人员进入相应处理流程，此时运维平台中问题单的状态标志位为“已导出\"。
三线人员受理问题单后，对问题原因进行分析、制定解决方案、评估解决时间并将以上分析计划内容维护到问题平台.对于问题平台中已经维护分析计划内容的问题单，二线人员应及时将问题内容导出为 ZIP 包，并在运维平台导入更新计划信息，导出的内容中,除了计划解决时间和状态，其他的重要信息例如：
事件原因分析、预计解决方案等都写入到一个文档中作为附件上传到运维平台对应的问题单中，运维平台问题单的状态标志位变更为“处理中”.
三线人员根据分析计划的安排对问题进行优化解决,并通过测试组测试通过,问题版本发布时，将问题上报。
二线人员将问题平台中处于上报状态的问题单导出 ZIP 包,并在运维平台中导入，更新运维平台中问题单的状态值为“已解决”.
问题提交人对问题验证不通过时，修改问题单的状态为“未通过”，由二线人员分析并重新下发三线，在运维平台导出 ZIP 包,并在问题平台导入,转派三线继续处理;对问题验证通过时，修改问题单状态为“已关闭”,二线人员将已关闭的问题单导出为ZIP 包, 并在问题平台导入. 1.1.2.2.4. 在线咨询支持服务
由于企业应用环境千差万别，应用水平参差不齐，缴费人在申报过程中必然需要大量的咨询服务和其他个性化服务.而面向全省所有缴费人，目前省局 12366 咨询热线（主要受理政策方面问题），尚不能完全满足我省缴费人客户端的咨询服务；为满足“有利于提高纳税人用户体验、有利于系统稳定平稳过渡、有利于税改工作的整体顺利推进”为总体部署要求,使扣缴单位掌握XXXXXX系统扣缴客户端相关业务知识、系统安装与操作、系统重大升级变化内容，在电话咨询服务基础上，采用在线咨询的方式相结合,提供客户端咨询服务,确保缴费人的疑问、故障等第一时间得到有效解决.
（1)服务方式
在工作时间,提供服务人员，为缴费人提供人工在线咨询服务，工作时间与西藏自治区税务局作息时间保持一致。
在非工作时间，以机器人智能问答的形式，为缴费人提供咨询服务。 (2）服务内容包含但不仅限于以下内容： a。在线咨询
在工作日内，提供人工在线咨询服务，主要负责解答用户在使用单位社保费管理客户端时遇到的相关问题；其任务包括受理缴费人及用户在线提出的咨询、意见、建议、批评、投诉和一般性求助，同时对受理问题的解决情况进行跟踪服务。
在非工作时间，以机器人智能问答的形式，为缴费人提供咨询服务。 在线咨询服务人员即时受理用户在线提交的各种问题，实事求是、高效快捷地进行办理和解答；在服务时使用礼貌用语进行解答，并做好记录工作。
b。热点问题
根据在线咨询内容进行不同处理，并归纳、记录、整理。就其中咨询量大的问题,应整理提供标准答案,并通过“热点问题”的形式进行展示，供广大缴费人学习掌握，以提高其使用XXXXXX系统扣缴客户端的熟练程度。
c。 .资讯中心
提供“资讯中心”服务，为本省缴费人提供和社保费相关的实时资讯。“资讯中心”主要为当前最新的税局要闻、业务点评、业务风险等相关内容.缴费人点击相关内容链接后,可方便地使用默认浏览器打开“资讯中心\"相关内容页。
d.知识查询
提供“知识查询\"服务，为本省缴费人提供社保费相关的学习知识点。“知识查询”主要为个人所得税业务的具体知识分类，包括：政策法规（中央、地方）、各类分项所得解读、税收减免优惠、征收管理等。
缴费人点击相关内容链接后，可方便地使用默认浏览器打开“知识查询”相关内容页。
（3）服务工具
我司将提供上述内容所需的点播流量、硬件支撑，和一款专业咨询服务工具作为上述服务的载体,用以覆盖互联网在线渠道咨询。 1.1.2.3. 服务要求 1.1.2.3.1. 系统可用性
系统可用性要求达到 99。99%，即在非自然灾害、外在不可抗力、停机升级等因素外，365*7*24 小时均需保障系统业务正常办理,若出现故障情况，需按问题响应要求及时解决并恢复业务正常办理；可用性管理的作用是确保所有设计的 IT 服务均能以连贯且符合成本效益原则的途径实现业务所需的可用性水平。通过优化 IT 基础架构、服务以组织的能力，从而提供最有效的、最稳定的服务可用性，来最大化的支持业务的正常运行，实现业务的目标。 1.1.2.3.2. 问题响应
一般系统故障（某些功能间歇性不可用或在某个场景下系统业务中断或业务缓慢导致的无法正常办理 1 小时以下），现场技术人员 2 小时之内解决问题；
对重大问题提供现场技术支持(系统业务中断或业务缓慢导致的无法正常办理 1 小时以上），2 小时内到达指定现场， 8 小时内解决,问题与技术支持要求解决后 24 小时内，提交问题处理报告，说明问题种类、问题原因、问题解决中使用的方法及造成的损失等情况；
对用户提交的系统运行问题及时予以响应，进行分析定位；其中操作类问题应三天内解决，数据类问题应在一周内解决，需修改软件的问题应按税务总局要求及时上报；
紧急问题根据招标人要求通过紧急补丁解决(补丁由招标人提供）。 1.1.2.3.3. 运维规范
需要在 ISO20000 运维服务规范、遵循国家税务总局以及西藏自治区税务局相关运维管理办法和规定，在指导西藏自治区税务局的指导下建立可靠的运维保障体系。
1.1.2.3.4. 运维管理信息化
社保费征管信息系统整体规模较大，节点较多,系统监控、日志管理、发布管理都需要通过自动化的工具完成对此需要一套运维管理工具（由我司自行提供，服务期满后需提交可通过通用软件(如：wps 等）打开的系统监控记录、运维日志、问题解决知识库等）来支撑运维规范的执行监督。 1.1.2.3.5. 服务方式
我公司安排服务人员进驻采购人指定地点提供现场服务，通过建立健全科学高效的运维服务机制，综合采用热线电话、QQ 服务群、邮箱和运维平台等方式提供运维服务。 1.1.2.3.6. 服务时间
（1）正常工作日时间要求：运维人员工作时间要求与采购人办公时间保持一致。
(2）非工作日服务要求：在非工作日期间，运维人员必须按照采购人要求提供运维服务，可以采用远程方式提供服务,但对于远程方式不能解决处理的必须按照要求及时提供现场服务;法定节假日期间,中标人需在放假最后一天安排人
员对本项目涉及的主机、存储、网络、应用系统等软硬件环境进行全面检查，及时解决存在的问题，确保收假后正常上班期间本项目软硬件环境的正常运行，提供电话值班.
（3）根据税务总局要求提供特殊时间段的 24 小时值班。 1.1.2.3.7. 运维服务监督
我公司认真根据全省运行维护服务需求制订全省切实可行的运维服务方案，并严格根据运维服务方案为全省切实提供可靠的运维服务保障,同时在服务期间还必须注意及时根据全省各地实际需要进一步持续动态补充健全。
我公司每月按照采购人的统一要求及时报送运维服务工作报告及相关资料，工作报告应包括系统运维综合情况、存在问题和改进措施等核心主体内容、且内容必须详实具体，以确保全省运维服务切实发挥积极作用并得到持续优化及提升。
1.1.2.3.8. 保密原则
项目相关人员在未经过采购人书面批准的情况下，不得将任何采购人认为涉及数据安全的观点、数据、系统结构信息、测试结论以及测试记录传播、披露和使用。未经采购人同意，中标人不得擅自修改任何程序和数据。 1.1.2.3.9. 履约要求
以上采用列举方式对本项目涉及的主要服务内容进行了具体约定，本项目服务内容应包括但不局限于以上已列举部分，原则上对于本项目涉及的应用系统上线运行中产生的问题全部属于本项目运维范围，我公司按照采购人要求提供运维服务,不得以非正当理由拒绝。 1.1.2.4. 服务时间
1 年，签订合同约定起止时间。
1.1.2.5. 人员要求
我公司人员配置至少包含 6人,分别如下:
（1）项目经理 1 人：负责项目运维现场的项目管理和应急保障支持及管理、技术协调接口人。
(2）驻场运维工程师 5人：负责现场系统运维及技术支持，包含：
b、2技术支持工程师（负责应用系统、问题处理、数据查询等,需具备 Oracle相关认证及 Linux、weblogic 相关工作经验）。
b、3 名技术支持工程师（负责应用系统、问题处理、数据查询等,需具备 Oracle相关认证及 Linux、weblogic 相关工作经验）.
4.2.运维人员学历年限要求和专业技能要求如下：
（1）要求计算机及相关专业毕业,大专以上（含大专）学历、具有一年以上运维工作经验。
（2）了解相关政策法规、业务知识、系统架构、系统功能、数据库、中间件等。
（3）熟悉系统操作流程。
（4)具备良好的沟通能力和服务技巧，能够准确判断用户问题. （5)具有独立解答所支持的应用系统咨询问题的能力.
（6）具备根据知识库或在其他高级岗位指导下解决应用系统一般性问题的能力。
(7)遵纪守法,诚实守信，无不良记录，待人处事得体，严于律己. (8)工作热情、有责任心、具有团队合作精神，耐心细致,待人处事得体，严于律己。
1.1.2.6. 服务数量、项目交付或者实施的时间和地点
1。服务数量：XXXXXX系统（个人所得税管理信息系统）驻场运维服务 1 年。 2.项目交付或者实施的时间:合同生效后 2 日内进场服务.
3。项目交付或者实施的地点：国家税务总局西藏自治区税务局办公地点，必要时需延伸至西藏自治区税务局境内税务系统各单位。 1.1.2.7. 验收标准
1。验收方式及时间
初验:采购人按月考核我公司提供的各项服务，若有未达到服务要求的，采购人将给于警告一次，每累计三次警告的，采购人将扣减履约保证金的 10%，直至扣完履约保证金。
终验：服务期结束 10 日内，验收由采购人现场组织,我公司配合进行。 2.验收标准
国家有关规定、本项目须执行的税务系统信息化建设及运维的相关标准或规范，以及招标文件明确的各项服务质量及具体技术指标要求、我公司投标文件及承诺。
验收争议事项解决：双方对质量要求和技术指标的约定标准有相互抵触或异议的事项，由采购人按服务质量及技术指标要求有利于采购人的原则确定验收标准进行验收.如验收合格，双方签署验收合格报告.
3。验收内容及提供的资料（按月/年度进行，需提供下列材料)包括但不限于以下内容：
*服务工作记录 *服务工作总结 *系统巡检报告
4. 验收时供需双方均须派人参加，并共同完成验收。
1.1.2.8. 服务的承诺 1.1.2.8.1. 服务期限
本项目免费服务期为1年，自最终验收合格之日起开始计算。 1.1.2.8.2. 服务形式
我公司为本项目建立独立的售后服务和技术支持组织，并按照国家税务总局西藏自治区运维体系建设要求，服从招标人的统一调度和管理。
1）驻场服务
终验后我公司将提供5人×1年的技术人员驻采购人工作现场免费运维和技术支持服务，并提供与驻场支持服务人员配套的内部支持体系，与驻场支持服务人员进行衔接,以确保现场支持工作的有效进行,保证服务质量。
2）远程技术支持
我公司将向采购人提供电话、电子邮件和网站技术支持方式对软件使用过程中出现的各类问题进行免费解答，确保用户能够在互联网站上查询、下载相关技术资料、提交问题并获得支持。电子邮件至少需当日回复。 1.1.2.8.3. 服务响应
1) 对系统故障，我公司接到用户技术支持请求后，现场技术人员需30分钟之内作出实质性响应，1小时之内解决问题；如现场服务人员无法解决，我公司将指派后台高级工程师在2小时内到达故障现场,在报修8小时内恢复采购人系统的正常运行,恢复系统正常运行。
2) 我公司在问题解决后24小时内,提交问题处理报告,说明问题种类、问题原因、问题解决中使用的方法及造成的损失等情况。 1.1.2.8.4. 服务策略
我公司在企业的高速发展中,累积了丰富的系统集成经验、储备了大量的系统集成高素质人才，本着服务是企业生存的命脉、以优质的服务赢得用户、为用户解决实际问题为根本出发点，已经形成了一套完备、优质、快捷的服务体系,包括:
1）服务提供者 2）服务地点
3）服务时段 4)服务响应时间
5)服务内容等若干服务要素。 1.1.2.8.4.1. 组织体系
我公司为确立这种服务体系，设置了一整套的服务组织机构。如下图所示：
1.1.2.8.4.2. 售后流程
项目成功的根本标志是客户满意，它贯穿软件项目的售前、售中和售后全过程。我们认为客户满意是一个实在的可以度量的目标 ，确保软件项目达到客户满意,尤其确保软件项目交付后长期的售后服务过程中的客户满意，使售后服务与项目承诺不脱节，有三个基础环节作为组织级支撑和保障，即组织级基础设施的保证；规范化的过程流程的保证和具体项目实施过程中监控与反馈机制（工具）的保证.
质量管理体系在软件项目生存周期内作用于三个基础环节，管理控制每一个项目作用域内的相关活动。使软件项目的售后服务受控于质量管理体系。
1.1.2.8.4.3. 服务措施
技术支持和服务的工作范围
技术支持和服务的工作范围主要包括运行管理、系统维护和技术支持工作. （一）运行管理主要工作 1、系统总体运行;
2、分析、研究并提出进一步的应用需求； 3、各种规章制度的建立； 4、各参与单位的协调； 5、系统的监督控制; 6、系统的安全管理； 7、技术培训的组织; 8、业务咨询；
9、系统权限分配及权限变更审定等。 （二）系统维护和技术支持主要工作
系统维护工作关系着系统能否在遇到问题的时候顺利的运行下去，而我公司技术服务中心联合研发中心将以多种技术服务的形式为用户提供积极、快速、准确、高质量服务.主要工作内容有：
1、系统使用操作指导和管理指导
由于系统使用环境的变化和用户的计算机水平参差不齐，即使用户通过了培
训掌握了该系统的使用、管理和配置等技能，但是用户在开始使用系统的时候，在遇到紧急的情况下也迫切的希望得到技术支持中心的服务.对此，我公司技术支持服务中心将急用户所急,想用户所想,以多种技术服务的形式，积极、快速、准确、高质量的为用户正常使用系统和管理系统提供技术支持。
2、预防性维护
技术支持中心将定期对系统和新设备进行巡检，提出有关系统调整、优化、故障预防等建议,及时发现潜在的问题,提高系统的运行效率。
3、改正性维护
由于系统测试不可能暴露出一个大型软件系统的所有潜藏的错误，这些隐藏的错误将在某些特定的使用环境下会暴露出来.所以当用户在使用系统时,发现了潜在的bug应详细记录发生该bug时的运行情况和环境特性并及时报告给技术支持中心，技术支持中心将派遣工程师到用户现场服务并解决用户提出的问题.
4、维修性维护
当发生一些不可预知的情况时，当系统的硬件设备、系统软件、应用软件等发生了故障，请用户及时和我公司技术服务中心联系，技术服务中心将快速响应并将投入精兵强将对系统进行维护，在最短的时间内使系统恢复正常运行。
5、适应性维护
随着计算机的飞速发展,外部环境（新的软、硬件配置)或数据环境(数据库、数据格式、数据输入/输出方式、数据存储介质）可能发生变化.当用户希望软件适应这种变化，技术支持中心将联系研发中心的软件工程师到用户现场服务对用户提出的需求进行调研和分析，并对系统进行适当的修改，以满足用户的要求. 1.1.2.8.4.4. 组织保障
为了保证系统的持续、可靠运行，提供有力的组织保障。我公司将组织多人专门技术力量成立运行维护组，在业主方的领导下，负责本项目的运行维护和技术服务。
在项目维护支持过程中，首先由运行维护组提供强大的技术支持；运行维护组根据技术任务的复杂程度，为用户提供最快捷的服务，在需要时由运行维护组负责人调派技术支持中心专家和研发实施工程师。 1.1.2.8.4.5. 售后服务组织人员及职能
职位 分管副总 部门经理 职责 人事、行政、制度决策 管理部门日常事务，制度并监控部门规范及标准化流程的执行 服务一线售后服务工程师的技术培训及指导 售后服务回访，服务质量评测、考核 硬件产品的日常售后服务工作管理 受理客户故障申报、故障分析、派工、区域日常维护资料统计回报 接受公司派工，进行日常售后服务工作 服务支撑中心 服务质量监督小组 维护项目部 市、区域维护负责人 售后服务工程师
1.1.2.8.5. 技术支持服务工作方式 1.1.2.8.5.1. 电话、传真服务
我公司将免费为用户提供7天*24小时的热线电话及传真支持，如果用户使用的系统出现技术故障，无论是软件、硬件，都可以通过热线电话得到支持与帮助。用户只需仔细记录故障现象，然后通过服务热线与我们联系，技术专家在尽可能短的时间内协助和指导客户方制定解决问题的方案，然后由用户反馈给我们解决方案是否有效，我们会依据反馈信息决定进一步的支持措施.
您的问题将以“技术支持请求”(Technical Assistance Request，TARs）的形式记录于我公司客户支持系统中，由专门工程师负责。
请求服务流程如下:
TAR技术支持登记Technical AssistanceRequest登 记完成完成完成处理未完成TAR升级未完成厂家支持中心
1.1.2.8.5.2. 远程在线诊断和故障排除服务
如果条件允许，在得到用户许可的情况下，我公司将为客户提供远程登入(Telnet）、远程访问、远程监控服务，以及时、准确、全面了解客户系统运行状况,发现其中存在的认识误区和隐蔽的错误，从而更直接、快速地为客户免费的排除故障，解决问题。 1.1.2.8.5.3. 现场响应服务
自收到用户的服务请求后，对于通过电话无法解决的问题，我们将根据故障的严重程度，派遣技术支持中心的工程师到用户现场服务.如果遇到重大技术问题，我们将及时组织有关技术专家进行会诊.公司将通过备品备件库为用户提供满足相应功能的替换设备，保证用户整个系统的正常运行。同时我们将每年定期对用户进行回访，技术工程师将帮助用户在现场进行系统维护，包括：
1）系统状况检测
根据用户的运行记录和系统的运行日志，对软件、硬件的状况进行检查，及时发现并解决潜在的问题。
2）系统升级或修补
根据行业发展和产品厂商提供的支持，定期对系统性能测试及调整，解答用户与系统维护有关的问题，了解用户对服务的满意程度和新的需求. 1.1.2.8.5.4. E-Mail服务
公司将充分利用Internet为客户提供内容丰富的技术支持服务:
协助安装：特定产品的逐步安装指导,安装手册，版本注意事项，README文件等.
热门话题:介绍最新的产品，技术，应用，特定的产品警示，重要的通知。 产品参考：包括产品文档,技术支持布告，白皮书等. 问题解答：为客户提供详细的解决方法,提供重要的补丁等。 1.1.2.8.5.5. 印刷品信息服务
公司在支持服务有所改动或变更,或是认为某些技术特性应告知客户时，将给客户寄发印刷品信件进行通知，以维护客户的权益. 1.1.2.8.5.6. 技术讲座
公司会一丝不苟地为用户提供咨询与技术支持工作，不定期为用户举办专题技术讲座，技术研讨会。我公司的软件、硬件技术人员将把自己的实践经验，研究心得与客户交流，同时为客户提供新产品技术的发展动态。 1.1.2.8.5.7. 电话巡访和用户走访
公司技术服务中心将派遣软、硬件技术支持工程师定期或不定期到用户现场走访，帮助用户进行软、硬件系统状况检测，了解设备的运行情况,听取意见和建议，帮助用户进行预防性的维护和提供软、硬件的升级服务。解答用户与系统维护有关的问题，了解用户对服务的满意程度和新的需求。 1.1.2.8.5.8. 本地化服务模式
若中标我公司将本省设立本地化服务团队，所以针对本工程项目,我公司能够提供有效、稳定、可靠的本地化服务。 1.1.3. 服务团队组织安排计划 1.1.3.1. 团队建设
对参与本项目的技术人员进行统一的管理和调配，并协调各个团队成员的活动，使他们作为一个和谐的整体,适时履行其各自的工作。 1.1.3.1.1. 运维人员配置
我方承诺为本项目投入至少6人的运维服务团队,各岗位要求如下： （1)项目经理1人：负责项目运维现场的项目管理和应急保障支持及管理、技术协调接口人.
（2）驻场运维工程师5人：负责现场系统运维及技术支持，包含：
a、2名技术支持工程师（负责应用系统、问题处理、数据查询等，需具备 Oracle相关认证及 Linux、weblogic 相关工作经验）。
b、3 名技术支持工程师（负责应用系统、问题处理、数据查询等，需具备 Oracle相关认证及 Linux、weblogic 相关工作经验).
运维人员学历年限要求和专业技能要求如下：
（1）要求计算机及相关专业毕业，大专以上（含大专）学历、具有一年以上运维工作经验。
(2)了解相关政策法规、业务知识、系统架构、系统功能、数据库、中间件等。
(3）熟悉系统操作流程。
(4）具备良好的沟通能力和服务技巧，能够准确判断用户问题. （5）具有独立解答所支持的应用系统咨询问题的能力。
（6）具备根据知识库或在其他高级岗位指导下解决应用系统一般性问题的能力。
（7)遵纪守法，诚实守信，无不良记录，待人处事得体，严于律己。 （8)工作热情、有责任心、具有团队合作精神，耐心细致，待人处事得体，严于律己.
1.1.3.1.2. 运维人员要求
西藏自治区税务局可根据工作需要,结合本项目具体情况对技术支持人员配置和工作场地进行调整。投标供应商派驻西藏自治区税务局运维工程师应满足以下要求：
学历经验要求：本科学历,两年以上相关工作经验.硕士研究生学历，一年以上相关工作经验。（提供相关证明材料）
熟悉linux、windows操作系统的管理和维护、精通oracle数据库、中间件和Tomcat的管理、维护和调优。
具有系统运维工作经历,熟悉决策支持二包软件系统架构和相关技术、数据库表结构和相关系统的业务知识.
具有独立分析、定位和解决系统问题的能力，并能指导其他人员判断和解决问题.
有文档起草、修订等文字处理能力。
遵纪守法，严于律己,诚实守信，待人处事得体 ，无不良记录。
工作有热情、有责任心、具有团队合作精神,有良好的沟通能力；具有良好的表达能力、自控能力和应变能力;工作具有计划性，能够制定项目计划，善于对工作进行总结和分析；具有较好的管理和组织能力。 1.1.3.2. 项目管理
1、通过制订运维工作计划，分解任务,确定任务优先级,合理利用资源，对于工作中的难点、风险点及时向用户以及公司领导反馈,并获取相关支持。
针对本次项目我公司结合客户要求做出如下运维计划：
序号 1 2 3 4 5 6 7 8 9 10 11 12
2、通过指导项目组成员工作，确保项目组成员能够履行各自职责，对项目阶段任务的完成和质量负责。并对项目及成员的绩效进行考核；
3、保证运维工作效率与质量,注重项目成员专业技能成长，形成良好的
名称 XXXXXX系统运维周报 应用服务器监控 数据库服务器监控 OGG同步监控 数据汇集同步监控 数据库系统运维 中间件系统运维 问题报告 月总结报告 季度总结报告 年总结报告 系统定期升级发布 人员 驻点工程师 驻点工程师 驻点工程师 驻点工程师 驻点工程师 驻点工程师 驻点工程师 驻点工程师 驻点工程师 驻点工程师 驻点工程师 驻点工程师 周期 每周 每日 每日 每日 每日 每日 每日 问题解决后 每月 每季度 每半年 每月 知识传递机制，并及时进行知识归集与整理.
4、按照各自负责的运维模块和替代关系确定职责范围,根据事件单数量的变化进行人员职责微调，降低项目组对核心成员的依赖度
5、与其他各驻场软件厂商之间保持协作与配合甲方管理。
6、通过严密的运维工作风险管理，评估并应对该系统在业务上、技术上对于采购方税收业务管理可能出现的各类风险问题，并及时向甲方报告。 1.1.3.3. 沟通管理 1.1.3.3.1. 信息传播
针对不同需要沟通的场景，确定不同沟通类型，如书面、口头等方式，确保信息的正确的理解和执行. 1.1.3.3.2. 执行报告
通过项目周例会、项目周报、月报等方式定期描述项目已完成工作、当前现状、未来工作情况预计以及风险。 1.1.3.3.3. 项目总结
通过里程碑总结、阶段性总结、项目总结等方式对整个项目进行总结，不断提升项目服务质量. 1.1.4. 工作流程 1.1.4.1. 问题跟踪管理 1.1.4.1.1. 程序bug管理 1、概述
对在程序运行过程中存在的程序bug进行跟踪管理。 2、管理流程
(1）用户在使用软件过程中，发现存在的问题，并详细描述操作过程和现象.用户整理问题清单，填写《程序bug管理清单》，提交给国税局项目组,项目组提交给我公司维护组负责相关模块小组组开发经理。
（2)开发经理根据用户反映的情况，布置模块负责人查找原因,并做好bug记录和情况分析，在接到问题清单一个工作日之内给与国税项目组答复，确定问题原因。
（2）开发经理和国税项目组该模块负责人确定修改完成计划。
(3）模块维护人员根据修改计划修改完毕并自我测试后，提交测试组进行测试。 （4）测试组通过测试后，发布到测试机，提交用户测试。 （5）用户测试通过并签字后，双方项目经理确认,发布到生产机。 （6)发布完毕后，由客户通知最终用户bug修改完毕。
(7）模块维护人更新问题管理清单,描述问题存在的现象，解决方案，以建立维护知识库，为以后快速解决问题提供方便。
（8）《程序bug管理清单》将跟随问题流转直到问题关闭.
（9）开发经理有义务监控整个流程,并定期向客户报告问题解决的状况。此流程执行情况将受到项目经理、QA和客户模块负责人的监控。 程序bug管理清单 序试点局问题描述 试点局开发公
项目组验证号 确认情况 备测试模具块体名功称 能 环境/真实环境 问问题题描类述 别 提提出出时部间 门 应优先级 联系人 急处理情况 注 （可填写解决建议） 是否当场解决 程试序点是局否测已试发结布 果 司反馈情况 情况 程反馈结果 责任人 反验馈证时结间 果 验证人 验序证是时否间 发布 1 2 3 1.1.4.1.2. 程序性能优化管理 1、概述
程序在上线以后，处于一个不断优化改进的过程。针对数据量的不断变化,在程序运行过程中，不断优化程序的性能. 2、性能优化管理流程
（1）在系统运行过程中，通过对应用服务器和数据库服务器性能检查,客户或者程序员发现某模块性能上需要改进,形成文档《性能问题清单及解决状况》，描述操作过程和程序表象.
（2）国税和公司相关模块负责人，共同查看相关模块程序，并共同分析是否程序有待优化和改进。
(3）如果需要优化和改进,开发经理和模块维护人制定优化计划，进入计划管理环节。
(4)优化完毕后，模块维护人自我单元测试。模块维护人自我测试通过，开发经理检查修改情况，确认合格，则提交给测试组测试。
（5）项目测试组进行性能测试。如果测试通过，则发布到测试机。
(6）用户测试优化后的程序，确定合格，则发布到生产机,如果是程序员自主优化性能的,则通过测试机的测试后直接发布到生产机.
（7)模块维护人更新问题管理清单,描述优化前存在的问题，优化解决方案，以建立维护知识库。此流程结束. 表－性能问题清单及解决状况 问题描述 分析 解决方案 状态 解决状况 Open或者close 1.1.4.2. 客户问题管理 1、概述
在维护过程中，客户由于对业务的理解和操作的原因，存在非程序原因的问题，并且由于误操作造成存在垃圾数据,需要维护人员对客户提出的问题提供解决办法，甚至手工处理数据。因为运行维护工作是一项长期而系统的工作，为了高效快速地解决用户的疑问,建立客户问题档案，以更好地为国税服务。 2、管理流程
（1）记录用户每次提出的问题，分模块做好记录。如果接电话的人无法当场找到相关模块的负责人,必须详细记录用户的问题，并且承诺给用户回答的时间.在第一时间找到相关模块负责人后,需要立即通知模块负责人问题情况，并有义务督促他回答用户。
（2)模块负责人根据用户的问题，提供解决方案,并且详细记录用户的问题、解决方案，并作为维护知识库。
（3）相关开发经理,有义务抽查问题回答和解决情况，并且对相关用户做回访。
1.1.5. 进度计划及保证措施 1.1.5.1. IT服务体系的建立
我公司作为国内积极参与各类信息化建设的企业之一,长期以来积累了丰富的技术支持和运维服务经验,始终视服务为企业生存与发展的生命线,优秀的服务理念成为我们在激烈市场竞争中所体现的鲜明特色。 1.1.5.1.1. IT服务体系整体结构
只有高效、稳定、个性化的本地化服务模式才能满足用户随时随地的服务需求;也只有迅速的维护响应才能真正保证用户的利益不受损害。因此我们在自身服务体系的基础上，针对本项目，特定IT服务体系，由响应体系、维护体系和质量监督体系构成，见下图所示:
客户需求质量监督体系响应体系维护体系质量监督体系
1、客户需求
在服务协议规定范围内的任何服务请求,包括咨询、问题申报、投诉等。 2、响应体系
第一时间受理客户的需求，以最快的速度解决问题,保障客户系统尽快恢复正常。
3、维护体系
对客户系统进行主动式服务，发现并解决系统隐患，优化系统性能，并提出合理的改进和升级建议。
4、质量监督体系
为保障服务的质量制定相关的服务协议，通过满意度调查等方式评估服务的提供是否正常.
IT服务体系最终都可以通过本次项目建设的ITIL运维体系落实,响应体系对应ITIL运维体系的“事件管理”，维护体系对应ITIL运维体系的“问题管理”，质量监督体系则通过“运维管理\"来实现。 1.1.5.1.2. 响应体系
响应体系包含服务台和突发事件管理，主要任务是受理客户的服务需求，尽快恢复客户系统的正常运行。
客户有问题可以通过热线电话、Email与服务台联系，服务台负责接听技术服务电话、受理客户问题，进行记录，分类并转给相应的工程师处理。二线工程师负责处理服务台分配的事件或问题，当二线工程师需要技术支持时,可以从公司总部获第三方获得到技术支持和实验室环境支持。 (一) 故障(二) 服务请(三) 响应方式、时间 级别 一级故障 求时间 7×24 服务台接到服务请求后，即刻响应，服务人员工作时间内马上到达现场,非工作时间1小时内到达，进行现场服务。 二级故障 7×24 服务台接到服务请求后，对于电话未解决故障，15分钟内再次回应，提供电话技术支持，工作时间内服务人员1小时到达现场。 三级故障 7×24 服务台接到服务请求后，30分钟内再次回应，提供电话技术支持，工作时间内服务人员2小时到达现场，或与用户协商 1.1.5.1.3. 质量监督体系
为保障向客户提供的服务准时高效,质量监督体系是必须的。运维团队和客户将按照合同的要求，共同制定服务协议书中的各项服务水平要求,以监督保障所提供的服务质量。
质量监督体系的主要工具是满意度调查，衡量的标准即双方认可的服务水平要求。
满意度调查制度及时了解客户对我们事件处理情况的重要手段。也是我们不断改进、完善服务的渠道。
服务满意度调查制度同响应体系事件的调查制度一样，技术服务中心将协同客户一起定期对提供的服务进行全面的满意度调查，以此来提高服务的质量.
满意度调查结果与服务工程师的当期绩效考核挂钩，作为工程师个人业绩评价的参考数据之一。 1.1.5.2. IT运维体系的建立
ITIL提供了一个概念化、模块化的优秀框架，与其说是解决方案,不如说它更象理论。它提出了建立IT服务管理体系时要考虑哪些流程，提到了应该做哪些，好处在哪儿，但并不详细介绍怎样去做,因此它本身不具备实际操作可能性.
我们在长期的运维项目中积累的丰富的经验，根据项目的实际情况,对ITIL进行适当选取、适应和扩展：
导入ITIL是一个长期过程，运维运维初期，以“系统日常运行和支持”为主，重点解决服务支持（Service Support）流程，对发生的问题进行维护和处理。在运维后期,运维的服务支持流程步入正轨后，再关注运维服务的长期计划和改进，考虑服务提供（Service Delivery）。
针对XXXXXX系统，运维的主要任务是解决发生的问题，对IT基础架构进行基本的配置管理，因此主要实现“服务台”、“事件管理”、“问题管理”和“配置管理\至于变更管理在实际运维中，暂时没有系统工具支持，放在后期在规范流程,并用信息系统化实现.
由于初期运维工作内容多，系统繁杂，人员少,为提高运维人员解决问题的能力和效率，运维体系扩展加设“知识库”，以提高运维技术的积累、传承、利用。
XXXXXX系统运维体系设置“服务平台\"统一接受各种故障受理，包括最终用户直接电话或邮件传来的求助信息和运维监控软件过来的自动报警信息，然后服务台问题分析并归类，力求初步解决用户或系统的故障；不能在线解决的需求问题,启动“事件管理”和“问题管理”流程，运维人员按照既定的流程，在“知识库”和“配置管理”的支持下，解决故障，并把积累的经验知识归入知识库。问题解决后，运维体系反馈于IT系统，促使其更好更稳定运行,并促进其优化和完善。
其中，“知识库”和“配置管理”可以依托运维监控工具实现信息化作业,而“服务台\"、“事件管理”和“问题管理”则仍然依照对应的制度人工操作，暂时没有信息化系统辅助运行,可以考虑在后期建设运维平台时优先实现。
所有的事件都应该基于影响度、紧急度和优先级进行分类分级，并提供相应的解决方案和临时方案。 故障级别 一级故障 服务请求时间 7×24 响应方式、时间 服务台接到服务请求后，即刻响应,服务人员工作时间内马上到达现场，非工作时间1小时内到达,进行现场服务。 二级故障 7×24 服务台接到服务请求后，对于电话未解决故障,15分钟内再次回应，提供电话技术支持,工作时间内服务人员1小时到达现场. 三级故障 7×24 服务台接到服务请求后，30分钟内再次回应，提供电话技术支持，工作时间内服务人员2小时到达现场，或与用户协商 注： 故障级别描述：
一级故障是指系统发生严重故障,业务发生中断，或虽然业务未中断但已经无法保证及时、正确的情况，对用户业务的运行有严重影响。
二级故障是指对于系统发生的非严重故障，业务并未中断,业务仍然及时、正确的情况，但性能有所下降。
三级故障是指系统发生轻微的故障，系统有警告信息等，对系统没有较大影响的故障。
1.1.5.3. 系统运维制度建设
在信息化运维中，制度建设是一道必要的保障。信息化不能一蹴而就,在信息化发展到一定阶段，建设重点应该要从系统实施转向以应用运维提升为主，运维质量保障、安全机制变得重要起来，这时除了技术的保障以外，制度保障越显得重要。
对于IT运维团队来说，可从以下几个方面来进行IT运维制度化: （一）转变运维观念，树立规范化意识。树立只有建立制度化的IT运维意识，才能在日常繁杂琐碎的工作中有效的区分任务的优先级，将有限的资源投入到最能满足“客户”需要的工作中.
为保证运维工作，把运维工作和制度化紧紧地捆绑到一起。运维工作很琐碎，关键在于规范而不是创新。只有各级运维技术人员一丝不苟、老老实实按规范做,才能够把事情做好。
（二）建立事件处理流程，强化规范执行力度。首先需要建立故障和事件处理流程，利用表格工具等记录故障及其处理情况，以建立运维日志，并定期回顾从中辨识和发现问题的线索和根源。建立每种事件的规范化处理指南，减少运维操作的随意性，在很大程度上降低故障发生的概率。
同时，建立IT运维制度非常重要，但是有了制度还要有人去执行，要强化执行制度比建立制度更重要的观念和意识。 1.1.5.4. 运维管理机制建设
“三分建设，七分管理\"，我公司采用多重管理制度，并加强沟通机制，力求完善建设ITSM中的服务监督体系。 1.1.5.4.1. 升级管理机制
升级管理是突发事件管理的重要组成部分。“事件跟踪”将记录从受理用户问题到派单过程中相关人员所做的处理和建议，保证信息的正确传递,记录内容将做为我们向用户提供服务及分析和衡量服务水准的依据。
我们将通过服务系统监控事件的全过程，直至服务结束。当出现的问题在承诺时间内无法有效解决时，“事件跟踪”会自动启用逐级上报升级管理流程,该流程旨在能真正起到督促问题快速有效解决的作用.我们将和用户一起共同制定出适合社保费业务需求的升级流程并指定相应的人员来监督流程的实施.
1.1.5.4.2. 报告系统
我们将按采购方要求定期提供标准报告。 突发事件管理报告
确保用户的电话被接受、解决并记录,服务范畴之外的问题也会转至第三方.突发事件管理着眼于解决问题的快速，解决问题的高质量，确保用户的满意度并达到承诺的服务级别。突发事件的出现和解决方法将体现在定期的服务报告中。
问题管理报告
我们将对重复发生的，主要的突发事件进行问题管理，诊断问题的真正原因。问题管理着眼于获得系统的高可靠,避免问题的再度发生,赢得用户高满意度，达到承诺的服务级别。经常出现及主要的问题,及相应的解决方法将体现在定期的服务报告中.
报告内容包含重点问题分析、潜在服务隐患、优化建议等信息。 1.1.5.4.3. 月、季度总结机制
我们每月、每季与采购方召开总结会，共同讨论前一月或季度的服务执行情况。会议时间建议在该月、季度结束后、下一周或每月10日之前，具体时间可以与采购方协商确定.会前双方应沟通和确定议程并在会前提供必要的报表和报告。
会议主要回顾从上次会议结束到本次会议前一天,我们所提供的服务的绩效，同时讨论和达成为改善服务必须采取的改进措施和行动步骤。 1.1.5.4.4. 客户满意度调查系统
以目前的客户满意度调查表格为蓝本，与客户共同协商适用于客户的调查选项、格式和方法。下表仅供参考，以和用户协商后的调查表为准。
开始时间 对主机设备使用评价 对网络设备使用评价 对运维服务人员评价 结束时间 □好 □较好 □ 一般 □差 原因： □好 □较好 □ 一般 □差 原因： □好 □较好 □ 一般 □差 原因: 对整体工作评价 □好 □较好 □ 一般 □差 原因： 评价人（签字）： 日期： 年 月 日 1.1.5.4.5. 事件信息发布通知
对于机房的服务事件，例如：设备维护、线路维护、网络故障或主机故障等，运维管理中心通知客户方，内容包括：
1、事件内容
2、事件类型(一般、紧急) 3、发生的时间段
4、影响范围（部分、全部） 5、客户应采取措施(如需要的话）。 1.1.5.4.6. 投诉管理
1. 用户可以书面或口头形式对我司提供服务的服务质量进行投诉。投诉的受理
和处理部门由双方事先约定;
2. 用户可以书面或口头形式对我司的各部门/各级员工进行投诉； 3. 设立投诉专线受理甲方投诉；
4. 在受理用户投诉后的8个工作小时内向投诉方提供第一份书面形式的投诉处
理情况报告。
1.1.5.5. 项目沟通机制建设 1.1.5.5.1. 内部团队沟通
在每个角色组或在特定系统工作的所有角色中每天或定期举行简短的会议，提供关键的或时间紧迫的系统和业务问题方面的更新和所需行动的更新。
客户可以根据需要浏览的相关信息和分阶段的操作统计数据，如正常运行时间、客户访问次数、行为趋势、开放问题等等.
在为从发布到生产所作的最后准备工作中与开发和部署组队一起举行的由开发组主持的会议。这一签收表示所有的开发组都已准备就绪。
实施阶段可以承担产品或系统的运行支持工作了,要分发和阅读（例如 e-mail 的格式编写)定期状态报告,提交给 IT 管理层,以及针对操作的关键绩效指标方面的业务内容（例如，依照服务级别协议的量度、服务台日志统计、项目目标实现进展等等）。 1.1.5.5.2. 外部客户沟通
同其他任何项目一样，有效沟通是事关本项目最终能否成功的非常关键的一个环节.鉴于项目本身的建设内容和牵涉到关系的复杂程度,沟通管理自然显得尤为重要，为此，必须从项目的干系人以及他们之间的工作关系和社会关系出发，详细分析项目所需的各种沟通环节，对其中最主要的沟通环节制定计划进行专门的管理，避免项目因为信息沟通不足而陷入困境或造成不必要的损失.
沟通分为三个层面即：执行层面，主要是各干系单位的工作人员就一些具体工作中涉及的配合问题进行沟通和交流；管理层面,主要是各干系单位的在本项目及其子项目的项目经理及监理单位，沟通的内容主要是有关项目执行中的重要事项、活动和决定；决策层面，主要包括业主领导、开发商领导、运维商领导等,沟通的内容主要是对项目进展过程中间碰到的重大问题的协调、重大事项的决定、重大事件的见证等。
为了实现充分沟通的目的,将主要设立如下沟通手段. （1）会议或交谈
按需要组织会议进行沟通，或直接找相关的人进行讨论,注意记录沟通和讨论结果。每次正式会议都要形成会议纪要,由项目组文秘做会议纪要，并分发到有关人员手中。
（2）工作联系单
联系单将处理项目执行过程中重要事项的决定、变更或者项目问题报告的多点沟通的一种正式的形式，一般在其他辅助手段沟通无效的情况下采用。联系单上须明确所联系事项的内容概要、紧急程度及其解决请求.在出具的联系单中，一般情况下主送业主或监理单位，抄送其他相关单位，并要求有关单位及时回复或者解决。在接到需我们解决或回复的联系单后，我们也会在第一时间给出答复或者采取行动。
项目实施期间所有收发的工作联系单都代表着项目执行过程中的重要活动的书面依据，都将作为项目执行过程中的档案进行整理存档，在项目终验时移交给业主。
（3）电话或电话会议
通过电话的方式进行信息沟通.对比较重要的事情，需要包括实施地点以外的人员，则需要利用电话会议的方式进行讨论，沟通.实践证明，电话是点到点沟通的最普遍和最常用的形式。
需要声明的是，对于项目中一些重大问题，仅仅通过电话沟通仍然是不够的，在电话确认以后，仍然需要以备忘录、联系单的形式落实到纸面，作为对这些问题的最后确认.
（4）书面报告、备忘录和传真
书面报告、备忘录和传真事点对点沟通的相对比较正式的手段，主要考虑用于对项目过程中的一些重要事件或方案的描述、质询等。
(5）电子邮件
作为现代办公的一种常用手段，电子邮件系统也将成为项目组内部以及项目组合外部沟通的一种非常重要而且高效的沟通手段，应该视为同书面报告和传真具有同等的严肃性。 1.1.5.6. 运维保障机制建设 1.1.5.6.1. 机构保障
建议双方联合成立运维领导小组,增强沟通协调，加强运维组织建设，建立稳定的运维团队。
在社保费征管信息系统运维项目启动阶段，我们将高度重视,并组织人员组建了筹备机构，由丰富经验的资深咨询人员及熟悉运维的工作人员共同组成工作小组，广泛研究国内外信息化系统运维经验，深入调研分析，“尽我所能”，无私奉献我们在大型项目建设及运维经验。
我们在承担此项目后，将成立独立的部门，采用专职部门、专人专职、专款专用等措施来保障该部门不同于公司其他的项目组织。 1.1.5.6.2. 人员保障
（一）运维优秀人员
本次项目，我们将按照采购人要求专门组建运维团队，使运维团队具备娴熟的技术和广泛的专业知识,系统运维人员具备高超的技能和丰富的经验。
（二）
核心人员备选
我们聚集了国内优秀的IT人员、管理人员，对于进驻核心人员，建立备份替补机制，备份替补人员随时可以入场开始工作.
（三）
凝聚人才的企业文化
我们一贯的企业文化，凝聚了大批优秀人才，使整体团队能保持工作激情,传承知识，从而创造一个高效、团结、和谐的工作环境。
我们所有工作人员在企业文化的洗礼下，具有良好的职业素质和道德品质，面对具有历史使命的工作任务，不会讲任何条件,作为战略合作伙伴，坚决服从采购方领导，服务好XXXXXX系统运维服务项目!
（四）规范管理规避人员流动风险
通过建立规范的软件开发管理、项目管理、IT服务管理、运维管理等管理体系，和科学的咨询方法等诸多知识体系，保障运维工作的开展，弱化个人能力对整个运维项目的影响,把人员流失造成的风险降低到最低。
根据我们以往的经验可以证明,我们有能力使人员流失的风险在可控范围内.
(五） 人员调动须经同意
本次项目的所有人员调离，都要和采购方协商，经采购方同意后方可进行. 1.1.5.6.3. 培训和技术保障
加强对运维人员的培训，提高技术保障能力，成功有效地实施和运营服务管理流程。除此之外，培训还有以下几个方面的作用：
1、促使所有相关人员清楚和理解ITIL计划和有关术语; 2、为相关人员提供讨论的平台；
3、为发现和减少可能的问题和不正确的实施方法提供了平台和知识； 4、帮助发现缺乏的技能并采取相应改进措施； 5、提供大量的培训流程所需的资源. 1.1.6. 质量保证措施
1.1.6.1. 服务质量、标准要求
按照相应的ISO9001：2000国际质量体系标准及国家规定进行质量控制，还以相应的规范要求对设计质量，施工质量、材料和设备质量进行管理、要求、控制。
公司的运维阶段性内部验收制度，是质量控制管理的有利保证。工程的每一个阶段完成时，公司技术支持部门都要按有关部门规范和要求进行严格的内部验收。验收标准整体上高于用户验收标准。
1。一般性技术支持问题
一般性技术支持指客户打电话咨询有关问题，包括与应用集成有关的业务问题以及不需要进行审批的一般性技术问题的处理；对于一般性的咨询问题，要做好记录工作。
2.重大事件的技术支持
重大事件的技术支持指客户由于误操作，会对业务处理结果产生影响的重大事件,或由于硬件故障引起的软件重安装等涉及到应用集成技术支持问题，以及应用系统软件出现影响系统整体业务处理的重大故障性问题；此类问题，首先由项目经理向甲方有关部门反映，并发出正式报告,同时附上《重大请求审批表》，由技术部门和相关业务部门审批同意后，交由乙方的技术支持人员进行处理，处理完成后由相关支持人员填写《重大请求处理记录表》，并归档；对于甲方不同意进行处理的请求，不得擅自进行处理。
3.相关信息的反馈
参与技术支持与售后服务的人员，要及时回答用户通过各种方式提出的有关问题，并尽快给出解决建议或初步解决建议；归档每月受理的重大请求及其审批意见和处理结果,统计每月重大请求涉及的技术问题、业务问题和问题原因；所有相关归档文件由专人保管，存放在指定位置,统一管理。技术支持与售后服务项目经理根据技术支持人员统计的支持记录，需要进行归类分析，同时便于采取一些有针对性的对策。
4.技术支持与售后服务问题培训
根据整理和不断丰富的技术支持常见问题手册，采取对系统维护人员不定期培训的方式，不断提高甲方系统维护人员的系统维护水平。现场培训，如果甲方
要求，乙方应就现场服务中故障发生的原因、处理过程、以及类似故障的预防和处理经验对甲方提供必要的培训。
5。其他服务要求
(1）对于软件开发性项目，乙方必须按照软件开发的一般方法(计划、需求分析、设计、编码、验收、上线）来进行严格组织和实施，并及时提供开发项目范围内所涉及的所有文档资料（需求分析产物、开发计划、测试计划、测试报告、操作手册、用户预生产手册等）。
（2）所有软件维护和开发必须提供有中文说明的数据表结构和接口调用逻辑图，所有现场维护人员必须按人按周向甲方提供个人工作周报，维护小组按月向甲方提供维护月度总结报告。
（3)对于性能优化方面，乙方指定专人进行性能监控，并每月出一次性能监控报告。对于监控过程中出现的性能问题,需要及时组织相关人员进行程序优化、系统参数调整，如果现场人员无法解决的性能问题，乙方必须派遣维护以外的高级技术人员到现场解决。不得在没有得到甲方的许可下，对现有生产、预生产环境做任何配置上调整和修改。
(4)乙方必须指定项目负责人参加每月运维工作会议，配合甲方解决或优化系统运行过程中出现的各类问题。 1.1.6.2. 运维时限要求
一般业务运维时限。按照招标方确定业务运维的范围,一般业务运维服务请求原则上在1天之内解决;涉及数据调整、数据查询的业务运维服务请求应在3天之内解决；涉及新增及变更业务需求开发按照招标方确定的工作计划进行；涉及重大紧急类问题按照故障处理时限要求执行。
系统故障运维处理时限。对用户所提出的业务应用软件和系统软硬件平台等故障处理要求，必须在1小时内做出安排并将其反馈给用户；遇到一至五级故障，应在30分钟内响应，并在招标方确定的故障处理时限范围内采取相应措施以确保系统可正常操作。无法在24小时内解决的,必须提供解决时间表。
故障处理时限表: 故障级别 1级故障 故障现象 此类故障导致整个系统无法使用，故障级别处理时限 1小时 最高。应协调各方面资源,逐步降低故障级别，最终解决问题。 此类故障导致系统多个业务域、前台重点业2级故障 务域（登记、申报、征收、发票、社保、税库银、电子税务局等）、重点业务域中的核心业务功能不能使用，对前台业务办理产生严重影响. 3级故障 此类故障导致系统某个业务域不能使用但对其他业务域影响较小,不影响前台核心业务办理。 此类故障导致系统某个或几个功能不能使4级故障 用，不影响该业务域其他功能使用，对前台业务办理影响较小。 5级故障 此类故障暂不影响核心征管业务的正常使3天 24小时 4小时 2小时 (非故障） 用，解决较为简单,但存在一定风险。 故障记录.接到故障申请应按规定进行记录;故障分析处理过程应有文档；故障处理结束48小时需向采购方提交故障报告。故障报告必须写明故障原因、故障处理方法、改进措施。 1.1.6.3. 售后服务内容 1.1.6.3.1. 软件维护流程
软件维护是软件项目售后服务的重要内容。软件维护包括：纠错性维护、适应性维护和完善性维护三类活动。我公司管理体系要求并约束软件项目维护活动过程，体现为：
活动流程
维护申请即时处理/维护方案维护申请审核实施维护方案维护复查、评审、验收维护归档 过程说明 1、收集维护信息并对信息进行管理。售后服务部门接收用户提出的维护申请（来自网络的客户信息、电话或者书面申请等），填写《客户咨询/反馈登记表》。
2、售后服务工程师对维护申请进行处理：根据问题实际进行即时处理；对于需要深度维护的问题制定维护方案,并与用户进行协商以确定维护的模式，维护活动的实施细节，是有偿维护还是无偿维护等。在《用户问题反馈及落实情况表》上做出问题审核处理意见。对于不需要进行维护的，发送《客户回执》给用户，并将《用户问题反馈及落实情况表》进行归档。
3、售后服务工程师实施维护。实施时根据维护的类型参见《软件维护规范》和《系统维护规范》。维护实施完毕后，售后服务工程师请客户填写意见。
4、维护完成后，进行维护验收,验证修改是否正确,并重新确认整个软件。 5、售后服务工程师将维护过程中产生的记录和客户意见提交给客户服务部或项目维护小组，对本次维护进行确认，如果合格,则本次维护结束。所有过程质量记录交由文档管理员进行归档。
责任人
售后服务部门、客户服务部门、项目文档管理人员
产生记录
《客户咨询/反馈登记表》 《用户问题反馈及落实情况表》 《客户回执》《维护任务单》 《用户意见反馈表》 《维护验收表》 《归档记录》
1.1.6.3.1.1. 软件版本升级流程
申请人填写《应用系统版本、补丁发布申请审批表》，提交版本管理员审查。 版本管理员审查通过后，提交现场运维经理审核。 现场运维经理审核通过，报客户负责人审批
客户审批后，由现场运维经理在《应用系统版本、补丁发布申请审批表》上批转各相关系统版本管理员组织实施。
版本管理员在实施生产环境的版本、补丁发布前，对系统原有配置进行备份，以便在版本、补丁发布错误或失败时，及时恢复到原配置状态。
版本管理员在实施生产环境的版本、补丁发布前，在模拟环境中进行发布，并进行相关功能测试。确认无误后，版本管理员方可实施生产环境的版本、补丁发布。
版本、补丁发布完成后，由版本管理员进行系统启动、配置项检查、例行试操作等工作，确认版本、补丁发布无误后，由版本管理员填写《应用系统版本、补丁发布执行情况表》并签字确认。
版本、补丁发布完成后，《应用系统版本、补丁发布申请审批表》和《应用系统版本、补丁发布执行情况报告》由文档管理岗存档，以备查验。
申请人发起申请客户负责人审批审批运维经理批复批复版本管理员模拟环境部署提交相关开发部门程序修改失败测试成功原程序备份生产环境部署生成版本发布情况表 软件版本升级管理流程图
1.1.6.3.1.2. 软件故障处理流程
1、建立案例流程说明
我公司通过与局方服务专员的电话、传真、E_Mail等方式，接受局方的服务请求.
接受服务请求时，了解的信息有： 设备类型 软件序列号 软件安装地点 服务情况描述
在设备保修期内,我公司售后服务人员师根据局方服务专员描述确定服务等级，发出《服务处理报告》，通知工程师。
注:非正常工作时间,有专门的服务热线手机，以保证不漏接甲方电话。我公司服务专员通知值班工程师电话响应局方，值班工程师于次日通知局方服务专员建立案例，正常运作。 在设备保修期外，投标方服务专员将局方的服务请求转送对应的部门，由对应部门决定是否提供服务。如果提供服务，则进行远程支持，否则向甲方解释说明，并提出解决方案建议.
2、任务分配流程说明
我公司服务专员在确认局方的服务描述后，确定服务等级。 开《服务处理报告》单,请售后服务经理分配执行工程师响应，通过邮件将《服务处理报告》单发给执行工程师，并电话确认执行工程师已接受到报告单。 对于一级服务（重大紧急服务），直接分配给升级工程师。 当执行工程师不能在规定的时间内响应甲方，或在规定的时间内不能提供解决方案，投标方服务专员则通知技术经理改派执行工程师.
3、任务执行流程说明
执行工程师接受任务后，需在案例开始的一小时内电话响应局方。如果执行工程师不能在规定时间内电话响应局方，则另指派一名执行工程师接受任务。执行工程师电话响应局方，核实服务,了解相应信息，提供解决方案. 如果执行工程师不能提供解决方案，则在规定的时间内升级上报，改派升级工程师提供解决方案。
4、跟踪任务执行情况流程说明 共有四个主要跟踪点： 响应时间 确诊时间
内部升级上报时间 升级到厂商的跟踪
投标方服务专员在将《服务处理报告》单分配给执行工程师后，该执行工程师要发EMail或电话通知局方服务专员已接受任务。如果局方服务专员没有收到执行工程师的回复，则每隔15分钟向该工程师发出催请电话响应的跟踪电话，在任务开始的第三个15分钟（即45分钟），通知技术经理改派工程师. 根据服务等级时限，当执行工程师不能解决问题时，催请工程师升级上报。并通知相关
的上级（如技术经理）。升级工程师采用《服务处理报告（升级）》单。 升级到厂商的案例，由原案例升级执行工程师负责追踪进展情况，并将进展情况通知局方服务专员. 执行工程师提交解决方案时，我公司服务专员监督相关记录文档的回收。 对于在规定的时间内没有关闭的案例,我公司服务专员要追踪其原因，且任务执行人要提供合理的原因及下一步计划. 1.1.6.3.1.3. 案例结束流程
执行工程师提供解决方案后，同局方确认服务处理结果，然后向局方服务部提交技术服务记录：《现场维护报告》、《案例服务处理报告》等。 甲方服务专员通知甲方关闭案例。向局方了解对工程师的评价，案例关闭. 1.1.6.3.1.4. 软件故障处理流程图
1.1.6.3.1.5. 定期巡检流程
售后服务工程师定期进行巡检，并将检查结果记录,形成报告，交给客户和上级领导。
我公司派经验丰富的售后服务工程师到客户现场进行巡检,查看系统及数据库是否运行良好
1)向客户提交巡检报告并签字确认
2）根据局方需要的时间点，提供上述询价服务报告
3）我公司会经常主动拨打电话给用户，与其进行交流，及时了解客户系统的运行情况
1.1.6.3.1.6. 性能诊断
在巡检过程中,现场对系统性能进行诊断，根据结果调整系统参数，使系统始终在最佳状态下运行,对可能出现的问题进行科学性预测，并采取必要的预防和补救措施，防患于未然。 1.1.6.3.1.7. 巡检记录
每次巡检完毕,我公司售后服务工程师就客户运行系统情况填写《现场巡检记录表》和《现场保修情况记录表》，针对系统软件及数据库运行情况，进行记录说明。
1.1.6.3.2. 服务升级流程
（一）服务内容
系统升级服务针对系统可能存在的系统瓶颈进行性能扩充或者弥补系统中原有的漏洞，简单的系统升级通过安装系统补丁程序即可完成.复杂的系统升级则需要对硬件平台进行改造。但是无论是哪种系统升级，都会对原有的系统产生影响,如果没有详细周密的系统升级计划，可能会导致系统长时间停止运行甚至不能恢复.所以我们对系统升级制定统一的服务流程，以规范系统升级工作的实施。
（二）服务流程
（三)咨询服务流程 1。服务内容
针对客户提出的关于系统运营、运行方面的优化、改进要求，投标人提供咨询服务,为客户制定合理的、可实施的优化、改进方案。在其他日常工作中，根据维护人员发现的潜在问题,我们也将主动向客户提出有效的建议。
2.服务流程
咨询服务没有特定的针对性,一般是根据客户的要求提供。 3。服务文档 ①日常监控记录
按照设定的监控时间，分时段记录系统运行情况，进行异常状况分析，及时
备案解决.
②故障报告
记录与故障有关详细情况，包括:故障提交人、部门或公司、故障现象、解决方案等.
③季度巡检
售后服务期内每季度提供一次的免费巡检服务,并向用户提供巡检报告。
1.1.7. 合理化建议
无 1.1.8. 其他
无 1.2. 实施方案 1.2.1. 总体原则 1.2.1.1. 整体性原则
我们将综合考虑社保费征管信息系统相关应用系统的现状，提出整体的运行维护策略,有效保障系统运行中各环节的不间断运行,并综合使用不同层次的技术手段，为应用系统和系统依托的基础环境提供全方位的监控管理和服务。 1.2.1.2. 有效性原则
将充分利用各种现代技术手段，选择一款功能丰富、技术先进的系统运维监控软件，结合科学合理的运行管理机制，对系统的稳定可靠运行提供有效的保障。
1.2.1.3. 可靠性原则
对维护工作中后续应用系统模块的开发设计中，应采用成熟可靠的技术和产品，同时配合完善的项目控制规范和质量保证体系，保证互联网站的升级维护中的严格的质量控制,保证系统开发和运行的安全可靠。 1.2.1.4. 反馈性原则
实现运维中发现、需要解决的问题要及时反馈给信息系统的开发商进行完善,利于优化机构、岗位设置，利于业务流程的改进。 1.2.1.5. 防范预警原则
运维系统中应包含各种预案，争取实现在故障、问题出现时有章可循，在紧急状态有应急措施，提高运维效率，将故障代价减小到最小。 1.2.2. 运维内容
运维周期内内容如下： 1.2.2.1. 日常运维服务
日常问题受理和一般问题处理：通过西藏自治区税务运维平台、QQ运维群等方式接收并处理税务人员和纳税人提出的系统使用过程中的各类问题。确保当天的问题单当天有回复，能解决的及时解决，不能及时解决的应回复原因并估计解决时间.
专项问题分析：当总局、省局税收政策发生变化，个人税费业务流程发生调整时,投标人应在尽快了解流程调整内容基础上，结合本地实际业务情况，充分考虑系统升级带来的涉及历史数据的衔接、业务办理的变化等因素，向采购人汇报，并共同确定调整方案.
紧急问题处理:因系统异常造成业务中断、需要支持人员能够随时响应、快速到位，尽可能短时间内恢复的问题按照紧急问题处理流程来进行处理。
程序问题确认和处置：由于系统设计缺陷、程序bug等原因造成的系统使用故障或性能低下属于程序问题。运维服务人员对程序问题进行复现测试和确认,排查问题原因，提供解决方案并实施，实施后将确认结果反馈相关负责人。
重大配置变更：运维服务人员对可能发生的重大配置变更需求（如应用系统网络、存储、主机、中间件、数据库、操作系统的重大配置调整）进行评估和方案制定，并综合判断重大配置变更执行的风险、回退方案、可行性、所需资源等
补丁开发和发布:社保费征管信息系统业务逻辑应保持高度一致,投标人必须随时了解总局XXXXXX个人税收系统的版本更新情况，及时完成XXXXXX系统相关功能修改和补丁开发,并将系统变动情况通知采购人负责人和关联系统负责人,制定完备的版本发布计划和回退机制。版本发布完毕后应做好测试验证工作，并协助关联系统做好测试验证工作。根据补丁发布情况，及时更新操作手册等文档。
软件功能咨询：针对网上申报系统的业务处理方法、业务处理原理等在软件功能上反映的问题提供及时全面的解答，完成查询、统计、报表等功能的口径解释、功能答疑等工作。
软件操作咨询:针对涉及操作人员在软件使用过程中碰到的由于计算机操作熟练程度不高引起的包括计算机基本操作咨询和软件操作咨询。
业务需求编写支持:协助采购人业务人员进行业务需求的编写和相关技术问题的支持，参与各业务政策分析等具体工作。
知识收集整理和转移：投标人应按照采购人要求对系统运行过程中出现的知识点进行收集，并及时发布到知识库；定期对知识点进行分类、整理，输出常见操作问题解决文档；按采购人要求进行知识转移类培训等。同时，运维公司应定期更新常见操作问题解决文档。
税务机关交办的其他支持工作：参加各税收业务系统需求研讨、需求编制、系统测试及试运行等相关工作会议,对需求编制、软件测试、运行情况进行跟踪；维护文档管理和问题管理；参与业务部门安排的业务测试工作，参与对业务需求的解释。
工具配置:运维团队负责按照采购人的需要对XXXXXX系统运维项目中涵盖的工具进行初始化配置。 1.2.2.2. 系统级服务
系统性能监控：开展应用系统性能进行监控,及时发现应用点宕机、数据库锁死等影响系统运行效率的问题，及时解决提升用户体验。
综合故障解决：综合故障分析主要是针对系统运行过程中出现的故障，包括运行环境、系统运行、基础软件情况，对应用、系统、数据库进行全面检查，就系统出现的相关问题进行综合故障分析，通过分析明确故障原因。
系统巡检和优化:为省局的系统运行环境提供每年2次的系统巡检服务（包括但不限于：系统资源配置检查、系统参数配置检查、oracle数据库参数检查、weblogic中间件参数检查等方面),并出具巡检报告。根据系统运行状况和巡检结果，针对发现的问题进行优化和调整，针对疑难问题应提出架构级解决方案并负责实施。
系统迁移：系统迁移是指网上申报系统的数据库、数据及应用软件等,按照采购人的要求从现有的设备环境迁移到新的设备环境，新的设备环境由采购人提供，投标人负责实施。
接口运维：应安排专人负责接口运维,及时响应第三方公司提出的接口调试需求，积极配合分析和定位问题,保障围绕网上申报系统运行的各外围系统所有功能正常运转。对西藏税务需要新增的网上申报系统接口需求，应提供技术和业务咨询服务，并予以实施。 1.2.2.3. 基础环境保障
系统环境监控与维护：对服务器、数据库、存储空间、应用中间件等进行例行的健康检查，同时接收系统管理员、用户等反馈的系统环境问题。对发现和接收的问题进行调查、诊断、定性后，进行相应的处理、维护、优化等。
数据库性能优化：对数据库脚本、语句性能问题，同时周期性对数据库整体性能情况进行检查，对接收到和检查发现的数据库性能问题进行分析，根据分析结果采取脚本调优、数据库参数调整等方法分别实施优化 1.2.2.4. 数据服务
数据库备份:按照统一的数据备份策略完成数据库的备份工作，定期检查并确认数据备份情况，形成数据库备份报告.
历史数据剥离：历史数据迁移，主要是对影响系统运行效率的生产库进行历史数据的剥离，将部分历史数据迁出数据库，其迁出前要制定数据迁移方案,执行迁移过程,并在完成数据迁出后编制数据迁移报告.
数据提取和解释服务:根据采购人业务工作需要后台提取数据(包括业务理解、口径确认、脚本编写、脚本校验、脚本执行、结果推送和脚本可追溯等），负责对后台数据的业务处理逻辑、数据结构和各项查询功能口径进行确认和解释，协助采购人熟悉后台数据业务逻辑,应指定专人负责该项工作。
数据质量监控:通过后台脚本或辅助工具的形式对数据的质量进行监控,并给出处理建议。
数据分发服务：数据库中的数据可按照采购人的要求，向其他数据库进行推送或者分发，可向其它应用系统提供数据支持。
数据维护服务：对系统或用户操作失误造成一些数据问题进行后台维护，包括数据维护业务需求沟通确认、数据分析、出具方案、方案审核、方案测试、方案实施、编写处理报告等. 1.2.2.5. 接口服务
XXXXXX系统涉及到外围的接入,如网报系统、自助终端系统等，为保障外围系统接口能够正常运行使用，我公司将为外围系统提供接口清册，并协助外围系统测试接口是否正常. 1.2.2.6. 培训服务
对XXXXXX系统升级后以及业务发生变更后的内容，组织系统使用人员进行培训，并进行培训考核。
一、培训对象
税务前台工作人员 各业务处室工作人员 运维中心工作人员 二、培训原则与要求
坚持按需施教、务求实效的原则.根据需要和税务人员多样化培训需求，分层次、分类别地开展内容丰富、形式灵活的培训，增强培训的针对性和实效性，确保培训质量.
培训内容：系统使用.
培训方式：集中培训和个别培训.
培训批次：不少于2次的集中培训（每年）.个别培训随时安排. 由于本项目是一项综合型的项目，系统使用范围广，用户层次多，不同用户层次使用的系统角色不相同，使用的内容和侧重点各不相同，因此我们在本项目中将针对不同的用户层次提供针对性的用户培训，保障培训效果,使各层次的对象都能熟练掌握系统的相关知识。
前台工作人员：前台工作人员是应用系统的直接使用者，涉及到系统的各方面功能，是对系统功能理解最深、业务最熟悉的用户群，然而前台工作人员由于覆盖的面广，各部门主要使用的功能模块不尽相同,因此针对于前台工作人员将按照不同的部门的侧重点进行分期培训，组织类似业务部门或单独部门进行培
训，以便于各部门对各自业务系统使用的把握，以达到各用户能熟练掌握系统的使用方法。
各业务处室工作人员：各业务处室工作人员是单位对系统进行管理维护的人员，这一用户掌握一定的信息技术,并且针对各业务处室工作人员分别进行针对性的培训,主要侧重于系统的建设原理和规划，总体架构,常见问题的解决，系统安装配置等内容。系统的维护和管理工作需要对应用系统较熟悉，并且能处理运行过程中遇到的各类问题，因此对于各业务处室工作人员将采用共同参与项目维护和实施的方式，从长期实践中逐渐掌握系统维护知识，提升其技术技能和对系统的认识.
运维中心工作人员培训:运维中心工作人员主要是指单位具备一定的应用系统开发能力，主要用于系统上线后对系统的需求变动进行二次开发和修改,以及系统扩展能力的技术人员,针对这一用户群，将着重于应用系统的后台原理、数据库、系统架构等进行培训。
1.2.3. 日常服务内容 1.2.3.1. 日常巡检服务
现场日常巡检服务是我公司对应用系统服务设备进行全面检查的服务项目,通过该服务可使客户获得设备运行的第一手资料，最大可能地发现存在的隐患，保障设备稳定运行。同时，公司将有针对性地提出预警及解决建议，使客户能够提早预防，最大限度降低运营风险. 1.2.3.2. 日常巡检安排
公司安排定期（每月/每天/上午下午各一次)例行巡检和预防性维护，内容包括：
(1) 设备运行物理状态（每月/次）； (2) 电源稳定性和线路检查（每天/次）； (3) 系统性能检查(每月/次）； (4) 逻辑卷检查（每月/次）； (5) 内存交换区检查（每月/次）； (6) 系统硬件诊断（每月/次）;
(7) 数据安全存储检查（每天/次）； (8) 数据备份状况(每天/次）；
(9) 系统错误报告的分析、记录和清理(每天/次); (10) 及时更换损坏的或有潜在故障的部件(每月/次）;
(11) 设备物理检查（包括机体、风扇、风道及过滤器等）与清洁（每月/次）；
(12) 针对巡检工作应提交完善的巡检报告,并且存档、编辑成册,每月月初提交，以便日后清查。
(13) 数据库的巡检工作，数据库日常监控,每日至少2次，分上下午分别进行。
1.2.3.3. 出具巡检报告
提供故障报告等触发性报告。 1、日常巡检报告等日常报告。
2、周报、月报、季报、半年报、年报等总结性报告。
报告内容包括:检查内容、操作步骤、检查结果、操作人、操作时间、意见与建议等. 1.2.4. 系统安全服务
(1) 7X24小时监控服务
(2) XXXXXX系统及其相关网页安全性检查
(3) 按照省局技术规范和安全管理规范，对应用软件、中间件以及数据库进
行日常安全性检查。
(4) 系统服务器以及网络安全性检查
(5) 按照技术规范和安全管理规范，定期对服务器操作系统进行安全性检查
以及进行系统杀毒。 (6) 数据库备份及备份验证 1.2.4.1. 监控原则
(1) 我们将对系统进行7*24不间断监控； (2) 监控岗保证一直有人值守；
(3) 每日分别于上、下午对服务器进行巡检,并于当天提交运维监控报告；
1.2.4.2. 监控方案
(1)
系统访问监控
在系统访问监控功能中，系统监控内容包括网页名称、网址、监控类型、最后检测时间、响应时间及本日产生的上传下载流量等。点击“查看”后可查看更详细的网址监控项目，包括响应时间、连接数、网络流量，以及浏览用户在网站提交的纠错内容等.
1) 响应时间
每间隔指定时间Ping指定的网址，并从返回的值中计算指定网站的响应时间。
监控详情：点击菜单“网站访问监控”—“网站访问监控详情”,系统在列表中显示每个已经添加并指定需要监控的网址，并在列表中显示该网址的响应时间.
数据采集：系统按照在“监控网址管理”中的设置,按指定间隔Ping出该网址的响应时间，并将数据保存至监控数据库中.
2) 连接数
每间隔指定时间，取得指定网站的连接数.
监控详情：点击菜单“网站访问监控”—“网站访问监控详情”，系统在列表中显示每个已经添加并指定需要监控的网址,并在列表中显示该网址的当前连接数量.
数据采集：系统按照在“监控网址管理”中的设置，按指定间隔测试该网址的当前连接数量，并将数据保存至监控数据库中。
3) 网络流量
每间隔指定时间，取得并统计指定网站的网络流量，上传和下载流量分别显示。
监控详情：点击菜单“网站访问监控\"-“网站访问监控详情”,系统在列表中显示每个已经添加并指定需要监控的网址,并在列表中显示该网址的累计网络流量。
数据采集:系统按照在“监控网址管理”中的设置，按指定间隔测试该网址的累计网络流量,并将数据保存至监控数据库中。
4) 统计分析
针对网站监控中的各项指标进行统计分析，统计的条件包括时间范围、网址及指标值范围等.
监控情况统计表：统计指定时段内,网站各项监控指标的监控值。 监控预警趋势表：统计指定时段内，网站监控指标的统计值及趋势走向，同时以表格和图表形式展示。
监控预警统计表：统计指定时段内，全部（或指定)网站中，已经产生的（邮件或短信)预警的次数。
(2)
设备监控
在设备监控界面中，列表显示了全部设备的最近一次监控情况，包括设备名称、IP、最后检测时间、各项监控数值及设备状态是否正常等.可以在左上方选择不同的分组以关注不同分组的设备，也可以勾选右上方的“仅显示异常服务器\"以迅速找到运行异常的设备。
1) Ping返回时间
每隔一段时间，首先Ping设备判断设备是否能正常连接，以及连接所需的时长等，较长的返回时间或无响应通常表示设备可能已经发生故障。
监控详情：点击菜单“设备监控\"—“设备监控详情”，系统在列表中显示每台已经添加并指定需要监控的计算机设备，并在列表显示该计算机设备的Ping返回时间。
数据采集：系统按照在“监控设备管理”中的设置，按指定间隔读取该计算机设备的监控数值，并将数据保存至监控数据库中。
2) CPU使用率查询
每隔一段时间，检测目标计算机上CPU的使用率情况。CPU使用率反映的是当前CPU的繁忙程度。
监控详情：点击菜单“设备监控”—“设备监控详情”，系统在列表中显示每台已经添加并指定需要监控的计算机设备，并在列表显示该计算机设备的CPU使用率情况。
数据采集：系统按照在“监控设备管理\"中的设置，按指定间隔读取该计算机设备的CPU使用率,并将数据保存至监控数据库中。
3) CPU负载
每隔一段时间，检测目标计算机上CPU的负载情况.CPU负载指某段时间内占用CPU时间的进程和等待CPU时间的进程数，这里等待CPU时间的进程是指等待被唤醒的进程,不包括处于wait状态进程。
监控详情：点击菜单“设备监控”-“设备监控详情\"，系统在列表中显示每台已经添加并指定需要监控的计算机设备，并在列表显示该计算机设备的CPU负载情况。
数据采集：系统按照在“监控设备管理”中的设置，按指定间隔读取该计算机设备的CPU负载，并将数据保存至监控数据库中。
4) 内存使用率
每隔一段时间,检测目标计算机上内存情况.内存使用率指已经使用的物理内存与全部物理内存的比率.
监控详情:点击菜单“设备监控”—“设备监控详情\"，系统在列表中显示每台已经添加并指定需要监控的计算机设备，并在列表显示该计算机设备的内存使用率情况。
数据采集:系统按照在“监控设备管理”中的设置,按指定间隔读取该计算机设备的内存使用率,并将数据保存至监控数据库中。
5) 磁盘空间使用率
每隔指定时间，检测目标计算机上磁盘空间使用率情况。
监控详情:点击菜单“设备监控”—“设备监控详情\系统在列表中显示每台已经添加并指定需要监控的计算机设备，并在列表显示该计算机设备的磁盘使用率情况.
数据采集：系统按照在“监控设备管理\"中的设置,按指定间隔读取该计算机设备的磁盘使用率，并将数据保存至监控数据库中.
6) 网络流量
间隔指定时间，检测目标计算机上网络流量情况，包括网络上传流量与网络下载流量。流量可简略反映计算机的网络传输流量是否在正常范围内.
监控详情：点击菜单“设备监控”-“设备监控详情”，系统在列表中显示每台已经添加并指定需要监控的计算机设备，并在列表显示该计算机设备的网络上传下载流量。
数据采集：系统按照在“监控设备管理”中的设置，按指定间隔读取该计算机设备的网络流量，并将数据保存至监控数据库中。
7) 系统进程数
每隔一段时间，检测目标计算机上系统进程数量。系统进程数量表示当前监控的计算机在运行中的进程，进程越多，通常占用的CPU及内存资源也越多.
监控详情：点击菜单“设备监控”—“设备监控详情”,系统在列表中显示每台已经添加并指定需要监控的计算机设备，并显示该计算机设备的系统进程数量.
数据采集：系统按照在“监控设备管理”中的设置，按指定间隔读取该计算机设备的,并将数据保存至监控数据库中。
8) 统计分析
针对设备监控中的各项指标进行统计分析,统计的条件包括时间范围、设备名称及指标值范围等。
监控情况统计表：统计指定时段内，设备各项监控指标的监控值. 监控指标趋势表:统计指定时段内，设备监控指标的统计值及趋势走向，同时以表格和图表形式展示。
监控预警统计表：统计指定时段内，全部（或指定）设备中，已经产生的（邮件或短信）预警的次数。
9) 监控设备管理
添加需要监控的设备，从IP及端口唯一指定需要监控的设备,并加以描述。可以选择哪些设备需要发送告警信息。预警级别分为两级，预警级别（蓝色)及告警级别（红色，达到告警级别后系统将按设置发送邮件或短信对管理员进行提醒.
可以更改每个网址的序号,在网址访问监控界面列表显示时,以序号为顺序升序显示。
在列表中可以设置每个设备的分组信息，如“外网服务器\"、“内网服务器”或“网络设备”，以查看监控情况时能迅速查看及判断设备监控情况。
勾选“是否监控”并保存后，系统开始以指定的频率读取相关的监控数值并保存.
(3)
应用服务监控
监控指定应用服务（如Apache、WebSphere及Tomcat等）的运行情况，并对无法连接的应用服务,以及监控指标超过指定阈值的情况进行邮件或短信告警。
对于WebSphere的监控，很可能无法取得相关的监控项目值,在这种情况下可能需要通过Tivoli Performance Viewer工具来获得监控项目和数据。
(4)
数据库监控
监控指定数据库实例的运行情况,并对无法连接的数据库，以及监控指标超过指定阈值的情况进行邮件或短信告警。 1.2.5. 网站安全性检查
我司公司按照技术规范和安全管理规范，对应用软件、中间件以及数据库进行日常安全性检查。确保系统能够正常使用；确保页面内容正确,确保系统应用正常，并能够提供正常的服务。
针对管理子系统，我们采取有效的方法防止网页被攻击或恶意篡改，杜绝因攻击而带来的恶性事件发生.针对于更为重要的信息数据我们更需要提高安全防护的水平，确保网站系统的数据不被恶意修改，敏感的数据不被非法访问或泄露。具体的从以下几个方面进行: 1.2.5.1. 阻断应用攻击
应用专业的应用防护设备进行防护，通过对输入内容的过滤及请求过滤实现对网站的保护。防止跨站脚本攻击、SQL注入等常见攻击。 1.2.5.2. 屏蔽安全隐患
为了防止服务端敏感信息泄露，我们通过对现有网站的敏感信息进行屏蔽，如备份文件的下载、敏感数据库下载，管理后台的外网尝试等，另外还屏蔽编写程序过程中遗留下的程序注释，对服务出错信息进行有效屏蔽。 1.2.5.3. 防止网页篡改
应用网页防篡改系统有效的防护机制，实时监测网站服务器的相关信息是否给非法更改,一旦发现被改则第一时间通知管理员，并形成详细的日志信息。但对外仍显示篡改前的正常页面，用户可正常访问网站。事后可对原始文件及篡改后的文件进行本地下载比较，查看篡改记录，恢复被篡改的页面。 1.2.6. 数据库备份及备份验证
公司按照省局技术规范和安全管理规范，制定科学有效的数据备份与灾害恢复计划,对省局内容管理平台范围内要求的网站、应用及数据进行备份. 1.2.6.1. 应对黑客攻击
公司按照技术规范和安全管理规范进行应对黑客攻击，保证网站防篡改系统正常运行且发挥作用，确保XXXXXX系统不被黑客攻破，防止黑客篡改页面内容及数据的破坏。
公司定期监控系统访问记录，及时查找异常访问记录并查找原因，消除隐患；并及时修复不安全漏洞，消除隐患；定期出具服务器运行情况及被攻击情况报告。
1、工作时间内，发现黑客攻击应在第一时间通知具体责任人。
具体责任人接到通知后，应详细记录有关现象和显示器上出现的信息,将被攻击的服务器等设备从网络中隔离出来，保护现场.同时通知总负责人，召集相关技术人员共同分析攻击现象,提供解决方法,主机系统管理员和应用软件系统管理员负责被攻击或破坏系统的恢复与重建工作。视情况向部领导汇报事件情况。
非工作时间内发现的攻击事件，值班人员应首先立即切断被攻击外网服务器的网络连接,并做好相关记录;然后通知具体责任人按流程处理。 1.2.6.2. 系统故障处理
运维过程中出现的系统故障，我司将进行紧急处理和故障修复.在故障处理和修复过程中，我司负责系统故障分析、问题定位并提供系统故障修复方案，采购人认可后并执行系统故障修复方案,在系统故障修复方案中涉及购买的第三方服务，需采购人负责协调第三方服务人员配合我司进行系统故障恢复。
故障恢复后,需要对故障的发生、处理过程和结果进行记录，并形成故障报告,汇报给采购人.
1.2.7. 其他
1.2.7.1. 主机系统日常运行维护 1.2.7.1.1. 配置信息表
为系统建立档案。 1.2.7.1.2. 用户权限检查
为防止无关人员访问系统，Administrator/root密码仅限少数人知道;所有用户不允许远程登陆；新建用户单独用户可以远程登录。 1.2.7.1.3. 系统服务检查
为防止系统不必要服务引起问题，停止所有不必要服务。 1.2.7.1.4. 文件系统空间使用情况
为了保证文件系统的使用率不超过96％.检查人员每日一次执行命令查看文件系统的使用率，如果所有文件系统的使用率小于96%,为正常。则在报告上记录其使用率。如果有文件系统的使用率大于或等于96%，则在报告上标明异常。并通知此系统负责人.如果有文件系统的使用率达到100%，要立即通知此系统负责人.如果有文件系统的使用率虽然没有达到96%，但其使用率每天增长超过2%，则需要在报告上注明。
1.2.7.1.5. CPU、内存、IO、网络
为了记录系统负载状况，以备故障处理参考。检查人员每日一次检查cpu、内存、IO、网络状况，并在报告上记录获得的数据。 1.2.7.1.6. 错误日志
为确认系统运行正常，检查人员每日一次执行命令察看系统日志中是否有硬件报错信息。当日日志信息中无硬件报错信息，为正常，则在报告上标明正常。如果有硬件报错信息，则说明系统异常，在报告上标明异常，并立即通知此系统负责人。
1.2.7.1.7. 双机热备软件运行情况检测
为了确认双机热备软件运行正常。检查人员每日一次执行命令查看双机热备软件运行状况。如果状态为正常,则在报告上记录其正常。如有异常,请通知此系统负责人。
1.2.7.1.8. 系统整体使用情况周报
为对每周系统运行情况作整体评估，发现问题，提出改进方案.检查人员每周记录一次系统整体使用情况周报，在报告中记录评估情况，记录发现的问题，并提出改进建议。 1.2.7.1.9. 系统备份
为了对主机操作系统做磁带备份，以备系统崩溃时可以快速恢复，维护人员每月一次使用磁带对操作系统进行备份，并将备份好的磁带妥善保存. 1.2.7.1.10. 填写报告
对于硬件故障，需填写《故障记录单》。 对于系统参数调整，需填写《系统调整记录单》。 1.2.7.2. 数据库日常运行维护 1.2.7.2.1. 检查INSTANCE状态
每天定时登陆各数据库服务器，通过sql语句检查数据库INSTANCE状态，并填写每日数据库维护报告。如果发现INSTANCE状态异常，则进行检查处理并填写故障处理报告。
1.2.7.2.2. 检查警告日志等文件
每天定时登陆各数据库服务器，通过vi检查数据库警告日志文件，并填写每日数据库维护报告。如果发现警告日志文件有ORA—??？??和WARNING错误，则进行检查处理并填写故障处理报告。 1.2.7.2.3. 检查SQL*NET日志文件
每天定时登陆各数据库服务器，通过vi检查数据库警告日志文件,并填写每日数据库维护报告。如果发现警告日志文件有错误，则进行检查处理并填写故障处理报告。
1.2.7.2.4. 检查数据库会话情况
每天定时登陆各数据库服务器，通过sql语句检查会话情况，确认是否有死的会话占用数据库资源，并填写每日数据库维护报告。如果发现异常会话，则进行检查处理并填写故障处理报告. 1.2.7.2.5. 检查表空间使用情况
每天定时登陆各数据库服务器，通过sql语句检查数据库表空间的使用情况（表空间名称、总大小、已用空间、未用空间、使用率、空闲率），并填写每
日数据库维护报告。如果发现表空间有异常,则进行检查处理并填写故障处理报告。
1.2.7.2.6. 监控数据库文件状态
每天定时登陆各数据库服务器,通过sql语句检查数据库各表空间数据文件的使用情况（数据文件名称、状态），并填写每日数据库维护报告。如果发现数据文件有异常，则进行检查处理并填写故障处理报告。 1.2.7.2.7. 监控数据库临时表空间
每天定时登陆各数据库服务器，通过sql语句检查数据库查看数据库中临时表空间文件的状态（如被误删除），并填写每日数据库维护报告.如果发现临时表空间异常，则进行检查处理并填写故障处理报告。 1.2.7.2.8. 监控数据库回滚段表空间
每天定时登陆各数据库服务器,通过sql语句检查数据库回滚段表空间数据文件的使用情况（数据文件名称、状态),并填写每日数据库维护报告。如果发现。回滚段表空间有异常，则进行检查处理并填写故障处理报告。 1.2.7.2.9. 监控数据库联机日志
每天定时登陆各数据库服务器，通过sql语句检查数据库联机日志文件数据文件的使用情况（组别、是否归档，状态，归档时间），并填写每日数据库维护报告。如果发现异常,则进行检查处理并填写故障处理报告。 1.2.7.2.10. 监控数据库JOB
每天定时登陆各数据库服务器，通过sql语句检查job运行状况，并填写每日数据库维护报告.如果job运行异常,则进行检查处理并填写故障处理报告。 1.2.7.2.11. 监控数据库数据文件的IO情况
每天定时登陆各数据库服务器，通过sql语句检查数据库数据文件IO是否正常（数据文件名、物理读，物理写），并填写每日数据库维护报告。如果发现某个数据文件IO异常，则进行检查处理并填写故障处理报告。 1.2.7.2.12. 检查文件系统使用情况
每天定时登陆各数据库服务器，通过执行df –k名令,取得各文件系统的使用情况，并填写每日数据库维护报告。如果发现有异常增长或空间使用率过高，则进行检查处理并填写故障处理报告。
1.2.7.2.13. 监控数据库服务器性能
每天定时登陆各数据库服务器，通过使用vmstat，iostat，glance，top等命令监控CPU、IO、内存等方面的系统性能，并填写每日数据库维护报告。如果发现系统性能较低时及时预警，则进行检查处理并填写故障处理报告。 1.2.7.2.14. 逻辑备份
每天定时登陆各数据库服务器，通过查看备份服务器上的备份日志,并填写每日数据库维护报告.如果发现没有成功备份,则进行检查处理并填写故障处理报告。
1.2.7.2.15. 逻辑备份恢复测试
每天定时登陆各数据库服务器,通过回复测试服务器对备份文件进行恢复，并填写每日数据库维护报告。如果发现没有成功恢复，则进行检查处理并填写故障处理报告。
1.2.7.2.16. 检查对象增长情况
每周定时登陆各数据库服务器,通过执行sql来检查大表、分区表、大表索引、分区索引的增长情况，并填写每日数据库维护报告。如果有异常增长，则进行检查处理并填写故障处理报告。 1.2.7.2.17. 监控top sql情况
每周定时登陆各数据库服务器，通过执行sql来检查是否有需要优化的sql语句，并填写每日数据库维护报告。如果有效率低下的sql语句,则进行检查处理并填写故障处理报告. 1.2.7.2.18. 数据库空间扩展
每周根据每天的表空间增长情况报告分析出合理的表空间增长趋势，确定扩表空间方案。并填写数据库维护报告。 1.2.7.2.19. 系统健康检查
每周定时登陆各数据库服务器，通过执行sql来检查数据文件、控制文件是否正常,并填写每日数据库维护报告。如果有异常，则进行检查处理并填写故障处理报告。
1.2.7.2.20. 检查无效对象
每周定时登陆各数据库服务器,通过执行sql来检查无效的数据库对象、不起作用的约束、检查无效的trigger等，并填写每日数据库维护报告。如果有无效对象,则进行检查处理并填写故障处理报告。 1.2.7.2.21. 将所有的警告日志存档
每周定时登陆各数据库服务器，为减少文件系统使用，便于查看告警日志及对历史问题的回顾及跟踪，定期备份清理所有告警日志。并填写数据库维护报告.
1.3. 技术方案 1.3.1. 安全管理
1.必须严格遵守国家、总局和西藏自治区税务局相关的安全保密制度。 2。投标供应商需要与西藏自治区税务局签订保密协议,运维工程师也要与西藏自治区税务局签署保密协议，并严格遵守。
3.运维工程师必须严格遵守西藏自治区税务局办公安全管理要求，私有设备（包括计算机、笔记本、移动存储设备等）一律不许带入办公区，确因工作需要须填写私有设备进入申请单，经批准后使用,但不得接入办公区内网。
4.严格内外网管理，未经允许，不得擅自从内网拷贝并向外携带办公区数据、文档、程序等信息资源，确因工作需要，须填写内网刻录文件申请单，批准后方可在指定计算机用光盘进行拷贝。外网的数据进入内网，必须在指定计算机上，并进行严格检查杀毒后，方可进入内网，避免将病毒或木马等带入。
5.办公区计算机设备使用和安全要求严格遵循国家税务总局西藏自治区税务局设备安全管理的规定。办公区外网计算机需安装指定系统及防毒软件等必要软件,严禁接入办公区内网，不得保留与工作有关的文档、图片等电子文件,因工作需要上传下载的文件须及时删除。
6.办公电脑必须要安装西藏自治区税务局规定的监控软件和杀毒软件；办公电脑不得安装和工作无关的软件；不得随意重新安装电脑操作系统，确因工作需要,须由采购方主任批准后方可安装。
7。运维工程师要设立专门的电子邮箱接收、发送工作过程中的各类文档，
重要文档要进行加密处理，用户名、密码、涉税数据等不得通过外网传递。 1.3.2. 运维应急方案
➢ 为保证用户使用效果，提高业务人员服务质量，在一定程度上提高纳税人服
务满意度，充分考虑系统运行维护工作过程中可能发生的各种不确定因素，防范风险，我们为本次运维采购中运维服务工作制定了专门的《系统安全预案规范》.
1.3.2.1. 应急指挥管理小组及职责
1、安全事故分级
➢ 一级事故（重、特大事故）
➢ 因系统故障障而引发的业务中断,宕机等突发性情况造成大面积人业务人员
无法办理业务，特别是因此造成用户投诉的事故，属一级事故； ➢ 二级事故（较大事故）
➢ 因系统故障障而引发的业务中断,宕机等突发性情况造成小面积人业务人员
无法办理业务,特别是因此造成用户投诉的事故，属二级事故； ➢ 三级事故（一般事故）
➢ 因系统故障而引发的系统不能流畅办公,或者短时间宕机等突发性情况造成
小面积人业务人员无法正常办理业务，属三级事故； 2、应急指挥管理小组成员设置
为了加强对系统运行故障的应急处理，制定事故处理意见及同类事故防范措施,特建立安全事故三级应急指挥管理小组。(其中一级事故为公司级，二级事故为部门级，三级事故为项目组级）6 问题记录小组 故障处理小组 结果反馈小组 问题归档小组 总指挥 副总指挥 一级应急小组（公司级） 总 指 挥：公司负责人 副总指挥：部门负责人
其他：部门骨干及项目骨干和参与人员 二级应急小组（部门级） 总 指 挥:部门负责人 副总指挥：项目负责人 其他：项目参与人员 三级应急小组（项目组级) 总 指 挥：项目负责人 副总指挥：项目骨干 其他：项目参与人员
3应急指挥管理小组及各成员职责 应急小组职责：
发布和解除应急抢险行动命令。
向上级部门和有关单位报告事故的情况。 负责事故调查的组织工作。
负责总结事故的教训和应急抢险经验。 总指挥职责：负责组织全公司的应急指挥工作. 副总指挥职责:协助总指挥负责应急的具体指挥工作。 问题记录组：负责问题的采集,分析及上报工作. 故障处理组:负责问题具体处理。
结果反馈组：负责沟通协调，事后改善工作。 问题归档组:负责总结事故的教训和应急抢险经验 其他:负责协助应急的处理。 1.3.2.2. 应急响应
1、发出警报
一旦现场人员发现紧急情况，现场判定是否立即启动应急程序.如启动应急程序，立即通知有关人员赶赴现场。应急总指挥（或副总指挥）了解情况或者赴
到现场后,根据事故情况，决定是否立即向公司领导汇报。公司领导接到报告后，并根据情况决定是否启动公司级事故应急处理程序。
2、接警要求
接警人员问清事故发生的时间、地点、事故情况及报告人的姓名、联系电话、并详细记录。
所有人员接到报警后，应采取最快的交通方式,正常条件下应保证30分钟内开始处理。
应急抢险人员，必须保证通讯一天24小时畅通. 3、报警要求
报警要求：发生事故后，不得瞒报、迟到、误报、谎报。报警时应口齿清楚，尽量使用普通话，要讲清事故的详细地点和大概情况。
4、初始应急响应
在紧急情况下,当班的现场人员组成初始应急响应组织。初始应急组织应立即采取有效行动，控制事故范围。
如事故较为严重，应立即报告公司领导及客户领导,向外协助控制事故态势。 5、进一步应急响应
一旦确定需要进一步进行应急响应，根据报警程序进行通知,紧急启动公司一、二级事故应急程序。
6、防护行动
防护行动是为预防或尽可能减小事故扩大的应急行动，如果不采取防护行动，就可能造成更大损失。 1.3.2.3. 客户应急处理方案
首先问题记录小组发现问题后无论何种情况立马启动三级应急预案程序,由总指挥现场判断决策是否升级为一二级应急预案。
三级应急处理
如暂不升级为一二级预案，则由三级事故应急总指挥协调副总指挥共同制定应急处理办法,事故处理小组根据解决办法执行解决，总指挥和副总指挥实时跟进问题解决进度，同时安排问题反馈小组进行客户沟通,以及制定善后处理办法，由问题归档小组跟进问题记录，进行问题追踪分析。解决进度过程中，问题反馈
小组与客户保持不间断沟通，事故处理完毕后，由问题反馈小组报告客户，并且制定向客户及领导汇报的报告。由问题归档小组制定经验总结和防范措施.
二级应急处理
如事故由三级应急总指挥确定上升为二级预案，则由二级事故应急总指挥协调副总指挥共同制定应急处理办法,事故处理小组根据解决办法执行解决,总指挥和副总指挥实时跟进问题解决进度，同时安排问题反馈小组进行客户沟通,以及制定善后处理办法，由问题归档小组跟进问题记录，进行问题追踪分析。解决进度过程中,问题反馈小组与客户保持不间断沟通，事故处理完毕后,由问题反馈小组报告客户，并且制定向客户及领导汇报的报告。由问题归档小组制定经验总结和防范措施。
一级应急处理
如事故经三级事故应急总指挥或者二级事故应急总指挥进一步上升为一级预案,则由一级事故应急总指挥协调副总指挥共同制定应急处理办法，事故处理小组根据解决办法执行解决，总指挥和副总指挥实时跟进问题解决进度，同时安排问题反馈小组进行客户沟通，以及制定善后处理办法,由问题归档小组跟进问题记录，进行问题追踪分析。解决进度过程中,问题反馈小组与客户保持不间断沟通,事故处理完毕后，由问题反馈小组报告客户，并且制定向客户及领导汇报的报告。由问题归档小组制定经验总结和防范措施。由公司级事故领导小组成立专门的汇报和善后解决小组,负责善后赔偿等问题。 1.3.2.4. 附则
术语和定义:本项预案各术语及定义参见公司安全事故综合应急预案。 维护和更新:本预案至少每年评审一次性更新有关数据，并根据实际情况对预案进行修改。
应急预案实施:本预案自项目中标签订合同后立即实施。
因篇幅问题不能全部显示，请点此查看更多更全内容