什么是根本原因分析

根本原因分析（Root Cause Analysis，简称 RCA）是一套"顺藤摸瓜"的系统方法：当问题发生时，不停留在修复表面现象，而是沿着因果链一层层向下追问，直到找到那个"不解决它、问题就会反复出现"的根因，再针对根因制定对策。它不迷信某一个工具，而是一套思维纪律——5 Whys、鱼骨图、故障树都是它的常用武器。

起源与关键人物

根本原因分析的思想最早来自丰田生产系统。大野耐一在丰田推行"问五次为什么"（5 Whys），要求工程师遇到任何异常都要连问五个为什么，直达流程缺陷而非停留在操作失误。几乎同一时期，质量管理学家石川馨发明了鱼骨图（Ishikawa Diagram），把"人、机、料、法、环"等维度的可能原因可视化，让团队集体排查不再遗漏。

后来 RCA 被引入航空、医疗、核电等高可靠性行业，成为事故调查的标准动作；再后来又进入互联网行业，成为线上故障复盘（Postmortem）的标配流程。从丰田车间到数据中心，变的是工具，不变的是那句追问：到底为什么？

如何使用

1. 定义问题，钉住现象：用一句话写清"发生了什么"，加上可观测的事实（时间、范围、影响），而不是猜测。比如不说"系统不稳定"，而说"11 月 2 日 14:00–14:40，支付接口 P99 延迟从 200ms 涨到 8s，失败率 12%"。
2. 封存现场，收集证据：在记忆消退前固定证据——日志、监控曲线、变更记录、当事人陈述。证据只记录事实，不掺杂"谁的错"的判断。
3. 画出因果链，从表象向下挖：用 5 Whys 或鱼骨图展开。每问一次"为什么"，都要求回答必须是可验证的事实，而不是推测。链条分叉时并行排查，不提前下结论。
4. 验证根因，而不只是"觉得是"：对候选根因做反证——如果真是它，现象应该能复现；把它拿掉，问题应该消失。经不起验证的"根因"只是嫌疑犯。
5. 制定对策，分三层下药：针对根因的纠正措施（杜绝复发）、针对表象的缓解措施（先止血）、针对流程的预防措施（让同类问题难以发生）。每个措施都要有负责人和截止时间。
6. 复盘归档，形成组织记忆：把分析过程写成复盘文档，沉淀到知识库。根因分析的最大价值不是解决这一次，而是让组织下次不再交学费。

案例学习

背景：虚构案例。"云杉科技"是一家在线协作文档 SaaS 公司。某周二下午，客服群突然涌入上百条投诉：文档保存时转圈、偶尔丢失未保存的内容。监控显示 API 错误率从万分之三飙升到 8%，持续约 40 分钟后自行恢复。

诊断：值班工程师第一反应是"数据库挂了"，但检查发现主库一切正常。团队启动 RCA：先钉住现象——错误集中在"保存文档"接口，且全部来自华东地区的用户。问为什么：华东流量走了新上线的边缘节点；为什么新节点会出错：它的本地缓存配置与其他节点不一致；为什么配置不一致：上周的配置下发脚本在新节点上静默失败了，而健康检查只看了进程存活，没校验配置版本。

行动：三层措施同步推进。止血：把华东流量切回老节点；纠正：修复配置下发脚本的错误处理，让失败显性化；预防：健康检查增加"配置版本一致性"校验，配置变更走灰度发布。

结果：故障后 2 小时内完成止血，当天修复脚本，一周内灰度发布流程上线。之后三个月，同类配置漂移问题零复发。

复盘：这次最贵的教训不是技术，而是"静默失败"——脚本失败了却没人知道。团队把"任何自动化失败必须显性告警"写进了工程规范。RCA 的价值在这里兑现：不挖到"脚本静默失败"这一层，下次换个配置还会栽跟头。

优点与局限性

优点：RCA 最大的优点是治本。它逼团队穿透表象，用证据链代替拍脑袋，解决一次、管用一类。复盘文档沉淀下来，就是组织的免疫记忆。

局限与边界：RCA 也有明确的边界。第一，它是事后方法，不适合需要事前预防的场景（那是 FMEA 的地盘）。第二，它假设因果关系相对清晰，在高度复杂的混沌系统里，"根因"可能根本不存在——只有一堆相互作用的因素。第三，它很吃证据质量，日志不全、监控缺失时，分析容易变成"有罪推定"。

风险与缓解：最大的风险是 RCA 异化为"追责大会"——一旦变成找人背锅，没人再敢说真话，证据链就断了。缓解办法是建立"对事不对人"的复盘文化：复盘文档里不写人名、只写角色；管理层带头先讲自己环节的问题。另一个常见风险是分析瘫痪——为了找"终极根因"拖几周不出对策。缓解办法是设时间盒：止血措施 24 小时内必须出，根因分析两周内闭环。

常见问题

Q：5 Whys 问几次才够？一定要问满五次吗？

A：不需要。"五"只是个经验数字，关键是问到"再往下挖就超出本次问题边界"为止。可执行的判断标准：当答案变成"流程/机制缺失"而不是"某个人/某次操作"时，就可以停了——因为对策已经可以落到流程改进上。

Q：鱼骨图和 5 Whys 应该用哪个？

A：看问题形态。选择方法：如果现象单一、因果链比较线性（比如一次线上故障），用 5 Whys 深挖；如果现象复杂、可能原因散落在多个维度（比如"客户流失率上升"），先用鱼骨图把"人、流程、产品、外部"等维度的嫌疑列全，再对每条分支用 5 Whys 深挖。两者经常配合使用。

Q：根因找到了，但改造成本太高，怎么办？

A：这是常态。操作建议：把对策分三层——先上便宜的缓解措施止血（比如加监控告警），再排期做根因级别的根治（比如重构），同时评估"不彻底解决"的残留风险并由负责人签字接受。判断标准：只要残留风险被显性记录和接受，就是合格的 RCA；最怕的是"假装解决了"。

Q：小问题也值得做 RCA 吗？

A：看复发成本。操作建议：用"影响 × 复发概率"快速打分——线上 P0 故障、客户资金损失、合规风险，必须做；偶发的 UI 小毛病，修掉就行。但关键动作：即使不做完整 RCA，也要把现象和处理记下来，攒够三次同类问题就升级成正式分析。

推荐资料

• 《丰田生产方式》（大野耐一）：5 Whys 的源头，理解"现地现物"思想必读。
• Google SRE 系列（《SRE：Google 运维解密》）：第 15 章讲 Postmortem 文化，是互联网行业 RCA 的实战范本。
• 石川馨《质量管理入门》：鱼骨图的发明者亲自讲解因果图的使用。

相关方法

鱼骨图

5 Whys 分析

PDCA 循环

议题树

核心表达

头痛医头只会让问题复发，挖到根因才能一劳永逸。