某通信公司ITIL事件管理流程细化说明书

1、综述

1.1 设计目的

本文档的目的是：

1. 建立基于ITIL的业务支撑网事件管理的基本框架，提升业务支撑网的IT服务可用性
2. 对集团公司和各省公司业务支撑网的事件管理进行规范化、统一化管理
3. 指导业务支撑系统服务管理平台的建设 

1.2 适用范围

本文档作为本次项目的事件管理流程详细设计的交付物，读者对象为与事件管理流程相关的所有技术与管理人员。

1.3 相关术语

◆ ITIL（IT Infrastructure Library ）

◆ 帮助台（Service Desk）

帮助台从根本上来说是提供了用户和IT部门的唯一接口。此项功能常通过集中方式提供服务。帮助台的根本目的是提供初始支持，并通过变通方法、解决方案或升级到一线、二线支持等手段帮助用户恢复到正常工作状态。

◆ 事件管理（ Incident Management）

ITIL流程之一，事件管理负责解决所有的IT事件、问题和用户请求。它的目的是尽快恢复被中断或受到影响的IT服务，所以它的特点往往是以解决表征现象为目的，而不在于查找根本原因。

◆ 问题管理（Problem Management）

ITIL流程之一，问题管理负责解决重大紧急事件或具有相同症状的一组事件。它的目的是找出事件的根本原因，并通过解除该根本原因从而防止类似事件的再次发生。同时问题管理流程也负责预防事件的发生。

◆ 配置管理（Configuration Management）

ITIL 流程之一，配置管理负责描述，跟踪和汇报所有IT基础架构中的每一个设备或系统的管理流程。这些设备和系统被称为配置项(CI) 。每一个CI必须有效管理，跟踪和控制以支持公司的IT服务和基础设施成功运行。

◆配置管理数据库（CMDB - Configuration Management Database）

是在配置管理流程中用于记录企业所有IT相关配置项信息及其相互关系而建立的数据库。

◆变更管理（Change Management）

ITIL流程之一，变更管理通过控制和管理IT相关的变更， 使变更对生产环境可能的影响和风险降到最小，从而提高IT环境的整体稳定性。

2 事件管理流程设计

2.1 流程目的

事件管理流程的主要功能是尽快解决出现的事件，保持业务支撑系统的稳定性，其目的包括：

◆在成本允许的范围内尽快恢复IT服务

• 快速响应服务请求（电话/Web/邮件等）
• 用户在线获得帮助（知识库共享）
• 沟通事件解决的状态
• 和客户确认事件的解决

◆进行事件控制

• 按规范记录事件
• 就事件的优先级，影响度 进行分类
• 分析，诊断，必要时进行升级
• 监视并结束事件
• 进行定期服务流程回顾

◆提供IT管理信息

• 人力资源利用情况
• 故障处理情况
• 支持效率

2.2 流程主要内容

◆ 事件接收和记录

◆ 分类和在线支持

事件可以是一个申告/故障/告警/咨询/业务处理/维护作业，对于每个事件，需要确立优先级和分类。若没有现成的解决方案或临时解决措施，该事件将分配给合适的支持人员对此进行调查。

◆调查和诊断

◆ 解决和恢复

◆结束事件

2.3 与其他流程的关系

◆ 和问题管理流程的关系

事件管理流程将提供事件的详细、精确的记录信息给问题管理流程来定位问题及分析问题的趋势，以及在优先级为紧急的事件解决并恢复服务后做为问题进行进一步的分析和处理。

◆ 和配置管理流程的关系

需要从配置管理数据库中查询配置项的属性和配置项间的关联关系来定位故障和帮助快速的恢复。

◆ 和变更管理流程的关系

帮助台应了解变更管理流程中目前正在进行的变更信息，检测因变更而可能引发的事件。在事件的解决过程中，必要时需要发起变更请求来解决事件。

2.4 流程范围

业务支持中心的事件管理范围包括与BOSS、客服、经分、容灾、BOSS网管相关的所有IT生产环境所产生的申告、故障、告警、咨询、业务处理和维护作业。

本事件管理范围不包括尚处于开发或测试环境的系统和应用引发的事件。

2.5 流程执行原则

2.5.1 常规原则

1. 所有业务支撑部门事件管理范围内发生的事件，都应该记录在服务管理平台中，记录的信息应足够详细，包括事件处理交互过程，详细的解决方案和相应的附件
2. 所有IT支持人员对优先级为紧急和高的事件所采取的服务恢复行动，在比对其它行动的时候，将拥有优先处理级别
3. 应该每月产生事件管理报表，并对重复发生的事件和变通方法解决的事件，应该举行定期的事件管理会议对这些事件进行评估
4. 应该半年对流程进行回顾，回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性，以改进事件管理流程

2.5.2 流程关联原则

◆ 和问题管理的关联

• 所有优先级为紧急的事件在恢复服务后，都应该创建问题单（问题单必须和事件单建立关联）
• 一线支持在解决事件的过程中，可以通过问题记录查找相应的解决方案

