> ## Documentation Index
> Fetch the complete documentation index at: https://meta.niceshare.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 根本原因分析

> 根本原因分析是识别问题根本原因的系统性过程。学习方法、技术以及何时应用每种方法。

<Info>
  **类别**: 方法<br />
  **类型**: 问题解决技术<br />
  **起源**: 质量管理运动，1950年代，美国<br />
  **别名**: RCA、根本原因分析、原因分析
</Info>

<Note>
  **快速回答** — 根本原因分析（RCA）是一系列用于识别问题根本原因的系统性方法。与修复直接症状不同，RCA深入挖掘找到潜在原因，一旦解决就能防止复发。它在二战后的制造业质量管理原则中发展而来，现已成为医疗保健、软件工程、航空和各行业事件管理的必备技能。
</Note>

## 什么是根本原因分析？

根本原因分析是一个统称，指用于识别问题或事件潜在原因的一系列技术。核心原则看似简单：出了什么问题，不要只修复可见的问题——首先找出为什么会发生，然后修复那个。

症状与原因之间的区别是根本性的。你观察到的是症状——一个bug、一次失败、一个投诉。根本原因是症状存在的潜在原因。治疗症状提供暂时的缓解；治疗根本原因提供永久的解决方案。这个区别听起来很明显，但在实践中，组织经常把资源花在治疗症状上，而潜在的问题却在恶化。

RCA通常遵循一个结构化过程：定义问题、收集数据、识别可能的原因、确定根本原因、实施纠正措施。识别原因的方法各不相同——有些使用特定的框架，如"五个为什么"或鱼骨图，而有些使用更复杂的统计或系统思维方法。

> "如果你不消除根本原因，问题会复发。就是这么简单。" — 丰田生产系统原则

RCA的价值超越了问题解决。严格执行根本原因分析的组织会建立关于失败模式的机构知识，随着时间推移变得更具弹性。每次properly进行的RCA都会增加对系统如何失败以及如何防止失败的了解。

### 根本原因分析的三层理解

* **入门**: 面对任何问题时，区分发生了什么（症状）和为什么会发生（原因）。使用"五问法"技术一次深入一层，直到找到一个你可以实际处理的原因。

* **实践者**: 使用鱼骨图映射问题空间以识别多个潜在原因，然后使用数据和实验来确定哪些原因最重要。

* **进阶**: 应用系统思维来识别造成重复问题模式的反馈循环和二阶效应。对于具有多个相互作用故障的复杂系统，使用故障树分析等技术。

## 起源

根本原因分析起源于二战后美国的质量管理运动。受爱德华兹·戴明和约瑟夫·朱兰工作的影响，日本制造商开始系统性地分析缺陷以提高质量。这种方法在1950年代和1960年代成熟，成为后来被称为丰田生产系统的一部分。

"根本原因分析"这个术语本身在1990年代获得更广泛的使用，特别是在核工业和航空业在几起重大事故后采用它之后。1979年的三里岛事故和1986年的挑战者号灾难都促使高风险行业加强对系统性根本原因分析的重视。

在软件开发中，RCA在2000年代随着DevOps和站点可靠性工程的兴起而获得重视。谷歌的SRE书籍和Netflix的混沌工程实践将RCA formalize为管理事件和提高系统可靠性的核心实践。

## 核心要点

<Steps>
  <Step title="将症状与原因分开">
    你观察到的（症状）不是需要修复的（原因）。任何RCA的第一步是清晰定义问题，不要将其与原因混为一谈。
  </Step>

  <Step title="不同情境使用不同技术">
    没有一种RCA方法适用于所有情况。五问法适用于线性因果链；鱼骨图适用于复杂多因素问题；故障树分析适用于具有关键故障模式的系统。
  </Step>

  <Step title="实施前验证">
    识别多个潜在的根本原因，然后使用数据或实验来确定哪个实际上是导致问题的原因。为未验证的原因实施修复会浪费资源。
  </Step>

  <Step title="寻找系统性模式">
    单个问题通常共享共同的根本原因。跟踪RCA发现随着时间推移揭示的系统性问题，一旦修复就会同时消除多种问题类型。
  </Step>
