根本原因分析

​

什麼是根本原因分析？

根本原因分析是一個統稱，指用於識別問題或事件潛在原因的一系列技術。核心原則看似簡單：出了什麼問題，不要只修復可見的問題——首先找出為什麼會發生，然後修復那個。 症狀與原因之間的區別是根本性的。你觀察到的是症狀——一個bug、一次失敗、一個投訴。根本原因是症狀存在的潛在原因。治療症狀提供暫時的緩解；治療根本原因提供永久的解決方案。這個區別聽起來很明显，但在實踐中，組織經常把資源花在治療症狀上，而潛在的問題卻在惡化。 RCA通常遵循一個結構化過程：定義問題、收集資料、識別可能的原因、確定根本原因、實施糾正措施。識別原因的方法各不相同——有些使用特定的框架，如「五個為什麼」或魚骨圖，而有些使用更複雜的統計或系統思維方法。

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

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

​

根本原因分析的三層理解

• 入門: 面對任何問題時，區分發生了什麼（症狀）和為什麼會發生（原因）。使用「五問法」技術一次深入一層，直到找到一個你可以實際處理的原因。
• 實踐者: 使用魚骨圖映射問題空間以識別多個潛在原因，然後使用資料和實驗來確定哪些原因最重要。
• 進階: 應用系統思維來識別造成重複問題模式的回饋循環和二階效應。對於具有多個相互作用故障的複雜系統，使用故障樹分析等技術。

​

起源

根本原因分析起源於二戰後美國的品質管理運動。受愛德華茲·戴明和約瑟夫·朱蘭工作的影響，日本製造商開始系統性地分析缺陷以提高品質。這種方法在1950年代和1960年代成熟，成為後來被稱為豐田生產系統的一部分。 「根本原因分析」這個術語本身在1990年代獲得更廣泛的使用，特別是在核工業和航空業在幾起重大事故後採用它之後。1979年的三哩島事故和1986年的挑戰者號災難都促使高風險行業加強對系統性根本原因分析的重視。 在軟體開發中，RCA在2000年代隨著DevOps和站點可靠性工程的興起而獲得重視。Google的SRE書籍和Netflix的混沌工程實踐將RCA formalize為管理事件和提高系統可靠性的核心實踐。

​

核心要點

​

應用場景

​

經典案例

在醫療保健領域，品質研究所將RCA作為核心患者安全實踐推廣。一個有據可查的案例涉及一家醫院發生手術部位錯誤。表面分析會責怪外科醫生個人。RCA則識別了系統性原因：令人困惑的手術標記協議、手術室的時間壓力、以及質疑資深外科醫生的文化。 醫院實施了系統性改變：通用手術部位標記協議、要求口頭驗證的「術前暫停」政策、以及允許任何團隊成員如果有問題可以暫停手術的「紅旗」政策。實施後，手術部位錯誤降到接近零——不是個人更小心了，而是系統使錯誤幾乎不可能發生。 在技術領域，Etsy在2013年停機兩小時後進行了RCA。他們的分析顯示，雖然觸發因素是部署的代碼更改，但根本原因是不充分的金絲雀測試和不清楚的回滾程序。他們實施了自動金絲雀分析並簡化了回滾流程，使未來事件不太可能導致長時間停機。

​

邊界與失效場景

​

常見誤區

​

相關概念

根本原因分析與特定技術和更廣泛��問題解決框架相關。

​

一句話總結