事后复盘：不追人，追那条让人踩空的路

一句话

SRE 第 15 章要立的规矩只有一条：事故的学费已经付过了，复盘（postmortem）是唯一能把它换成资产的动作。而这个动作成不成，取决于一个反直觉的设计——把「谁做错了」这个问题从流程里彻底删掉。删它不是出于对人温柔，是因为你最需要的那部分信息只存在当事人脑子里：他当时看到了什么、为什么那个选择在当时看起来是对的。你一开始追人，这部分信息就永远拿不到了。本章的原话是：「你没法『修好』人，但你可以修系统和流程，让人在设计和维护复杂系统时更容易做出正确的选择。」还有一句更硬的判据：一份没被评审过的复盘，跟从没存在过一样。

Glossary · 术语表

坐标

作者 John Lunney 与 Sue Lueder。本章在 SRE 书 Part III「实践」里紧接着事故处置那一串：上承第 12 章「有效排障」（怎么把毛病找出来）、第 13 章「紧急响应」与第 14 章「事故管理」（事故当中怎么组织人），而本章管的是事故结束之后的那 48 小时。它同时是第 3 章「拥抱风险」的还款通道——错误预算被烧掉的那一截，只有靠复盘产出的行动项才换得回来。落到现实里，各家的名字不同（incident review、post-incident review / PIR、correction of errors / COE），做的是同一件事；它也对应一道几乎必问的面试题：「讲一次你参与过的线上事故，后来你们改了什么。」

这章要解决什么

本章的题词就是整章的经济学：「失败的代价是教育。」（The cost of failure is education. —— Devin Carraway）翻译成工程语言：事故已经把钱花掉了——用户疼过了、错误预算烧掉了、几个人的周末没了。这笔支出唯一可能的回报，是你从中学到点什么并落地。不写复盘，等于交了学费不去上课。

把账算给 SLO 看最直白：一条 99.9% 的月度可用性目标，整月只允许约 43 分钟不可用（第 3、4 章的口径）。一次 30 分钟的事故就吃掉七成；同一类事故一个季度回来三次，全年余额基本就没了。所以「防止它再来」不是道德要求，是预算算术。

本章要治的病有三个。一是教训不落地：修好了、群里说声「好了」，教训留在两三个人脑子里，其中一个半年后换了组，同类事故原样重演。二是指责导致的瞒报——这是本章最坚决的主张：把指责从复盘里拿掉，能让人有底气毫无顾虑地把问题捅上去；反过来，弥漫着指责的空气会造就一种把事故扫到地毯底下的文化，而这让组织承担的风险更大。三是没有判据：没人事先规定什么情况必须写，实际结果就是「大到瞒不住才写」，于是事故库里只剩 P0，看着风平浪静。

核心内容，讲透

一、复盘是什么：一份带产出义务的文档

本章给的定义是五件东西的合集：一次事故的书面记录，包含它的影响、为缓解或解决它所采取的动作、根因，以及为防止它再次发生的后续行动。五样里前四样都是「回顾」，只有最后一样是「未来」——而全章的重量正压在最后一样上。

三个主要目标的排序也很讲究：① 确保事故被记录下来；② 确保所有促成它的根因都被弄明白；③ 尤其是，确保有效的预防措施被真正落实，以降低它再次发生的概率与影响。那个「尤其是」不是修辞——它意味着一份写得漂亮、时间线精确、却没产出任何行动项的复盘，在本章的判据下是失败的。所以判断一个团队的复盘文化是真是假，最快的办法不是读文档，是去看那些行动项有没有被关掉：每条都该有负责人、有合理优先级、直接落成缺陷跟踪系统里的一张单子，否则「以后我们会注意」会大量出现，而它不改变任何东西。

还有一个容易被忽略的判据：复盘的读者不是你的主管，是六个月后那个不认识你的值班工程师。他会在凌晨三点搜到这份文档，因为他遇到了很像的症状。为他写，时间线和术语解释就自然会写对。

二、什么时候必须写：判据要事先写死

本章明确要求：复盘的触发判据要在事故发生之前就商定好、公之于众。它给的常见判据清单是——

清单里最容易被跳过的是最后一条：监控没报出来、靠人工发现。它意味着这次事故是用户先告诉你的——即便影响很小、几分钟就好了，你的监控有个洞本身就值得一份复盘（呼应第 6 章）。同理，「值班工程师人工介入过」的隐含意思是：需要人半夜爬起来敲命令，本身就是一个待修的缺陷。

