1. 前言

1.1 目的

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

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

1.2 适用范围

包括xxx项目相关的所有 IT 生产环境系统所产生的申告、故障、咨询。包括需求人员驻点，收集到的客户提出的申告、故障和咨询

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

1.3 名词解释

1.4 参考资料

2. 角色与职责

3. 输入

4. 流程图

5. 过程描述

5.1 事件登记和分类

• 事件单来源：
  • 客户的投诉和问题，如通过热线、邮件、电话、面谈等方式提交的各种客户投诉或问题。
  • WEB系统的工单，如xxxIT运维支撑管理平台等平台的客户提交处理的工单。
  • 系统故障的告警或问题报告。运维人员实施监控发现的故障或问题、系统告警等
  • 测试漏洞扫描发现的异常
• 登记人，详细记录相关信息，并转交一线处理；
• 一般，为了能获取客户反馈投诉、故障的完整信息，建议登记人自行处理的投诉、故障、问题也进行登记，可直接填写执行情况并直接关闭。
• 对于初步判断为紧急的事件马上升级，由事件经理组织处理。
  • 事件优先级/影响度/紧急度定义，参见附录

5.2 初始支持

1. 属于运维职责范围内可以处理的事件，运维人员应尝试解决，如果无法解决及时升级到一线处理（运维组），一线人员无法处理的，再直接分配到二线处理（开发组、测试组、信息系统部）
2. 对于需要事件经理跟踪的事宜，转发事件经理。

5.3 一线尝试解决

1. 运维组在接受到由服务台派发的事件后，进行调查诊断,尝试解决方案。
2. 事件解决后，在事件管理平台记录事件解决方案并更新事件状态。
3. 需要事件经理跟踪的事宜，转发事件经理。
4. 判断为紧急的事件马上升级，由事件经理组织处理。

5.4 二线尝试解决

1. 二线支持人员（开发组、测试组、信息系统部）接受事件，进行调查诊断，尝试解决方案
2. 对于需要通过变更解决的事件。转入缺陷处理、需求处理流程（可争取到外需的情况）
3. 事件解决后，在事件管理平台记录事件解决方案并更新事件状态
4. 判断为紧急的事件马上升级，由事件经理组织处理。
5. 需要事件经理跟踪的事宜，转发事件经理。

5.5 记录解决方案细节

1. 在事件得到解决后，各线支持人员负责详细记录事件解决过程及方案并更新事件信息。
2. 对于变通解决的事件，可由处理人员按照实际情况，服务台在关闭时触发新事件进行后续跟踪，并进行关联。也可以生成问题单，后续的跟进。

5.6 关闭事件

1. 事件提出人确认事件是否已得到解决，如果解决或暂时解决，事件以成功解决或变通方法解决而关闭。
2. 涉及客户的事件，建议与客户确认后再关闭。

5.7 事件处理的监控与分析

1. 事件经理负责监控和跟踪整个流程的运行情况，及时跟进各种问题和告警信息。协调资源，保证各类事件处理满足客户的标准和要求，并获得最终解决。
2. 对重复事件进行分析。

5.8 紧急事件处理

1. 事件经理负责协调紧急事件的处理
2. 紧急事件处理过程，按照实际需要，对必要信息进行发布

【注】

紧急事件包括：

1) 来自客户或重要干系人（如高层领导）的需求中明确要求紧急处理的;
2）可能或已经影响核心业务正常使用
3）可能或已经引起大量（>50单）用户投诉的

4）由事件经理识别为紧急事件的

6. 输出

7. 事件管理流程指标

事件处理及时率 （参见SLA的工单处理及时率）

8.附录

1、事件定义：

2、根据事件的影响度定义优先级如下：

XXX系统故障共分为黑色故障、红色故障、橙色故障、黄色故障和轻微故障等五个级别，其中轻微故障和黄色属于一般故障，橙色故障属于严重故障，红色和黑色故障属于重大故障；

各级故障定义标准如下：

1.黑色故障

以下几种情形之一的故障将定义为黑色故障：

• 由于XXX计费、出账、充值缴费、余额查询、业务受理或短信提醒等功能故障影响的用户数规模在100万以上或达到总承载用户规模的80%以上（对于承载用户规模小余100万的省份）——以客户确认的影响用户数为准；
• 当次故障累计用户投诉达到1000单——以客户提供的投诉数为准；
• 由XXX系统故障引起的导致关键业务中断（语音、数据和短信业务使用）超过1小时或系统切离线时间超过10小时（不包括计划内工程操作）；
• 由XXX系统故障引起的导致系统出账（包括日账、月账、季账、半年账和年账等）时间延迟超过12小时（不包括计划内的出账延迟）；

