（100.5）紧急事件再确认
流程描述如下：
序号 | 步骤名称 | 责任人 | 输入 | 输出 | 说明 |
100.5.1 | 确认优先级 | 一线支持 | 事件记录 | 确认紧急的事件 | 一线支持根据该事件相关的业务或IT系统/设备的实际故障情况，并结合其他相关因素，再次确定事件优先级 |
| 优先级为紧急吗？ | 一线支持 | N/A | N/A | 判断优先级＝紧急吗？ q 是，通知事件经理，由事件经理负责紧急事件子处理的处理，转101紧急事件处理子流程 q 否，转100.3一线尝试解决 |
| 可以独立处理吗？ | 一线支持 | 紧急事件 |
| 根据业务影响的严重程度和自身技能，判断自己能否独立处理或需要通知事件经理启动紧急处理流程？ q 能独立处理，转100.3一线尝试解决 q 不能独立处理，转100.5.2通知相关管理层和事件经理 |
100.5.2 | 通知相关管理层和事件经理 | 一线支持 | 紧急事件 | 事件通知 | 通过服务管理平台通知（邮件、短信等）事件经理和相应的管理人员 |
（100.6）记录解决方案细节
流程描述如下：
序号 | 步骤名称 | 责任人 | 输入 | 输出 | 说明 |
100.6.1 | 记录详细的解决方案 | 一线支持/二线支持/帮助台 | 事件记录 | 更新的事件记录 | 根据事件的处理状况填写事件信息项 1．填写“解决方案” 2．确定“事件分类”和“事件所属系统类型”是否正确 3．填写“结束代码” 4．对于故障，应填写“业务恢复时间”以及确定“故障厂商” 5．确定“事件影响度”的等级是否正确 6．根据自己所处岗位填写“事件解决人角色” 7．对于故障和告警，应该明确是哪个配置项发生的，关联正确的配置项 8．填写事件的“实际完成时间”并将状态改为“已解决” 9．如果有自己处理的重复事件单，则简单填写重复事件单的信息项，状态改为“已解决” 一线支持和二线支持接到的由帮助台分配的事件单，应该转回帮助台，由帮助台和用户确认关闭 |
（100.7）关闭事件
流程描述如下：
序号 | 步骤名称 | 责任人 | 输入 | 输出 | 说明 |
| 自动转单/自动告警？ | 帮助台 | 事件记录 | 事件记录 | 帮助台判断是否是客服等系统自动转单或监控系统自动产生的告警； q 是，转100.7.1更新事件状态 q 否，转100.7.2与用户处确认事件解决 |
100.7.1 | 更新事件状态及结束代码，关闭事件 | 帮助台 | 已解决的事件记录 | 关闭的事件 | 更新事件记录，状态为“已关闭”，结束代码根据实际处理结果或用户反馈填写； 如果该事件单有相关联的重复事件，应该将重复事件单一起关闭，重复事件的结束代码和该事件保持一致 |
100.7.2 | 与用户处确认事件解决 | 帮助台 | 用户反馈 | 反馈结果 | 从事件请求人处确认所提供的解决方案是否有效 |
| 是否解决？ | 帮助台 |
|
| 判断是否解决方案是否有效？ q 是，转100.7.1 q 否，转100.7.3重开单处理 |
100.7.3 | 重开单处理 | 帮助台 | 未解决的事件记录 | 新的事件记录 | 帮助台将该事件单的的结束代码置为“不成功”，关闭保存； 创建一个新的事件单，事件信息可以复制，分配到原处理人员处理，新事件单状态“分配到一线”或“分配到二线” 注：帮助台应该和原处理人员沟通事件的确认结果和后续的处理方式 |
100.7.3 | 重开单处理 | 帮助台 | 未解决的事件记录 | 新的事件记录 | 帮助台将该事件单的的结束代码置为“不成功”，关闭保存； 创建一个新的事件单，事件信息可以复制，分配到原处理人员处理，新事件单状态“分配到一线”或“分配到二线” 注：帮助台应该和原处理人员沟通事件的确认结果和后续的处理方式 |
| 是帮助台分派吗？ | 一线支持/二线支持 |
|
| 如果是帮助台分派的事件单，需要返回到帮助台，否则直接到100.7.4 |
100.7.4 | 更新事件状态及结束代码，关闭事件 | 一线支持/二线支持 | 已解决的事件记录 | 关闭的事件 | 更新事件记录，状态为“已关闭”，结束代码根据实际处理结果填写； 如果该事件单有相关联的重复事件，应该将重复事件单一起关闭，重复事件的结束代码和该事件保持一致 |
（100.8）事件处理的监控
流程描述如下：
序号 | 步骤名称 | 责任人 | 输入 | 输出 | 说明 |
100.8.1 | 事件队列的监控 | 事件经理 | 当前打开的事件单 服务管理平台的超时告警 |
| 事件经理可以从以下途径获取事件处理的信息 q 服务台系统自动发送的告警通知 q 查询服务台系统的当前处理中的事件列表 |
| 需要介入吗？ | 事件经理 |
|
| 事件经理根据处理时限和该事件对业务的影响程度，判断是否需要及时介入，帮助协调资源解决 q 需要介入，转100.8.2 q 不需要，则继续监控 |
100.8.2 | 召集资源协商解决 | 事件经理 | 告警事件 支持人员的电话通知 | 解决方案 | 由于处理不及时而可能导致用户满意度下降的事件或疑难事件，事件经理负责召集相应二线专家，共同商讨并制定解决方案，并实施解决方案 |
| 可以解决吗？ | 事件经理 |
|
| q 如果解决，转100.7关闭事件 q 无法解决，转100.8.3升级到管理层解决 |
100.8.3 | 升级到管理层解决 | 事件经理 | 升级的事件记录 | 解决方案 | 事件经理负责将升级事件通报到管理层，通过高层寻求更多的资源介入，共同商讨和制定解决方案 |
（101）紧急事件处理子流程
制定紧急事件处理子流程的目标：
当紧急事件发生时，尽可能采取措施减少对于业务带来的影响
确保对紧急情况的有效管理
- 加快紧急事件的响应和处理速度
- 对紧急情况中的人员及采取的行动加强管理
- 加强处理人员与用户之间的沟通和反馈
- 对紧急情况妥善处理
流程原则
制定各系统应急处理预案
为了确保系统发生重大故障时，能够尽快恢复业务，并充分调动技术力量，在最短时间内排除故障，各系统应该建立相应的应急处理预案，建议预案中的内容至少应涵盖以下方面 ITIL培训：
- 应急预案启动条件
- 应急处理小组负责人和成员联系名单和联系方式
- 应急处理步骤
- 应急信息通报
- 应急善后处理
- 应急保障措施（人员、培训、演习、场地等）
紧急事件上报集团公司
为切实掌握各省公司业务支撑系统紧急事件情况，要求各省公司在紧急事件发生时立即上报，并在紧急事件处理过程中的关键点将处理情况上报，具体上报内容和方式参见2.12集团、省公司两级交互。
紧急事件处理子流程概要说明
紧急事件处理子流程说明如下：
序号 | 步骤名称 | 说明 |
101.1 | 召集应急小组，协调应急会议 | 事件经理主持应急会议，并组织讨论、协调各方资源，分析紧急事件处理方案，并将紧急事件情况通报省中心相关领导和集团公司 |
101.2 | 判断是否属于应急预案中的事件？ | 应急小组和相关厂商根据紧急事件现象和影响程度，判断是否需要启动相应系统的应急预案？ q 如果没有应急预案，则进入101.4组织相关厂商共同分析紧急事件，制定处理方案并处理； q 如果有应急预案，则进入101.3按照应急预案处理 |
101.3 | 按照应急预案处理 | 根据各系统制定的应急预案中的实施步骤，处理紧急事件 |
101.4 | 组织相关厂商共同分析，制定处理方案并处理 | 应急小组负责组织相关厂商共同分析紧急事件，制定相应的处理方案，如果需要集团中心介入处理，则向集团中心申请介入； 处理方案在实施前应得到应急小组和相关领导的认可； 事件处理过程中如果需要中断业务或对系统的IT组件产生变更，则需要按照紧急变更管理流程的定义和要求，提出紧急变更请求 |
101.5 | 紧急事件解除确认？ | 在紧急事件处理方案实施后，应急小组、相关厂商和相关部门对紧急事件是否解除进行确认 q 紧急事件如果没有解除，则重新进入101.4组织相关厂商共同分析紧急事件，制定处理方案并处理； q 如果解除，则进入101.6紧急事件善后处理和总结分析 |
101.6 | 善后处理和通报 | 紧急事件解除后，应急小组向申告方、公司相关领导简要报告紧急事件处理过程，解决方法，事件解除时间，业务恢复情况，并将该信息汇报到集团公司 对于影响度为重大的紧急事件，必须通过服务管理平台提交《重大事件报告》，报告内容和提交方式见2.12集团、省公司两级交互 紧急事件的处理人需要创建一个新问题，将紧急事件处理过程的详细信息记录到问题单中，提交到问题经理，由问题经理组织相关专家进行问题根源的分析 |
