事件管理流程设计样例

1、信息中心事件管理流程业务需求文档日期:2012-11-26文档版本: V 0.1 目录事件管理流程业务需求文档11. 介绍1.1. 文档简介本文介绍XXXX信息中心事件管理流程和对工具的业务需求，供参与信息中心IT运维管理系统事件管理流程模块的开发和测试人员使用。1.2. 文档目的为了保证即将建设的“IT运维管理系统”符合XXXX信息中心建设全省一体化协同运维体系的要求，本文对“IT运维管理系统”中的事件管理模块的业务需求进行细化。事件管理流程以确保在故障发生后尽快地恢复服务，减小对业务的影响。事件管理流程关注快速地解决故障现象而非查找故障背后的根本原因。1.3. 前提与假设读者应该了解ITI

2、L，并对事件管理流程具有基本的技能。1.4. 文档结构本文由以下几个章节组成：第一章，“介绍”，描述了本文的适用对象、组织，以及相关术语。第二章， 介绍“事件管理流程”的业务逻辑，定义了总体流程，详细流程，流程步骤、角色及职责、业务规则、事件单代码、流程衡量指标。第三章，介绍“事件管理流程”的工具功能需求以实现其业务逻辑，从工具用户特点、工单流程、与其他流程关系和流程评估和改进四个方面阐述。第四章， 介绍服务台结构，省市服务台逻辑及联动模式，及为实现该种模式服务台业务逻辑的工具功能需求。1.5. 术语为方便相关人员对事件管理流程的理解，下表对事件管理流程中涉及的术语进行解释。名词解释ITIL(

3、IT Infrastructure Library)是英国政府在1987年制定的有关IT服务管理的最佳实践，现已成为事实上的IT管理标准。事件管理流程ITIL流程之一，事件管理负责处理IT事件和用户请求。它的目的是尽快恢复被中断或受到影响的IT服务，是以快速解决故障现象为目的，而不在于查找根本原因。IT服务XXXX省局信息中心和地市信息科提供给全省税务系统业务部门的IT支持服务内容。事件不包含在标准服务操作之内，导致或可能导致服务中断或服务质量降低的事件。范围包括XXXX信息中心维护范围内的所有与IT基础架构和应用系统相关的故障、咨询和服务请求。事件单事件在流程管理系统中的数据记录。解决方案是

4、指针对某一个或某一类已找到根本原因的问题，提出的解决问题的最终方案。变通方法（也称临时措施）是指解决事件的临时修复方法或技术，目的是使用替代措施暂时恢复SLA约定的服务，避免事件继续对客户的业务产生影响，该事件的永久解决措施有赖于对该事件潜在问题的最终解决。IT用户XXXX省局信息中心和地市信息科的服务对象。监控服务台监控服务台是信息中心为用户提供服务的唯一接口，是全省一体化协同运维体系中的重要组成部分。监控服务台的主要工作内容是记录和受理事件内容，通过知识库提供初始支持，或通过功能型升级到对应的运维组帮助用户恢复到正常工作状态。事件分析员进行事件处理的支持人员，通常对应信息中心的二线或三线支

5、持人员。事件经理负责协调和管理事件管理流程的各项活动。运维办事件经理流程所有者，负责对流程的审计和评估，持续改进该流程。CIConfiguration item 配置项RFCRequest for change 变更请求单CMDB配置管理数据库2. 事件管理流程2.1. 流程概述XXXX事件管理流程包括地市事件处理和省局信息中心事件处理两个部分。整个流程、执行步骤和各步骤执行的顺序参见流程概览图。这个流程旨在确保全省所有与省级集中信息系统相关的事件得到有效记录和跟踪，使事件能在最短的时间内得到解决，并为问题管理等其它服务管理流程提供相关信息。要达到这个目标的重点在于：l 各地市信息科首先对事件

6、进行有效记录和过滤，如果本级不能处理，则确保升级至省局的事件单信息完整和准确；l 地市和省局信息中心服务台准确分类分级事件；l 准确的将故障单分派给后台技术支持组或人员；l 确保用户对于事件的解决方案是满意的。事件管理流程由事件驱动，关注事件的响应速度以尽快恢复业务运营。2.2. 流程步骤描述2.2.1. 事件记录（地市）2.2.1.1. 描述:事件的记录是事件管理流程的起点。所有用户报告或系统产生的IT事件都必须从这个步骤开始。该步骤的目的是快速、准确地探测和捕捉到在IT生产环境中发生的错误。除此以外，该活动也是其它用户相关请求的入口，诸如信息咨询、服务请求。本步骤的重点是准确、完整地采集创

7、建一个事件单所需的必要信息。2.2.1.2. 流程主要内容:输入：任务：输出：· 事件驱动输入： 来自于用户的请求（提交方式：电话、邮件、Web） 运维人员主动发起的事件0.11发起请求0.12识别并验证用户信息0.13信息充分性判断0.14进一步提供信息0.15新事件判断0.16更新相关事件单0.17记录新事件单· 已创建的事件单· 已更新的事件单2.2.1.3. 过程环节:0.11发起请求执行者：用户· 用户向所在地市信息科服务台提交事件请求。· 用户提交事件请求的方式可以有多种：- 通过电话向服务台提交请求；- 通过web 网页形式向运行

