吉林省计算机应用系统运维工作流程.docx

吉林省计算机应用系统运维工作流程.docx

《吉林省计算机应用系统运维工作流程.docx》由会员分享，可在线阅读，更多相关《吉林省计算机应用系统运维工作流程.docx（13页珍藏版）》请在冰豆网上搜索。

吉林省计算机应用系统运维工作流程

全省计算机应用系统运维工作流程

（讨论稿）

第一章总则

根据《全省计算机应用系统运维管理暂行办法》的有关要求，制定省局运维工作流程，旨在规范运维工作的相关行为，以此提高运维工作的质量和效率。

运维工作流程主要包括事件管理流程、问题管理流程、变更管理流程、需求变更流程。

省局信息中心将根据运维工作的需要，在不断完善现有工作流程的基础上，补充新的业务流程。

第二章术语和定义

为了方便在日常维护工作能够对工作内容进行更加清晰的定义和了解，避免误解，因此，特对相关术语进行定义和描述。

1、事件和事件管理

事件指在某一服务中不属于标准操作的、并能导致或可能导致这个服务的中断或服务质量下降的任何情况。

服务台接收到的所有呼叫都称之为事件（包括业务类咨询）。

事件管理则指对事件的响应、监控、追踪、关闭，直至恢复正常服务的一系列过程和活动。

2、问题和问题管理

问题指引起一个或多个现存或潜在事件的、非预料的深层次根源。

问题是事件的起源。

问题管理则指对问题的响应、回复、处理、关闭的一系列过程和活动。

问题管理的目标是消除引起事件的深层原因。

3、变更和变更管理

变更指IT环境中的各要素，如网络基础设施、各系统的服务器、数据库和应用等的变动和更改，包括设备增减、配置改变和结构变化等情况。

变更管理是指从对变更请求的处理、批准、变更的准备、实施、实施后的确认或拒绝、恢复管理、变更的控制和跟踪，到终形成变更管理报告的一系列管理过程和活动。

4、需求变更和需求变更管理

需求变更是指经由省局相关业务处室提交的软件处理与业务处理存在差异的情况。

需求变更管理是指从对变更请求的处理、批准、变更的准备、测试、推广等一系列管理过程和活动。

5、应用部门

应用部门是指信息化日常服务需求的主要提出者和服务提交的对象，是运维工作的主要服务对象。

这里泛指提出服务请求的单位或个人。

6、运维服务台

服务台是运维工作全部运维需求的单一联络点，是运维工作的统一出入口，联络方式为电话、EMAIL或通过运维网提交运维需求，运维服务台负责接收和归集问题、解答问题以及问题的甄别、分发和反馈工作，即受理各地通过电话、运维网提交的各类运维需求并按照需求的实际情况进行相应的规范化处理。

7、业务支持组

省局征管处与相关业务处室指派专人组成业务支持组，由征管处负责日常工作，业务支持组主要负责解决经由运维服务台提交的各类业务类问题。

8、技术支持组

技术支持组由信息中心内部技术力量构成，负责受理由服务台转交的事件请求，为用户提供现场或远程的技术支持，并形成事件处理报告反馈到服务台。

9、高级技术支持组

省信息中心与运维合作单位指派专人组成高级技术支持组，由信息中心负责日常工作，高级技术支持组主要负责发现解决运维过程中出现的技术难题。

第三章业务事件管理流程

一、参与方

1、服务台——系统运维出入口。

2、业务支持组——相关业务运维人员。

二、关键活动

1、用户通过电话、email或通过运维网提交电子版或文本格式（服务台运维岗填写）的《事件工单》，对所发生的事件进行详细描述，服务台接收《事件工单》，并给出收到确认。

2、服务台根据记录的事件情况判断该事件是否已重复发生，如果从未发生，则直接流转到业务支持组，如果该事件曾经发生，则继续判断是否有解决方案。

●如事件库中已有解决方案并能够解决事件，则关闭事件并填写《事件工单》处理意见；

●如事件库已有解决方案但此类事件重复出现超过3次，则升级为问题，填写《问题工单》，关闭事件。

●如事件库中没有解决方案，提交业务运维岗处理；

3、业务运维岗收到来自服务台流转的事件，首先复查事件记录进行分析。

●经过分析核实，如事件库已有解决方案但此类事件重复出现超过3次，则升级为问题，填写《问题工单》，关闭事件。

