故障复盘从来不是用来追责的
2026-11-01 15:38:17
作者：
fawen
上周去见一个做基础架构的朋友，他刚熬完一个3小时的支付链路故障。散了复盘会出来脸都绿了。
CTO在会上直接拍桌子，说负责网关的组为什么没提前做容量评估，最后当场扣了季度绩效。他说那天散会他在楼梯间抽了三根烟，说这会开的，下次再出故障，没人敢说实话了。
复盘的第一原则是先找事实不是先找责任人
很多人搞复盘上来就追谁的锅，完全搞反了顺序。那次故障的实际触发点很简单：上周三凌晨的一次配置变更，运维同学把灰度的路由权重从10%改成了100%，没注意到对应的新版本网关服务还没完成压测，刚好赶上早高峰的流量峰值，直接把集群打挂了。
支付链路故障时间线还原示意图
很多团队的复盘会，前半小时都在掰扯“这个配置是谁点的确认”“当时为什么没人检查”，根本没人坐下来把时间线捋清楚：变更是什么时间提交的，哪个环节的校验规则没拦住，流量是从哪个时间点开始掉的，监控告警晚了多久响。说白了，你连事实都没拼全，谈什么改进？
更离谱的是有的公司要求复盘会必须在故障发生后24小时内出报告，人都还没从应急的疲劳里缓过来，写出来的东西全是情绪发泄，要么就是把锅往资历最浅的同事身上推，一点参考价值都没有。
那些写在报告里的整改项大多是无效劳动
我见过太多故障复盘报告，整改项列了十几条，什么“加强人员培训”“提高安全意识”“建立值班响应机制”，全是正确的废话。上次翻到某团队去年的12份故障复盘报告，里面8份都写了“加强监控告警覆盖率”，结果今年同一类故障出了4次，告警还是没覆盖到核心的链路节点。
麻烦在于，写这些整改项的人根本没去想，你要加强监控，是哪个指标没覆盖？需要加多少预算？谁来做？什么时候上线？没有这些具体的东西，所有整改项都是写在报告里给领导看的，下次故障该怎么出还怎么出。我见过最离谱的一份复盘报告，整改项第一条居然是“要求值班人员7*24小时保持手机满电，不得出现关机情况”，合着之前出故障是因为值班同学手机没电关机了？那你倒是说说，当时告警是哪个环节漏了，为什么没触发备用值班人的通知？
故障整改项落地优先级矩阵图
真的有用的整改项，从来都很小。比如之前碰到过一个团队，出了一次数据库主从切换的故障，复盘之后定的整改项不是“提升数据库可靠性”这种空话，是“把主从切换的脚本校验逻辑加上磁盘剩余空间判断，避免切换的时候因为磁盘满了启动失败”，就这么一个小改动，之后两年再也没出过同类问题。你说这些写空话的人，是真的不知道怎么改吗？不是，是因为写具体的整改项要担责任，写空话永远不会错。
好的复盘会要敢谈那些没人敢说的取舍
很多团队的复盘，只谈技术问题，不谈业务上的取舍，这是最大的忌讳。比如开头提到的那个网关故障，当时为什么那个新版本的网关服务没压测就敢上灰度？因为产品那边催了快三周，说那个新的优惠活动必须在大促前上线，不然要错过流量高峰，运维那边反复说压测要花3天时间，产品说等不了，最后两边折中，先上10%灰度，等压测完了再全量。结果呢？负责配置的同学记错了灰度比例，直接拉满了。
这些话，在正式的复盘会上谁敢说？说了就等于打产品的脸，等于说当时为了赶进度冒了风险。但这些恰恰是故障最核心的诱因。你要是复盘的时候把这些话都绕过去，最后只把锅扣在运维点错按钮上，那下次换个新人上来，一样会出同样的问题。
说实话，没有哪个团队是在所有准备都做足了的情况下才上线的，大家都是在风险里走钢丝，复盘的意义，就是把当时走钢丝的时候哪块地方没踩稳记下来，下次别在同一个地方摔。要是你连当时为什么要走这段钢丝都不敢提，那复盘就真成了走过场。
后来那个朋友跟我说，他们后来改了故障复盘的规矩，开会的时候第一句话就说，今天谁要是因为说真话被批评，他第一个跳出来反对。第一次按这个规矩开的复盘会，大家把之前藏了大半年的几个流程漏洞全说出来了，改了之后这俩月的线上故障数直接掉了一半。
你看，这事没那么玄。不需要什么复杂的方法论，不需要请外部专家来做培训，只要你别把复盘会开成批斗会，让大家敢说实话，愿意把真的问题摆出来，自然就会有改进。别总想着靠复盘证明什么，也别总想着靠复盘抓几个典型，故障本身就够让人头疼了，何苦还要在事后给大家添堵呢？
免责声明：市场有风险，选择需谨慎！此文仅供参考，不作买卖依据。如有侵权请联系删除。
文章名称：
故障复盘从来不是用来追责的
文章链接：https://m.itcdj.com/it/364.html