根因分析：不止于"五问"

预计时间：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 题）

场景题

七、答题提示

展开提示

• Q1-3 核心：防止再发生 > 惩罚人；系统性 > 表面原因。
• Q4-6 「预算不够」和「审批走过场」都是「中间原因」——继续追问。
• Q7-8 鱼骨图适合发散探索，不是精确归因工具。
• Q9-10 屏障分析把人放在系统里看——一个屏障失效了，是系统的问题。
• R1-R3 每个场景的关键都是「不要停在最近的那一层」。

八、本课行动清单

1. 回想最近一个月你遇到的一个反复出现的问题——用 5 Whys 追到系统性原因。
2. 下次做 RCA 时，写完之后标注每个原因属于「近因」「条件原因」还是「系统性原因」。
3. 在团队中推广「无责」RCA——分析时不追究个人责任，只问系统怎么改进。
4. 建立「问题-根因-改进」追踪表：记录问题和改进措施，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）。