8、部提交请求；- 通过电子邮件提交请求；0.12识别并验证用户信息执行者：地市服务台 · 接受用户的事件报告。提示：· 建议通过统一工作平台用户管理，建立客户信息库以提高识别和验证效率；· 可使用电话号码等作为用户的唯一识别；· 在发现现有客户信息库不完整时，服务台需要及时更新；· 对用户信息进行识别和验证，服务台需要尽量多地获取用户基本信息，诸如：- 用户姓名（必填）- 用户标识（是否为VIP用户）- 电话号码（手机）（二者必填一项）- 分机号码- 员工当前所在地点- 所属部门/所属办税服务厅- 地址· 检查该用户是否属于服务对象的范

9、围。· 如有必要，更新用户资料，如联系方式。0.13信息充分性判断执行者：地市服务台 · 对于事件请求，服务台需要判断用户提供的信息是否足够用于后续提供支持，快速恢复服务。 - 如果足够，则进入环节“0.15 新事件判断”· 如果不够充分，则进入环节“0.14 进一步提供信息”0.14进一步提供信息执行者：用户· 用户按照服务台要求补充相关信息；0.15新事件判断执行者：地市服务台 · 根据用户提供的事件描述信息，判断请求是否为新的事件。- 新的事件，进入环节“0.17记录新事件单”- 原有的事件，进入环节“0.16更新相关事件单”0.16更新

10、相关事件单执行者：地市服务台 · 对于原有的请求，根据用户所提供的描述信息，对之前由该服务请求所产生的工单进行进一步补充。· 补充后的工单仍按原有工单流程进行处理。0.17记录新事件单执行者：地市服务台 · 创建事件请求，生成事件单，进入后续流程。· 在事件单中至少需要录入以下事件信息，以下信息需要详细而准确： - 事件单号（系统自动产生）- 事件的标题- 事件的详细信息，包括事件可能造成的服务影响，影响部门等。- 可能的描述事件现象的附件- 事件发生的时间- 事件单创建时间（系统自动产生）- 事件来源- 事件报告人信息· 事件单如果是来自用户

11、，则需要填写用户信息，至少包含以下内容：- 用户姓名 - 用户标识（是否为VIP用户）- 联系电话/手机- 所属部门/所属办税服务厅· 如果该事件单是由运维人员主动发起，运维人员作为事件提交者其相关信息由系统自动填写，至少包含以下内容：- 运维人员帐号或姓名- 运维人员联系电话2.2.2. 事件分类分级与初步支持（地市）2.2.2.1. 描述：该步骤的目的是判断事件级别和分类，随即在现存的解决方案中查询与该事件相匹配的方案，或根据个人经验尝试在线对事件进行处理。若没有找到合适的解决方案或变通方法或需要离线对事件进行处理，该事件需要分配给二线具有合适技术技能的事件分析员。该步骤的重点是

12、正确地分配事件，以避免后面对时间的浪费。2.2.2.2. 流程主要内容:输入：任务：输出：· 来自于步骤0.17新记录的事件单0.21 分类分级0.22 初步支持0.23 能否解决问题0.24 服务台分派事件单3.25 判断是否接受事件单3.26 受理事件单· 已分派的事件单表格 21受理与初步分析内容2.2.2.3. 过程环节:0.21分类分级执行者：地市服务台· 确定事件等级；（具体请参见2.4.7）· 根据事件影响度和紧急度，确定优先级。（具体请参见2.4.8 “优先级规则”）。· 确定CTI分类（具体请参见2.5.4 “事件分类”）。&

13、#183; 如果是省级集中信息系统类事件单，则需标注。0.22 初步支持执行者：地市服务台· 在事件管理中查询已经存在的解决方案/变通方法，或进行知识库有效知识的匹配进行在线事件解决；· 根据事件记录人员所拥有的技能尝试确定“解决方案或变通方法”，进行在线事件解决；· 如果可以解决，转至步骤IM-05“事件单关闭”中的步骤0.51。如果不能解决，转至步骤0.24“分派事件”。0.24分派事件单执行者：地市服务台· 根据事件分类不同，把事件分派给合适的事件分析员；· 若地市二线技术人员认为事件单派转不合理，则事件重新进入“分派事件”环节。0.25

14、 二线受理事件单判断 执行者：地市二线· 地市二线事件分析员接到事件后，判断事件是否分派正确，即是否本人的工作职责和技能范围。如果是，则转步骤0.26。如果不是，说明理由，并须考虑是否需要对事件进行重新分类，以帮助服务台在下一次分派时更准确派单。流程返回步骤 0.24“分派事件”。3.7受理事件单 执行者：地市二线· 如果被分派的事件分析员确认该事件单分派正确，则接受该事件单，进入步骤0.31“故障分析”。2.2.3. 二线受理与诊断（地市）2.2.3.1. 描述: 这个步骤的目标是对事件进行分析以便提出解决方案，不同技术领域的事件分析员将会参与到该步骤中以寻求一个事件解决

