> ## 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>
  **Category**: 方法<br />
  **Type**: 問題解決技術<br />
  **Origin**: 品質管理運動，1950年代，美國<br />
  **Also known as**: RCA、根本原因分析、原因分析
</Info>

<Note>
  **Quick Answer** —
  根本原因分析（RCA）是一系列用於識別問題根本原因的系統性方法。與修復直接症狀不同，RCA深入挖掘找到潛在原因，一旦解決就能防止復發。它在二戰後的製造業品質管理原則中發展而來，已成為醫療保健、軟體工程、航空和各行業事件管理的必備技能。
</Note>

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

根本原因分析是一個統稱，指用於識別問題或事件潛在原因的一系列技術。核心原則看似簡單：出了什麼問題，不要只修復可見的問題——首先找出為什麼會發生，然後修復那個。

症狀與原因之間的區別是根本性的。你觀察到的是症狀——一個bug、一次失敗、一個投訴。根本原因是症狀存在的潛在原因。治療症狀提供暫時的緩解；治療根本原因提供永久的解決方案。這個區別聽起來很明显，但在實踐中，組織經常把資源花在治療症狀上，而潛在的問題卻在惡化。

RCA通常遵循一個結構化過程：定義問題、收集資料、識別可能的原因、確定根本原因、實施糾正措施。識別原因的方法各不相同——有些使用特定的框架，如「五個為什麼」或魚骨圖，而有些使用更複雜的統計或系統思維方法。

> "如果你不消除根本原因，問題會復發。就是這麼簡單。" —— 豐田生產系統原則

RCA的價值超越了問題解決。嚴格執行根本原因分析的組織會建立關於失敗模式的機構知識，隨著時間推移變得更具彈性。每次properly進行的RCA都會增加對系統如何失敗以及如何防止失敗的了解。

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

* **入門**: 面對任何問題時，區分發生了什麼（症狀）和為什麼會發生（原因）。使用「五問法」技術一次深入一層，直到找到一個你可以實際處理的原因。

* **實踐者**: 使用魚骨圖映射問題空間以識別多個潛在原因，然後使用資料和實驗來確定哪些原因最重要。

* **進階**: 應用系統思維來識別造成重複問題模式的回饋循環和二階效應。對於具有多個相互作用故障的複雜系統，使用故障樹分析等技術。

## 起源

根本原因分析起源於二戰後美國的品質管理運動。受愛德華茲·戴明和約瑟夫·朱蘭工作的影響，日本製造商開始系統性地分析缺陷以提高品質。這種方法在1950年代和1960年代成熟，成為後來被稱為豐田生產系統的一部分。

「根本原因分析」這個術語本身在1990年代獲得更廣泛的使用，特別是在核工業和航空業在幾起重大事故後採用它之後。1979年的三哩島事故和1986年的挑戰者號災難都促使高風險行業加強對系統性根本原因分析的重視。

在軟體開發中，RCA在2000年代隨著DevOps和站點可靠性工程的興起而獲得重視。Google的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>

## 經典案例

在醫療保健領域，品質研究所將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-hant/methods/five-whys)是最常用的RCA技術之一，使用迭代提問深入根本原因。
  </Card>

  <Card title="魚骨圖">
    [魚骨圖](/zh-hant/methods/fishbone-diagram)是另一種將潛在原因可視化的RCA技術。
  </Card>

  <Card title="第一性原理思維">
    [第一性原理思維](/zh-hant/thinking/first-principles-thinking)透過鼓勵分解為基本真理為RCA提供了哲學基礎。
  </Card>
</CardGroup>

## 一句話總結

<Tip>
  治療症狀是為了緩解，治療根本原因是為了治癒——投入時間找到基本原因，你的修復將持續下去。
</Tip>