本章还配了一句用来对冲判据压力的话：写复盘不是惩罚，而是全公司的一次学习机会。如果团队把「要写复盘了」听成「要挨罚了」，判据越严格、瞒报越严重——这两件事必须一起立。

三、无指责到底是什么，以及不是什么

本章对「无指责」的定义是一句可操作的假设：一份无指责地写成的复盘，假定所有卷入事故的人都是本着好意、并且用他们当时掌握的信息做了正确的事。请注意这句话里的时态——「他们当时掌握的信息」。这是整个机制的支点：读复盘的人已经知道结局，天然带着事后偏见，会觉得线索「明明很明显」；而当事人在那一刻并不知道。

于是提问方式必须换。不问「你为什么按了那个钮」，问「为什么按那个钮在当时看起来是对的」；不问「谁改的配置」，问「什么条件让这次改动看起来是安全的」。本章把这类调查描述为：从分配责任，转向调查是什么系统性的原因让某个人或某个团队掌握了不完整或不正确的信息——只有转过来，有效的预防方案才做得出来。

这套东西不是软件业发明的。本章明说它源自医疗与航空业：在那些行业里失误会死人，所以它们培育出一种氛围，把每一次「失误」都当成加固系统的机会。落到最有名的一句结论就是：「你没法『修好』人，但你可以修系统和流程，让人在设计和维护复杂系统时更容易做出正确的选择。」本章还给了正反措辞的对照：同一个技术判断（这个后端烂到每周出问题、该重写），可以写成情绪化的抱怨兼暗指某人无能，也可以写成面向未来的主张（重写确实能止住这些告警，而且维护手册长到没人学得完，未来值班的人会感谢我们）——只有第二种写法能被别人接着往下推。

四、瞒报：指责的代价是可以量化的

上一节是价值观，这一节是机制。本章讲得非常直接：把指责从复盘里拿掉，能让人有底气毫无顾虑地把问题往上捅；反过来，一种弥漫着指责的空气，冒的风险是造就一种把事故和问题扫到地毯底下的文化，而这会让组织承担更大的风险。

为什么这条比听上去更严重？因为它污染的不是士气，是数据。可靠性工程的所有决策都建立在「我们知道自己出过什么事」之上：错误预算怎么花、下季度修哪块、告警加在哪。一旦小事故不再被上报，你的事故库就只剩下瞒不住的那些——这是一份幸存者偏差的样本。你会得出「系统很稳」的结论，而真实情况只是没人说。这也是为什么「无指责」必须写成制度而不是态度：态度会随着人换、随着考评变，制度不会。

五、复盘不是一个人的作业：协作与评审

本章强调复盘从头到尾是协作产物，并点名几个关键能力：实时协作（多人同时编辑，事故刚结束、信息还热着就一起补）、开放的评论与批注（任何人都能就某一行提问）、邮件通知（相关方不用主动来捞）。听着像工具功能，但它们决定了一份复盘能不能在信息蒸发之前被写完。

写完之后是评审，由没有直接卷入这次事故的资深工程师把关，逐条检查：关键的事故数据有没有为了以后被完整记录下来？影响评估做全了吗？根因挖得够深吗？行动计划是否恰当、由此产生的缺陷单优先级是否合理？结果有没有分享给相关方？

并且立了一条措辞毫不客气的最佳实践：没有一份复盘可以不被评审——一份没被评审过的复盘，跟从没存在过一样。理由很实在：写作是私人的，评审才是把这份知识并入组织的那一步。

六、让它变成文化：四种具体做法 + 度量

本章清楚地知道，光有流程没用——它花了一整节讲怎么把复盘从制度变成习惯，给的都是具体到可以照抄的做法：

• 月度精选复盘：把当月写得最好的一份放进内部通讯，让全公司读到。
• 公司内部的复盘小组：一个持续讨论内部与外部复盘、最佳实践的地方。
• 复盘读书会：定期把一份有意思或影响大的复盘搬上桌（配上点心），当事人、旁观者和新同事一起聊：当时发生了什么、教了我们什么、后来怎么样了。本章特意点出：被拿来读的那份，常常是几个月甚至几年前的——这正是它的价值，老复盘是组织记忆的载体。
• Wheel of Misfortune（灾难轮盘）：拿一份旧复盘按角色重演，新 SRE 扮演当时的人。它把「读过」升级成「练过」。

