上周跟在某互联网公司做SRE的朋友在园区门口喝冰美式，他攥着半杯化了的咖啡跟我吐槽，刚结束两小时的故障复盘会，散会的时候老板拍着他肩膀说“下次大家多注意”，他回到工位坐了二十分钟，觉得这两小时的会，半点儿用没有。
没用。
别一上来就找“背锅的人”
很多团队开故障复盘会的开场，永远是先翻操作日志，找那个最后点下生产环境发布按钮的人。
上次他遇到的那次故障，是网关层的限流阈值设错了，大促前半小时流量刚上来，就把30%的用户请求拦在了外面。翻日志的时候大家发现，这个阈值的配置，是三个月前一个已经离职的同事改的。会议室里瞬间安静，所有人盯着屏幕上那个已经灰掉的名字看了足足五分钟，没人说话。
大部分人对复盘的误解，是把“找到责任人”当成了整个流程的终点。
真要顺着这个逻辑往下追，能扯出一长串的关联人：当时提交配置变更的MR，审核的同事因为赶版本上线，扫了一眼就点了通过；原定上线前的全链路压测，因为排期冲突临时砍掉了；监控系统的告警阈值设得太高，流量涨了三倍才弹出第一条提醒，等值班的人收到推送点进系统的时候，已经有两千多用户在支付页面卡了快一分钟。
这哪是某一个人的错？
写在PPT上的“根因”，多半是假的
那场会最后做的PPT，我瞟了一眼。根因那栏写的是“研发人员对网关配置规则不熟悉，操作存在疏漏”，对应的整改措施是“下周组织全员开展生产环境操作规范培训”。
说实话，看到这行字的时候我差点笑出来。这是多少团队复盘的标配内容啊？听着政治正确，挑不出半点儿错，实际上啥用没有。培训完了，该错还是错。
说白了，这就是把所有人都知道的正确废话，往PPT上堆。真的根因是什么？是三个月前业务量悄悄涨了40%，当时所有人都铆着劲赶新版本上线，没人提一句要给网关的限流阈值做动态调整；是值班的同学收到告警之后，要切三个不同的系统才能定位到具体故障点，光找问题就花了二十分钟；是上次出现过一次类似的小流量拦截，当时因为影响范围小，大家觉得没必要记，转头就把这事忘得一干二净。
这些东西，写PPT的人敢往上写吗？写了就意味着要掏预算改监控系统，要跨部门协调调整变更流程，要占本来就排满的迭代排期。哪像组织一场培训、补一个流程文档来得快，零成本，还能在汇报的时候显得工作做得到位。
那些被写在复盘PPT最显眼位置的整改措施，往往因为需要协调资源、需要跳出大家舒适的工作惯性，最后躺在共享盘的文件夹里，再也没人打开过。
最有用的复盘，从来不是写给老板看的
我之前在一个做云服务的团队待过，他们开故障复盘会根本不搞什么正襟危坐的流程。就拉上当时在一线处理故障的三四个同学，找个没预约的小会议室，泡几杯速溶茶，从故障发生的第一秒开始倒推。
你当时看到告警第一反应是什么？哦，为什么没立刻切备用节点？哦，切备用节点的操作手册存在老的共享盘里，链接半年前就失效了。谁当天跟进这个事？下午就把操作手册更新到内部知识库，给所有值班的同学发一遍永久链接，下次再发现链接失效，直接在群里@平台管理员追责。
好的故障复盘，最后落下来的全是能立刻落地的小事。不是那种“提升团队整体风险意识”的空话，是你下次遇到同样的问题，能少花十分钟定位，能少打五个跨部门的协调电话，能让正在等服务的用户少等两秒。
不过话说回来，很多团队的复盘之所以变味，也不全是大家想摸鱼。毕竟要写一份能过审的报告，要应付各个部门的问询，要避免自己被划进“责任人”的范畴，自然就会把那些可能得罪人的内容删掉，把所有问题都归到“大家以后多注意”的泛泛之谈上。
我那个喝冰美式的朋友，后来没在正式的复盘汇报里提那些难啃的问题。他自己拉了个在线表格，把这次故障里每个卡壳的节点都列出来：哪个监控告警延迟了，哪个操作链接失效了，哪个跨团队的对接通道断了。每周站会的时候，他就拉着对应负责的同学，把表里的小问题挨个清掉。上个月他跟我说，这一个月里，团队处理同类小故障的平均响应时间，比之前快了六成。
系统这东西，本来就没有百分百不出错的完美架构。你做故障复盘的目的，从来不是证明这次出错的人有多粗心，而是让下次再遇到事的时候，大家别像这次一样手忙脚乱，别让同样的坑，绊同一个人两次。