背景与目的

流程的目的

• 事件（Incident）：会引起或可能引起IT服务的非计划中断或者IT服务质量的下降的任何事件。
• 事件管理流程的主要目的：

事件管理的生命周期

事件管理主要活动－事件检测和记录

事件来源

事件性质

事件管理主要活动－分类和优先级

事件管理主要活动－匹配和分派

事件的分类

系统所属类型

• 用于事件发生时定位哪个系统出现问题：

优先级矩阵

• 优先级由所属系统和影响范围共同决定
• 事件处理过程中，优先级无法进行修改
• 事件处理解决后，可以由负责关闭的人员对优先级做最终的修正。 

重复事件原则

• 重复事件是指在一个较短时间段： 由监控平台上报的同一个配置项（CI）上现象相同的告警
• 或多人申告的同一事件来源（系统、应用）现象相同的事件 从而新报告的事件与某个已经创建且尚未解决的事件单相同，则该事件被认为是重复的。

处理方式：

• 重复的事件信息必须被标识，不会被计入事件流程的关键衡量指标中
• 服务台、一、二线支持人员都可以对重复事件标识
• 重复事件需要与原事件单关联
• 在原有事件单获得解决时，所有的重复事件单获得解决。 

事件管理主要活动－调查和诊断

再分派原则

• 是确保事件在服务目标时段内处理和解决的重要因素.
• 尽量减少事件单再分派的几率：  
  • 事件单的分派次数不应该超过5次（从服务台派单开始计算）；  
  • 超出分派次数，短信通知事件经理；
• 分派给一线、二线和厂商时，只能够分配到具体的个人

事件管理主要活动－解决和恢复

响应与解决时限

• 根据事件的优先级别，有相应的响应与解决时限要求： 

事件管理主要活动－结束事件

事件结束代码说明

谁来关闭事件工单？

关闭原则

• 事件工单处于关闭环节时需要根据实际解决情况填写事件的结束代码： 

事件管理主要活动－升级

升级原则

• 对所有事件，服务台应立即派发到一线进行处理；
• 优先级为紧急的事件，由一线再次确认后，则立即升级到事件经理，并短信通知相应的管理层（室经理），由事件经理启动紧急事件处理流程；
• 优先级为高的事件，一线人员在处理15分钟（解决时限的50%）内未解决时，则要求其立即升级到二线人员进行处理；
• 优先级为中、低的事件，处理时间超过解决时限的80%时，由服务台对处理人进行督促，要求将规定时间内不能及时解决的事件升级（一线à二线à事件经理）；
• 服务台人员主动监督优先级为中和低的事件处理情况，应及时将不能解决的事件升级；
• 事件经理主动监督优先级为紧急和高的事件处理情况；
• 事件超出规定的解决时限时，系统会将事件信息通报事件经理，由事件经理协调资源，并督促事件的及时被响应与处理。

通知提醒（1/2）

• 工单分（转）派时，发送通知给接收人；
• 紧急事件发生时，发送通知给事件经理、室经理；
• 超出分派次数时，发送通知给事件经理；
• 为关闭代码是“不成功”的事件工单创建新工单时，发送通知给事件经理；

通知提醒（2/2） – 处理过程中

• 对所有的事件，在处理时间过去50%时，发送提醒给事件处理人；
• 对紧急、高优先级的事件，在处理时间过去80%时，发送提醒给事件经理、事件处理人；
• 对中、低优先级的事件，在处理时间过去80%时，发送提醒给服务台、事件处理人；
• 对高、中、低优先级的事件，超过解决时间时，发送提醒给事件经理；

事件管理概要流程

紧急事件处理子流程

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

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

紧急事件流程

紧急事件流程细节

事件工单的状态

事件工单信息项（1/2）

事件工单信息项（2/2）

与其他流程间的关系图

流程角色

角色与职责

流程角色和人员对应表

衡量指标

报表

场景1 – 地市提交申告

场景2 – 业务人员电话/邮件/QQ/飞信进行咨询、投诉、建议、申告

场景3 – 巡检时发现事件

场景4 – 监控平台的事件

场景5 – 紧急事件

场景6 – 未解决的事件

场景7 – 管理层面的关注