根因分析：从时间线到因果证据闭环
TL;DR：根因分析（RCA）的难点不是“找到原因”，而是判断一个原因主张证据是否闭合。因果分析与根因分析 给出了从时间线到证据表的六步流程；本篇深化“证据标准与适用边界”——人的失误是调查起点而非结论，5 Whys 和鱼骨图只生成假设，故障树处理 AND/OR 组合，FMEA 是前瞻工具而非事后证明。一条因果路径只有同时具备机制、时序和区分性证据，才应进入“已闭合”集合。
目录
| 章节 | 说明 |
|---|---|
| 与既有 RCA 笔记的分工 | 流程在 06，证据标准在本篇 |
| 证据闭环三要素 | 机制、时序、区分性 |
| 人的失误是起点不是结论 | 解释行为合理性 |
| 工具的证据边界 | 每种工具能证明什么、不能证明什么 |
| 软件事故场景 | 从“配置错误”到证据闭合 |
| 适用边界与误用 | 何时 RCA 不适用 |
与既有 RCA 笔记的分工
因果分析与根因分析 解决“怎么查”：时间线、变化分析、因果树、证据表、屏障分析与纠正验证。本篇解决“查到什么程度算够”：一条原因主张满足什么证据标准才算闭合，哪些常用工具只能生成假设、不能当作证明。两篇是配套关系：06 是流程，01 是证据门槛。
| 问题 | 去哪篇 |
|---|---|
| 怎么组织一次 RCA | 因果分析与根因分析 |
| 5 Whys / 鱼骨 / 故障树怎么用 | 因果分析与根因分析 |
| 一条原因算不算查清了 | 本篇 |
| 哪些工具的结论不能直接当因果 | 本篇 |
证据闭环三要素
一条因果主张要进入“已闭合”集合，需同时通过三道检查，缺一不可：
| 要素 | 含义 | 缺失时的症状 |
|---|---|---|
| 机制 | X 能通过某个具体过程影响 Y，且过程在技术上成立 | 只有“时间上先后”，说不清怎么发生 |
| 时序 | X 的变化在 Y 之前出现，且延迟合理 | 把后果当成原因，或时序无法对应 |
| 区分性 | 排除“没有 X 也会出现 Y”，存在反事实或对照 | 单案例，无法排除其他解释 |
flowchart TD
A["因果主张<br/>X 导致 Y"] --> B{机制成立?}
B -- 否 --> Z["回到假设池"]
B -- 是 --> C{时序合理?}
C -- 否 --> Z
C -- 是 --> D{能排除<br/>替代解释?}
D -- 否 --> Z
D -- 是 --> E["进入已闭合集合<br/>可驱动行动"]
Z --> F["补证据或改设计"]
F --> B
style E fill:#cfc,stroke:#060
style Z fill:#fcc,stroke:#c00
证据闭合不是“我们觉得查清了”，而是这三道检查都有具体证据对应。把“最后一个 Why”或“鱼骨图上一根分支”直接当结论，等于跳过了区分性检查。
人的失误是起点不是结论
把事故归因为“某人不小心”会终止调查——而那恰恰是调查应该开始的地方。Google SRE 的无责复盘要求解释当时行为合理性：操作者掌握什么信息、界面给什么反馈、目标和约束是什么、为什么这个动作在当时显得合理。
| 把人当结论 | 把人当起点 |
|---|---|
| “工程师配置错了” → 培训、提醒、加强意识 | “为什么这个配置在当下显得正确？” → 校验缺失、默认值危险、灰度不覆盖高峰 |
| 终止机制调查 | 进入屏障分析与系统设计缺口 |
| 把可靠性寄托于记忆 | 改信息流、约束与防错 |
“人为错误”几乎总是一个症状，背后是界面、流程、激励或防线设计允许单点错误无声扩散。调查的产出应是“什么系统条件使这个错误成为合理且危险的选择”，而非“谁该负责”。
工具的证据边界
常用 RCA 工具各自只能支撑特定强度的证据，混用其能力会高估结论：
| 工具 | 能做什么 | 不能证明什么 | 误用信号 |
|---|---|---|---|
| 5 Whys | 探索较短、近似线性的原因链 | 处理 AND/OR 多因素组合；自身无证据 | 把第五个 Why 当成事实 |
| 鱼骨图 | 按人/机/料/法/环发散假设 | 把分类分支当成已证实原因 | “鱼骨图显示原因是流程” |
| 故障树 | 用 AND/OR 逻辑分析顶事件如何由组合产生 | 解释组织适应与长期反馈 | 只画 OR 树，忽略必要条件 |
| 因果树 | 表达多条原因路径与证据状态 | 精确表达反馈与动态 | 单线故事，无竞争路径 |
| FMEA | 在故障发生前识别失效模式与控制 | 作为事后因果证明（它是前瞻的） | 用 FMEA “证明”已发生事故的根因 |
| 证据表 | 检验每条主张的支持/反证与置信度 | 自动发现新原因 | 表填满就结案，未验证 |
FMEA 的定位：失效模式与影响分析（FMEA）是前瞻风险工具——在发布前识别可能的失效模式、严重度、发生度与可探测度，并据此排序控制措施。它不产生事后证据。把 FMEA 的评分当成已发生事故的因果证明，是混淆了“可能怎么坏”与“这次为什么坏”。
软件事故场景
某服务配置发布后缓存雪崩。直觉结论“工程师配置错误”只满足时序（配置在前、雪崩在后），机制含糊，且跳过了区分性——没有这次配置，缓存也可能因其他路径雪崩。证据闭合需要同时回答：
- 机制：危险默认值如何导致回源放大？为什么没有 schema 校验？回源为何无限流？
- 时序：配置发布、命中率下降、回源飙升、错误率上升的时间戳能否对齐？
- 区分性：同期是否有其他变更？未受影响实例是否因为没有该配置而正常？
只有当机制、时序和区分性都指向同一组防线缺失（危险默认值 + 无校验 + 灰度不覆盖高峰 + 回源无限流 + 命中率告警缺失 + 回滚审批慢），这条因果路径才算闭合，据此设计的行动项才切中要害而非泛泛培训。完整六步流程见 因果分析与根因分析。
练习
选最近一次事故，为“直觉根因”填一张证据表：列出机制、时序、区分性各自的证据与缺口。再列三个竞争性解释并标注证据状态。让未参与事故的人判断：按当前证据，这条主张该进“已闭合”还是“待验证”？他指出的缺口，就是你证据链还没闭合的地方。
适用边界与误用
- 不适合事故处置进行中：恢复服务优先，RCA 在稳定后进行；危机中做漫长分析会延误止损。
- 不适合有标准答案的故障：明确的技术 bug 直接修，不必套用完整 RCA 仪式。
- 不要追求单一根因：复杂事故是多重条件 AND 组合，强求“一个根因”会遗漏必要条件。
- 不要用 RCA 证明已经选定的方案：证据表若只收集支持证据、从不列反证，就是用流程背书既有结论。
- 行动项不等于证据闭合：行动项是否落实、是否经过演练或数据验证，才是事故关闭标准，而非“任务都领走了”。
关联笔记
- 因果与证据总览：从主张到可验证决策（证据强度阶梯与统一工作流）
- 因果图与混杂：为什么控制更多变量也会出错（用 DAG 显化混杂与竞争性解释）
- 因果分析与根因分析（RCA 六步流程与工具分工，本篇是其证据标准深化）
参考资料
- Postmortem Culture: Learning from Failure — Google SRE
- NIST/SEMATECH e-Handbook of Statistical Methods（过程改进与因果工具）
- Five Whys / 鱼骨图 / FMEA — ASQ 质量资源（FMEA 为前瞻性风险工具，非事后证明；ASQ 站点对自动化访问返回 403，按名引用）
- 《学习型管理：培养领导团队的 A3 管理方法》（原著 Managing to Learn）— John Shook
评论 (0)