1.1.流程目的

本文档是针对挑战365活动（以下简称C365）范围内的相关事件进行处理的细则，基于集团对BOMC系统规范2.0。

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

• 在成本允许的范围内尽快恢复IT服务
  • 快速响应服务请求（电话/Web/邮件等）
  • 用户在线获得帮助
  • 沟通事件解决的状态 
  • 和客户确认事件的解决
  • 启动应急预案
• 进行事件控制
  • 按规范记录事件
  • 就事件的优先级，影响度进行分类
  • 分析，诊断，必要时进行升级
  • 监视并结束事件
  • 进行定期服务流程回顾
• 提供IT管理信息
  • 人力资源利用情况
  • 故障处理情况
  • 支持效率

1.2.流程主要内容

事件管理流程始于事件的接收和报告，结束于事件的解决。该流程包含下述主要内容：

• 事件检测和记录

 这个环节是事件管理流程的起点。所有用户或系统报告的IT 事件必须由此步骤开始。此步骤的目的是在事件发生时快速准确地发现，以协助事件的诊断和解决并通知相关人员。在此步骤中将会收集创建事件记录所需的信息。

该环节的关键是信息的准确性和完整性。

• 分类和初步支持

对于每个事件，需要确立优先级和分类。若没有现成的解决方案或临时解决措施，该事件将分配给合适的支持人员对此进行调查。

• 调查和诊断 

若支持人员无法解决事件，可运用自身技能、知识库、诊断工具等进行更加深入的分析以找到恢复服务的临时措施，必要时可调用多名支持人员以寻求解决措施。

• 解决和恢复

支持人员实施事件的解决方案，并将解决完毕的事件转回开单人.

• 优先级为紧急的事件（紧急事件）和事件升级

对于紧急事件，服务台应立即提交给一线人员，由一线人员判断，上报给事件经理和相关的管理层，由事件经理决定紧急事件的处理方式，确保其得到最快速的解决。

当事件处理超过预期时限，将自动通知处理人员和相应管理层，以引起相关人员和管理人员的重视和参与。

• 结束事件

服务台通知用户解决的结果，并得到用户的确认。当用户确认事件解决后，此时可结束该事件。

1.3.与其他流程的关系

• 和问题管理流程的关系

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

• 和配置管理流程的关系

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

• 和变更管理流程的关系

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

• 和知识库的关系

事件得到解决后，解决的过程中所获得的经验以及相关解决方案可以进入知识库，作为知识保存，为后续的工作提供指导。

1.4.流程范围

在此次C365项目中事件管理流程的范围包括涉及到BOSS系统和CRM系统中所有IT生产环境所产生的申告、故障、告警、咨询和客户投诉。

不包括：

1. 尚处于开发或测试环境的系统和应用引发的事件
2. 容灾系统和BOMC系统相关的事件

1.5.流程执行原则

1.5.1.常规原则

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

1.5.2.所有权原则

所有权原则用来确保每个事件在任何时段都有适当的人员负责，服务台是事件的负责人。下表是事件管理中各角色在各环节中承担不同责任的RACI模型。

表2-1 事件管理RACI模型

1.5.3.再分派原则

事件的再分派原则是确保事件在服务目标时段内处理和解决的重要因素。因此，应当尽量减少事件单再分派的几率。事件单可以分派给服务台组，但分配给一、二线时，只能够分派到个人。

• 事件单的重分派次数不应该超过5次（从服务台派单开始计算）。
• 超出分派次数，短信通知事件经理。
• 地市支撑人员提交工单给服务台组；
• 服务台可以将事件单分配给其他服务台人员、一线支持
• 一线支持人员可以将事件单重新再分配给服务台（驳回）、其他一、二线支持人员
• 二线支持人员可以将事件单重新再分配给其他一线（驳回）、二线支持人员和厂商人员

1.5.4.重复事件原则

