上周跟三个不同公司的运维团队吃大排档，半桌人吐槽各自刚交的复盘文档。有个哥们说他熬了两个通宵，把责任链从产品经理一路捋到机房保洁，最后文档交上去，领导扫了三行就批了个”不够深刻”。他当时差点把手里的烤串签子捏断。
别一上来就找那个背锅的人
太多团队的故障复盘，从开门的第一句话就歪了。
没人先聊系统到底哪块出了问题，先问”当时是谁值班”。
上次听朋友说他们团队的支付通道在大促时挂了40分钟，最后复盘结论是”值班工程师巡检不认真”，扣了当月绩效。结果三个月后同个故障又爆了——没人提，当时用的巡检脚本是三年前写的，根本没覆盖新上线的三个灰度节点，就算工程师把脚本跑十遍，也发现不了那几个节点的安全证书已经过期了。
真正的故障复盘，第一步从来不是对着人说话，是对着堆成山的日志说话。你得把故障发生前72小时的所有变更都列得明明白白：谁改了网关的路由配置，谁把原来的限流阈值从1000调到了10000，谁临时割了机房出口的10G带宽去给新的测试集群用。这些东西摆到台面上，谁的操作有问题一目了然，但真没必要揪着某个人的失误往死里批。
说白了，人只要在敲键盘做操作，就有概率出错。你就算把所有核心操作都加上双人复核，也挡不住两个同时熬大夜的工程师，看走眼把同一个参数填错。我见过太多团队把复盘搞成批斗会，最后所有人都学会了藏日志、删变更记录，下次出故障第一反应不是先捞系统，是先把自己的操作痕迹擦干净。这才是最贵的代价。
别把复盘写成没人看的厚文档
我见过最夸张的一份故障复盘，写了47页。
从分布式系统的一致性原理，讲到国内外互联网行业的运维趋势，最后存到公司网盘的三级目录里，除了写文档的人，没人打开过第二次。
有个做云服务的朋友跟我说，他们之前的复盘文档平均阅读时长是12秒——大家打开文档，直接拉到最后一页看整改清单，前面的技术分析半字不看。这就很扯。
真正有用的复盘文档根本不需要写这么长。第一页就把最核心的信息列清楚：故障从哪开始，影响了多少用户，持续了多久，是谁第一时间发现的，花了多久把服务恢复的。剩下的内容别写那种正确的废话，比如”我们要加强团队的应急响应能力”——这种话写了等于没写。要写具体的：比如当时的告警为什么晚了47秒？因为告警规则里的阈值是按去年的流量设的，今年QPS涨了三倍，原来的阈值触发条件早就不准了，下次要把告警规则的评估周期改成每季度一次，谁来负责，什么时候改完。
所有整改项必须对应到具体的动作、具体的人、具体的截止时间，没有落地动作的复盘，全是自我感动。
别等大故障出了才想起复盘
很多团队有个很奇怪的执念，只有挂了核心服务、影响了几十万用户的大故障，才值得花几个小时开复盘会。那些影响了几个用户、持续了两分钟就自动恢复的小问题，根本不值得提。
这就大错特错。
我之前接触过一个做电商的团队，他们定了个规矩，不管故障大小，只要是触发了告警、需要工程师手动介入处理的问题，都要做个15分钟的快速复盘。比如上次有个商品详情页的接口，在用户集中访问某个新上线的小众品牌时，偶尔会返回502，持续了大概30秒就自动恢复了，当时值班的同学本来想在故障记录里写”偶发抖动，无需处理”，结果快速复盘翻日志的时候发现，是那个接口的连接池配置比实际需要的少了两个，刚好在流量峰值的时候占满了。要是等这个问题攒到双11当天，那损失可就不是30秒的小抖动了。
真的，小故障从来不是”运气好没出事”，是系统在给你递小纸条，提醒你哪里有裂缝。你要是假装没看见，下次裂缝变大了，塌下来砸的可是整个团队的饭碗。
上周跟之前吐槽写复盘写到脱发的哥们再见面，他们团队把原来的流程全改了。不再要求写几千字的正式文档，每次复盘就拿个白板，把故障的时间线一笔一笔画出来，把找到的问题挨个列上去，谁认领整改项就写在白板旁边的便签上，散会就把白板照片贴到团队群里，下次开会先看上次的便签有没有落地。
他说现在再也不用熬夜凑字数写文档了，这两个月团队出的小故障，比之前少了六成。