15、方案，在有必要时会升级至省局信息中心以便快速解决恢复事件影响。2.2.3.2. 流程主要内容:输入：任务：输出：· 来自于步骤“0.26受理事件单” 0.31收集相关信息0.32是否重复事件0.33 关联至主事件单0.34进行事件分析0.35找到解决方案0.36升级至省局信息中心· 针对该事件的解决方案· 升级至省局信息中心的事件单2.2.3.3. 过程环节:0.31收集相关信息执行者：地市二线· 二线对事件进行处理，并查找可能对事件处理有效的相关信息。· 该处理过程一线往往脱离开流程系统进行，在得到相关信息后，重新登录到流程系统，并将相关信息

16、记录在事件单中。0.32是否重复事件执行者：地市二线· 寻找有相似症状(即由同一原因造成)的事件:- 如找到类似的事件，即进入步骤0.33“关联事件到主事件”，如果在事件诊断过程中发现匹配错误，可以取消此关联。- 如果没有找到，进入步骤0.34“事件单分析”0.33关联到主事件单执行者：地市二线· 判断当前事件单所描述的现象与之前未解决的事件是否有相似：- 如果确认是重复工单或主事件驱动工单，将新的事件单关联到原主事件单- 原有事件单被标识为“主事件单”- 原有事件单关联事件单数加一- 新建事件单出现在原有事件单重复工单列表中· 新事件单状态将随原有事件单状态的更

17、新而更新，不单独进行处理。0.34 事件单分析执行者：地市二线· 检索知识库查询可能的解决方案，查找的途径包括但不限于：- 通过对已记录激活和未激活知识记录进行查询- 通过以往已关闭事件单中的解决方案或处理过程进行查询- 通过其它公共的资料信息进行查询· 根据专业技术经验寻找解决方案或者变更方法。· 经分析如发现解决方案，转到步骤“0.41解决和恢复” · 如未发现解决方案，在转到步骤“0.36升级至省局信息中心”。· 如果在事件恢复和解决阶段未能恢复业务，或者在事件关闭阶段用户不满意解决方案，则需返回“0.34 事件单分析”，由同一名事件分析

18、员继续进行处理。5.8升级至省局信息中心执行者：地市二线· 如果当前地市事件分析员由于某些原因不能解决该事件，需要将事件升级至省局信息中心监控服务台。（只限于省级集中信息系统类事件单）2.2.4. 解决和恢复（地市）2.2.4.1. 描述:该步骤尝试使用解决方案和变通方法来解决事件。某些情况下，需引入变更管理来批准评估实施步骤。对于某些事件，即使得到了解决，仍然需要创建问题单以进一步寻找其根源。2.2.4.2. 流程主要内容:输入：任务：输出：· 来自于步骤“0.35找到解决方案”0.41采取恢复操作0.42验证解决方案0.43服务是否恢复0.44是否进行根源问题分析0.4

19、5创建新的问题并与事件关联· 恢复受影响的服务· 创建根本解决该事件单的问题单2.2.4.3. 过程环节:0.41采取恢复操作 执行者：地市二线· 由二线工程师负责实施以确定的解决方案，以恢复受影响的服务。0.42验证解决方案&0.43服务是否恢复 执行者：地市二线· 验证解决方案的实施是否有效：- 对于方案无效的情况，转到子流程“0.34进行事件单分析”。- 对于方案有效的情况，转到子流程“0.51事件关闭”以及活动“0.44是否进行根源问题分析”0.44是否进行根源问题分析&0.45创建新的问题并与事件关联 执行者：一线·

20、判断是需要对以解决的事件进行根源问题分析：- 对于需要分析的情况，转到活动“0.45创建新的问题并与事件关联”，针对该事件单新建一个问题单或关联到已有的问题单上。- 对于不需要分析的情况，转到步骤“0.51事件关闭”2.2.5. 事件关闭（地市）2.2.5.1. 描述: 这个步骤确保用户对事件的处理情况感到满意。事件单的信息是正确、完整的，以便于以后生成报表。2.2.5.2. 流程主要内容:输入：任务：输出：· 来自于步骤“0.43业务恢复”0.51检查事件记录0.52是否需要与用户确认0.53与用户沟通0.54提供反馈信息0.54用户确认事件是否解决0.56关闭事件单·

21、已关闭的事件单2.2.5.3. 过程环节:0.51检查事件记录 执行者：地市服务台· 对于用户报告的事件单，服务台检查系统中事件单记录的完整性，对于不完整的记录进行补充。0.52是否需要与客户确认&0.53与客户沟通 执行者：地市服务台· 服务台根据事件性质，判断是否需要与用户沟通事件的处理结果，以便确认事件的真正解决。- 如确认需要告知用户事件处理结果的情况，转入活动“0.53与用户沟通”，沟通形式包括但不限于：系统通告，短信告知，邮件通知，电话通知等方式。- 如确认不需要告知用户事件处理结果，转入活动“0.56关闭事件单”0.54提供反馈信息 执行者：用户