重复事件是指在一个较短时间段（通常30分钟内至1小时），由监控平台上报的同一个配置项上现象相同的告警，或者一人/多人申告的同一来源（系统、应用）现象相同的事件。

当被报告的事件与某个已经创建且尚未解决的事件单相同，则该事件被认为是重复的。由于此时已创建的事件尚未解决，还没有采取修正措施来恢复服务，因此，新报告的事件被认为是原有事件单的重复事件单。

• 监控平台应该自动过滤重复告警，避免将重复的告警发送到服务管理平台
• 重复的事件信息必须被标识，并且不计入事件流程的关键衡量指标
• 如果服务台可以判断到重复事件，则由服务台对重复事件标识，否则由一、二线支持人员负责重复事件的处理
• 重复事件与原事件单关联
• 在原有事件单获得解决时，所有的重复事件单获得解决。

1.5.5.关闭原则

事件工单关闭环节的基本原则：谁开单，谁负责关闭。

• 各地市支撑人员提交的工单，最后由提交人关闭；
• 服务台通过电话、邮件、飞信、BQQ等方式受理的事件工单，由服务台和IT用户确认解决后进行关闭；
• 二线人员自行创建的事件单，由创建人关闭；
• 监控平台产生的告警，由服务台人员（机房值班人员）根据监控平台的反馈确认后关闭；
• 优先级为紧急的事件工单由事件经理进行关闭
• 事件处理人员在解决完成事件时，根据实际解决情况填写事件的结束代码，采用临时措施恢复服务时，结束代码为“变通方法解决”。服务台负责和IT用户再次确认事件的解决
  • 由IT用户认可获得关闭的事件单的结束代码为“成功解决”关闭
  • 采用临时措施恢复服务时，结束代码为“变通方法解决”；
  • 已解决的事件单如果没有得到IT用户的认可，则首先关闭该事件单，结束代码修改为“不成功”，同时创建一个新的事件单重新分配到原处理人员继续处理。同时短信通知事件经理，服务台通过线下的方式让用户了解不成功的工单后续处理情
• 已关闭的事件单不允许重开。如果事件重复发生，则创建一个新的事件单，并与已关闭的重复工单进行关联。

1.5.6.升级原则

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

• 优先级为紧急的事件，由一线再次确认，如果确认了优先级为紧急，则通过线下短信通知的方式升级升级到事件经理，启动紧急事件处理流程，并用短信方式通知相应的管理层—室经理
• 优先级为高的事件，一线人员处理15分钟（解决时限的50%）内未解决，则要求立即升级到二线人员进行处理
• 优先级为中、低的事件，处理时间超过解决时限的80%时，由服务台对处理人进行督促，要求将规定时间内不能解决的事件升级。（一线升级到二线，二线升级到三线）
• 各支持人员应及时响应和处理分配到本组或自己的事件单，如果超出规定解决时限，服务台系统应自动将事件信息通报事件经理，事件经理负责协调资源，并督促事件能够及时被响应和处理
• 服务台人员主动监督优先级为中和低的事件处理情况，应及时将不能解决的事件升级；事件经理并对未及时升级的事件及时介入，负责协调升级处理。事件经理通过对事件的抽查和对超时解决的事件统计情况对服务台人员的主动性进行监督。

1.6.流程相关定义

1.6.1.事件信息项

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

表5-2 事件信息项

1.6.2.事件性质

事件性质定义为如下五类事件：

1.6.3.事件来源

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

1.6.4.所属系统类型

定义业务系统。当事件发生时，应该由服务台初步定位是哪个系统及子类出现问题，由一、二线进行进一步的明确。

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

1.6.5.事件分类

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

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

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

表5-3事件分类

1.6.6.事件优先级

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

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

注：

1. 如果某些业务模块没有反映在优先级映射表中，各省可以根据实际需要添加
2. 优先级映射表中空的字段，各省在细化流程中自行定义
3. 在事件处理解决后，可以由负责关闭的服务台人员对事件的优先级做最终的修正。