◆ 和变更管理的关联

• 事件处理过程中，如果需要对系统进行变更，必须按照变更管理的定义，提交变更请求单（变更单必须和事件单建立关联），变更完成后，继续事件单的处理
• 紧急事件（优先级为紧急的事件，下同）的处理过程中，如果需要对系统进行变更，必须按照变更管理的定义，提出紧急变更请求，变更完成后，补录紧急变更单，并和紧急事件单建立关联

◆ 和配置管理的关联

• 事件处理过程中，可以通过配置管理查询相关的配置项信息以及该配置项历史上发生的事件、问题或变更，来帮助故障的定位

• 事件处理过程中，如果可以将故障定位到某个配置项，则必须将事件单与该配置项关联

2.5.3 所有权原则

所有权原则用来确保每个事件在任何时段都有适当的人员负责，帮助台是事件的负责人。

• 由IT用户申报的事件单，帮助台员工是该事件的责任人，必须确保事件得到有效跟踪与解决，并负责事件单的关闭

2.5.4 再分派原则

事件的再分派原则是确保事件在服务目标时段内处理和解决的重要因素。因此，应当尽量减少事件单再分派的几率。事件单可以分配到个人，或者分配到组（帮助台，一线支持，二线支持），再由组内的支持人员处理。事件单的重分派次数不应该超过5次。

1. 帮助台可以将事件单分配给一线支持，如果找不到合适的一线支持，可以直接分配到二线支持
2. 一线支持可以将事件单重新分配给帮助台，其他一线支持人员，二线支持
3. 二线支持可以将事件单重新分配给帮助台，一线支持，其他二线支持人员

2.5.5 重复事件原则

重复事件是指在一个较短时间段（通常30分钟内至1小时），由监控平台上报的同一个配置项上现象相同的事件或一人/多人申告的同一来源（系统、应用）现象相同的事件。当被报告的事件与某个已经创建且尚未解决的事件单相同，则该事件被认为是重复的。由于此时已创建的事件尚未解决，还没有采取修正措施来恢复服务，因此，新报告的事件被认为是原有事件单的重复事件单。在原有事件单获得解决时，所有的重复事件单获得解决。

1. 监控平台应该自动过滤重复告警，避免将重复的告警发送到服务管理平台
2. 重复的事件信息必须被标识，并且不计入事件流程的关键衡量指标
3. 如果帮助台可以判断到重复事件，则由帮助台对重复事件标识，否则由一线支持人员负责重复事件的处理

2.5.6 关闭原则

由IT用户申报的事件单，关闭必须由帮助台完成。

◆ 事件处理人员在解决完成事件时，根据实际解决情况填写事件的结束代码，采用临时措施恢复服务时，结束代码为“变通方法解决”。帮助台负责和IT用户再次确认事件的解决

• 由IT用户认可获得关闭的事件单的结束代码为“成功解决”关闭
• 已解决的事件单如果没有得到IT用户的认可，则首先关闭该事件单，结束代码修改为“不成功”，同时创建一个新的事件单重新分配到原处理人员继续处理

◆已关闭的事件单不允许重开。如果事件重复发生，则创建一个新的事件单

1. 业务支撑部门的维护人员（一线或二线）自行创建的事件单，本着“谁开单，谁负责关闭”的原则
2. 监控平台自动发送的事件单，第一次接收的维护人员负责关闭
3. 对于IT用户（例如客服）申报的事件单，可以实现由IT用户自行确认事件是否解决，超过一定期限（例如3－5天）不确认的事件单由系统自动关闭或由帮助台协助关闭 

2.5.7 升级原则

制定升级原则的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和领导，引起更多的重视，提供合适的资源，从而快速找到解决事件的方案。

1. 优先级为紧急的事件，帮助台应立即升级到相应一线支持，由一线支持再次确认，如果确认了优先级为紧急，则立即升级到事件经理，并通知相应的管理层（通过服务管理平台），由事件经理启动紧急事件处理流程
2. 各支持人员应及时响应和处理分配到本组或自己的事件单，如果超出规定的响应时限和解决时限，服务台系统应自动将事件信息通报事件经理，事件经理负责协调资源，并督促事件能够及时被响应和处理
3. 帮助台和一线支持应及时将不能解决的事件升级到下一级，若未及时升级，事件经理应及时介入，负责协调升级处理

2.6 流程相关定义

2.6.1 事件信息项

事件单必须包含如下事件信息项，各省可以在此基础上扩充：

2.6.2 事件性质

根据系统的业务要求和管理要求，定义如下六类事件： 

注：业务处理和维护作业的处理流程见流程概要设计相关子章节。

2.6.3 事件来源

事件来源代码用来标明事件的提出方式，事件来源可以包括以下几种：

2.6.4 事件所属系统类型

根据目前业务支撑系统和子类的划分定义事件所属系统类型，当事件发生时，应该由帮助台初步定位是哪个系统及子类出现问题，由一线、二线进行进一步的明确。