22、83; 用户在接受服务台通知后，向服务台提供着呢对事件处理结果的反馈信息。0.55用户确认事件是否解决 执行者：地市服务台· 服务台根据用户反馈确定事件是否被成功解决：- 如确认事件未解决的情况，转入子流程“0.34进行事件单分析”，重新查找事件原因。- 如确认事件已解决的情况，转入活动“0.56关闭事件单”0.56关闭事件单 执行者：地市服务台· 按照关单原则对事件单进行关闭。2.2.6. 事件受理和记录2.2.6.1. 描述:这个步骤是XXXX省局信息中心事件管理流程的起点。所有地市升级至省局信息中心、IT工程师主动报告或监控平台产生的IT事件都必须从这个步骤开始。该步

23、骤的目的是快速、准确地探测和捕捉到在IT生产环境中发生的错误。本步骤的重点是准确、完整地采集创建一个事件单所需的必要信息。 2.2.6.2. 流程主要内容:输入：任务：输出：· 事件驱动输入： 来自于地市信息科升级的事件单 工程师主动发起的事件 通过监控平台发现的告警事件· 其他信息来源 来自失败的变更实施1.1识别并验证事件单信息1.2信息充分性判断1.3进一步提供信息1.4新事件判断1.5更新相关事件单1.6监控告警1.7记录新事件单· 已创建的事件单· 已更新的事件单表格 22记录事件环节的内容2.2.6.3. 过程环节:1.1识别并验证事件单信息

24、&事件单信息充分性判断执行者：省局监控服务台 · 对地市升级的事件单信息进行识别和验证，重点关注如下几点：- 用户基本信息是否完备；- 事件描述是否清晰，是否提供截图；- 事件分类分级是否合理；- 是否有对应“内部呈批表或加盖公章”；- 要求维护参数表代码表，确认是否有提供EXCEL格式的内容。· 监控服务台需要判断地市升级的事件单信息是否足够用于后续提供支持，快速恢复服务。 - 如果足够，则进入环节“1.4 新事件判断”· 如果不够充分，则进入环节“1.3 进一步提供信息”1.3进一步提供信息执行者：用户· 用户按照服务台要求补充相关信息；1.

25、4新事件判断执行者：监控服务台 · 根据地市升级的事件单描述信息，判断请求是否为新的事件。- 新的事件，进入环节“1.7受理新事件单”- 原有的请求，进入环节“1.5更新相关事件单”1.5更新相关事件单执行者：监控服务台 · 将该事件单关联到原有事件单。可对主事件单进行进一步补充相关信息。· 关联后的工单仍按原有工单流程进行处理。1.6监控告警执行者：监控工具/工程师· 监控平台自动触发的，事件告警信息是通过系统接口自动载入的事件。由工程师主动发起，并在系统上自助填写事件单，并转监控服务台受理。1.7受理或记录记录新事件单执行者：监控服务台 ·

26、 受理或记录新事件单请求，进入后续流程。2.2.7. 初步支持2.2.7.1. 描述：该步骤的目的是监控服务台在现存的解决方案中查询与该事件相匹配的方案，或根据个人经验尝试在线对事件进行处理。若没有找到合适的解决方案或变通方法，将事件分配给一个具有合适技术技能的运维组。该步骤的重点是正确地分配事件，以避免后面对时间的浪费。2.2.7.2. 流程主要内容:输入：任务：输出：· 来自于步骤1.7“受理或者记录新事件单”2.1确定事件分类分级2.2重大事件判断2.3 提供初步支持2.4 能否解决事件单2.5 分派事件单2.6接受事件单分派判断2.7 说明理由，返回服务台重新分派事件单2.8

27、报告事件至中心领导层· 已分派的事件单· 管理升级的信息表格 23受理与初步分析内容2.2.7.3. 过程环节:2.1确定事件分类分级&2.2重大事件判断执行者：监控服务台· 确定事件等级是否正确（具体请参见2.4.7 “事件等级”），如果是重大事件则进行（管理升级）· 确定事件分类是否正确（具体请参见2.5.4 “事件分类”）。· 根据事件等级和紧急度，确定优先级。（具体请参见2.4.8 “优先级规则”）。- 如果不是重大事件则进入步骤 “2.3提供初步支持”。2.3提供初步支持&2.4 能否解决事件单执行者：监控服务台

28、83; 在事件管理中查询已经存在的解决方案/变通方法，或进行知识库有效知识的匹配进行在线事件解决；· 根据监控服务台人员所拥有的技能尝试确定“解决方案或变通方法”，进行事件解决；· 如果可以解决，转至步骤IM-06“事件单关闭”中的步骤6.1。如果不能解决，转至步骤2.5“分派事件”。2.5分派事件单执行者：监控服务台提示：· 在此环节，如果是分派到组，则该运维项目组必须制定负责人，由负责人负责对事件单的组内分派。组员也可主动认领未组内分派的事件单。· 根据事件所属系统和类型，将事件单分派到对应运维人员或者运维项目组。2.6是否接受事件单分派&2

29、.7解释理由并返回服务台执行者：运维项目组· 运维项目组/人接到事件后，判断事件是否分派正确，即是否本组/人的工作职责和技能范围。- 如果不是，则须在事件单上解释理由，将事件单返回服务台进行重新分派。- 如果接受，则转步骤 2.5“分派事件”。2.8报告事件至中心领导层执行者：监控服务台· 如果事件是重大事件，则立刻向信息中心管理层报告事件。· 信息中心管理层需要考虑和决策是否需要启动重大应急流程或灾备流程。2.2.8. 管理升级2.2.8.1. 描述：该步骤的重点是明确默认的管理升级机制及事件处理过程中正确的进行事件信息通知。2.2.8.2. 流程主要内容:输入

