五個為什麼（5 Whys）

🎯問題定義 #

不帶形容詞、可測量的一句話

開頭不是「部署經常出問題」，而是帶著數字和期間的句子：「最近 4 週 12 次部署中有 3 次被回滾」。問題陳述一模糊，從第一個「為什麼」起，與會者就在各自分析不同的問題。一次五個為什麼只處理一個事件，把多個事件攪在一起，原因也會被攪爛。

為什麼 1 #

直接原因：那一刻發生了什麼

第一個「為什麼」的答案大多是看得見的技術或物理事實，例如「遷移腳本執行失敗了」。如果這裡冒出多個答案，挑貢獻最大的那一個，其餘拆成單獨的鏈條另行處理。這一層的答案必須能用日誌、紀錄、重現立即驗證。

為什麼 2 #

那個直接原因為什麼會發生

從第二個開始，答案從事實轉向條件，比如「測試環境沒有和正式環境一致的資料」。「好像是」從這裡開始混進來，所以在每個答案旁邊寫上確認方法，確認之前不下探到下一個「為什麼」。搭在猜測之上的第三個「為什麼」，全都是白費功夫。

為什麼 3 #

那個條件為什麼一直被放任

到第三個左右，個人的行為很容易登場：「負責人跳過了檢查」。想在這裡停下的誘惑最大。一旦出現人的失誤，就換個問法：「為什麼這個失誤在結構上是可能的」「為什麼失誤沒有被攔住」。允許失誤發生的系統，才是下一個「為什麼」的對象。

為什麼 4 #

結構與流程缺陷浮出水面的一層

鏈條走得順的話，到第四個左右，答案就不再是某個具體事件，而是可重複的模式：「檢查清單裡沒有這一項」「根本不存在負責這項驗證的環節」。如果答案仍然是某個人或某一天的特殊情況，說明鏈條走岔了，回到為什麼 2 或 3，重新選一條岔路。

🧨為什麼 5 = 根本原因候選 #

修好它就能擋住復發的那個點

根本原因的判定標準不是深度而是效果：把它修好，同一族的問題是否就不再發生。用反向測試來確認：從為什麼 5 開始，用「所以」一路倒推，能自然地接回問題陳述，鏈條就成立。湊滿五問不是目的，第三問就到了，就在第三問停下。

在哪裡停下 #

觸到可控的流程就結束

無止境往下鑽的鏈條不是分析，是逃避。停下的位置，是我們團隊能控制的最深一層流程。答案變成「景氣不好」「人性使然」這類搆不著的東西時，往上退一層，把那裡定為根本原因。控制範圍之外的原因不是修理對象，而是要設計成能扛住的前提條件。

🛠️制定對策 #

要麼消除原因，要麼吸收失誤

對策有兩種：把原因本身消除，以及即使原因還在也不至於釀成事故的緩衝裝置。「多加注意」「加強教育訓練」不是對策，是願望；必須是不依賴人類記憶的結構改動（自動化、改預設值、強制檢查）。每條對策會帶來的新副作用，也在這個階段一併寫下。

對策驗證 1：復發指標 #

定好用數字觀察效果的期限

在套用對策之前，先定好觀察什麼、觀察多久才算成功，例如「上線後 8 週內同類型回滾 0 次」。沒有指標和期限就關閉的五個為什麼，下次事故時只能從頭再來。真的復發了，先懷疑原因診斷錯了，再懷疑對策失效。

對策驗證 2：反向閱讀 #

用「所以」測試稽核整條鏈

在敲定對策之前，把整條鏈倒過來讀一遍。從根本原因出發，用「所以」逐級往上接，句子讀起來彆扭的地方，就是邏輯跳躍藏身之處。請第三方反向讀一遍，是最便宜也最快的稽核：寫的人看不見自己的跳躍。

⚠️常見陷阱 #

毀掉追問鏈的三個習慣

五個為什麼淪為走過場的儀式，原因不在工具而在運用。停在怪人身上、滿足於第一個答案、用猜測銜接，這三樣佔了失敗的大宗。開會前把這三條作為明確規則公告出來，鏈條的品質就會不一樣。

陷阱 1：停在怪罪個人 #

出現「誰」的時候，才走了一半

「新人失誤了」不可能是根本原因：那個人明天離職，同樣的事故還是會發生。名字一出現，就把問題拉回結構：為什麼這個失誤能穿過整個系統？免責（blameless）原則不是仁慈問題，而是準確性問題：一旦預感會被處罰，從下一次事故起，資訊就開始躲起來。

陷阱 2：滿足於第一個答案 #

聽起來合理的答案最危險

第一個冒出來的合理答案，多半是症狀的換個說法，或者大家早就相信的假設。在每一層問一次「還有別的解釋嗎」，鏈條就能加深一層。尤其當答案在開會 5 分鐘內就全票通過時，要起疑心：未經驗證的共識不是分析，是記憶。

陷阱 3：不經驗證就銜接 #

假設串成的鏈條必然崩塌

每個「為什麼」的答案，都必須有資料、日誌、當事人確認三者之一作支撐。哪怕只有一環是猜測，它下面的一切都立在沙灘上。出現無法確認的答案時，先停鏈，從確認做起。五個為什麼不是必須在一場會議內結束的儀式，而是允許在確認之間花上幾天的調查。

🌿原因分岔時 #

不再是鏈條，而是一棵樹

現實的問題往往不止一個原因。一個「為什麼」冒出兩個以上答案時，不要硬選一個，按岔路各分一條鏈。但不必把每條岔路挖到同樣深：先挖貢獻最大的那條，其餘明確標註「暫緩」。分岔的紀錄本身，就是下次類似事故的地圖。