编辑导语：我们在日常工作中很多时候都需要复盘，特别是在完成一个项目或者遇到技术问题时，复盘可以更好的解决问题，避免后续再次发生，也能得到很多经验；本文作者分享了关于互联网人在遇到故障时的复盘流程，我们一起来了解一下。
互联网产品的更新迭代是非常快的，很多公司推崇敏捷开发，固定每周一个小版本，2周一个大版本的节奏，紧急线上问题、政策限制、实时热点（如新疆棉事件）还需要加急发布。
频繁的变更过程就难以避免不出故障，“常在河边走，哪能不湿鞋”。
规范的流程和高超的技术只是减少故障的发生频次，故障难以避免；出了故障后，为什么要做故障总结呢？
- 复盘成长，这是最主要的价值。吃一堑长一智，通过复盘总结教训，后期工作中规避问题再发生；
- 组织过程资产沉淀，故障总结文档可以作为部门的组织过程资产为他人提供前车之鉴，新人入职或新接手项目后可以快速了解之前发生过什么，自己如何重蹈覆辙；
- 给老板交代，出了问题后，尤其是线上生产问题，影响大的时候要逐层汇报，有故障复盘，过程清晰明了，沟通效率更好；
- 给业务交代，产品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. 故障总结
- 故障发生暴露的问题；
- 责任认定，目的主要是厘清故障产生各相关者的权责关系，方便后期跟进改进。
6. 改进计划
根据故障复盘发现的问题，制定出可实施的改进计划。日后同类型的错误自己及相关的同事都去避免发生改进计划包括todolist、跟进人、deadline。
改进计划可以包含但不限于：
- 经验总结、知识分享；
- 监控覆盖；
- 系统或工具设计改造类；
- 流程类的、规则/规范类的、机制完善类；
- 系统、业务需求改造类的。
出问题不可怕，可怕的出问题不复盘，同样的问题重复犯。
不管公司怎么要求，复盘和成长是自己的事情，成长的过程犯错误交学费在正常不过。
作者：千冰仪，微信号公众号：数据干饭人，主要从事数据中台产品体系建设，包括：开发套件、数据资产、BI应用、精准营销平台、机器学习平台等。
本文由@数据干饭人 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议
,
