互联网产品的更新迭代是非常快的，很多公司推崇敏捷开发，固定每周一个小版本，2周一个大版本的节奏，紧急线上问题、政策限制、实时热点（如新疆棉事件）还需要加急发布。频繁的变更过程就难以避免不出故障，“常在河边走，哪能不湿鞋”。
一、为什么要做故障复盘
规范的流程和高超的技术只是减少故障的发生频次，故障难以避免。出了故障后，为什么要做故障总结呢？
1.复盘成长，这是最主要的价值。吃一堑长一智，通过复盘总结教训，后期工作中规避问题再发生
2.组织过程资产沉淀，故障总结文档可以作为部门的组织过程资产为他人提供前车之鉴，新人入职或新接手项目后可以快速了解之前发生过什么，自己如何重蹈覆辙
3.给老板交代，出了问题后，尤其是线上生产问题，影响大的时候要逐层汇报，有故障复盘，过程清晰明了，沟通效率更好
4.给业务交代，产品Bug、系统故障往往会造成业务损失，要摆好姿态，厘清权责，给业务一个态度和交代
二、什么情况下做复盘
很多人不愿意做复盘，出来问题修复后，想着是能不让别人发现尽量不让别人发现，否则背着Bug后绩效C、D没跑了。或者是“懒”，“好了伤疤忘了疼”。故障和绩效各家公司的标准不一样，有的公司推崇的文化是鼓励员工主动复盘，但对个人而言，复盘更多的是自己的事情。
以下情况都可以做复盘
Ø 产品变更发布后，产生Bug
Ø 未做变更但产品或服务突然不可用(系统攻击、或机房故障)
Ø 操作故障，如产品、运营、研发在使用产品时的操作引发的隐在问题
Ø 产品或服务遭到舆论导向的客诉
Ø 误操作，由于未按照流程、没看清楚、没确认好等无心操作，带来的人为故障
Ø 复盘时间要求：1个工作日以内（24小时），趁热打铁，凉了就没那么“刻骨铭心”了
三、故障复盘形式
按照故障影响范围和对业务造成的损失，每个公司都会对故障进行定级，以电商公司为例，可能会用损单量指标作为故障分级的标准。计算公示：
损单量=故障持续时长*昨日（或上周同期或近七日日均）同时段平均订单，到小时或者分钟级别
故障级别和损单量的关系与公司业务量级以及对故障的容忍度有关。示例如下，P0为最高级故障
1.会议复盘
P0、P1级故障，典型故障、业务比较关注呼声较高的，可以组织会议复盘，当面沟通效率更高、能快速平息故障，解决问题。
参会人员：当事人及其leader 必须参加，产品经理、开发、产品&开发负责人、业务同事及其Leader，关心故障问题的老板们
会议纪要：复盘会议结束后，要形成会议纪要邮件发送参会人及其他周边干系人，会议内容参考复盘总结模板部分
2.邮件复盘
P2~P3故障，影响范围小，业务关注度低的可以采用邮件复盘的方式，把复盘过程邮件抄送相关方，如当事人leader 必须参加，产品经理、开发、产品&开发负责人、业务同事及其Leader，关心故障问题的老板们。
3.文档复盘
P4及以下故障，业务影响很小，团队内做好复盘文档沉淀，作为组织过程资产存档
四、复盘总结模板
1.故障标题
【故障级别】+日期+业务描述+故障简介+复盘总结+责任人，方便信息同步，如很多新闻用XX事件，七一五事件等，例如：【P0故障】20210401-小程序金刚位页面跳转异常-复盘总结-张三
2.故障影响
为什么把故障影响放到最前面？故障复盘内容一般会比长，尤其是老板们每天看的邮件、汇报很多，没时间把所有内容全部读一遍的，把故障影响提前告诉他们，他们自己心里有杆秤，要不要继续关注和跟进下去。故障影响，一般是描述故障带来的业务损失、产品、用户体验损失等多维度的影响分析
3.事件回顾
从故障开始、发现、修复、修复完成的详细过程，需要包含When、Who、Where、What，即什么时间，谁，做了什么事情，目的是通过详细的过程描述，方便发现故障和处理故障过程中暴露出的问题，作为后续改进的依据。例如
Ø yyyy-M-dd hh:mm 故障因xx开始
Ø yyyy-M-dd hh:mm 运营张三发现故障 （或收到监控报警）
Ø yyyy-M-dd hh:mm 张三把问题反馈给开发李四
Ø yyyy-M-dd hh:mm 李四验证发现问题确实存在，企业微信拉群，并通知上级领导报备故障
Ø yyyy-M-dd hh:mm 李四通过代码、监控日志找到问题所在，确认影响范围及故障发生时间点
Ø yyyy-M-dd hh:mm 李四定位问题后，通知上级领导及运营张三准备做回滚（代码修复），预计XX时间完成
Ø yyyy-M-dd hh:mm 李四确认问题已修复，群内同步
Ø yyyy-M-dd hh:mm 张三确认问题已修复，故障处理已结束
Ø 故障从XXX-XXX持续时长：XX小时XX分
4.故障原因
分析总结故障发生的原因，以上述案例为例，
（1）故障发生前导致故障的原因
首先是为什么出现这个线上Bug，代码质量，开发自测、QA测试、产品验收为什么没发现？是没有自测还是测试用例执行不充分？
（2）故障发生后运营上报的原因
上线流程是不是不合理，监控是不是没覆盖？
（3）故障处理过程耗时
定位问题慢的原因？
5.故障总结
Ø 故障发生暴露的问题
Ø 责任认定，目的主要是厘清故障产生各相关者的权责关系，方便后期跟进改进
改进计划
根据故障复盘发现的问题，制定出可实施的改进计划。日后同类型的错误自己及相关的同事都去避免发生改进计划包括todolist、跟进人、deadline
改进计划可以包含但不限于：
Ø 经验总结、知识分享
Ø 监控覆盖
Ø 系统或工具设计改造类
Ø 流程类的、规则/规范类的、机制完善类
Ø 系统、业务需求改造类的
五、小结
出问题不可怕，可怕的出问题不复盘，同样的问题重复犯。不管公司怎么要求，复盘和成长是自己的事情，成长的过程犯错误交学费在正常不过。
