想像一個一直回來報到的服務事故。某類設定變更上線後，服務偶爾會在高流量時段失敗；rollback 通常能救回來，但大多數變更其實沒事。監控有時晚了一步，change review 也沒有穩定攔住這種風險。

把同一份 incident 丟給四個人，答案可能長得完全不一樣：

  • 用 5 Whys 的人會一路追到「為什麼這個設定能進 production」。
  • 畫 Fishbone 的人會先把 people、process、technology、environment 等候選原因攤開。
  • 做可靠度分析的人可能先定義 top event，再看哪些條件必須一起成立。
  • 做 system safety 的人會看 constraints、control actions 與 feedback，問系統為什麼沒有把狀態維持在安全範圍內。

這些答案未必互相衝突。差異常常更早就出現了：每個人其實先替問題選了一種「因果形狀」。一條鏈、候選原因空間、AND/OR 組合、控制結構，會讓不同關係浮出來，也會讓不同關係暫時消失。

RCA 的麻煩就在這裡。工具不是空白容器；你一選表示法，分析視野就已經被切了一刀。

先別急著選工具，先看問題長什麼樣子

「5 Whys、Fishbone 還是 FTA？」通常不是第一個問題。比較早該確認的是：目前最需要理解的，是哪一種關係？

有時是一段可追蹤的局部機制；有時連候選原因都還沒展開；有時失敗必須由幾個條件共同構成。再往外走，問題可能落在多層 control structure、互相衝突的 problem definition，或帶有 feedback 與 delay 的動態系統。

這篇文章把選擇順序整理成：

Problem shape → Representation → Method → Escalation

這是編輯上的 synthesis，不是任何標準組織發布的官方 taxonomy。它也不是「初階工具一路升級到高階工具」的階梯。範圍清楚、機制單純的故障，5 Whys 可能就夠；如果事故來自多層控制與互動，繼續把 why chain 拉長，反而可能把重要關係壓扁。

方法選擇圖：依六種問題形狀分別對應 5 Whys、Fishbone、FTA、STPA/CAST、SSM/PSM/Cognitive Mapping 與 CLD，並標示何時應切換或疊加方法。

5 Whys 和 Fishbone，差別先在「深度」與「廣度」

兩者常一起出現在 RCA 工具箱，但起手式不同。

5 Whys：手上已經有一條線，就沿著它往下追

Toyota 長期把反覆追問 why 放在 kaizen 與問題解決的傳統裡。重點並不是一定要問滿五次，而是避免停在第一層症狀。Toyota 的材料與 Lean Enterprise Institute 的說明都支持這種用法。

放到前面的 incident，可以這樣追：

服務為什麼失敗？因為某個設定在高負載下觸發錯誤。
為什麼這個設定能上線？因為 validation 沒有覆蓋那個狀態。
為什麼 validation 沒覆蓋？因為 change check 只測一般流量條件。
為什麼高負載不在必要條件裡？因為測試與變更標準沒有把它編進 operating constraint。

這條鏈把「服務掛了」往設計與流程推進了一層，已經足以產生可修的工作。但它只會沿著你選中的 branch 前進。監控延遲、容量邊界、第三方依賴或交接問題如果在另一條 branch 上，5 Whys 不會自動幫你把它們撈出來。

因此，5 Whys 最適合的是：局部機制已經大致看得到，只是不想停在表面症狀。

Fishbone：還不知道該追哪條線，就先把搜尋空間打開

Fishbone Diagram（Ishikawa / Cause-and-Effect Diagram）先做的是候選原因展開。ASQ把它定位為辨認許多可能原因、分類想法、支援結構化 brainstorming 的工具。

同一個事故可以先分成幾個 branch：

  • People：reviewer 經驗、交接、ownership。
  • Process：change workflow、test conditions、rollback criteria。
  • Technology：configuration validation、monitoring、capacity limits。
  • Environment：traffic profile、dependent services、deployment timing。

這張圖的用處，是避免團隊太快把第一個合理故事當成答案。骨頭上的項目仍然只是 candidate cause；它不會自動證明因果，也不會替你排出優先順序。

問題5 WhysFishbone
主要動作沿一條局部鏈往下追向外展開候選原因
適合的起點已看到一段可追蹤機制還需要擴大原因搜尋空間
常見誤用把第一條鏈當成唯一真相把 brainstorm 結果當成已驗證因果
該換表示法的訊號分支、互動或組合開始主導候選因素之間有 AND/OR 或動態依賴

如果 A 單獨出現不會出事，必須 A 和 B 同時成立才會產生結果，接下來需要的就不是更長的 why chain，也不是更多分類。

當失敗要靠幾個條件湊在一起