●经过分析核实，如事件库中有解决方案且能够解决事件，则恢复服务，同时将解决方案报告填写入《事件工单》中。

●经过分析核实，如事件库中没有解决方案，则提供解决方案，同时将解决方案报告填写入《事件工单》，如需要进行变更处理的转入变更管理流程。

4、服务台得到来自业务支持组的解决方案后，确认《事件工单》已经填写完成，与用户确认事件处理意见，并将处理结果存入事件库，对于《问题工单》转入问题管理流程。

三、输入/输出

1、主要输入：

《事件工单》

2、主要输出：

事件解决报告、事件解决方案

四、流程图

第四章技术事件管理流程

一、参与方

1、服务台——系统运维出入口。

2、技术支持组——技术运维岗。

3、高级技术支持组——合作运维单位/设备供应商与信息中心共同组成的技术组。

二、关键活动

1、用户通过电话、email或通过运维网提交电子版或文本格式（服务台运维岗填写）的《事件工单》，对所发生的事件进行详细描述，服务台接收《事件工单》，并给出收到确认。

2、服务台根据记录的事件情况判断该事件是否已重复发生，如果从未发生，则直接流转到技术支持组的相应技术运维岗，如果该事件曾经发生，则继续判断是否有解决方案。

●如事件库中已有解决方案并能够解决事件，则关闭事件并填写《事件工单》处理意见；

●如事件库已有解决方案但不能自行处理或此类事件重复出现超过3次，则升级为问题，填写《问题工单》，关闭事件。

●如事件库中没有解决方案，则提交技术支持组处理；

3、技术支持组的技术运维岗收到来自服务台流转的事件，判断服务台事件分派是否合理，如事件分派不合理，则返回服务台重新确定分派对象，如果合理则复查事件记录进行分析。

●如事件库中有解决方案且能够解决事件，则判断是否需要变更，如需变更，则形成变更申请；不许变更，则恢复服务，同时将解决方案报告填写入《事件工单》中；

●如事件库中没有解决方案，且自身无法提供合理的解决方案时，则转入高级技术支持组。

4、高级技术支持组得到来自技术支持组流转的事件，首先复查事件记录进行分析。

●如不能解决问题，则填写《事件工单》的“退回意见”，发布故障公告；

●如有解决方案且能够解决问题，则恢复服务并提供解决方案及计划同时填写《事件工单》。

5、服务台得到来自技术支持组或高级技术支持组的解决方案后，确认《事件工单》已经填写完成，与用户确认事件处理意见，并将处理结果存入事件库。

三、输入/输出

1、主要输入：

《事件工单》

2、主要输出：

事件解决报告、事件解决方案、

四、流程图

第五章问题管理流程

一、参与方

1、服务台——系统运维出入口。

2、高级工程师——信息中心总工程师。

3、技术支持组——相关技术运维岗人员。

4、高级技术支持组——合作运维单位/设备供应商与信息中心共同组成的技术组。

二、关键活动

1、服务台接受用户的事件请求后判断为重复出现、已有解决方案但不能自行处理的事件，进入问题管理流程，同时填写《问题工单》。

2、高级工程师接收到从服务台转入的问题请求，首先判断问题请求是否成立：

●成立，则提出问题解决方案建议，由技术支持组进行问题解决。

●不成立，则回复服务台，同时填写《问题工单》。

3、技术支持组相应技术运维岗得到问题后，首先收集相关的信息（包括现象、配置、产品类型、供应商或开发商等），根据信息判断高级工程师提交的解决方案是否可行：

●如能够解决问题，则将解决方案填入《问题工单》中且关闭问题，同时将解决方案提交事件库，并判断是否需要进行变更，按情况提交变更申请：

●如不能解决问题，则将问题返回给高级工程师，同时填写《问题工单》。

4、高级工程师将技术支持组不能解决的问题返回服务台，转交高级技术支持组处理，高级技术支持组将解决方案填入《问题工单》后，关闭问题，同时将解决方案提交事件库。

三、输入/输出

1、主要输入：

服务台转交的问题请求（通过《问题工单》提交）。

2、主要输出：

问题的解决方案（由技术支持组或高级技术支持组给出，并填写在《问题工单》中）。

四、流程图

第六章变更管理流程

一、参与方

1、变更申请人——业务支持组、技术支持组或高级技术支持组相关人员。

2、变更控制管理员——是指按照岗责分工负责与变更内容维护有关的运维人员，如涉及数据库的变更，则变更控制管理员则指数据库运维岗相关人员。

