根因分析：不止于"五问"
出事后找一个责任人是最简单的——但真正解决问题的人找到的是系统的深层原因。根因分析是防止同一类问题反复发生的系统性方法。
**预计时间：**25 分钟读完 + 30 分钟做练习 = 55 分钟。
一、根因分析不是什么
| 根因分析是 | 根因分析不是 |
|---|---|
| 找到系统层面的深层原因 | 找到一个”责任人”然后惩罚他 |
| 防止同类问题再发生 | 写出”已整改，加强管理”这种套话 |
| 理解为什么系统允许这个错误发生 | 追究”这个人怎么这么不小心” |
| 持续迭代的分析过程 | 一次性的报告 |
二、根因分析的三个层次
2.1 第一层：近因（Proximate Cause）
直接触发事件的原因。比如：“服务器宕机是因为运维人员执行了错误的命令。”
问题：如果只停在这里，你只会”惩罚”那个运维，但相同的情景可能再次发生——因为系统允许一个人用一条命令关停所有服务。
2.2 第二层：条件原因（Conditional Cause）
为什么近因能够发生？：“运维人员没有经过审核就能执行高危命令——因为运维流程中没有审核/审批步骤。”
问题：你加了一个审批步骤——但是审批会不会变成走过场？审批延迟会不会影响紧急恢复？
2.3 第三层：系统性原因（Systemic Cause）
为什么条件原因存在？：“团队文化鼓励快速响应而非充分审核；流程设计没有考虑人为错误的高概率；绩效指标关注速度多于正确性。”
这才是根因——需要改变系统/文化的层面。
三、RCA 工具箱
3.1 5 Whys（五问法）
经典方法：追问 5 次”为什么”来穿透表面。
- 为什么交易结算失败？→ 因为数据格式不对
- 为什么数据格式不对？→ 上游系统改了字段定义但没有通知
- 为什么没有通知？→ 系统间没有自动化的变更通知机制
- 为什么没有机制？→ 团队没有建立系统间集成测试和变更同步的流程
- 为什么没有这个流程？→ 架构治理体系中缺少”跨系统变更协调”这个环节（根因）
3.2 鱼骨图（Ishikawa / Fishbone Diagram）
将可能的原因分为几个维度（人/机/料/法/环/测 或 人员/流程/技术/数据/外部）。适用于原因不清晰、需要发散探索的场景。
3.3 屏障分析（Barrier Analysis）
问：“本应防止这个错误的屏障在哪？为什么失效了？”
比如，交易系统应该有”金额超过阈值二次确认”的屏障——但它失效了，为什么？有人绕过了？配置错了？从来没配过？
四、RCA 的常见陷阱
| 陷阱 | 表现 | 解法 |
|---|---|---|
| 停止太早 | 找到了”直接原因”就停止了——“是因为 A 做了 B” | 追到”系统为什么允许 A 做 B” |
| 找替罪羊 | 归因于”这个人不够小心” | 人都会犯错——系统应该被人为错误设计（Human Factors） |
| 因果链断裂 | ”因为预算不够”——然后停住了 | ”预算不够”本身也是个结果，继续问为什么预算不够 |
| 确认偏误 | 已经认定是某个原因，然后只找支持它的证据 | 主动寻找”这个原因不成立”的可能性 |
| 过于复杂的根因 | 根因分析变成了”所有问题都是系统性问题”——太抽象了无法行动 | 根因必须对应一个可操作的改进措施 |
五、实战案例
5.1 案例 1：生产环境 Bug 的根因分析
现象：用户看到一个错误的持仓数据。
近因：缓存没有及时失效。
条件原因：缓存失效机制是定时刷新（每 5 分钟），不是基于事件触发的。在定时刷新间隔内，如果数据变更了，用户看到的是旧数据。
系统性原因：系统的缓存策略没有分类——“高实时性要求的数据”和”低实时性要求的数据”用的是同一种缓存策略。团队没有定义数据的实时性要求和对应的缓存策略。
可操作的改进：(1) 对持仓类数据改为事件驱动缓存失效；(2) 建立”数据实时性分级标准”——根据业务影响定义不同数据的缓存策略。
5.2 案例 2：OTP 系统”每日对账不平”
现象：每天对账都有几笔对不上，需要人工核对。
近因：A 系统和 B 系统的交易记录时间戳不一致。
条件原因：两个系统的时钟不同步，差距约 30 秒。
系统性原因：系统架构设计时没有做时间同步的规范——没有 NTP 强制同步，也没有在数据层面加上”交易发起 ID”来做跨系统关联。
可操作的改进：(1) 强制 NTP 同步；(2) 增加跨系统交易关联 ID（correlation ID），不依赖时间戳做匹配。
5.3 案例 3：产品需求”反复被推翻”
现象：团队花了 2 个月开发的功能，上线后被业务方推翻——“这不是我想要的”。
近因：需求文档写得不清楚。
条件原因：评审会只是过了 PPT，没有人验证过真正的交互流程。
系统性原因：公司没有原型验证环节——所有需求从”文档”直接到”开发”，没有用原型让业务方在实际使用前确认。
可操作的改进：在产品流程中增加”交互原型验证”环节——业务方在原型上操作确认后才进入开发。
六、测验（12 题）
根因分析的最终目标是？
下面哪一项属于"系统性原因"？
5 Whys 方法的核心价值是？
如果 RCA 找到了"预算不够"就停了——主要问题在哪？
根因分析的"基础假设"是什么？
"系统增加了审批流程但审批变成了走过场"——这说明了？
鱼骨图（Ishikawa）最适合用于哪种场景？
"同样的 Bug 过了两周又出现了"——最可能的原因是？
屏障分析（Barrier Analysis）的核心问题是？
根因分析和"找替罪羊"的本质区别是？
场景题
R1. 场景：一个交易系统在生产环境出现了金额计算错误——原因是某个产品的手续费率配置错了。做 RCA——你的追问路径是？
R2. 场景：一个 Sprint 交付的功能，业务方验收时发现 5 个重大缺陷。RCA 路径？
R3. 场景：用户登录总是超时——因为认证服务响应慢。但每次重启认证服务就好了。RCA？
七、答题提示
展开提示
- Q1-3 核心：防止再发生 > 惩罚人；系统性 > 表面原因。
- Q4-6 “预算不够”和”审批走过场”都是”中间原因”——继续追问。
- Q7-8 鱼骨图适合发散探索，不是精确归因工具。
- Q9-10 屏障分析把人放在系统里看——一个屏障失效了，是系统的问题。
- R1-R3 每个场景的关键都是”不要停在最近的那一层”。
八、本课行动清单
- 回想最近一个月你遇到的一个反复出现的问题——用 5 Whys 追到系统性原因。
- 下次做 RCA 时，写完之后标注每个原因属于”近因""条件原因”还是”系统性原因”。
- 在团队中推广”无责”RCA——分析时不追究个人责任，只问系统怎么改进。
- 建立”问题-根因-改进”追踪表：记录问题和改进措施，3 个月后检查同样的根因是否引发新问题。
九、参考来源
- ② 经典：James Reason，《Human Error》——关于系统性错误和人因工程的经典著作
- ② 经典：Sidney Dekker，《The Field Guide to Understanding Human Error》——为什么”找到责任人”不是好方法
- ③ 严肃著作：Charles Perrow，《Normal Accidents》——复杂系统中灾难性事故是”正常的”（系统性的）
- ④ 实用读物：Toyota Production System 中的”5 Whys”方法论——工业级 RCA 实践
**下一步：**看 Lesson 0009 · 帕累托法则（80/20）。