故障复盘别做成甩锅大会

上个月去南京雨花软件园找几个老同事撸串，冰啤刚喝到第三瓶，做运维的大刘把杯子往桌上一墩，骂上周的复盘会开得窝火。

线上核心服务挂了112分钟，复盘会开了整整240分钟，其中一半时间在翻三个月的变更聊天记录找责任人，另一半时间在补之前漏写的工单备注，最后定位的原因是机房空调制冷管漏了，机柜温度飙到92度触发了服务器自动降频保护。

白忙活。

先搞清楚复盘的第一现场在哪

很多团队的故障复盘从一开始就走偏了。上来就拉上所有相关方开大会，对着聊天记录逐句抠谁哪句话说过“这个配置没问题”，根本没人先去拉故障发生时间点的全链路监控曲线，没人去导当时各个节点的报错日志，没人去翻用户端实际的报错截图。

我见过最离谱的一次跨部门复盘，把近三个月所有的代码变更、配置调整、版本发布记录全打印出来，一摞纸有半人高，从下午两点核对到晚上八点，眼睛都看花了，最后发现根本跟代码没关系，是运营商的专线临时断了半分钟，触发了服务熔断，流量没兜住全打在了单节点上。

说白了，复盘的第一现场从来不是会议室，是故障发生的那几十分钟里，系统真实跑起来的所有痕迹。你不先把这些痕迹拼起来，坐会议室里扯再多谁的责任，全是无用功。

别把代价算漏了最疼的那部分

翻了这么多复盘报告，我发现大家算故障损失的时候，总有个统一的盲区。

算来算去，全是直接的交易损失、广告投放的折损、渠道的赔付金额。

很多团队算故障损失的时候，天生就对人付出的精力和情绪成本视而不见。

那些没被算进去的账是什么？是客服组的小姑娘连续接了八个小时的投诉电话，下班的时候嗓子哑到说不出一句话，含着润喉糖坐地铁回家；是产品经理连着熬了两个通宵，改了三版用户告知弹窗，还要在各个用户群里挨个给来问的人解释原因；是开发团队本来排了三周的版本迭代，硬生生往后推了十天，之前跟业务团队拍胸脯承诺的功能，到点交不出来，还要陪着笑脸道歉。

这些成本不会出现在财务报表的科目里，但会实打实攒在团队的情绪账户里。攒多了，下次再遇到故障，没人敢主动站出来说自己当时在哪一步做了什么操作，都怕被揪出来当典型挨批。

麻烦在于，你把这些人付出的精力全当成理所当然的事，下次再出事，没人愿意掏心窝子跟你说真话。大家都学着把责任往流程上推，往别人身上推，本来十分钟能定位的问题，硬拖成俩小时的大事故，最后买单的还是普通用户。

最没用的复盘是写满了“下次注意”

我现在看到复盘报告里的改进措施栏，先看有没有具体的执行动作。

十份报告里有八份，写的是“加强变更校验”“提高监控覆盖率”“强化值班人员责任意识”。全是没有任何执行标准的正确废话。

什么叫加强变更校验？是把原来的单人审批，改成必须两个人交叉核对配置项才能提交，还是把原来的提前24小时发变更通知，改成提前48小时抄送所有链路相关方？什么叫提高监控覆盖率？是把核心接口的告警阈值从原来的错误率5%报警，改成错误率0.1%就触发电话告警，还是把原来只监控自身服务的可用性，改成把所有第三方依赖的接口响应时间也纳入监控面板？

没落地的措施，写了等于没写。

之前跟一个做基础架构的团队聊，他们去年出过一次因为配置参数错了导致的服务全挂，复盘的时候没搞什么全员检讨，就改了三个硬规则：第一，所有涉及核心链路的配置变更，必须先在预发环境跑满两小时的流量回放，性能指标不达标不许上线；第二，变更窗口里如果错误率超过0.5%，系统自动触发回滚，不需要等值班人员手动操作；第三，每个季度抽两个下午，把之前出过的故障场景做成模拟演练，所有人轮着当值班人，从发现告警到定位问题全流程走一遍。

这事没那么玄。

就这三个硬规则，执行了半年，他们团队同类配置错误导致的故障次数直接掉了八成。

说实话，我特别烦那种一遇到故障就全公司通报批评的做派。

线上系统每天跑着那么多变更、那么多流量、那么多外部依赖，出故障本来就是大概率的事。要是每次出了事，大家的第一反应是找个倒霉蛋出来背锅，下次谁还敢在故障发生的第一时间，把真实的原因说出来？

真正的故障复盘，从来不是为了证明谁错了。

是为了下次踩同一个坑的时候，整个团队能少慌一点，少折腾一点，少让用户跟着受牵连。