根因分析也常被称为根因分析法，英文常写作 Root Cause Analysis，简称 RCA，是一套结构化的问题调查方法。它的目标很具体，找出什么条件导致了这次问题发生，以及什么改变可以防止它再次发生。IBM 在 2023 年 4 月发布的根因分析指南中，把它定义为组织在问题、故障或事件发生后寻找根源的质量管理过程。这个定义强调两件事。一是调查发生在问题之后，二是结论要能转化为防止复发的行动。
在数据分析场景里，根因分析通常从一条异常指标开始。先看症状，再顺着证据链往下追，最后落到可改变的流程、系统或设计条件。症状容易看见，根因往往藏在几个系统的交界处，需要把数据、日志、流程记录和现场事实放在一起看。
根因到底指什么
根因是导致问题发生的根本条件。 它和症状、直接原因处在不同层级。症状是你能直接看到的结果，比如转化率下降、留存下滑、系统报错。直接原因是紧挨着症状的那一环，比如支付页加载超时。根因还要继续往下问，为什么支付页会超时，为什么这个问题没有被提前发现，什么流程或设计条件让它可以发生。
举个假设的例子。一家电商发现支付转化率连续三天下降，主要集中在安卓低端机型。直接原因可能是支付页加载超时。继续追，可能是新版 SDK 与旧系统版本不兼容。再往上，可能是发布前的兼容性测试矩阵没有覆盖这类机型。最后这一层更接近根因，因为它指向了可改变的发布流程。
根因未必只有一个。 IBM 和 Juran Institute 的资料都提醒，一个问题可能存在多个根因。把多个原因压缩成一个结论，措施容易只覆盖其中一段。实践中可以先找主因，再把促成因素一并列出，分别判断哪些需要纠正，哪些需要预防。
判断一条原因够不够接近根因，可以看三点。它能不能解释问题发生的机制，能不能解释为什么发生在这个时间、这个对象、这个环节，以及它是否指向可改变的条件。只能解释一次事件，却无法指向可复用改进的原因，通常还停留在直接原因层。
根因分析和归因分析，边界在哪里
归因分析常出现在营销和增长场景，用来判断不同渠道、触点或因素对结果的贡献。根因分析继续往下追问，为什么这个因素会在这个环节产生影响，什么条件让影响变成问题。一个回答贡献度，一个回答机制。 两者可以接力使用，先用归因分析缩小范围，再用根因分析验证因果关系，最后用措施验证结论。
在业务复盘里，这两个词经常被混用。比如发现某渠道带来的新用户留存更低，归因分析可以告诉你这个渠道的贡献更大。根因分析还要继续看，是素材承诺与产品体验不一致，还是渠道人群本身与目标用户不匹配，抑或新用户引导流程在这个渠道的设备环境下出了问题。分析停在前一步，措施很容易变成简单砍预算。走到后一步，才可能找到更准确的调整方式。
做一次根因分析，通常要走完六步
IBM 的指南把根因分析拆成识别问题、组建团队、收集数据、头脑风暴原因、确定根因、制定行动方案等环节。放到企业日常复盘里，可以落成六步。
- 把问题说清楚。 写清时间、范围、对象、指标口径和影响。比如“支付转化率下降”还不够，至少要说清哪个端口、哪些机型、从什么时候开始、下降了多少、影响到哪些用户。问题定义越模糊，后面越容易各说各话。
- 收集证据。 数据、日志、工单、流程记录、变更记录、访谈和现场观察都可以用。先收集事实，再讨论观点。证据要能回答时间顺序、影响范围和异常出现的条件。
- 列出可能原因。 这一步要发散，先把可能性摆全，不急着选一个最顺眼的结论。5Why、鱼骨图、故障树都可以在这里发挥作用。
- 验证原因。 用数据回溯、对照、复现或排除法，判断哪条原因真正成立。条件允许时，可以用灰度、回滚或小范围对照验证。相关性不能直接写成因果，时间上同时发生也不代表就是原因。
- 制定措施。 把临时止血、纠正措施和预防措施分开。临时止血解决眼前影响，纠正措施处理这次问题的原因，预防措施防止同类问题在其他环节重演。每项措施都要有负责人、完成时间和验证指标。
- 验证并沉淀。 用同一口径复核问题是否下降或消失。把有效的原因链、措施和失败假设写进知识库，更新监控规则和流程。没有验证，根因分析只是一次讨论。
常用方法怎么选
方法用来组织假设，因果还要靠证据确认。不同方法解决的是不同环节的问题，选错了，讨论会很热闹，结论却落不下来。
| 方法 | 适合的问题 | 使用要点 | 需要留意 |
|---|---|---|---|
| 5Why | 原因链相对清晰、单一事件、需要快速推进 | 连续追问为什么，直到找到可改变的系统条件 | 容易受参与者经验和预设影响，要拿数据、日志和现场事实校准 |
| 鱼骨图 | 原因多、需要团队一起发散 | 按人员、方法、机器、物料、测量、环境六类展开，再逐项筛选 | 它帮助找候选原因，不负责证明因果 |
| 故障树分析 | 重大故障、组合条件、安全或可靠性问题 | 从结果向上拆解必要条件，用逻辑关系表达 | 建树成本较高，适合高风险场景 |
| 失效模式与影响分析 | 还没发生但风险较高的流程或产品 | 列出失效模式、影响和可能原因，提前排优先级 | 更偏事前预防，不能替代事后调查 |
| 变更分析 | 指标突然变化，怀疑由版本、配置或环境变化引起 | 对比变更前后的时间、对象、配置和数据 | 相关变化不等于因果，还要排除其他同时发生的因素 |
| 帕累托图 | 问题很多，需要先抓主要矛盾 | 按发生频率排序，优先处理贡献最大的原因 | 频率高不等于根因深，仍需继续追问机制 |
5Why 由丰田工业创始人丰田佐吉在 20 世纪 30 年代提出。Juran Institute 的资料提醒，它更适合相对直接、原因链不复杂的问题。问题越复杂，越需要多种方法配合。
鱼骨图常被追溯到质量管理学者石川馨。精益改善机构 TXM 的指南把常见原因分为人员、方法、机器、物料、测量、环境六类。故障树、变更分析和帕累托图则适合不同的证据结构。
企业里常见的四个断点
第一，问题定义太宽。只写“转化下降”“留存变差”，没有时间、范围和口径，团队会在不同问题上各说各话。
第二，把直接原因当根因。看到“员工操作失误”“第三方接口异常”就结案，措施往往变成提醒、处罚或换供应商，同类问题仍可能换一个入口重来。人会犯错是常态。流程为什么允许这个错误造成后果，更值得追问。
第三，只开会不看数据。讨论靠印象，结论靠谁声音大。根因分析需要证据链，会议只能用来对齐问题和判断，不能替代数据与现场事实。
第四，措施没有验证。动作做完就结案，没有同一口径的复核，也没有把有效做法写回流程。下一次问题出现，团队又从零开始。措施没有验证，分析就没有闭环。
当问题发生在数字化业务里
数字化业务里的根因分析，难点通常落在证据分散上。指标在数据平台，日志在研发系统，用户反馈在客服工单，版本变更在发布记录。分析人员要在几个系统之间来回拼图，很多时候还没拼完，业务已经换了下一个问题。
举个假设的例子。某游戏新版本上线后，新用户次日留存下降。按渠道、版本、机型、地区拆分后，发现安卓某类机型的崩溃率明显上升。继续追，发现新接入的 SDK 与旧系统版本不兼容。再往上，是兼容性测试矩阵没有覆盖这类机型。留存下降只是症状，根因落在发布前的兼容性验证流程。对应的措施也不只是修崩溃，还要补测试矩阵、加发布前拦截和上线后的异常监控。
当分析对象变成 Agent，证据链还要包含运行过程。 用户看到的是一次任务失败，背后可能是意图理解偏差、工具调用失败、上下文过长或模型输出不稳定。以 ThinkingAI 的 Agent 观测能力为例，Trace 会记录调用关系、执行状态、耗时和 Token 使用，AI Monitor 从失败、长耗时、异常 Trace 和 Token 波动中聚合信号，再下钻到单次 Trace 核对 Conversation、Model、Tool 与 Skill 的执行证据。这样，团队才能判断问题出在意图理解、工具调用还是内容生成，避免只停在任务完成率这个表面指标上。
ThinkingAI 的 Agentic Engine 把用户行为分析、归因分析和 Agent 观测放在同一套数据基础上，已服务全球超 1500 家企业、接入产品超 8000 款。对于需要把业务结果和运行过程放在一起看的团队，这类能力可以减少在多个工具之间拼接证据的时间。
怎样判断找到的是根因
根因要能解释机制，也要能接受验证。 可以用四个问题做自检。
- 证据链是否完整。 事实能不能按时间顺序连起来，关键节点有没有记录或数据支撑。
- 机制是否说得通。 这条原因能不能解释问题为什么发生，而不只是与问题同时出现。
- 替代解释是否排除。 有没有另一个同时发生的变化也能解释结果，团队是否认真比较过。
- 措施是否有效。 采取措施后，问题是否在同一口径下下降或消失。条件允许时，用回滚、灰度或对照实验验证。
根因分析最终要落到可改变的条件上。把结论停在某个人做错了，措施通常只能变成提醒和处罚，问题仍然可能重复。能解释一类问题、能指导一类措施的原因，比只能解释一次事件的原因更有复用价值。
关于根因分析的常见问题
根因分析和 5Why 是一回事吗？
5Why 是根因分析的一种常用方法，不是根因分析的全部。它适合原因链相对清晰的问题，通过连续追问把表面原因往下推。复杂问题还需要鱼骨图、故障树、变更分析等工具配合。5Why 的结论要拿数据、日志和现场事实校准，否则容易变成个人经验的串联。
根因分析一定要找到唯一原因吗？
不一定。一个问题可能有一个主因，也可能有多个必要条件同时成立。IBM 和 Juran Institute 的资料都提到多根因的可能。实践中可以先找主因，再把促成因素一并列出，分别安排措施。强行压缩成一个原因，容易漏掉让问题扩大的条件。
根因分析和归因分析有什么区别？
归因分析更关注贡献度，比如哪个渠道、哪个触点、哪个因素对结果影响最大。根因分析更关注机制，为什么这个因素会导致问题，什么条件让问题得以发生。两者可以接力使用。先用归因分析缩小范围，再用根因分析验证因果关系，最后用措施验证结论。
根因分析报告一般包含什么？
一份可执行的报告通常包括问题描述、时间线、证据、原因链、根因判断、纠正与预防措施、负责人和验证结果。报告可以很短，但要能让没有参加分析的人看懂结论是怎么来的，以及下一步谁在什么时候完成什么动作。
没有完整数据，还能做根因分析吗？
可以做，但要调整结论强度。访谈、现场观察、工单记录、变更日志和时间线都可以作为证据。数据不完整时，先把结论写成待验证的假设，再设计小范围验证。把推测直接写成确定根因，后面的措施很容易落空。
把一次分析变成可复用的能力
根因分析的价值不止于解决一次问题。 企业可以把问题定义模板、证据清单、方法选择规则和验证口径固定下来，让不同团队用同一种方式复盘。每完成一次分析，把原因链、有效措施和失败假设写进知识库，下一次遇到相似问题时，团队不必从零开始。
对数据基础较好的企业，可以把异常监测、多维分析、归因和 Agent 观测接进同一条链路，让发现问题、定位原因、执行措施、验证效果形成闭环。根因分析因此从一次会议，变成组织持续改进的日常动作。
