什么是根因分析（RCA）？5Why、鱼骨图在问题管理中的用法

根因分析（Root Cause Analysis，简称RCA）是指在故障或异常发生后，不满足于"先恢复再说"，而是系统地追问"为什么会发生"，找到导致问题的根本原因，并据此采取措施防止再次发生的分析方法。 在 ITIL流程 中，它是问题管理的核心环节：事件管理解决"眼前的故障"，根因分析解决"故障为什么反复出现"。

很多团队的处理方式是：故障出现，重启服务恢复，工单关闭，下次再来一遍。这样的"救火循环"消耗大量人力，却始终没有改善稳定性。本文介绍几种常用的根因分析方法、实施步骤，以及如何借助 工单系统 与 CMDB 的数据让分析更有依据。

一、先分清：症状、直接原因与根本原因

1. 症状

用户看到的现象，比如"网站打不开"。

2. 直接原因

导致症状的直接技术原因，比如"数据库连接数耗尽"。

3. 根本原因

真正导致问题发生的深层原因，比如"某次发布引入了未释放连接的代码，而发布前的测试没有覆盖该场景"。

如果只处理到"直接原因"这一层，比如重启数据库，问题很可能在下次发布后再次出现。根因分析的价值，就在于往下多问几层，直到找到能够被改进的流程、设计或管理缺陷。

二、三种常用的根因分析方法

1. 5Why分析法

举个简化的例子：网站响应变慢，为什么？数据库查询变慢；为什么？某张表缺少索引；为什么？新功能上线时没有评估查询性能；为什么？发布流程中没有性能检查环节；为什么？之前没有出现过类似问题，也没人提出要求。最终的改进点是"在发布流程中增加性能评估"，而不是简单地"给表加个索引"。

需要注意，5不是固定数字，追问到可以采取有效措施的层面即可。同时要避免把根因归结为"某某人操作失误"，真正有价值的问题是"为什么流程允许这样的失误发生"。

2. 鱼骨图

适合多个因素交织的情况。团队围绕问题，从"人员、流程、技术、工具、环境"等维度分别列出可能原因，再逐个核实、排除。它的优点是帮助团队不遗漏角度，缺点是需要用日志、监控等证据去验证每个分支。

3. 时间线分析

把故障前后的变更、发布、告警、操作按时间排列，往往能迅速发现"问题出现前不久发生了什么"。这种方法特别依赖完整的变更记录，也是 ITSM系统 中变更管理与事件管理相互关联的价值所在。

三、如何在团队中落地根因分析

1. 明确哪些问题值得做RCA

不需要对每一张工单都做深入分析。适合启动RCA的情形包括：重大事件、同类事件反复出现、影响范围大、处理成本高。选择合适的对象，才能让分析投入产生回报。

2. 建立"问题"记录

当同类事件重复出现，或重大事件解决之后，应在系统中创建问题（Problem）记录，关联相关的事件工单，指定负责人和分析期限。这样根因分析不再依赖某个人的记忆，而是进入可跟踪的流程。

3. 组织无责复盘

复盘的目的在于找到系统性原因，而不是追究个人。氛围越开放，团队越愿意说出真实情况。会议结束后应形成书面结论，包括时间线、根因、改进措施和负责人。

4. 用数据支撑分析

借助工单历史、监控数据、变更记录和 CMDB 中的依赖关系，可以更快判断问题影响了哪些服务、与哪些变更有关、是否在同一类配置项上反复发生。凭感觉得出的结论，往往经不起推敲。

5. 区分临时方案与永久方案

分析期间，可以先制定临时的绕过方案（Workaround）恢复业务，并记录到已知错误库（KEDB），让一线能够快速处理类似事件。永久方案则需要通过变更流程实施，并验证是否真正消除了根因。

6. 跟踪改进措施的落实

根因分析最容易出现的问题，是"报告写得很好，措施没人跟进"。每项改进措施都应有明确的负责人、完成日期，并在系统中跟踪状态，直到验证有效后才关闭问题。

7. 用指标衡量效果

关注重复事件的数量是否下降、重大事件的发生频率、平均恢复时间的变化，以及问题记录的平均关闭时长。这些指标能反映根因分析是否真正提升了稳定性。

四、常见问题解答（FAQ）

Q1：根因分析和事件管理有什么区别？
事件管理的目标是尽快恢复服务，根因分析的目标是找出并消除根本原因。前者治标，后者治本，两者配合才能降低故障发生频率。

Q2：所有故障都要做根因分析吗？
不需要。建议优先针对重大事件和重复发生的事件，避免分析工作本身成为负担。

Q3：找不到明确根因怎么办？
有些问题确实难以定位。可以记录已排除的假设，制定监控和防护措施，并在问题再次出现时收集更多证据，而不是勉强写出一个不确定的结论。

Q4：5Why和鱼骨图可以一起用吗？
可以。先用鱼骨图广泛列出可能原因，再针对重点分支用5Why深入追问，两种方法互补。

Q5：谁来负责根因分析？
通常由问题负责人牵头，邀请相关团队参与。关键是有明确的责任人和时间期限，而不是"大家都关注，没人负责"。

Q6：根因分析的结论如何沉淀？
可以整理为知识库文章，并更新已知错误库和排查手册，让下一次遇到同类问题的人能够更快应对。

Q7：怎么避免复盘变成"甩锅会议"？
明确"对事不对人"的原则，把关注点放在流程与机制上；领导者先示范开放的态度，并强调改进而非追责。

五、结语：与其反复救火，不如找到火源

根因分析 把团队从"一次次救火"带向"让问题不再发生"。从选择合适的问题、使用恰当的方法，到跟踪改进措施，每一步都需要流程与数据的支撑。善用 工单系统 的历史记录与 CMDB 的依赖关系，会让分析更快、更准。

如果你正在建设问题管理流程，可以了解一下 ManageEngine ServiceDesk Plus。它支持问题记录与事件关联、已知错误库、变更联动以及CMDB，适合作为落地根因分析与问题管理时的参考选项之一。