30、：任务：输出：· 来自于步骤“IM-2.受理与初步分析”中确定为对事件单级别的判断· 来自于步骤“IM-5.事件分析”中确定为对事件处理时间的预估3.1开始管理升级3.2/3.5/3.8/3.11重要性判断3.3/3.6/3.9是否升级3.4/3.7/3.10/3.12持续关注3.13 事件进展通报3.14是否启动紧急状态判断· 中心领导层宣布紧急状态· 管理层对事件处理指导与批示· 管理层对事件处理持续关注2.2.8.3. 过程环节:3.1开始管理升级 执行者：运维工程师· 运维工程师根据事件等级和性质对事件信息进行恰当的升级。默认

31、的升级规则见图中管理升级中默认升级机制· 根据预定义的通知规则进行升级通知，通知的形式可能包括诸如：- 通过系统传递信息；- 电话，邮件或者短信；· 升级之后进入环节“3.2重要性判断”，判断是否有必要继续升级。3.2/3.5/3.8/3.11重要性判断&3.4/3.7/3.10/3.12持续关注执行者：各升级环节的负责人提示：· 事件管理升级应首先按照等级自动升级；在事件重要性发生变化时，可由适当级别的负责人进行人工升级· 根据下级人员提供的事件描述信息，判断是否应将事件单信息向上级升级。- 如果确定事件单应继续升级，转入下一升级环节。 - 如

32、果不需继续升级，转入“持续关注”环节。在“3.4/3.7/3.10/3.12持续关注”环节中，本环节负责人应及时收听或查看与事件处理相关的报告或汇报，确保对事件进展的持续关注。3.13实时进展汇报执行者： 运维工程师由事件的处理工程师向各级领导实施汇报事件的处理进展与当前的影响范围。3.14 是否启动紧急状态执行者：中心领导层· 由中心领导层对事件的影响度及处置情况进行综合评估，判断是否将当前事件升级为重大紧急状态：- 如果确定是紧急状态，转至 “IM-7 重大紧急事件”子流程- 如果认为暂不构成紧急状态，转至 “持续关注”环节密切关注事件的进展和处置情况。2.2.9. 故障分析2.

33、2.9.1. 描述: 这个步骤的目标是对事件进行分析以便提出解决方案，不同技术领域的事件分析员将会参与到该步骤中以寻求一个事件解决方案，在有必要时会升级至三线或者原厂开发商以便快速解决恢复事件影响。2.2.9.2. 流程主要内容:输入：任务：输出：· 来自于步骤“2.6受理事件单” 4.1收集相关信息4.2是否重复事件4.3 关联至主事件单4.4进行事件分析4.5预估解决时间所需时间4.6判断是否找到解决方案4.7转派事件单（技术升级）4.8判断是否受理事件单4.9说明拒绝原因4.10提出解决方案· 针对该事件的解决方案· 管理升级信息2.2.9.3. 过程环节:

34、4.1收集相关信息执行者：二线· 二线对事件进行处理，并查找可能对事件处理有效的相关信息。· 该处理过程一线往往脱离开流程系统进行，在得到相关信息后，重新登录到流程系统，并将相关信息记录在事件单中。4.2是否重复事件执行者：二线· 寻找有相似症状(即由同一原因造成)的事件:- 如找到类似的事件，即进入步骤4.3“关联事件到主事件”，如果在事件诊断过程中发现匹配错误，可以取消此关联。- 如果没有找到，进入步骤4.4“事件单分析”4.3关联到主事件单执行者：二线· 判断当前事件单所描述的现象与之前未解决的事件是否有相似：- 如果确认是重复工单或主事件驱动工单

35、，将新的事件单关联到原主事件单- 原有事件单被标识为“主事件单”- 原有事件单关联事件单数加一- 新建事件单出现在原有事件单重复工单列表中· 事件单状态将随原有事件单状态的更新而更新，不单独进行处理。4.4 事件单分析执行者：二线· 检索知识库查询可能的解决方案，查找的途径包括但不限于：- 通过对已记录激活和未激活知识记录进行查询- 通过以往已关闭事件单中的解决方案或处理过程进行查询- 通过其它公共的资料信息进行查询· 根据专业技术经验寻找解决方案或者变更方法。4.5预估解决时间所需时间执行者：二线· 二线对事件处理所需的资源和时间进行预判，并将结果通过

36、 “IM-3 管理升级”向管理层及时通报。4.6判断是否找到解决方案执行者：二线· 经分析如发现解决方案，转到步骤“5.1解决和恢复” · 如未发现解决方案，或者需要其他系统运维项目组配合解决，则转到步骤“4.7转派事件单（技术升级）”。4.7转派事件单（技术升级）执行者：二线· 如果当前事件分析员由于某些原因不能解决该事件，需要将事件转派给其他系统运维项目组。· 被分派事件的事件分析员进入步骤4.8“是否接受事件”。5.8判断是否受理事件单&5.9说明拒绝原因执行者：二线、三线· 运维项目组/人接到转派的事件后，判断事件是否分派正确，