1.6.7.事件响应时限和解决时限

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

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

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

事件优先级对应的事件响应时限和解决时限参考下表（以下时间是24×7工作时间）：

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

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

1.6.8.通知与提醒

在事件流程开始和处理过程中，发送满足以下条件的通知或提醒，推进事件工单的及时执行：

• 当事件工单分（转）派时，发送通知给接收人；
• 当紧急事件确认并触发按钮后，发送通知给事件经理、室经理；
• 当超出分派次数时，发送通知给事件经理；
• 为关闭代码是“不成功”的事件工单创建新工单时，发送通知给事件经理；
• 对高、中、低优先级的事件，在处理时间过去50%时，发送提醒给事件处理人；
• 对紧急、高优先级的事件，在处理时间过去80%时，发送提醒给事件经理、事件处理人；
• 对中、低优先级的事件，在处理时间过去80%时，发送提醒给服务台、事件处理人；
• 对高、中、低优先级的事件，超过解决时间时，发送提醒给事件经理；

1.6.9.事件影响度

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

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

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

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

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

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

1.6.10.事件状态

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

1.6.11.事件结束代码

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

1.6.12.事件解决人角色

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

1.6.13.处理是否超时

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

1.6.14.故障厂商

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

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

1.7.流程概要设计

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

图2.1事件管理流程

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

下表以事件管理概要图中的关键流程活动为主线，与事件管理概要设计中的其它重要内容进行了关联，以帮助各省业务支撑维护部门更好地理解流程设计内容。 

 下表以事件管理概要图中的关键流程活动为主线，与事件管理概要设计中的其它重要内容进行了关联，以帮助各省业务支撑维护部门更好地理解流程设计内容。

1.7.1.紧急事件处理子流程

制定紧急事件处理子流程的目标：

• 当紧急事件发生时，尽可能采取措施减少对于业务带来的影响
• 确保对紧急情况的有效管理
  • 加快紧急事件的响应和处理速度
  • 对紧急情况中的人员及采取的行动加强管理
  • 加强处理人员与用户之间的沟通和反馈
  • 对紧急情况妥善处理

紧急事件处理的特殊性包括各系统应急处理预案的制定和使用，及时的集团上报等。

应急处理预案是事先制定的针对某种特定故障的处理措施，可以确保系统发生重大故障时，能够尽快恢复业务，并充分调动技术力量，在最短时间内排除故障。预案中的内容至少应涵盖应急预案启动条件、应急处理小组负责人和成员联系名单和联系方式、应急处理步骤、应急信息通报、应急善后处理、应急保障措施（人员、培训、演习、场地）等。

一线人员对紧急事件进行确认后，通过点击按钮的方式，触发紧急事件流程，工单自动流转到应急小组，并发送短信提醒事件经理和室经理，由事件经理通召集应急小组，协调会议的召开，开展事件的处理工作。

一线人员确认此紧急事件为普通事件后，修改优先级，按照常规方式执行。

为切实掌握各省公司业务支撑系统紧急事件情况，要求各省公司在紧急事件发生时立即上报，并在紧急事件处理过程中的关键点将处理情况上报，具体上报内容和方式参见2.10集团、省公司两级交互。

图2.2  紧急事件处理流程

紧急事件处理流程说明如下：

1.8.关键角色、职责定义

事件管理流程主要分为以下角色：

1.8.1.事件管理流程负责人

事件管理流程负责人从宏观上监控流程，确保事件流程在业务支持中心范围内被正确的执行。当流程不能够适应业务支持中心的情况时，流程负责人必须及时的对此进行分析、找出缺陷、进行改进，从而实现可持续提高。

职责：

