SRE 实战手册（七）｜故障复盘：黄金三问与判定三原则

对应课程「08｜故障复盘：黄金三问与判定三原则」。复盘是 SRE 闭环里性价比最高、却最常被敷衍的一步。

一、为什么复盘比"修好"重要十倍

第 06、07 讲我们处理了故障、恢复了业务。但 SRE 的终极目标不是"这次救回来"，而是**“同类故障下次不再发生，或发生了损失更小”**。

课程里一句话很扎心：

没有复盘，故障只是一次昂贵的加班；有复盘，故障才是一次便宜的培训。

我们实验台每次 On-Call 告警都会落盘到/opt/sre-lab/incidents.log——它就是复盘的"原材料"。

二、黄金三问：复盘会围绕什么展开

每次复盘，不管大小，都要回答这三个问题（课程核心框架）：

问 1：发生了什么？（What happened）

• 时间线（Timeline）：从最早异常信号到完全恢复，关键节点对齐到同一时间轴。
• 影响面（Impact）：受影响用户量、资损、时长和 SLO 消耗（烧了多少错误预算）。
• 表征：监控上看到了什么（我们的CheckoutBudgetBurnFast何时触发）。

问 2：为什么会发生？（Why did it happen）

• 直接原因（触发）：比如"注入了 30% 结账失败"。
• 根本原因（根因）：为什么注入能造成大面积影响？是没有熔断？没有降级？容量评估缺失？还是告警到人的链路断了？
• 用"5 Whys"或因果图往下挖，但别陷进"谁写的 bug"这种人身归因。

问 3：我们学到了什么？下一步做什么？（What did we learn / What’s next）

• 行动项（Action Items）必须有 owner、有截止日、可验证。
• 行动项分两类：止血类（短期防再发）和根因类（长期消除）。
• 复盘会散会 ≠ 结束；行动项关闭才算结束。

三、判定三原则：什么样的复盘是"合格"的

课程给了一套判定标准，用来审视自己的复盘有没有走过场：

原则 1：对事不对人（Blameless）

复盘不追究"谁犯错"，只追究"系统为什么允许这个错造成大影响"。只有免予追责，当事人才会说真话。我们 Demo 的故障是"人为注入"，但复盘依然聚焦机制缺口，而非"是谁执行的注入脚本"。

原则 2：有可验证的改进项

“加强监控”"提高意识"这种无法验证的废话，不算行动项。合格项长这样：

[行动项] 结账链路增加熔断：当 1h 错误率 > 5% 时自动拒绝新请求并降级到排队 [Owner] 张工 [截止] 2026-07-21 [验证] 压测注入 30% 失败，验证熔断生效且预算燃烧速率下降

原则 3：闭环可被追踪

行动项要进跟踪系统（Jira/禅道/TAPD 都行），下次复盘第一件事是回顾上次的行动项关了没。不闭环的复盘，不如不开。

四、一份能直接抄的复盘模板

仓库里附了可直接套用的模板docs/incident-postmortem-template.md，结构如下（节选）：

# 故障复盘：<标题> ## 0. 元数据：等级 / 起止时间 / 指挥官 / 记录人 ## 1. 发生了什么（时间线 + 影响面 + SLO/预算消耗） ## 2. 为什么发生（直接原因 + 根本原因，附证据） ## 3. 我们如何应对的（发现时长 MTII / 恢复动作 / 是否恢复优先） ## 4. 学到了什么（黄金三问之三） ## 5. 行动项（owner + 截止 + 验证方式，分止血/根因） ## 6. 复盘质量自检（是否免追责 / 是否可验证 / 是否闭环）

对应我们实验台那次演练，一份迷你复盘会长这样：

标题：结账接口错误预算快速燃烧（演练） 影响：模拟 30% 结账 5xx，1h 燃烧速率飙至 300×+ 发现：MTTI ≈ 2min（Alertmanager → On-Call 台自动寻呼） 应对：未查根因，先 fault.sh recover 恢复（符合"恢复优先"） 根因（真实场景需补）：缺少自动熔断/降级，单点劣化直接传导 行动项：① 加熔断（张工/07-21/压测验证）② On-Call 升级链路补二线（李工/07-18）

五、复盘最容易踩的三个坑

• 坑 1：变成批斗会→ 当事人 defensive，根因永远挖不到。坚持免追责。
• 坑 2：行动项无 owner/无期限→ 三个月后还在"待办"。每条必须可验证。
• 坑 3：只复盘大故障→ 小故障的预算燃烧信号恰恰是最便宜的学习机会，要常态化复盘。

六、小结与思考题

• 复盘 = 把"昂贵加班"变成"便宜培训"，闭环才是终点。
• 黄金三问：发生了什么 / 为什么 / 学到什么（落到行动项）。
• 判定三原则：免追责、可验证、能闭环。

思考题：翻一下你们过去半年的故障记录——有多少次，故障修好后，那句"后续优化"再也没有下文了？如果比例很高，先别急着学新工具，先把"行动项闭环追踪"这一个点做起来。

下一篇（也是实践篇收尾），我们聊最容易被"技术派"忽略、却决定 SRE 能否落地的部分：组织架构与跨团队协作。