37、即是否本组/人的工作职责和技能范围。- 如果不是，则须解释理由，将事件单返回原事件处理人员。- 如果接受，则转步骤 2.5“分派事件”。· 转派超过3次，则事件单自动到事件经理进行协调。5.10提出解决方案执行者：二线、三线· 二、三线工程师根据事件描述状况以及所掌握的相关信息，对事件着手进行处理，并尝试找到解决方案或者应急方案。找到方案后，转IM5.1 “事件解决和恢复”2.2.10. 解决与恢复2.2.10.1. 描述：这个步骤尝试使用解决方案和变通方法来解决事件。对于某些事件，即使得到了解决，仍然需要创建问题单以进一步寻找其根源。另外，处理过程中的经验能够得到记录以形

38、成可重用的知识图 28 解决与恢复2.2.10.2. 流程主要内容:输入：任务：输出：· 来自于步骤4.5&4.10 “找到解决方案”5.1是否需要变更5.2采取恢复操作5.3验证解决方案5.4服务是否恢复5.5是否进行根源问题分析5.6创建新的问题并与事件关联· 恢复受影响的服务· 针对该事件的需要根源解决的问题单2.2.10.3. 过程环节:5.1判断是否需要变更 执行者：二线、三线· 首先判断解决方案/变通方法是否需要启动变更管理流程- 如果需要，则进入步骤4.2“创建变更单”，通过变更流程实施； - 如果不需要，则可以直接执行，进入步骤5

39、.2“采取恢复操作”5.2采取恢复操作 执行者：二线、三线· 实施已确定的解决方案，以恢复受影响的服务。5.3验证解决方案&5.4服务是否恢复 执行者：二线、三线· 验证解决方案的实施是否有效：- 对于方案无效的情况，转到步骤4.4“故障分析”。- 对于方案有效的情况，同步转到步骤6.1“事件关闭”以及步骤“5.5是否进行根源问题分析”5.5是否进行根源问题分析&5.6创建新的问题并与事件关联 执行者：二线、三线· 判断是需要对已解决的事件进行根源问题分析：- 对于需要分析的情况，转到活动“5.6创建新的问题并与事件关联”，针对该事件单新建一个问题

40、单或关联到已有的问题单上。- 对于不需要分析的情况，转到子流程6.1 “事件关闭”2.2.11. 事件关闭2.2.11.1. 描述：这个步骤确保用户对事件的处理情况感到满意。事件单的信息是正确、完整的，以便于以后生成报表。2.2.11.2. 流程主要内容:输入：任务：输出：· 来自于步骤“IM-5.4 业务已恢复”已解决的事件单6.1检查事件记录6.2是否需要与用户确认6.3与用户沟通6.4提供反馈信息6.5用户确认事件是否解决 6.6关闭事件单· 已关闭的事件单2.2.11.3. 过程环节:6.1检查事件记录 执行者：监控服务台· 对于用户报告的事件单，服务台检

41、查系统中事件单记录的完整性，对于不完整的记录进行补充。6.2是否需要与用户确认&6.3与用户沟通 执行者：监控服务台· 服务台根据事件性质，判断是否需要与用户沟通事件的处理结果，以便确认事件的真正解决。- 如确认需要告知用户事件处理结果的情况，转入活动“6.3与用户沟通”，沟通形式包括但不限于：系统通告，短信告知，邮件通知，电话通知等方式。- 如确认不需要告知用户事件处理结果，转入活动“6.6关闭事件单”6.4提供反馈信息 执行者：用户· 用户在接受服务台通知后，向服务台提供着呢对事件处理结果的反馈信息。6.5用户确认事件是否解决 执行者：监控服务台· 服

42、务台根据用户反馈确定事件是否被成功解决：- 如确认事件未解决的情况，转入子流程“IM-5故障分析”，重新查找事件原因。- 如确认事件已解决的情况，转入活动“6.6关闭事件单”6.6关闭事件单 执行者：监控服务台· 按照关单原则对事件单进行关闭。2.2.12. 紧急状态2.2.12.1. 描述：这个步骤是针对重大紧急事件的子流程，该流程的启用必须通过管理升级决定。2.2.12.2. 流程主要内容:输入：任务：输出：· 来自于步骤“IM-3管理升级”中确定是紧急状态的事件7.1指定紧急应对小组的负责人7.2成立紧急应对小组7.3收集相关信息进行事件分析7.4初步分析结果汇报7.

43、5是否协调更多资源7.6是否有应急处置预案7.7提出紧急恢复方案7.8提交ECAB审批7.9实施方案7.10方案是否有效· 紧急恢复受影响的服务·2.2.12.3. 过程环节:7.1指定紧急应对小组的负责人 执行者：中心领导· 通过管理升级确定为重大紧急事件后，由信息中心领导制定一名负责人作为紧急应对小组的负责人，对紧急情况进行指挥和处理。· 如果启动紧急应急状态，则事件单转到该负责人，由该负责人对事件单进行分派。7.2成立紧急应对小组 执行者：紧急应对小组· 由紧急应对小组的负责人，选取适当的技术和业务人员成立紧急应对小组，对紧急事件进行处理