Fault Tree Analysis（FTA）先定義一個明確的 top event，再往下表示哪些事件或條件如何組合才會讓它發生。NASA 的 Fault Tree Handbook with Aerospace Applications把 FTA 描述為 top-down failure analysis，AND / OR 邏輯常被用來表示組合關係。

把 top event 定成：

「設定變更後，服務在高峰期無法提供請求。」

一個很小的 fault-tree fragment 就可能是：

  • Top event 發生，需要：
    • A：高風險設定進入 production，AND
    • B：系統進入會觸發錯誤的 load region。
  • A 可能因為 validation 沒攔住，OR change review 沒辨識風險。
  • B 可能來自正常尖峰，OR 上游 retry 帶來額外壓力。

這和 Fishbone 的差異不在「圖比較工程」，而在於你必須說清楚邏輯。Load、configuration、review 都可以出現在 Fishbone；到了 FTA，你得判斷它們是替代條件、共同必要條件，還是根本不該放進這棵樹。

FTA 也有使用前提。Top event 與分析邊界要先被定義，而且推理會在這個邊界內進行。若真正主導事故的是 management decision、control signal、delayed feedback 或跨層 interaction，event logic 仍可以畫，但它開始抓不住問題的主要結構。

當事故要看的是 control structure

STPA 與 CAST 來自 MIT 的 systems-theoretic safety 方法體系；MIT Partnership for Systems Approaches to Safety and Security提供相關 handbooks 與教材。

回到同一個服務事故。這次不先問「哪個設定錯了」，而是把視角往 control structure 拉：

哪個 safety constraint 本來應該阻止這個設定在這種 load condition 下被啟用？誰或哪個元件負責施加限制？控制者收到的 feedback 是否完整而且及時？管理流程有沒有讓 risk signal 在決策鏈中消失？

於是原本很難塞進單一 why chain 的情況會變得可見：validation 存在，但不知道 production 當下的真實 load state；reviewer 有審查，卻拿不到完整 risk signal；monitoring 能報錯，但 feedback 太慢；甚至每個 component 各自都按照設計運作，組合後仍然進入 unsafe state。

STPA 和 CAST 也要分開看。STPA 主要用於主動、前瞻的 hazard analysis；CAST 更直接用在事故或事件發生之後，追查 control structure 如何讓結果成為可能。

這並不代表 incident 一複雜就該上 STPA。局部、可重現，而且已經能被清楚機制解釋的 defect，用較輕的方法處理通常比較划算。STPA / CAST 的必要性會在 safety、control、組織與 interaction 本身就是因果結構時上升。

RCA 報告寫完了，問題可能還沒結束

2020 年一篇針對 patient safety RCA 的 systematic review整理到一個不太舒服的結果：RCA 常能找出 contributing factors，但後續措施能否穩定轉成可測量的 patient-safety 改善，證據有限而且不一致。

這個研究只支持醫療與 patient safety 範圍內的判斷，不能拿來宣稱「RCA 在所有產業都沒用」。它比較有價值的地方，是提醒我們不要把「因果故事寫完整」直接當成「預防復發已經成立」。

實務上，以下狀況可以視為 representation 開始撐不住的訊號：

  • 5 Whys 一路長出多條同樣合理的 branch。
  • Fishbone 上的 candidate 不是各自獨立，而要組合才會出事。
  • Fault tree 對 events 說得通，卻很難表示 control、feedback 或跨層 decision。
  • 部門之間連 problem boundary、成功條件都不同意。
  • cause 與 effect 會互相強化，還伴隨重要 delay。

前三種通常還有一個大致穩定的問題，只是因果結構變豐富了。後兩種則會動到問題本身的定義；這時候繼續追「root cause」可能太早。

如果大家講的「失敗」根本不是同一件事

假設公司丟下一句：「AI adoption 失敗了，找 root cause。」管理層可能在看 adoption rate，一線員工覺得工作流程變慢，法務關心資料與責任風險，工程團隊在處理模型品質和 integration，財務則看到成本上升但 productivity return 還不明顯。

此時若直接問「為什麼 adoption rate 低？」，等於先把管理層的指標選成了 problem definition。

Rittel 與 Webber在 1973 年談 wicked problems 時指出，這類社會規劃問題通常沒有一次定案的 formulation、明確 stopping rule 或客觀 final solution。意思不是「無解」，而是 problem understanding 與 intervention 會互相影響，不同 stakeholder 也可能用不同價值判斷結果。

SSM：先整理 problem situation

Checkland 對 Soft Systems Methodology 的回顧把 SSM 放在複雜的人類活動 problem situations 裡。它不負責像 FTA 那樣證明一套 failure logic，而是把不同 worldviews、目的與可行改變帶到桌面上，讓團隊能學習並採取行動。