1. 确定管理流程的衡量指标
2. 确保事件流程能够取得管理层的参与和支持
3. 确保事件流程符合公司实际状况和公司 IT发展战略
4. 总体上管理和监控流程，建立事件流程实施、评估和持续优化机制
5. 确保事件流程实用、有效、正确地执行，当流程不能够适应公司的情况时，必须及时的对此进行分析、找出缺陷、进行改进(假如增加或合并流程的角色)，从而实现可持续提高
6. 保持与其他流程负责人的定期沟通

1.8.2.事件经理

事件经理负责事件解决过程中的协调和监控，以及事件升级的判断以及具体执行。

职责

1. 负责对事件的解决协调资源，保证故障的最终排除
2. 确保和问题管理流程经理的有效合作
3. 确保正确和广泛地收集和分析事件数据，发现IT和业务相关的问题
4. 监督优先级为紧急、高的事件的处理情况
5. 监督服务台是否及时将事件工单升级。

1.8.3.服务台人员

服务台人员负责接收所有的事件，对事件进行初步的处理，并根据实际情况将事件分派到合适的一线支持工程师或者二线支持工程师。

职责：

1. 负责24×7的值班和系统监控
2. 响应客户投诉工单、热线电话、邮件、告警、飞信、BQQ等事件报告
3. 完整记录所有接收的事件信息，包括：记录事件报告人的详细联系方式、事件特征表现、描述、发生时间等
4. 为事件进行适当的分类、为事件分配优先级等属性
5. 做初步的诊断和处理
6. 将事件分配给最合适的一线支持小组/人员来处理
7. 检查事件记录的处理进度，保持与事件报告人的联系，适时通知事件处理进展
8. 与用户确认事件解决方案，关闭事件
9. 监督优先级为中、低的事件是否被及时处理，必要时进行升级

1.8.4.一、二线支持人员

一线支持人员按照系统进行进行划分，对事件进行快速有效的分析，提出解决方案以尽快恢复服务，并在必要时提供现场支持。

职责：

1. 按照系统进行划分，对事件进行快速有效的分析，提出解决方案以尽快恢复服务；
2. 验证事件的描述和信息，进一步收集相关信息；
3. 实施事件解决方案；
4. 更新事件解决信息，已解决的事件转回建单人。

二线支持人员按照专业组进行划分，是相关问题领域的专家。负责提供对一线支持人员无法解决的问题进一步进行调研，找出解决方案并尽快恢复服务。

职责:

1. 验证事件的描述和信息，进一步收集相关信息；
2. 进行深入调查研究或协调三线支持，提供/获取有效的解决方案；
3. 实施事件解决方案；
4. 更新事件解决信息，已解决的事件转回建单人。

1.8.5.三线支持人员

包括现场支持的应用开发厂商和远程支持设备厂商。

职责:

1. 必要时提供现场支持和深入调查研究，提供有效的解决方案
2. 参与解决方案的实施
3. 更新事件解决信息，已解决的事件转回建单人。

1.8.6.流程角色和人员对应表

1.9.关键流程衡量指标

为了控制流程的质量，必须为流程设置衡量指标。通过对指标的分析，可以有效地对流程的运行情况进行监控和改进。

表2-4 事件管理KPI指标

1.10.集团、省公司两级交互

省公司在紧急事件发生时，必须在第一时间上报集团公司业务支撑系统部，并在事件处理过程中的每个状态变化点将最新事件记录上传到集团公司。

1.11.事件管理报表

1.11.1.按业务系统和优先级分类统计报表

指标计算方法如下：

1.11.2.按业务系统细分的故障和优先级分类统计报表

指标计算方法如下：

1.11.3.按业务系统统计故障和申告处理效率指标报表

指标计算方法如下：

1.11.4.按事件分类的故障和优先级统计报表

指标计算方法如下：

1.11.5.按业务中断时长分类的统计报表

注： 业务中断时长＝业务恢复时间－事件发生时间， 单位为分钟

指标计算方法如下：

1.11.6.故障厂商统计

注：该报表中的厂商按照各省实际情况上报。

指标计算方法如下：

1.11.7.各组工程师工作量和工作效率统计报表