2.红色故障

以下几种情形之一的故障将定义为红色故障：

• 由于XXX计费、出账、充值缴费、余额查询、业务受理或短信提醒等功能故障影响的用户数规模在50万以上或达到总承载用户规模的50%以上（对于承载用户规模小余100万的省份）——以客户确认的影响用户数为准；
• 当次故障累计用户投诉达到500单——以客户提供的投诉数为准；
• 由XXX系统故障引起的导致关键业务中断（语音、数据和短信业务使用）超过30分钟或系统切离线时间超过5小时（不包括计划内工程操作）；
• 由XXX系统故障引起的导致系统出账（包括日账、月账、季账、半年账和年账等）时间延迟超过8小时（不包括计划内的出账延迟）；

3.橙色故障

以下几种情形之一的故障将定义为橙色故障：

• 由于XXX计费、出账、充值缴费、余额查询、业务受理或短信提醒等功能故障影响的用户数规模在20万以上或达到总承载用户规模的20%以上（对于承载用户规模小余100万的省份）——以客户确认的影响用户数为准；
• 当次故障累计用户投诉达到100单——以客户提供的投诉数为准；
• 由XXX系统故障引起的导致关键业务中断（语音、数据和短信业务使用）超过5分钟或系统切离线时间超过2小时（不包括计划内工程操作）；
• 由XXX系统故障引起的导致系统出账（包括日账、月账、季账、半年账和年账等）时间延迟超过5小时（不包括计划内的出账延迟）；
• 由于向总部网管系统或数据管控系统数据上传不及时或上传数据错误引起总部考核扣分；

4.黄色故障

以下几种情形之一的故障将定义为黄色故障：

• 由于XXX计费、出账、充值缴费、余额查询、业务受理或短信提醒等功能故障影响的用户数规模在5万以上或达到总承载用户规模的10%以上（对于承载用户规模小余100万的省份）——以客户确认的影响用户数为准；
• 当次故障累计用户投诉达到50单——以客户提供的投诉数为准；
• 由XXX系统故障引起的导致关键业务（语音、数据和短信业务使用）短时间中断（介于1分钟与5分钟之间）或系统切离线且时间不超过2小时（不包括计划内工程操作）；
• 由XXX系统故障引起的导致系统出账（包括日账、月账、季账、半年账和年账等）时间延迟超过2小时（不包括计划内的出账延迟）；
• 由于向总部网管系统或数据管控系统数据上传不及时或上传数据错误引起总部通报批评；

5.轻微故障

以下几种情形之一的故障将定义为轻微故障：

• 当次故障累计用户投诉达到20单——以客户提供的投诉数为准；
• 由于数据下发不及时或下发数据错误导致与周边系统接口异常；
• 由于向总部网管系统或数据管控系统数据上传不及时或上传数据错误引起总部问责；
• 由于违规性操作导致系统运行异常但对业务未产生实质性影响的故障；
• 由于业务突变、版本变化或参数错误等原因导致系统部分进程/功能异常退出但对业务为产生实质性影响的故障；

3、根据事件的紧急度定义处理优先级如下:

4、事件的升级机制

事件升级主要是针对类型为故障和投诉的事件，涉及以下几种情形之一将对该事件级别进行升级处理：

• 故障发生后没有根据故障通报管理要求及时进行故障通报，则在故障级别定义标准定义的故障级别基础上，对本次故障级别进行升一级处理，最高可以升级到黑色故障；
• 故障持续时间和影响范围进一步恶化，已经达到更高级别故障级别定义标准，则自动升级到更高级别的故障级别，最高可以升级到黑色故障；
• 由于故障影响比较恶劣，被客户投诉到公司副总或以上级别管理层，则在故障级别定义标准定义的故障级别基础上，对本次故障级别进行升一级处理，最高可以升级到黑色故障；
• 由于故障影响比较恶劣，被投诉到媒体或网络，在社会上引起极其负面的影响，则在故障级别定义标准定义的故障级别基础上，直接升级到红色或黑色故障；
• 由于服务质量问题，被客户投诉到公司副总或以上级别管理层，则该投诉升级为严重事件。