你的系统昨晚又挂了。凌晨三点，工程师被叫醒，手忙脚乱重启服务，监控面板终于变绿。大家松了口气，互道晚安，准备把这件事抛在脑后。
等等。这次崩溃的唯一价值，就是让你发现它——然后你就让它溜走了。
大多数团队处理故障的"急性期"还算过得去：症状被压制，服务恢复，值班表继续轮转。但真正的损失发生在事后。当疲惫的工程师关掉电脑，当产品经理催促着看新功能进度，当Slack频道里的告警记录被新消息淹没——学习的机会就这样消失了。
这不是道德问题，是机械问题。没有结构化的复盘，同样的故障会在六周后、三个月后、明年春天，以熟悉的面目再次出现。而你付出的，是又一个凌晨三点。
要解决这个问题，需要先厘清两个被混用的概念。
【Post-mortem vs RCA：不是一回事】
Post-mortem（事后复盘）是一份文档，也是一场对话。它记录时间线、响应过程、影响范围、哪些措施有效、哪些无效，以及团队承诺做出的改变。本质上，这是一件学习工具。
Root Cause Analysis（根因分析）则是复盘内部使用的一种技术——通常是"五个为什么"或其变体——用来穿透表面症状，找到让故障得以发生的底层条件。RCA是你填写复盘文档中最重要章节时使用的工具之一。
你可以只做RCA不写复盘（很多团队确实这么干，在Slack线程里草草了事，记录随即消失）。你也可以写复盘却不做真正的RCA（很多团队也这么干，最后产出"数据库挂了"这种毫无穿透力的结论，从不追问为什么）。只有两者结合，才能真正产生学习。
【"无责"不是道德姿态，是信息机制】
复盘最重要的属性是"无责"（blameless）。不是"除了这个明显案例之外无责"，不是"无责但我们会记下谁值班"，是完全无责。
原因在于机制，而非道德。一旦人们相信复盘可能被用来追责，信息就会干涸。工程师不再主动说明发布变更时的真实想法，运维不再承认没看懂手册。文档变成精心编织的虚构作品，优化目标是保护作者，真正的根因无人问津。
你无法修复看不清的系统。追责保证你看不清。
有效的框架来自Etsy的John Allspaw十多年前的表述：假设所有当事人在当时拥有的信息条件下，行为都是合理的。如果他们的行为导致了故障，真正有趣的问题是——什么让这种行为看起来合理？这个问题的答案几乎总是指向系统的某个方面：缺失的信号、模糊的职责边界、混乱的工具链、不足的测试覆盖——而这些才是你能真正修复的东西。
【可执行，否则等于没做】
以"团队下次会更小心"收尾的复盘，不是复盘，是被文字记录下来的情绪。
有用的复盘产出是一份具体、有负责人、可跟踪的行动清单。"当队列深度超过10000时增加告警，由平台团队负责，目标本冲刺完成"——这是行动项。"改进我们的监控"——这不是。
更好的清单会进一步区分：哪些是立即修复的止血措施，哪些是消除一类故障的预防性工作，哪些是需要长期投入的系统重构。没有这种区分，紧急事务永远会淹没重要事务。
【让复盘成为习惯，而非例外】
把复盘变成可选流程，就等于把它变成从不执行的流程。有效的团队将复盘纳入标准工作流：重大故障必须在48小时内启动复盘，文档在72小时内完成并评审，行动项进入与普通需求同等的跟踪系统。
更关键的可能是文化层面：团队领导是否会在复盘会议上首先分享自己引入的bug？是否会把"我们发现了系统盲区"作为值得庆祝的发现，而非需要遮掩的失误？
故障本身不会让你的系统更可靠。对故障的回应才会。当凌晨三点的告警再次响起，你希望团队只是疲惫地修复症状，还是在修复的同时，已经开始构思如何让下一次崩溃根本不可能发生？
选择权在你。但记住：系统不会自己变聪明，除非你从每次故障中偷走它的秘密。
热门跟贴