项目管理过程中故障及事件处理流程

一、故障处理流程简述 

       为应对工作日和非工作时间段各项目出现的故障问题，需要快速安排项目人员具备问题排查环境和条件，保障值班机制。

1、支撑人员安排

        项目组应具备故障处理人员，在业务出现故障需应急处理时，能高效快速的定位、处理问题；模块项目经理接到问题反馈或者协同请求时，第一时间安排问题处理人员进行处理，按照规定的时间进行反馈，安排人员日常值班(8:00-20:00)。项目远程值班人员在进行应急保障时必须能够快速响应，远程值班期间，要随时具有排查问题的环境和条件。例如，晚上回家将电脑带回家以备应急支撑处理故障问题。

2、问题排查条件准备

        值班人员要具备快速排查问题条件，提前梳理归集问题排查使用资源，以备应急使用。

3、值班巡检

        根据保障时间及保障类别分为日常保障巡检、网络服务等重大问题保障巡检、上线次日保障巡检，根据不同的保障类型进行不同的值班保障巡检，项目值班人员巡检项和指标进行巡检反馈。

二、故障处理原则

        项目组成员需按照流程上报和处理，以快速恢复生产为第一目标，完成故障处理。

1、处理过程中以保障和恢复生产为首要目标；

2、信息传递的及时性，及时上报负责人，任何与故障有关信息不能在环节中停留5分钟以上；

3、故障处理人员每10分钟反馈进展，包括问题系统、开始时间、影响范围、问题描述、当前进展，持续通报至故障恢复；

4、大规模大范围故障需各项目排查巡检时，每20分钟通报一次结果；

5、24小时内输出故障报告，48小时内完成故障复盘；

三、故障处理流程

故障上报：微信群，移动办公，电话提报的问题及时响应，影响用户数量超过20个，需及时上报项目负责人，避免问题影响范围扩大。

故障处理：收到问题提报时第一时间响应回复，给出临时处理方案及问题原因，安抚用户情绪，避免问题处理不当引发分公司投诉

故障善后：问题处理完后需及时整理生产调度产生的其他故障影响，对生产报表数据、分中心满意度、需求验收等环节进行评估考虑，制定善后工作推进计划，并严格落实。

故障复盘：针对故障发生的场景进行全面总结分析，处理过程中出现的纰漏及时查漏补缺，完善故障处理流程，针对故障出现的影响范围做评估并制定行之有效的防范措施，及时遏制，避免影响范围扩大，并总结此次故障环节中的经验教训，改进故障处理流程及措施。

流程说明：

