凌晨两点半被电话叫醒。P0故障。数据库连接池满了，业务全线飘红。折腾三小时恢复之后，团队里没人说话，群里只有一串“收到”。
第二天下午的复盘会，气氛诡异。主持人念了一遍时间线，责任方低着头说“我的锅”，然后大家沉默。有人建议加个监控，有人建议改改代码，会议纪要写得工工整整，像一份悼词。
散会。这件事就算过去了。
但你我都清楚——这种复盘，基本上等于没做。
时间线整齐得不对劲
我见过很多复盘文档。最典型的那种，时间线精确到秒，每一步都有理有据：14:32:15 收到告警，14:33:02 值班同学响应，14:35:48 定位到问题……看着像教科书。
问题在于，真实故障现场从来不是这样的。真实情况是，14:32 告警来了，值班同学在另一个群讨论午饭吃啥，15:47 才有人发现好像有点不对劲。中间那一小时没人看监控，不是因为懒——是因为那天恰好有三个告警同时响了，谁也分不清哪个该先看。
这才是要复盘的东西。
但很多团队不喜欢写这些。写“没人及时看监控”显得团队不专业，写“告警太多分不清主次”显得平台建设不到位。于是七拐八绕，最后时间线被裁成了好看的样子。剩下那个真正要命的问题——告警分级策略失效——被悄悄藏起来了。
说实话，一份没有“丑陋细节”的故障复盘，基本上没有价值。它只能帮你交差，不能帮你进步。
找根因还是找替罪羊
复盘会开成批斗会，这事情太常见了。尤其是那种跨团队、跨部门的故障，会上暗流涌动。A团队说B团队接口超时没处理好，B团队说A团队调用频率翻了三倍也不通知。吵到最后，结论是“双方都有责任，后续加强沟通”。
加强沟通。这四个字是故障复盘里最大的谎言。
什么叫加强沟通？谁跟谁沟通？多久一次？用什么方式？没标准，没动作，没验收。下次故障该来的还是来。
我采访过一个做支付系统的老运维，他说他们团队复盘有一条铁律：所有问题追溯到系统设计层面，不允许停留在“人没注意”这一层。人一定会犯错。这是常量。你要做的是让系统在人的疏忽下依然能兜住底。
比如那次数据库连接池泄漏。表层原因是开发同学忘了在某个分支里关连接。但往下挖一层：这个连接池配置本身有没有熔断机制？连接泄漏之后为什么没有自动告警？为什么等到业务全挂了才发现？
每一个“为什么”都指向一个可以落地的改进项。而这些改进项，比“开发同学下次注意”有用一万倍。
行动项不是许愿池
复盘的结尾通常是这么写的：后续计划——1. 增加监控告警；2. 优化代码逻辑；3. 加强值班巡检；4. 完善应急预案。
看着挺齐全。但麻烦在于，这些行动项没有一条能被验证。三个月后再问：监控加了吗？加了哪些指标？阈值多少？告警到谁那里？响应时间要求多久？——大概率没人说得清。
有个技术主管跟我吐槽过，他们年初复盘的一个故障，提出了“完善降级方案”这个行动项。半年后同一个模块又崩了，降级开关还是没做。他去查当时的复盘文档，发现行动项后面没有负责人，没有截止日期，没有验证方式。三无产品。
他说这事的时候语气很平，但你能感觉到那种无奈。复盘做了一堆，文档存了一堆，真正落地的东西——零。
我现在看一份复盘质量高低，不看时间线写得多细，也不看根因分析多深刻，就看一件事：每个行动项有没有对应的负责人和完成时间。如果一份复盘文档里连这个都没有，那后面写的所有内容都是表演。
对了，还有一个更隐蔽的问题。很多团队做复盘，行动项列了十几条，最后全部排进迭代。然后开发说没时间做，产品说需求优先，行动项就被无限期搁置了。下一次故障来了，再复盘，再加行动项。如此循环，直到所有人都麻木。
所以行动项不能太多。一次复盘聚焦两三个真正致命的改进，比列二十条没人做的许愿强得多。
复盘的沉默成本
还有个事，很少有人提。故障复盘是有沉默成本的。每一次复盘都在消耗团队的信任额度。
你让开发放下手里的活来开会，让他承认自己代码写得有问题，让他听别的团队指指点点。然后呢？如果复盘会开完，没有任何实质改变，下次他还愿意说真话吗？
不会的。他会学会闭嘴。他会学会在故障发生之后先想好怎么措辞，怎么把锅甩出去，怎么在复盘会上全身而退。当所有人都开始自我保护，复盘就死了。
所以故障复盘这事，技术能力只是一部分。更重要的是——这个团队有没有心理安全感。人敢不敢说“我不知道为什么会这样”，敢不敢说“我当时其实是猜的”。
这些东西写不进流程文档，但每个经历过几次故障的人心里都清楚。
回到开头那个凌晨的故障。后来我看了他们的复盘记录，最后一句话是“本次故障已恢复，后续会加强相关监控”。然后就没有然后了。
有些复盘是写给系统看的，有些是写给领导看的。真正写给团队自己看的——太少。