故障复盘从来不是找背锅侠

上周跟一个做基础架构的朋友在写字楼楼下喝冰美式，他刚熬完三个小时的复盘会出来，脸皱得像被告警炸过的监控面板。说出来你可能不信，三个小时的会，一半时间在跨团队掰扯责任，剩下一半时间在对着PPT念套话，到散会的时候，没人说清楚当时到底是哪个配置错了，也没人说接下来要改哪行代码。

先把“追责”的牌子摘了

我见过太多团队，一提到故障复盘，第一反应是先把当时值班的人、改了上线代码的人叫到会议室前排，像审犯人一样问“你当时为什么这么做”。

开场十分钟，会就变味了。前端说后端接口超时拖慢了页面加载，后端说数据库慢查询占满了连接池，DBA说存储集群当时IO直接飘到了天花板，飘到最后，没人记得当时是谁手滑把流量切到了已经下线的测试可用区。

没人敢说真话。

你以为藏着掖着就能把这事混过去，实际上下次遇到同样的流量峰值，手滑的人换一个，故障还是会原封不动炸在同一个路口。甚至因为上次的操作没人敢提，连对应的应急流程都没人敢更新，相当于在同一个坑里摔两次，连坑在哪都没人敢说。我之前就见过一个团队，因为一次误操作把值班的实习生骂到当场掉眼泪，后来那实习生离职之后，下次遇到同样的配置错误，再也没人敢站出来提当时的操作漏洞，硬生生把10分钟能恢复的故障拖了两个小时，算下来损失的钱，够给那个实习生发三年工资。真正有价值的故障复盘，第一原则是给所有人足够的心理安全感——你敢说当时自己慌了神手滑点错了，大家才敢顺着这个点往下挖真正的问题。

别把根因挖到“人不行”就停

很多复盘的报告，最后写出来的根因永远是那几句：值班人员应急响应不及时，上线人员操作不规范，测试环境覆盖不全。说白了，这根本不是根因，这是你懒得往下挖的借口。

之前有个做电商的朋友跟我吐槽，他们团队上次出了个大故障，最后查了三层才摸清楚源头：根本不是值班的同学没及时拉告警群，是上次版本升级的时候，把告警系统里值班群的webhook地址配错了，所有告警消息全发到了一个早就废弃的测试群里，连续两个小时没人看到。再往下挖，为什么配错了没人发现？因为配置上线之前的检查清单里，根本没有webhook连通性校验这一项。再往下挖，为什么检查清单缺这一项？因为当初写这份清单的人离职的时候，没把这部分的维护责任交接给任何一个人。

你要是把锅扣在值班同学头上，下次他就算把手机的告警音量拉到最大，消息根本到不了他手机上，有什么用？

根因的终点，永远是可落地的流程、工具、规则的漏洞，不是某个人的道德或者能力问题。这点想不明白，你就算把全团队的人都骂一遍，该漏的告警还是会漏，该配错的参数还是会配错。

复盘的产出不是厚厚的PPT

我见过最离谱的一份复盘文档，光故障背景介绍就写了八页，配了十几张精美的架构图，最后列的整改措施就三行字：加强值班培训，提高应急意识，完善流程规范。

这跟没写有什么区别？

好的复盘产出，从来不是存到共享盘里再也没人打开的精美PPT。是把当时踩的坑，补到对应的操作手册里——比如那个配错webhook的问题，就应该在配置上线的自动化流水线里加一步，发一条测试消息到目标群，收到回执了才算配置通过；是把当时绕了半小时才定位到的故障点，加进值班的应急排查清单里，下次再遇到类似的CPU飙高，值班同学不用翻半小时历史文档就能找到对应的操作步骤；甚至是当时大家手忙脚乱用错的那个带bug的应急脚本，直接改对了放到团队的公共脚本库，省得下次有人再翻出来个老版本把问题搞更大。

别搞那些虚的。

所有整改项必须有明确的验收标准——不是“加强培训”，是“下周三之前给所有值班同学做完告警配置的实操考试，80分及格”；不是“优化监控”，是“在这周内把告警消息延迟超过10秒的问题修复，配置对应的告警阈值”。整改措施如果不能落到具体的人、具体的时间节点、具体的工具操作上，那这场复盘会开了还不如大家早点下班改bug。

说实话，我跑了这么多互联网团队，见过真正把复盘做透的团队，根本不会在故障发生之后把人吓得不敢说话。之前去一个做云服务的团队交流，他们上个月刚因为跨地域数据同步的延迟问题，影响了小几百万的订单量，复盘会上我就坐在旁边，当时触发故障的那个研发同学，自己拿着键盘把当时的操作步骤一步一步讲得明明白白——从最开始看到监控告警，到怎么判断是同步链路的问题，到最后操作的时候哪个超时参数设错了，全程没人打断他，大家就顺着他的步骤，把每一个环节的漏洞都标出来。最后散会的时候，大家还一起吐槽当时的监控告警弹窗太小，晃了三次才看到。

这才对嘛。

故障这东西，你躲是躲不掉的。就算你把所有流程都设计得天衣无缝，指不定哪天哪个机房的光纤被施工队挖断了，哪个云服务商的底层存储飘了，该炸还是得炸。你能做的，就是每次炸完了，别忙着找个倒霉蛋顶锅，真的把当时踩的坑记下来，补上。下次再遇到类似的问题，大家不用慌慌张张翻文档，不用互相甩锅，能快一点把服务拉起来，少影响点用户，比什么都强。