注：各省在细化设计时不能修改此表中现有定义，第一层业务系统和第二层子类不能修改和扩充(注：第一层为”其它系统”的话，对应的子类可以扩充)，但可以有选择的基于第二层子类定义扩充进行第三层条目的细化。对没有覆盖到的业务系统用”其它系统”表示。

2.6.5 事件分类

事件分类代码用于标识故障或申告的具体原因，由支持人员在处理过程中填写。在制作统计报表时，可以通过和事件所属系统类型代码的结合来统计分析故障或申告。

事件的分类层次设计不超过三层，第一级分类，称之为“类别”，第二级分类，称之为”子类”，第三级分类，称之为”条目”。

注：各省可以在此表的基础上扩展子类和自定义条目，针对一个子类，可以定义多个条目。

2.6.6 事件优先级

优先级是事件管理的一个关键要素，优先级决定处理事件的顺序及所需的资源，事件优先级可分为四级（紧急、高、中、低）。

当故障发生时，为了在判断优先级时增强实际可操作性，可以根据故障的影响范围和业务系统的关键程度在优先级映射表中定位优先级。故障的影响范围可以根据配置项中定义的‘影响范围’和用户报障描述来确定。

注：

1. 如果某些业务模块没有反映在优先级映射表中，各省可以根据实际需要添加
2. 优先级映射表中空的字段，各省在细化流程中自行定义。

2.6.7 事件响应时限和解决时限

在事件处理过程中，对于一个事件有解决时间的限制和响应时间的限制，一方面，需要各工程师协同合作，在解决事件的时候应该有时间的概念，同时，也要求事件经理必须实时地督促事件的解决，对于影响度为高或者紧急的事件，需要及时通告事件经理，同时，如果该事件的响应或解决超过了时限，需要通告事件经理，同时也要根据具体情况通告给其他相关管理人员。

响应时限指的是事件状态从“已登记”到“一线处理中”经过的时间，如果帮助台直接分配到二线支持，响应时限指的是事件状态从“已登记”到“二线处理中”经过的时间；

解决时限指的是事件状态从“已登记”到“已解决”经过的时间；

注：

◆ 事件通告定义

• 通知人员列表的用途：当优先级为高或紧急的事件发生时，则按表中的人员列表发出邮件或短信通知。

◆ 超出响应时间的通告定义

• 通知人员列表的用途：当服务管理平台判断到响应时限已经超出，则自动按照表中的人员列表发出邮件或短信通知。

◆超出和即将超出解决时限的通告定义

• 通知人员列表的用途：当服务管理平台判断到解决时限已经或即将超出，则自动按照表中的人员列表发出邮件或短信通知。

2.6.8 事件影响度

事件影响度用于衡量事件所影响业务的严重程度。严重程度通常通过事件所影响的人数、关键系统数以及服务故障所造成的损失来设定。

定义事件影响度等级的因素有：

1. 是否影响了核心业务
2. 所影响的用户数
3. 服务失效的影响范围和时长

事件影响度在事件的生命周期中是可以改变的，例如，初始等级为严重的故障会随着服务失效的时间变成重大故障，所以事件的影响度应在事件得到解决（服务恢复）后重新确认。

事件的响应时间、解决时限以及处理事件所需要引入的资源主要由事件的优先级决定。

注：各省根据自己业务情况扩展或修改本表格的描述，对于重大级别的事件，应严格按照集团公司的定义。

2.6.9 事件状态

事件状态代码表明事件所处的处理状态，事件状态如下：

2.6.10 事件结束代码

事件结束代码说明了事件是在何种情况下关闭的，结束代码如下：

2.6.11 事件解决人角色

事件解决人角色用来标明该事件单最终解决的角色是帮助台、一线还是二线。

2.6.12 处理是否超时

每个优先级别都对应了解决期限，“处理是否超时”用来标明事件的处理是否已超过了解决期限。

2.6.13 故障厂商

用来在事件单中记录是哪个厂商的设备/系统，或者哪个集成商的应用软件发生故障(针对事件分类中的”应用软件”故障)。代码定义参见下表厂商和集成商名称标准（可以根据情况从厂商和集成商两个表中选择一个合适的故障厂商）。

各省可以根据实际情况对厂商名称标准表和集成商名称标准表进行扩充。

2.6.14 投诉分类

对于投诉类事件，帮助台可初步定位是哪类投诉，由一线、二线进行进一步的明确。

2.6.15 投诉条目

对于投诉类事件，帮助台可初步定位投诉属于哪个条目，由一线、二线进行进一步的明确。

2.7 流程概要设计

事件管理概要设计流程图如下：

事件管理概要设计流程说明

2.8 流程详细设计

2.8.1（100.1）事件记录和分类

流程描述如下：

2.8.2 （100.2）初始支持

流程描述如下：

2.8.3 （100.3）一线尝试解决

流程描述如下：

2.8.4 （100.4）二线尝试解决