生产事故复盘：从故障树到改进项落地

事故复盘的目的是改进系统，而不是追责。它的产出也不是一份解释谁做错了的报告，而是让同类故障更难发生、发生后更快发现、更容易控制。追责导向会促使参与者隐去不确定操作和薄弱环节，系统失去真实证据。无责文化也不等于不承担改进责任：事实、决策与流程仍需被审视，只是不把个体失误当作分析终点。

先保存证据，再补叙事

事故处理中应同步记录时间线，但不能只依赖群聊中的“刚才”“大概五分钟前”。每个事件使用统一时区与带日期的时间戳，优先取监控采样时间、日志事件时间、部署记录和审计事件；人工回忆作为补充，并标明不确定性。

时间线至少覆盖异常开始、检测、通知、响应、关键诊断、缓解、恢复和确认结束。监控图要保存查询条件与时间范围，不能只截一张没有坐标和图例的图片。不同机器时钟可能偏移，分析前应核对时钟同步与日志时区，必要时记录误差范围。

“14:04 回滚后恢复”只是一段相关性描述。若恢复发生在缓存过期、流量切换或依赖自愈之后，需要用更细证据确认因果。把当时的假设与事后结论分开，能看出响应者在有限信息下为何做出选择，也能发现信息面板缺失。

触发点不等于根因

触发点是让故障在某个时刻显现的事件，例如一次发布、一台节点退出或某个请求激活边界条件。根因更接近系统性缺陷：变更可以绕过验证、单点容量没有保护、降级路径未经演练、监控无法发现积压。只写“某人配置错误”，既不能解释错误为何能进入生产，也不能阻止下一种错误。

可以用反事实问题检验层次：如果没有这次发布，缺陷是否还可能被其他事件触发？如果另一位工程师执行相同步骤，系统是否会阻止？如果触发不可避免，保护机制为何没把影响限制在小范围？答案通常会指向验证、隔离、容量、权限和恢复设计。

根因未必只有一个。事故往往由潜在缺陷、触发事件、扩大条件和防线失效共同形成。复盘可以明确“已确认”“高度可能”“证据不足”，不必为了文档完整而强行选择唯一原因。

从现象向下画故障树

故障树以顶层现象开始，逐层拆解造成它的必要条件或可能路径。OR 门表示任一路径成立即可导致上层事件，AND 门表示多个条件同时成立才会发生：

顶层：订单 API 大量超时
  AND
  ├─ 可用处理容量低于到达流量
  │    OR
  │    ├─ 工作线程被慢查询占满
  │    └─ 半数实例未进入负载均衡
  └─ 保护机制未限制影响
       AND
       ├─ 超时设置长于上游等待窗口
       ├─ 熔断规则未覆盖该依赖
       └─ 告警只监控进程存活

每个叶子节点应能用数据验证或证伪。若节点写成“系统不稳定”“代码有问题”，还需要继续下钻。树中也应标出现有防线及其失效原因，例如 readiness 误判、限流阈值高于真实容量、备用链路权限过期。

故障树适合表达并发条件与多条路径，比线性的“五个为什么”更不容易把复杂事故压成单因果链。对每个关键叶子再追问设计原因、变更原因与未检测原因，可以形成更具体的改进方向。

把影响量化但不夸大

影响描述应给出可复核口径：受影响功能、时间窗口、错误请求或延迟分布、涉及区域与数据一致性状态。若只能估算，要注明数据源、计算方式和误差，不把峰值错误率当作整个事故期间的平均影响。

恢复时间也要区分服务恢复与积压清理。在线请求恢复正常后，队列中的任务可能仍需处理，用户侧状态也可能延迟。事故结束条件应事先定义，例如核心 SLI 连续稳定、积压回到安全水位、数据核对完成且临时措施有监控。

改进项必须可验收

“加强监控”“提高稳定性”“多做测试”无法判断是否完成。可验收项需要包含对象、动作、验收证据、负责人和期限：

动作：为 payment_queue_oldest_age_seconds 增加 P1 告警
条件：连续 10 分钟大于业务等待上限的 50%
验收：在预发布注入消费暂停，通知于规则窗口内到达值班系统，
      手册能定位消费者与积压分片
负责人：队列服务责任组
期限：2026-11-05

改进项可分为防止发生、缩小影响、加快发现、加快恢复四类。只增加告警会让系统更快报告相同故障，却没有降低发生概率；只修补触发代码也没有处理发布防线。应优先选择能切断故障树关键路径的措施，并说明它覆盖哪个节点。

每项动作还要评估潜在副作用。例如把所有依赖都加入 readiness 可能导致端点同时消失；自动回滚若依据单一噪声指标，可能在无故障时反复切换。验收应包含正常路径和失败路径，而不只是“配置已合并”。

跟踪、逾期与关闭证据

复盘会议结束后，改进项进入统一跟踪系统，不能只留在文档表格。每项具有唯一编号、优先级、负责人、期限、状态与关闭证据。定期评审未完成项，阻塞时记录原因和新计划；高风险项逾期应升级给服务责任人，并评估在完成前是否暂停相关变更、增加临时门禁或降低流量风险。

关闭动作不等于代码合并。告警项需要触发演练记录，容量项需要压测或计算证据，回滚项需要演练结果，流程项需要展示门禁确实阻止过一次不合规输入。若动作被取消，文档应记录风险接受者与依据，而不是从列表中消失。

复盘质量也可以回看：同类事故是否重复、检测时间是否缩短、临时操作是否被固化、行动项按期关闭率如何。指标用于发现机制问题，不应用来鼓励拆小任务或隐藏事故。

一份可复用的文档结构

# 事故标题与级别
## 摘要：发生了什么、当前状态
## 影响：功能、范围、时间、数据口径
## 检测与响应：如何发现、如何组织处置
## 时间线：统一时区、事实、证据链接
## 技术分析：触发点、扩大条件、根因、防线失效
## 故障树：AND/OR 路径与证据
## 做得有效与需要改进的环节
## 改进项：编号、负责人、期限、验收方式
## 未决问题与证据缺口

文档发布前由事故参与者、服务负责人和一位未参与处置的评审者共同检查：事实是否可复核，推论是否标注，术语是否让旁观者理解，行动项是否能验收。复盘后的关键一步不是归档，而是在计划日期再次打开文档，用演练和运行证据确认故障树上的防线已经真正改变。