</Steps>

## 应用场景

<CardGroup cols={2}>
  <Card title="软件事件管理">
    生产事件发生后，形式化的RCA不仅识别技术故障，还识别允许其发生的流程、监控和设计差距。
  </Card>

  <Card title="医疗患者安全">
    当发生不良事件时，RCA识别系统性因素——沟通协议、工作流程设计、人员配置——而不是将失败归咎于个人错误。
  </Card>

  <Card title="制造质量控制">
    当发现缺陷时，RCA追溯造成缺陷的流程变化和设备问题，实现有针对性的流程改进。
  </Card>

  <Card title="项目复盘">
    项目失败或成功后，类RCA分析识别影响结果的系统性因素，实现组织学习。
  </Card>
</CardGroup>

## 经典案例

在医疗保健领域，质量研究所在1999年里程碑报告《人非圣贤》之后将RCA作为核心患者安全实践推广。一个有据可查的案例涉及一家医院发生手术部位错误。表面分析会归咎于外科医生个人。RCA而是识别了系统性原因：令人困惑的手术标记协议、手术室的时间压力、以及质疑高级外科医生的文化。

医院实施了系统性改变：通用手术部位标记协议、要求口头验证的"术前暂停"政策、以及允许任何团队成员如果有问题可以暂停手术的"红旗"政策。实施后，手术部位错误降到接近零——不是个人更小心了，而是系统使错误几乎不可能发生。

在技术领域，Etsy在2013年停机两小时后进行了RCA。他们的分析显示，虽然触发因素是部署的代码更改，但根本原因是不充分的金丝雀测试和不清楚的回滚程序。他们实施了自动金丝雀分析并简化了回滚流程，使未来事件不太可能导致长时间停机。

## 边界与失效场景

<AccordionGroup>
  <Accordion title="需要时间和资源">
    Proper RCA需要专门的时间，有时还需要外部专业知识。在压力下"继续前进"的组织通常会跳过防止复发所需的深度。
  </Accordion>

  <Accordion title="可能识别错误的原因">
    没有数据验证，RCA团队通常会聚集在最明显或政治上最方便的原因上，而不是实际的原因。始终用证据验证。
  </Accordion>

  <Accordion title="修复根本原因可能很昂贵">
    系统性修复通常需要流程更改、新工具或培训。成本看起来与单个事件不成比例，使得在不了解累积影响的情况下很难证明其合理性。
  </Accordion>
</AccordionGroup>

## 常见误区

<AccordionGroup>
  <Accordion title="它只用于失败">
    RCA同样适用于成功。理解为什么某事运作良好揭示了什么需要在你的系统和流程中保留和放大。
  </Accordion>

  <Accordion title="一种技术适合所有问题">
    五问法适用于简单的因果链，但对复杂多因素问题无效。鱼骨图有助于映射复杂问题，但需要额外验证。根据问题使用正确的工具。
  </Accordion>

  <Accordion title="找到根本原因就结束流程">
    RCA只有在随后采取纠正措施才有价值。识别根本原因而不实施修复是学术练习，不是问题解决。
  </Accordion>
</AccordionGroup>

## 相关概念

根本原因分析与特定技术和更广泛的问题解决框架相关。

<CardGroup cols={3}>
  <Card title="五问法">
    [五问法](/zh/methods/five-whys)是最常用的RCA技术之一，使用迭代提问深入根本原因。
  </Card>

  <Card title="鱼骨图">
    [鱼骨图](/zh/methods/fishbone-diagram)是另一种将潜在原因可视化的RCA技术。
  </Card>

  <Card title="第一性原理思维">
    [第一性原理思维](/zh/thinking/first-principles-thinking)通过鼓励分解为基本真理为RCA提供了哲学基础。
  </Card>
</CardGroup>

## 一句话总结

<Tip>
  治疗症状是为了缓解，治疗根本原因是为了治愈——投入时间找到基本原因，你的修复将持续下去。
</Tip>