44、。7.3收集相关信息进行事件分析 执行者：紧急应对小组· 由紧急应对小组对事件的现象、相关CI、影响范围、技术相关领域的信息进行收集，以供分析诊断。7.4初步分析结果汇报&7.5是否协调更多资源 执行者：紧急应对小组· 根据上一步骤收集的信息对重大紧急事件作出初步分析判断，并及时提交报告至中心领导审批，由中心领导决定是否需要向紧急应对小组提供更多资源以便加快处理流程。- 如需要协调资源，转入活动“7.3收集相关信息进行事件分析”。- 如确认不要协调资源，转入活动“7.6是否有应急处置预案”7.6是否有应急处置预案&7.7提出紧急恢复方案 执行者：紧急应对小组

45、· 紧急应对小组查询已有资源，包括但不限于：可持续性计划、事件记录、知识库等，确定是否有可以应用于本事件的应急预案：- 如有应急预案，转入活动“7.8提交审批”。- 如确认没有应急预案，转入活动“7.7提出紧急恢复方案”，由紧急应对小组审计编写应急方案，之后转入活动“7.8提交审批”。7.8提交审批 执行者：ECAB· 应急负责人组织中心领导和对紧急应对小组提交的解决方案进行审批：- 如审批通过，转入活动“7.9实施方案”。- 如确审批未通过，转入活动“7.7提出紧急恢复方案”，由紧急应对小组审计重新编写应急方案。7.9实施方案 执行者：紧急应对小组· 紧急应对小

46、组实施以审批的解决方案。· 如果解决方案需要启动变更管理流程，则需在事件恢复后补录紧急变更单。7.10方案是否有效 执行者：紧急应对小组· 紧急应对小组检测事件解决方案的实施效果：- 如服务已恢复，转入子流程“IM-6.1事件关闭”。· 如服务未恢复，转入活动“7.7提出紧急恢复方案”，由紧急应对小组审计重新编写应急方案。2.3. 角色与职责本章节描述省局信息中心有关人员在参与执行和管理事件管理方案时的角色和责任。市局参与事件管理的角色可以参照省局对应角色进行设置。一个角色不等于对应一个人员，一个人员可以担任多个角色。例如，可以由同一个人员担任事件管理和问题管理负

47、责人的角色。以下为事件管理流程中必须具有的角色：2.4.1 事件管理流程负责人事件管理流程负责人作为事件管理流程的责任人，对于整个流程执行的结果负责，并有一定的权力管理流程。事件管理流程负责人的职责包括：· 全面负责流程的效率和成果· 建立考核和目标，以提升流程的有效性和效率· 为保障流程的有效性，需争取高级管理层承诺投入足够的资源· 鉴别和管理关键的流程成功要素· 控制和带领流程的改进 · 批准和拒绝偏离流程的请求· 定义事件管理的角色、责任和应负的责任· 定义目标、流程、工作流、政策和规则，并与相关人员进行沟通

48、· 强制事件管理流程的执行· 确保对流程的使用者提供适当的教育· 对其他流程负责人和管理层汇报流程的状况和进度 · 对事件管理流程的有效性和效率进行监控，在需要的时候作出改进· 召开和主持对事件管理流程改进的季度会议 · 审计事件管理流程的执行· 作为事件管理流程对外的代表2.4.2 事件经理事件经理负责协调事件管理的日常操作步骤，并管理工作的时间安排。事件经理的责任包括：· 协调事件管理的日常操作· 确定和执行流程本身的变更· 鉴别流程执行过程中的例外和异常情况，并进行管理· 传达流

49、程的新政策和更新的政策· 确保流程标准和步骤得到遵循· 作出资源的承诺和分配· 鉴别和实施流程的改进建议· 产生和分派流程管理的报表· 对事件管理流程的负责人提出改进的建议 · 作为流程的集中联络点，负责与用户、服务供应商、管理层之间的沟通· 组织解决需要跨越职能部门或项目组的问题，如有需要，应升级汇报· 对于不遵守流程的情形进行处理· 在需要的时候，按照升级政策中所定义的途径进行升级· 对不遵从事件管理流程的参与者作出通告· 执行日常的流程管理· 出席会议并传达和协调有关事

50、件和问题· 准备和分析报表· 从事件管理流程的开始到结束进行跟踪2.4.3 事件分析员事件分析员，主要是省局信息中心作为二线、三线的专业支持人员，具有某个领域的技术技能。负责提供良好的事件分析和/或者是提供一个方案，来快速恢复受到干扰的服务。省局信息中心的事件分析员按技能或者系统划分为运维项目组，例如应用运维项目组，大集中征管系统维保项目组等。事件分析员的责任包括：· 分析事件信息· 关联受事件影响的CI（配置项）· 确认事件的优先级· 查找相同的症状的事件，并进行关联· 决定恢复服务所需要的必要条件，并启动适当的行动