重点活动	参与角色	内容描述	注意事项
故障上报	分公司及用户	故障由分公司相关人员在故障群上报检查发现故障上报。	/
确定故障信息	项目组	故障上报后项目完成故障信息收集，由项目组事件处理人员牵头处理，先进行故障识别，确认后在微信群通知业务系统进行处理。	收集故障信息包括： 上报信息：上报人姓名、上报时间、上报人联系方式。 影响范围：影响省份、时段、用户区域、用户人数
组织故障定位	项目组	故障确认后，由项目组同步信息给分公司、总部运维小组、项目组，同步进行生产变更排查
故障通报	项目组	由故障处理人员每10分钟反馈进展，包括问题系统、开始时间、影响范围、问题描述、当前进展，持续通报至故障恢复	通报格式示例如下： 问题系统：XXX 开始时间：10:20 影响范围：XX 必现/偶现：偶现 问题描述：XX 生产变更检查： 1、请分公司确认有无生产变更 2、请运维小组确认有无生产变更 3、项目组确认有无生产变更：（注明发布工单号、DB工单号、上个版本号） 当前进展： 17:28 查询日志进一步确认问题。
分公司确认生产变更	分公司	分公司侧需要确认24小时内是否有故障系统相关的生产变更	分公司生产变更核实范围包括但不限于生产网络、域名、主机密码等
是否分公司变更引发	分公司	分公司如果有生产变更，需要进行故障是否由本次变更引发评估	XXX
分公司变更回退	分公司	确认故障是由变更引发时，需要分公司进行变更回退	XXX
运维小组确认生产变更	运维小组、网络运维	运维小组需要确认24小时内是否有故障系统相关的生产变更	运维小组生产变更核实范围包括但不限于生产网络、域名、容器、主机密码等
是否运维小组变更引发	运维小组、网络运维	运维小组如果有生产变更，需要进行故障是否由本次变更引发评估
运维小组变更回退	运维小组、网络运维	确认故障是由变更引发时，需要运维小组进行变更回退
应急预案检查	项目组	项目组进行应急预案检查，是否有对应故障场景的预案，包含版本上线前检查、常见故障应急处理。	每周二、周四由项目组对即将发布版本进行检查
执行预案	项目组	项目确认有对应故障场景的预案时，告知项目组负责人后直接处理。
项目组确认生产变更	项目组	项目组确认24小时内是否有生产变更	项目组生产变更核实范围包括但不限于版本上线、DB变更、配置变更
是否项目组变更引发	项目组	项目组如果有生产变更，需要进行故障是否由本次变更引发评估
是否业务量变更	项目组	确认故障不是由项目组生产变更引发时，需要项目组进行业务量变更评估	业务量变更评估需要项目组根据实际情况进行，包括但不限于接口调用、REDIS数据、基础数据、接入渠道
定位故障信息	项目组	确认故障不是由项目组业务量变更引发时，需要项目组进行故障信息定位
是否外围模块引发	项目组	项目组评估故障是否因为外围模块接口等问题引发
与外围模块对接	项目组	确认故障是由外模块引发时，需要项目组与外围模块对接	项目组要主动跟踪外围模块处理进展
外围模块解决	外围模块	外围模块配合处理，以快速恢复故障为第一目标	在与外围模块沟通处理过程中如果遇到困难，需要第一时间上报
项目组执行方案	项目组	确认故障非外模块引发时，需要项目组执行恢复方案	执行过程中如果遇到困难，需要第一时间上报
分公司验证	分公司	分公司组织相干人员进行业务恢复验证	分公司开始验证包括接收到分公司内部回退完成、运维小组回退完成、执行预案完成、执行恢复方案完成等通知后开始
验证是否通过	分公司	分公司如果验证不通过，项目组继续进行故障定位
故障恢复	分公司	分公司验证通过，同步故障恢复信息
故障善后工作	项目组	需及时整理生产调度故障影响，对生产数据、分中心满意度、验收等环节考虑，制定善后工作推进计划，并严格落实。	XXX
输出复盘报告	项目组	由项目组输出复盘报告	复盘报告主要包括：故障描述、处理过程、影响范围、故障定位、改进措施、经验教训总结
组织复盘评审	项目组	回顾整个故障处理全流程，分析故障原因，对故障经验进行总结分享
故障闭环		故障闭环，留存相干过程文档及会议纪要

（一）常见故障处理机制

1、版本回退

版本回退：如果故障原因经判断是前一天晚上发布有关，则首先应考虑在第一时间回退来保障故障恢复。

2、定时任务切换

针对于部分功能省内执行流程，省间执行流程等功能上线优化，若出现执行异常可先与负责人报备并发送邮件授权后，将控制流程的定时任务切换至灰度X线进行应急处理。

定时任务切换原则：

系统出现问题时，无法通过其他页面相关功能进行操作恢复的可考虑切换定时任务。

评估新版本的业务影响，切换定时任务后是否会造成更大影响，若切换后影响过大可暂缓切换定时任务。

若分公司对新版本部分功能反应较大，但尚未涉及版本回退时，可切换定时任务，将部分功能切换至稳定版本。

后台已无手段进行恢复，必须切换定时任务时，及时上报负责人，经授权后进行切换。

3、功能开关切换

部分新上线或者优化的功能由开关控制的，默认开关打开状态，若执行流程异常，无法正常使用，可先与负责人报备并发送邮件授权后，关闭开关，使用之前的业务功能进行应急处理。

功能开关切换原则：

1、业务功能无法正常使用，且有开关控制时，可上报负责人关闭开关；

2、部分功能只对部分省份开放使用时，未开放省份要求使用新功能时，可上报负责人经评估后方可打开。

3、若开关变更后的影响范围更大时，可暂缓变更，先评估是否可用其他处理手段进行恢复。

4、若开关控制的功能与外模块关联较深，先暂缓变更，经双方沟通一致后方可变更。

5、经项目组评估，开关变更前后无影响时，暂缓开关变更。