3、变更实施组——信息中心内/外部技术支持人员。

4、变更评审委员会——由信息中心相关主管领导和相关业务部门领导组成的临时组织，主要负责审批变更计划和变更方案，以确保变更后系统正常运转。

二、关键活动

1、变更申请人定期（每季度、半年或一年）或不定期通过服务台提出变更申请（软件、硬件设施），并初步拟定变更实施计划和实施方案，并将该请求提交变更控制委员会。

2、变更控制委员会根据变更实施计划和方案，组织相关的人员进行评审，并及时反馈评审意见，通知变更申请人进行调整。

3、变更控制管理员根据通过评审的变更实施计划和实施方案，填写《变更工单》，组织变更实施组进行变更。

●如果实施有效，则将变更结果报告填入《变更工单》，返回变更控制管理员；　

●如果实施无效，则恢复原有的IT配置，并将变更取消意见填入《变更工单》，返回变更控制管理员；

4、变更控制管理员将变更实施组提交的返回意见及时告知业务部门变更完成。

将变更计划和实施方案提交事件库做存档处理，同时完善变更报告。

三、输入、输出

1、主要输入：

变更实施请求（通过《变更工单》提交）。

2、主要输出：

变更实施计划、变更实施方案及最终变更报告（变更实施计划和变更实施方案可填写在《变更工单》中）。

四、流程图

第七章需求变更管理流程

一、参与方

1、业务处室——需求变更提出单位。

2、信息中心——需求变更的受理及组织单位。

3、开发商——具体施工的单位。

4、主管领导——需求变更处室的主管领导。

5、试点单位——需求变更调整后的试运行单位。

二、关键活动

1、业务处室提出变更申请并在部门领导审核后，提交主管领导批准。

2、主管领导批准后业务部门向信息中心提交系统变更申请，信息中心接收申请后，组织人员对变更申请进行可行性分析设计。

●可行性分析设计完成后，则组织包括开发商在内的人员进行专家评审。

●如果可行性分析设计存在问题，则将变更申请返还给提交申请的业务部门进行相应调整。

3、专家评审通过后，开发方需提交变更评审报告。

4、业务部门与信息中心组织人员编写详细需求分析，同时，分析需求变更是否涉及开发经费的问题。

●如果不需要增加开发费用，则信息中心直接提交开发商进行开发。

●如果需要增加开发费用，则需要经主管领导审批后方可提交开发商进行开发。

5、开发商接到提交的开发申请以及需求分析，进行概要设计、详细设计及程序编码阶段。

并在开发完成后，进行系统测试，通过后，向信息中心提交系统测试报告。

6、信息中心接到开发商提交的系统测试报告后，组织试点单位进行系统测试和试运行。

●如果测试结果达到要求，则进入上线推广、运维阶段。

●如果测试结果不能达到要求，则将系统测试报告提交给开发商，供开发商调整设计文档。

三、输入、输出

1、主要输入：

需求变更申请。

2、主要输出：

变更评审报告、系统测试报告。

四、流程图

附件3运维岗位说明书样式

吉林省地税局（）岗位说明书

一、岗位标识信息

岗位名称：

岗位编码：

直接上级：

隶属维护编组：

直接下级：

人员名称：

可轮换岗位：

填写日期

二、岗位工作描述

三、工作职责与任务

四、工作绩效标准

五、岗位工作关系

内部关系：

外部关系：

六、岗位工作权限

七、岗位工作时间

八、岗位技能要求

九、其他素质要求

事件（问题）工单参考样式

编号：

提交人

联系电话

提交部门

提交日期

事件描述

解决建议

主管领导审核意见：

领导签字：

接收人

接收日期

问题诊断

问题分析

业务类

□业务类□业务综合类

技术类

□技术类□技术综合类

□直接答复

答复内容：

□问题流转

流转岗位编码

领导意见

承办人

接收日期

问题处理

□答复

答复内容：

□处理时限

□延期答复

领导意见

问题回复

  部门负责人签字：

问题归类

业务类

□业务理解□业务需求□数据维护□其他（）

操作类

□操作错误

技术类

□程序□数据库□中间件□操作系统□网络□其他（）

发布审核

部门负责人签字：

填表说明：

1、报告单编号，问题归类由运维服务台填写，

2、接收人、承办人及接收承办部门领导需签署意见并签字；