还有一条最佳实践值得单独拎出来：当着大家的面奖励那些做对了事的人——尤其是主动承认自己失误的人。这是无指责文化最便宜也最有效的燃料。此外本章主张这件事应该被度量而非凭感觉：既看写了多少份、行动项关闭得怎么样，也直接收集工程师的反馈，看他们是否真的觉得这里的复盘是无指责的——因为这套东西唯一会失效的方式，就是大家嘴上认同、心里不信。

七、收尾：把写复盘的摩擦降下来

本章结尾谈持续改进，方向是工具化：统一模板、把事故数据（时间线、监控图、告警记录）尽可能自动填进去。逻辑很朴素——摩擦越大，写的人越少；一份要从零手工拼三小时的文档，注定只有大事故才会有人写。Google 也把模板和一份完整的示例复盘（附录 D，一次服务过载事故）公开了出来，可以直接拿去改。

关键权衡与选型

表 1 · 追人 vs 追条件：同一次事故，两种问法各买到什么

表 2 · 什么时候必须写：判据、阈值示例、跳过的代价（阈值是示例，本章只说「某个阈值」，具体数字由你的 SLO 决定）

表 3 · 复盘的四种失败模式：怎么认出来、怎么治

表 4 · 行动项分三类：一份复盘里最好三类都有

选型建议一句话：如果时间只够做一类，先做第三类。「防再发」经常要等一个季度的排期，而「补一条告警、把回滚做成一条命令」通常当周就能落地，并且对下一次完全不同的事故也管用。

为什么重要 / 落到真实系统

这一章在日常里的落点非常密集：值班交接时先看有没有未关闭的行动项；事故评审会的第一句话该是「我们不找人，我们找条件」；面试里被问到「讲一次你搞砸的事故」，标准答卷不是自责，而是——影响多大、当时为什么那个判断是合理的、后来改了什么、那条改动有没有被验证过。工程之外还有一个很实际的用途：对外的公开复盘已经是大厂事故公关的默认形态，写得好坏直接影响客户信任。

易错点与争议

• 无指责 ≠ 无问责。最常见也最伤人的误读。本章拿掉的是指责（「这是谁的锅」，指向惩罚），不是问责（「谁负责让它别再发生」，指向所有权）。行动项必须有名字——只不过那个名字出现在「负责修」的栏里，不是「负责背」的栏里。团队一旦把无指责理解成「出了事没人负责」，管理层就会在下一次大事故时把整套东西掀翻。
• 「无指责」做成表演，比不做更糟。行业内对这个词本身有持续的争论：有人主张改叫「blame-aware（觉察指责）」——因为指责是人的本能反应，宣称「我们这里没有指责」往往只是把它压到台面下，年底考评时照样记着这一笔。判据很简单：看最近一次事故之后，当事人的处境有没有变差。只要人能闻出味道，制度写得再好也拿不到那部分信息。
• 「根因」是单数吗？本章成书于 2016 年，用的还是较朴素的根因框架（注意它的原文其实用了复数 root cause(s)）。此后韧性工程一派的主张更进一步：复杂系统的事故是多个条件的合流，执着于找出「那个根」容易过早收束调查，也很自然地把注意力引向人。相关地，John Allspaw 在《The Infinite Hows》（2014）里给了一个实用的替换：连问「为什么」太容易滑向「是谁」；改问「怎么会」（在什么条件下这件事成为可能），拿到的是可操作的运行细节。Kitchen Soap · The Infinite Hows ↗
• 行动项黑洞。最普遍的失败不是写得不好，是写完没人做——改进单常年排在业务需求后面，一个季度后自动过期。对策不在复盘流程里，在第 3 章：错误预算烧超了就该冻结功能发布、把工程时间挪去还债，这才是让行动项排得进去的那个杠杆。
• 事后偏见会渗进文字。写复盘的人已经知道答案，很难不写出「本应该注意到」这类句子。一个可执行的自查：给时间线里每个动作补一句「他当时能看到什么」，凡是你写不出来的，说明你在用上帝视角。
• 复盘不是免费的。一份认真的复盘要花几小时到几人天。所以判据必须是阈值而不是「都写」——否则复盘本身就变成第 5 章定义的琐务，最后大家一起敷衍。
• 时代局限。2016 年的重点是「产出一份好文档」；此后事故分析一派（Allspaw 等人的 Learning from Incidents 社群）更强调价值在过程——访谈、多视角还原、集体讨论，文档只是副产品。这不否定本章，但提醒你：如果你的复盘只有一个人闷头写完再发出来，你拿到的可能只是文档，不是学习。

要点