信息系统运维事件管理规范1.1适用范围本规范适用于信息系统运维事件,包括对信息系统的使用咨询,系统故障,以及有关业务应用的支持要求。1.2定义与术语术语术语解释岗位AB角一个岗位安排两个人,其中一个主要负责,称为A角,当A角不能履行职责时,由B角替代。呼叫中心接收用户运维请求的受理平台。事件管理和呼叫中心一起组成事件处理流程,有效解决各类IT突发事件,尽快恢复IT服务。配置管理管理各IT资产系统(配置元素,配置项)的流程,包括相互间的关联与依赖关系。配置管理数据库对所有IT组件、组件的不同版本和状态以及组件之间的相互关系进行跟踪、记录。运维管理知识库操作指南,开发文档、技术文档、验收文档等技术资料的集合。影响程度问题造成对IT环境的影响范围,包括对其他IT系统,对相关人员等。优先级问题需要找到解决方法和处理措施的紧急程度。重大故障在各系统的系统故障分级中定义为一级故障的故障现象,均视为重大故障。一般故障在各系统的系统故障分级中定义为二、三级故障的故障现象,视为一般故障。1.3角色与职责本过程设立运维负责人、支持受理人、问题反映人、各系统管理岗,岗位设立AB角,负责信息系统运维事件的管理,具体职责要求如下:序号角色名称定义/职责1运维负责人1.全面负责运维各项工作。2.审核审批各项运行维护制度规范和工作流程,负责协调各部门间的工作。3.负责与其他部门间的协调工作。4.负责建立健全本级运维与上级运维部门、本级运维与下级运维之间高级技术支持之间的顺畅沟通机制。5.负责本级运维队伍的管理、培训工作。6.负责落实上级运维部门提出的运行维护任务。7.管理运行维护部门员工的工作。8.通过呼叫中心事件管理报告,监控事件管理的效率,改善运维服务质量。9.负责系统重大故障及紧急事件的处理,并负责组织进行相关事故原因的调查分析,形成事故分析报告和相应的解决方案。10.在业务部门,信息中心领导,以及信息中心内部维持良好的沟通渠道。11.完善和维护事件管理系统。2支持受理人1.负责接收用户反映的信息系统问题,并对问题记录、整理。2.负责对事件分类和提供初始的支持。3.将问题的解决步骤文档化。4.将服务请求分派给适当的工作组。5.跟踪服务请求的处理过程以确保在规定的时间内解决问题,同时在系统里更新相应信息。6.对于无法解答的技术问题,及时转送其他相关人员;序号角色名称定义/职责对于无法解答的业务问题,及时提交运维负责人。7.与服务请求的提交者进行直接的沟通,通报事件的处理情况。8.在结束事件之前要确认服务请求的提交者对事件的解决过程及结果是否满意。9.作为事件的责任人,监控,跟踪所有的事件处理过程,并作为和客户沟通的唯一联系点。10.编制管理信息报告。3问题反应人1.对于本级运维解决有困难的问题,负责向上级运维中心、高级技术支持或国家电网运维部门及时准确地上报。2.对于紧急、重大故障问题,负责向上级运维中心、高级技术支持或国家电网运维部门及时准确地上报。3.负责全程配合、协助国家电网解决上报问题,并跟踪问题的进展、解决、落实过程。4系统管理员1.在规定的时间内解决服务请求。2.对利用“临时方案解决的服务需求,在资源及时间允许时应找到问题根源。3.在需要时(有重大故障及升级需求时),及时利用其它资源(开发商或供应商)帮助用户解决问题。4.将服务请求的解决方案的步骤文档化,并录入系统。5.更新文档记录。6.和主机管理人、存储管理人、数据库管理人、中间件管理人一道,对业务系统实行全方位的管理。1.4工作流程与活动参与事件管理、服务请求管理、重大故障处理、事件升级、一般事件处理、服务报告管理流程涉及的系统运维工作。具体工作内容如下:1.3.1事件管理运维事件管理的总体流程如图1《问题响应管理总体流程》所示:1.支持受理人接受来自各种渠道的服务请求、告警、故障事件等;2.通过服务请求管理系统将事件进行记录、分类、确定优先级;3.根据预定义的重大故障分类,判断是否启动《重大故障处理流程》(见图3);4.如遇紧急事件,则直接执行《升级流程》(见图4),由运维负责人直接调用适当资源尽快处理;一般事件则执行《一般事件处理流程》(见图5)。问题响应总体流程系统管理员系统管理员支持受理人支持受理人最终用户最终用户是否否是重大系统故障?服务请求紧急事件?系统事件重大故障处理流程服务呼叫一般事件处理流程服务管理报告结束升级流程(图1问题响应管理总体流程)1.3.2服务请求管理1.支持受理人接受来自各种渠道提交的有关信息系统运维的服务请求、告警、故障事件等;2.确认事件请求人是否属于服务对象。如果不是,则拒绝服务转交其它部门处理;问题概要需要在《服务请求记录表》(见附录1)中进行详细的记录,如详细情况描述;1)按照预定义的“系统服务分类”对事件涉及的系统进行分类,如:网络系统,主机系统、营销系统等;2)根据预定义的配置管理数据库的相关内容,将事件与配置项联系起来;3)选择事件的影响程度:低:造成个别用户不能正常访问。中:局域网内超过5%的用户不能正常访问。高:营销系统、“95598”系统等核心业务系统大面积瘫痪,不能正常对公众提供服务,造成负面的社会影响。4)选择优先级:无优先级:无时限要求,在方便的时候排除故障。低:24小时内排除故障。中:8小时内排除故障。高:4小时内排除故障。最高:2小时内排除故障。服务请求管理流程如图4所示。服务请求管理支持受理人支持受理人最终用户最终用户重大系统故障?一般事件处理流程服务呼叫紧急事件?升级流程记录服务请求事件概要及现象描述服务呼叫类别及系统服务分类选择配置项目选择影响程度判断优先级重大故障处理流程是否是否AABBCC(图2服务请求流程)1.3.3重大故障管理支持受理人完成服务请求流程后,如果事件是属于影响程度最高的故障,则即刻启动《重大故障处理流程》;1.向最终用户发出服务中断通知;2.支持受理人同时要尽快将故障情况向运维负责人汇报;3.运维负责人应立刻通知相关领导以及灾难恢复领导小组(由主要业务部门领导,信息中心领导,主管领导等组成),决定本故障是否通过上级运维部门才能解决,如果是,则由问题反映者联系上级运维中心,上级运维部门根据有关流程予以解决;4.如果不用上级运维部门解决,则根据恢复时间标准确定是否启动应急预案;确定需要启动应急预案后,由应急预案小组执行恢复计划,使系统尽快恢复运作;5.同时运维负责人要召集所有相关技术专家(项目组技术负责人,服务商,厂商以及各系统管理员)进行集中诊断,制定系统修复方案。并由相关系统管理人联合服务商一起执行系统修复方案;6.系统修复并经测试成功后,支持受理人发布系统服务恢复通告;7.联合系统管理员在服务请求系统中将故障的所有信息进行更新,如解决方案,关闭代码,如果在呼叫登记阶段录入的配置项目,分类等有误,需要一并修正;8.联合相关系统管理员准备“重大故障责任报告”并提出整改措施;9.运维负责人负责审阅批准重大事件责任报告,并向相关领导分发此报告;10.运维负责人负责跟进整改措施。重大故障管理流程如图5所示。重大故障处理流程运维负责人运维负责人应急管理小组应急管理小组上级运维部门上级运维部门系统管理员系统管理员支持受理人支持受理人整改措施跟进结束签署“重大故障责任报告”系统恢复通告执行系统修复及测试系统服务中断报告确定是否启应急计划/灾恢复计划上级运维部门联合相关系统管理员准备“重大故障责任报告”确定是否转交上级运维部门处理更新事件记录分发“重大故障责任报告”应急计划/灾备恢复计划通知相关领导及应急管理小组A召集相关服务商,系统管理员集中诊断,制定服务修复方案否否是是(图(图3重大故障处理流程)1.3.4事件升级如果支持受理人接到紧急的服务请求(优先级最高),或在一般事件处理流程中,事件的完成时限超过了承诺的服务时限时,支持受理人可以启动升级流程。1.支持受理人通知运维负责人,请求支持;2.运维负责人协调相关资源解决问题;3.支持受理人负责跟踪事件进度以及确定事件状态;4.事件解决后,由支持受理人与服务请求者确认并更新事件记录;5.支持受理人关闭事件。事件升级流程如图4所示。事件升级流程运维负责人运维负责人支持受理人支持受理人事件解决?B跟踪事件进度确认事件状态并执行相应流程电话通知运维负责人请求支援更新事件记录及解决方案协调相关资源向用户反馈确认更新事件记录及解决方案结束事件否是(图4事件升级流程)1.3.5一般事件处理1、支持受理人接受的服务请求如果不属于“重大故障”或“紧急事件”,按照《一般事件处理流程》完成事件的处理。一般事件处理流程如图6所示。2、如果服务请求属于指定工作组的责任,支持受理人直接将服务请求分派给各工作组。对分派给指定工作组的事件,支持受理人要负责跟踪事件的解决状态,并定期监督相关服务人员尽快完成。如果相关服务组在接近服务时限(可定为超过服务时限的80%的时间)仍没有确定的解决方案,支持受理人需请求相关专家协助完成。对不能在服务时限内完成的事件,支持受理人应通过《升级流程》加快事件的解决速度。事件解决后,支持受理人通过电话等方式与呼叫者进行确认,并更新事件记录,关闭事件。3、对于非指定工作组处理的事件,支持受理人对事件进行诊断分析,尝试解决。4、对不能在线及时解决的事件,支持受理人应先在运维管理知识库中查找相应解决方案,找到解决方案后,尽快完成服务请求。不能解决的事件,请尽快根据服务范围职责划分(服务支持流程人员表),将事件升级给二线支持人员,并跟踪事件处理状态。如果相关二线支持服务组在接近服务时限的最后期限(可定为超过服务时限的80%的时间)仍没有确定的解决方案,相应系统管理人则需判断是否需要报请上级运维部门予以解决。如果需要,则通过问题反映者向上级运维部门报告,上级运维部门则按有关流程予以解决,如果不需要则请求三线支持人员协助完成。对不能在服务时限内完成的事件,支持受理人应通过《升级流程》加快事件的解决。事件解决后,支持受理人通过电话等方式与服务请求者进行确认,并更新事件记录,关闭事件。一般事件处理流程二线支持二线支持三线支持三线支持支持受理人支持受理人请求专家支持更新事件记录跟踪事件处理状态分析解决问题事件解决?预期可在服务时限内完成?是否解决?是否转交上级运维部门处理?与呼叫者确认响应服务请求在服务时限内完成?上级运维部门流程升级流程响应服务请求C尝试解决是否根据分类将服务请求转派给相应工作组否是否否是是否否(图5一般事件处理流程)支持受理人是事件管理流程的一线支持。各应用系统管理员、网络管理员、主机管理员等是事件管理流程的二线支持工程师。开发商、集成商、设备供应商等外部服务专家是事件管理流程的三线支持。1.3.6服务报告管理服务主管每月利用服务记录表,按照服务管理的指标分类整理各类数据,形成服务请求管理报告,提交给运维负责人进行审阅。运维负责人负责与相关部门及业务部门针对服务管理报告进行沟通,如果必要提出诸如用户培训、系统优化等建议,并负责跟进改进计划。1.5管理原则1、运维中心应设立呼叫中心,做为IT服务管理与用户的接口,受理并处理用户的服务请求。没条件设立呼叫中心的服务机构应设立服务热线。2、除非特别的服务说明,任何事件处理不应绕过服务热线来解决。3、所有最终用户的服务请求应由统一的系统记录在案,并通过系统完成工作分派,监测跟踪,事件升级管理和质量管理。4、呼叫系统应包含对事件处理进行跟踪及监控的流程。5、负责呼叫系统的员工应尽最大可能在一线解决用户的问题。6、对所有问题的解决方法应在呼叫系统所使用的系统工具中存档。7、应尽量将服务请求与配置项目联系起来。8、应及时向提交问题的最终用户通报问题的处理情况,系统维护服务的进度和情况也应由服务请求支持员工与最终用户进行沟通。9、服务请求完成后应确定最终用户对事件解决方案的满意程度。10、应完整的描述和记录当前信息中心为其它部门所提供的服务、服务级别、以及提供响应的流程文档。1.6附录1.6.1附表1服务请求记录表服务请求记录表请求信息报修时间故障地点客户电话IP地址记录人系统服务分类