故障review流程

1：故障Review负责人

有对应的Team或TeamLeader组织

2：故障会议准备

主要从故障平台上准备相关信息

1：故障影响时间范围及故障的详细处理过程

2：故障的影响范围，及造成的大概损失和后果（最好有相关记录数据）

3：故障产生原因分析

4：故障改进计划及避免方案（可以现场讨论）

5：如何跟进，改进计划确认到具体的负责人，并提供时间节点（开始时间-结束时间）

3：故障处理case：

详细处理过程示例  
从故障开始、到发现、到处理、到处理完成的详细过程，需要包含日期、时间、事件、人员；
  目的：能够通过详细的过程描述，方便找出我们在发现故障和处理故障过程中暴露出的问题，做为后续改进计划的依据

    ① yyyy-MM-dd hh:mm 故障开始
    ② yyyy-MM-dd hh:mm XX发现了这个故障或接到告警，并通知了谁进行问题排查
    ③ yyyy-MM-dd hh:mm XX确认了问题原因
    ④ yyyy-MM-dd hh:mm XX负责紧急处理过程
    ⑤ yyyy-MM-dd hh:mm XX确认线上问题已恢复正常
    ⑥ yyyy-MM-dd hh:mm XX开始查找故障期间会产生影响的问题数据
    ⑦ yyyy-MM-dd hh:mm XX来确认问题的根本原因
    ⑧ yyyy-MM-dd hh:mm XX开始修复数据
    ⑨ yyyy-MM-dd hh:mm XX确认修复完成，进行复盘
    进行故障记录，后续总结并review

导致故障原因

    ① 导致故障的角色是谁：dev、qa、ops、dba、
        [1] 代码及设计问题：dev是否有进行code review，是否有case没有执行。
        [2] 需求问题：需求排期时是否有深入思考需求的合理性，可行性和影响范围。
        [3] 测试过程：测试过程是否执行所有checklist，是否按流程/规范进行，是否进行codediff
        [4] 依赖第三方不受控制：为什么没有设计备用方案
        [5] 误操作：为什么没有审批/监督协作人员或审批/监督协作人也没有发现这个操作会带来什么影响

    ② 故障发现时间过长原因
        [1] 线上操作后是否有检查 功能、监控、日志问题
        [2] 监控是否完整，是否有异常处理流程
        [3] 报警阈值设置是否合理
        [4] 是否有人接到告警后未及时响应
        [5] 业务量过小导致无人关注

    ③ 处理过程慢原因：
        [1] 是否有安排人员及时定位/处理问题
        [2] 没有看监控定位故障时间，定位过程是否合理

根据review 中发现出来的问题，我们需要制定出可实施的改进计划。

目的：同类型的错误我们自己及相关的同事都不应该在犯

改进计划的记录至少包含： 措施、跟进人、完成时间 

改进计划可以包含但不限于下面几方面：

1. 规则类的、流程类的、规范类的
2. 人员经验总结类的
3. 监控添加
4. 系统或工具设计改造类的
5. 流程类的、规则/规范类的、机制完善类的
6. 人员经验总结类的、知识分享类的
7. 报警设置
8. 系统、业务需求改造类的

故障review提交后，将实时同步在JIRA上创建改进计划的任务。请务必在既定的时间内将任务完成并修改对应的状态，改进计划创建后只能在jira系统操作。