上周跟一个做基础架构的朋友撸串。他刚熬了三个通宵写完的故障复盘文档，被老大打回来三次，理由是太像检讨书，没说到点子上。
我太懂这种感觉了。很多团队对故障复盘的理解，从根上就歪了。
别把复盘写成追责清单
出事之后第一时间找责任人，好像成了很多团队的条件反射。代码谁写的，上线谁审的，告警为什么没人盯，值班的人当时在干嘛。顺着这些问题问一圈，总能找到个可以挨骂的人，然后文档里一写，“某某同学操作不规范，已做通报批评”，好像这事儿就算完了。
真正的故障复盘，从来不是为了给某个人扣帽子。你顺着链路从用户端的点击，到CDN的节点缓存，到网关的限流规则，到服务层的逻辑处理，到数据库的慢查询，把每一个节点当时的运行数据都拉出来对一遍，才能找到真正的根因，而不是逮着第一个看起来有问题的点就下结论。之前接触过一个做支付的团队，某次大促期间接口超时率飙到30%，一开始查了半天说是开发改了缓存过期时间没写注释，差点给人记过。结果顺着链路往下扒才发现，是网关层的限流阈值上个月被运维临时调过，没同步到配置中心的变更记录里，开发改缓存的时候根本不知道前面的限流已经卡到了七成流量。
你说这锅是谁的？说不清楚的。大家都是按照当时知道的信息做的操作，谁也没恶意。但如果复盘只停留在骂开发不写注释，下次一样会有人改了配置忘了同步，一样会出现链路上下游信息不对等的问题。
很多人写复盘的时候，总喜欢堆一堆“加强意识”“完善流程”的空话。说白了，写了等于没写。下次遇到同样的坑，该踩还是踩。我见过最离谱的复盘文档，最后改进措施写了十条，有八条是“提高团队对故障的重视程度”，剩下两条是“组织大家学习故障案例”。
有用吗？一点用没有。能落地的改进措施，必须精确到谁、在什么时间、改什么具体的东西。比如“下个迭代把网关限流阈值的变更同步流程，绑定到配置中心的提交校验节点，没有关联变更单的配置修改一律不允许生效”，这种才叫有用。改完之后，不管是谁动了配置，系统都会自动卡一道，从根源上避免信息不同步的问题，而不是靠大家“提高意识”去记。
别漏掉那些“本来可以”的瞬间
很多复盘写到最后，只会列三个数：故障从发生到恢复用了多久，影响了多少用户，造成了多少直接损失。写完这些就觉得够了，从来不去抠那些在故障发生过程中，本来可以更早止损的节点。
之前有个做短视频的团队，某次推荐服务集群挂了，从第一个告警触发，到值班同学真正介入处理，隔了整整18分钟。为什么隔这么久？因为告警发出来的时候，值班的同学刚好在接开水，手机放在工位上没看。等他回到工位点进告警详情，已经有几万用户在社交平台反馈刷不到内容了。
你说这个细节，算不算复盘里必须写的？当然算。因为你不能要求所有人24小时把眼睛钉在监控屏幕上，那接下来要做的就不是骂值班的人为什么不看手机，是把核心告警的通知渠道，从普通的企业微信消息，升级成带电话外呼的强提醒——只要核心服务的告警触发，30秒内直接打值班人的电话，打不通就打备班的。这才是真的从事故里捞出来的经验。
我见过太多团队，复盘的时候对这些“本来可以”的瞬间视而不见。总觉得故障已经发生了，花时间抠这些细节没用，赶紧写完文档交差就行。但恰恰是这些细节，决定了下次遇到同样的问题，你是用2分钟恢复，还是用20分钟恢复。
复盘的价值从来不是给老板看的
现在很多团队的复盘，本质上是做给上级看的。要写得足够深刻，足够有反思精神，让老板觉得大家都从这次事故里学到了东西，态度端正。但真的到了下次上线、下次做变更的时候，该不看变更记录还是不看，该压测不充分还是压测不充分。
说白了，这种复盘，除了消耗大家的加班时间，一点价值都没有。我之前待过的一个小团队，有个坚持了好几年的习惯：每次复盘完，都会把所有的改进项拆成小的可落地任务，贴在团队工位旁边的白板上，每完成一个就划掉一个。每次新同学入职，第一件事就是翻过去两年的复盘文档，看看之前都踩过什么坑，哪些地方是容易出问题的，遇到同类告警的时候第一步该查什么。
这种时候，那些熬夜写出来的复盘内容，才真的变成了团队的资产，而不是存在文档库里没人看的废纸。
说实话，谁都不想出故障。故障发生的时候，一线的同学比谁都急，比谁都想快点把服务恢复。你要是一上来就搞追责，下次大家遇到事，第一反应就不是赶紧止损，是想怎么把锅甩出去，怎么把自己的责任撇干净。那才是真的麻烦。
有人会说，故障复盘搞得太重，大家都怕出事，以后不敢做变更了怎么办？
这事没那么玄。真正好的复盘，从来不是为了限制大家做变更，是让大家做变更的时候心里有底，知道哪些地方容易出问题，出了问题之后多久能恢复，应急的流程是什么。你把这些东西都摸透了，做变更的时候反而更踏实，不会天天提心吊胆怕出问题。
毕竟，做技术的哪有不踩坑的。踩了坑不记下来，下次还得踩。花点时间把坑的位置标清楚，后来的人走的时候能少摔两跤，这才是故障复盘最实在的意义。