51、83; 根据事件的优先级提供有效的解决方案/应急预案· 如有需要，与厂家和其他小组人员协同合作· 确定恰当的分派 (例如转派到组内其他事件分析员或者其他组事件分析员)· 根据事件等级进行恰当管理升级· 识别解决方案或者变通方法是否需要提交变更申请· 记录解决方案/应急预案· 鉴别成为问题的事件，如需要找出问题的根源，创建问题单（待问题管理实施后需履行此职责）· 向服务台提供事件单处理进度· 有权限访问相关已知错误、问题解决方法和配置管理数据库(CMDB)2.4.4 监控服务台监控服务台作为省局信息中心的一线的支持人

52、员，是用户、各地市信息科和省局信息中心的主要联系人。作为是事件的负责人，负责受理或创建事件单、跟踪、协调事件的解决。监控服务台的责任包括：· 接受用户或者地市信息科的事件报告或者事件升级请求· 验证用户的基本信息，如有需要，更新用户的资料· 创建或者更新事件单· 收集与事件处理相关信息，并确保信息的完整（尤其是相关审批表）· 分析故障报告信息· 初步评估事件的优先级· 确定适当的分派· 基于知识库，初步解决事件· 对于不能解决的事件，分派给合适的事件分析组或人员· 若用户要求了解事件状态，则将事

53、件的当前状况通知用户· 与用户确认事件的状况和解决方案· 更新和关闭事件单2.4.5 角色映射角色省局信息中心岗位映射监控服务台监控服务台岗事件分析员（二线）应用运维项目组、系统平台运维项目组、安全及网络运维项目组事件分析员（三线）各信息系统运维项目组，例如：大集中征管系统维保项目组、发票在线系统项目组、纳服整合平台项目组等事件经理监控服务台台长事件流程负责人运维办事件经理2.4. 业务规则2.4.1. 总体业务规则· XXXX信息部门（包括省局信息中心和各地市信息科）支持的信息系统和网络环境中，所有对服务的正常提供有影响的事件都会通过事件管理流程处理；将通过流程

54、中定义的标准、政策和指导进行管理。· 所有报告事件的部门将会参与统一的事件管理流程，不应该有任何例外。· 确保各地市服务台作为各地市信息科事件的统一入口，省局监控服务台作为省局信息中心事件的统一入口，从而保证所有的事件都能够记录和跟踪。· 故障处理人员如果因为时间紧迫没有对所有发现的故障进行记录，直接解决故障的话，应事后补单。（补单情况应通过管理来尽量避免）· 需要定期抽查事件单填写的质量，确保内容足够明确、详细。· 应该定期产生和回顾事件管理报表。对没有解决的问题，应该举行定期的事件管理会议对这些事件进行评估。· 应该定期对流程进行

55、回顾，以改进事件管理流程。2.4.2. 责任人业务规则有效的管理事件的重要因素是定义一个责任人业务规则，以确保每个事件在任何时段都有适当的人员负责。当一个事件由地市服务台创建后且未升级至省局信息中心，地市服务台作为事件单的责任人，在事件单的全部生命周期内负责推进事件的处理进度。如果事件单升级至省局信息中心，则事件单的负责人是省局监控服务台，但是地市服务台继续跟踪该事件单的进度。如果事件单是由省局监控服务台或者工程师创建，则省局监控服务台是事件责任人，在事件单的全部生命周期内负责推进事件的处理进度。当事件单被分派后，接受事件单的事件分析员是此事件单的当前负责人；但是分派方（作出分派的服务台或是作

56、出转派的事件分析员）有责任通知被分派的事件分析员并要求他接受或是拒绝此事件单。如果需要向用户通知处理情况，由事件单的当前责任人或服务台负责。2.4.3. 分派和受理业务规则监控服务台可以直接分派事件到运维项目组或人。各运维项目组可以指定组长对分派到该组的事件单进行转派。在运维项目组组长未及时进行转派的情况下，组内任何成员均可主动受理此工单。事件处理人员在收到工单指派通知后应尽快做出响应。注:每个运维项目组都需设定一名组长角色。2.4.4. 转派业务规则转派指监控服务台或者运维项目组组长分派后，被分派对象将事件单转给组内或者其他组的事件分析员（服务台分派事件不属于事件转派）。转派业务规则确保事件

57、单不被过于频繁的相互转派，以至于无法在规定时间内得到解决。· 事件单可以由事件分析员转派给本组或其他组的事件分析员。· 事件转派超过3次（含3次），事件单将升级给事件经理。· 服务台和事件分析员，由于某些原因（例如出差，休假，培训等）离开本岗位时，必须确保将未处理完毕的事件单转派到本岗位其他事件分析员。服务台或者工具管理员可以手工干预对其单进行组内转派（不会影响一次分派成功率）· 组内转派不影响KPI“首次分派成功率”的计算，有两种情况： 服务台下单后分派到服务台组，此种分派不算作第一次分派，不影响一次分派成功率的计算，及后若继续在服务台组内转派，同样不影响一次分派成功率的计算。 服务台派单到后台各个分析员组后，事件分析员在其组内转派，也不影响首次分派成功率的计算，若其须转派到其它组，则需先退回到服务台，再由服务台作转派。此时则算作首次分派不成功，对一次分派成功率的计算有影响。· 事件单转派时，按第一次状态变为“