在 AI adoption 這個例子裡，起手問題可能會變成：我們要改善的是 adoption、task performance、risk-adjusted value，還是某一類 workflow？誰有權定義 success？哪些限制來自技術，哪些來自 policy、responsibility、incentive 或 organisational design？

PSM：一個問題可以需要不只一種方法

Mingers 與 Rosenhead 對 Problem Structuring Methods 的回顧討論 messy、complex problem situations，以及方法的選擇與組合。這讓分析可以先用 SSM 把 problem situation 理清，再把其中已經有穩定 boundary 與 objective 的子問題交給較硬的分析方法。

Cognitive Mapping：先把 belief structure 畫出來

Eden 對 cognitive maps 的研究用它來協助 structuring messy issues。假設團隊認為：

AI 品質不穩 → 員工不信任 → 使用率下降 → 實際回饋變少 → 產品改善更慢

這張 map 的價值在於把原本藏在腦中的 assumption 外顯，讓人可以討論、挑戰、比較。箭頭本身仍是 actor 或 group 對因果的理解，不會因為被畫成圖就變成已驗證的 causal fact。

Cognitive map 和下一節的 Causal Loop Diagram 也不是同一種東西。它們都可能有 box 和 arrow，但要表示的結構不同。

當結果會繞回來改變原因

System dynamics 裡的 Causal Loop Diagram（CLD）用來表示 feedback structure。John Sterman 的 Business Dynamics 資料強調 causal links、polarity、feedback、delay，以及 causation 與 correlation 的區別。

沿用 AI adoption。可以先假設一個 reinforcing loop：

實際使用 ↑ → 實務經驗 ↑ → 高品質回饋 ↑ → 工具改善 ↑ → perceived usefulness ↑ → 實際使用 ↑

若起始使用很低，這組關係也可能往不利方向跑：使用少，累積的經驗與回饋少，改善變慢，perceived usefulness 繼續偏低，最後又壓低使用。

另一條可能的 loop 是：

導入要求 ↑ → 學習負擔 ↑ → 短期產能壓力 ↑ → 抵抗 ↑ → 使用 ↓

同時，學習或工具改善帶來的 productivity benefit 可能有 delay。管理者如果只看導入後第一、第二週，很容易把一個有延遲的動態系統讀成單向失敗。

CLD 會逼團隊把 feedback、方向與 delay 說清楚，但它畫的仍然是 causal hypothesis。決策若依賴某條 link，還是要另外找 evidence 驗證；diagram 本身不會把 correlation 升級成 causation。反過來，如果問題根本沒有重要 feedback 或 delay，硬加 CLD 只會讓簡單問題長出一圈 spaghetti。

實務上的選法：用最輕的表示法起步，壞掉再換

前面的工具可以整理成一張工作表，但不要把它讀成「初階到高階」排名：

你目前看到的問題形狀先考慮的表示法 / 方法該換或加方法的訊號
有一條可觀察的局部因果鏈5 Whys出現多條同樣合理的分支或 interaction
候選原因空間還太窄Fishbonecandidate 有 AND/OR 組合或 dynamic dependency
有明確 top event，且多條件共同造成結果FTAcontrol、feedback、跨層 interaction 比 event logic 更重要
safety / risk 來自 socio-technical control structureSTPA；事故後可用 CASTproblem boundary、objective 或 success definition 也開始有爭議
stakeholder 對問題與目標持不同 worldviewsSSM / PSM；Cognitive Mapping行為明顯受 feedback、polarity 與 delay 影響
系統裡有 reinforcing / balancing loops 與重要 delayCLD / system-dynamics inquiry關鍵 causal hypotheses 需要進一步用 evidence 驗證

這張表不是 universal standard，也不是互斥 decision tree。方法可以接在一起用：Fishbone 先展開搜尋空間，再對已經有證據支持的 local mechanism 做 5 Whys；FTA 先把 safety-critical top event 的 failure logic 說清楚，再用 STPA 看 fault tree 很難表示的 control relationship；SSM 或 cognitive mapping 先把跨部門爭議攤開，之後再對穩定下來的 subproblem 做較精確的因果分析。

選擇時有一個很實際的成本原則：能用較輕的表示法回答，就先不要把問題升級成大型 systems model。另一方面，只要工具開始逼你忽略 branch、把 interaction 壓成單一 event、把 worldview 當雜訊，或把 feedback 畫成單向箭頭，就該重新檢查 representation 是否還合身。

所以在問「Root Cause 是什麼？」之前，可以先問一句比較便宜也比較有用的：這個問題現在最需要被表示成什麼結構？

如果某個重要關係只能靠刪掉或扭曲，才能塞進你正在用的圖裡，問題未必是資料太亂。那通常就是換方法的時候。

References