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

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% 结账 5xx1h 燃烧速率飙至 300× 发现MTTI ≈ 2minAlertmanager → On-Call 台自动寻呼 应对未查根因先 fault.sh recover 恢复符合恢复优先 根因真实场景需补缺少自动熔断/降级单点劣化直接传导 行动项① 加熔断张工/07-21/压测验证② On-Call 升级链路补二线李工/07-18五、复盘最容易踩的三个坑坑 1变成批斗会→ 当事人 defensive根因永远挖不到。坚持免追责。坑 2行动项无 owner/无期限→ 三个月后还在待办。每条必须可验证。坑 3只复盘大故障→ 小故障的预算燃烧信号恰恰是最便宜的学习机会要常态化复盘。六、小结与思考题复盘 把昂贵加班变成便宜培训闭环才是终点。黄金三问发生了什么 / 为什么 / 学到什么落到行动项。判定三原则免追责、可验证、能闭环。思考题翻一下你们过去半年的故障记录——有多少次故障修好后那句后续优化再也没有下文了如果比例很高先别急着学新工具先把行动项闭环追踪这一个点做起来。下一篇也是实践篇收尾我们聊最容易被技术派忽略、却决定 SRE 能否落地的部分组织架构与跨团队协作。