故障复盘别当事后问责的批斗会

上周在园区楼下碰到某云的运维兄弟，蹲在便利店门口啃包子，眼睛红得像兔子。问了才知道，前晚他们负责的支付通道抖了37分钟，刚开了3小时的复盘会，被业务部门追着要”谁的锅”。

别上来就找责任人

说实话，我刚入行那会，也觉得故障复盘就是找错人的会。毕竟出了问题，总得有个说法给上面交差。

可真在一线待久了就会发现，把复盘开成问责会，是最浪费时间的事。

太多团队的流程是这样的：故障刚恢复，大家还没喘匀气，就被拉进会议室，对着操作日志逐行查，谁点了变更，谁没做校验，最后把人骂一顿，写个检讨，这事就算完了。有用吗？没用。下次该出问题还是出。

之前接触过一个电商团队，大促前的库存系统出了问题，超卖了两千多单。复盘会一开始就追着发版的开发骂，说他没做边界值校验。结果翻了半小时日志才发现，是前一天运维改防火墙规则的时候，漏了一个端口段，开发提交的代码根本就没走到生产环境。你看，上来就定责任人，最后闹得两边都不痛快，问题根源也没挖到。

先把现场拼完整

故障刚发生的时候，所有人手里的信息都是碎的。谁看到接口报错，谁看到监控飘红，谁收到用户投诉，这些零散的点，拼不起来的话，你说啥都是瞎猜。

我之前碰到过一个CDN节点故障，一开始大家都拍着胸脯说肯定是缓存节点挂了，结果拼了所有监控的时间线才发现，是上游的DNS解析早了20分钟出了偏差，只是等流量全部打回源站把带宽打满了，大家才感知到故障。

拼现场的时候，别光盯着技术指标。要把所有能拿到的信息都摆出来：变更记录是什么时间提交的，监控告警是几点几分触发的，客服收到第一波用户反馈是几点，业务侧什么时候发现转化率掉了，甚至当时值班的人在做什么，有没有同时处理其他告警，都要写下来。

很多人忽略人的状态，这才是最容易漏的根源。就开头说的那个运维兄弟，我后来跟他聊了半小时才知道，当时他同时在处理另一个机房的磁盘告警，改完配置之后，手滑把灰度的开关推到全量了。那时候他已经连续熬了两个通宵，脑子根本转不动。你要是只看操作记录，就会觉得他操作不规范，往死里罚，但是你没看到他的值班排班表——那个月他们组三个人轮班，其中一个发烧休了一周，剩下的人连轴转了快二十天，这才是底层的问题啊。

别把整改写成空话

很多复盘会开到最后，写的整改措施全是”加强操作规范””提高安全意识””加强值班管理”。这些话写了跟没写一样。

麻烦在于，你说加强操作规范，到底怎么加强？是所有变更都要两个人复核，还是所有高危操作都要加二次校验，还是给操作界面加个确认弹窗，把”确认推送全量”的按钮做成红色的，需要长按3秒才能点？这些具体的动作，才叫整改。

我见过最实在的一个整改项，是某视频团队在故障复盘之后，把所有涉及生产环境的操作入口，都加了一个延迟弹窗。只要是要推全量配置，弹窗会停留10秒，上面写着”你确定要推全量吗？你现在真的想清楚了吗？”。就这么个小功能，之后三个月，手滑推错配置的故障直接少了八成。

真的，根本不需要什么高大上的架构调整。有时候就是一个小的交互改动，就能把人因为疲劳、走神犯的错给兜住。别总想着靠提高人的自觉性解决问题，人不是机器，熬到极限的时候，啥规范都记不住。

别再把故障复盘搞成走流程的事了。

谁在运维和开发的位置上，没碰到过几次半夜被告警喊起来的时刻？你天天跟系统打交道，那系统又不是你家冰箱，开开门就永远制冷，哪有不出问题的。出了问题不可怕，可怕的是出了问题，大家互相甩锅，最后啥经验都没留下，下次同样的坑再踩一遍。

那天我跟那个运维兄弟说，你回去把排班表调一下，别硬扛。他点了点头，把最后一口包子塞进嘴里，转身就往机房走。