运维定期check未close的故障复盘发送到核心研发群中。逾期没有完成的可以升级到alex
复盘后由故障对接人进行todo的check，所有todo完成之后告知运维故障复盘close。
形成Todo
文档准备
IC做完以上部分需要和TL一对一沟通
1、一般是引起故障的IC或者TL）准备复盘文档组织会议进行故障复盘2、故障对接人报备运维xx故障解决完毕后面会进行故障复盘3、公司所有部门复盘文档集中在同一个wiki或者石墨文件夹，所有产研均有权限查看。
复盘文档基础部分内容
M2、M1在周会宣讲故障原因（让其他的IC同学知道主要原因），也可以是抽查的形式问某个同学，xxx上周的故障复盘结果发给大家了，你来给大家讲讲这个故障具体原因是啥。
邮件周知所有研发故障原因以及复盘内容。
5Why形式寻找根因，以及可以想到的改进点。
复盘前准备
如何复盘
提前半天发出复盘文档给到参与人。故障模块相关产品、测试、运维、开发(前期必须要有技术核心群成员参与)。参与人提前阅读并通过评论的形式进行讨论。
过故障流水以及故障问题分析
复盘完成后
所有Todo必须有明确的动作且有明确的负责人和完成时间点。避免不可量化的”尽量“、”加强“
故障处理流水时间线(从发生到最后解决)
1、设计、开发、上线等各环节是否有问题？（包含但不限于需求质量、需求理解、测试等）为什么没提前发现？安全流程是否执行？2、各测试环节是否可以发现问题？为什么没提前发现？3、有无线上操作失误？或者线上问题处理不到位？为什么没提前发现？4、监控是否在第一时间发现了？为什么没有？5、响应/解决速度能否更快？6、损失能否更小？如何做到？
与会人参与讨论补充Todo
将本次故障套用到todo里面，看todo完成后这个故障会不会继续发生，如果还会的话继续寻找改进措施。
导致故障产生的原因或者行为
复盘会议
影响范围
1、一句话描述故障2、开始时间3、结束时间4、故障级别5、故障处理流水(从发生到最后解决)
思考分析
故障对接人
记录wiki文档（所有人均可查看）
其他可以思考回答的问题如下：
