最近有位研發同學參與故障復盤，將他的分析發給我double check，發現部分的故障原因沒有太深入的挖掘，停留在了表面現象，導致后續制定的行動項可能治標不治本。這種現象其實還挺普遍，我們可以嘗試使用一種簡單有效的根因分析（RCA：root cause analysis）方法來更好做故障復盤：5個Why分析法（5 whys）。

方法概述^[1]：

5 Whys是一種反復詢問的技巧，用于探索特定問題背后的因果關系。該技術的主要目標是通過重復問題“為什么？”來確定缺陷或問題的根本原因每個答案構成下一個問題的基礎。名稱中的“5”源于對解決問題所需迭代次數的軼事觀察。

5個why方法故障復盤主要的思想

1. 拉長邏輯鏈條，找到深層原因

2. 拋棄主觀假設和邏輯陷阱

3. 分清現象與原因

4. 步步分析，不直接跳躍下結論

5. 原因永遠不在個人身上，不要將諸如“人為疏忽”，“沒有注意”作為根因

5個why方法主要步驟

1. 分解問題，找到現象[2]

2. 問5個why（注意這里的5是概數，可以小于5，也可以大于5），直到無法再問why，找到根因。

3. 從最后的答案反過來問，看邏輯鏈是否反向成立，進行驗證。

舉幾個例子來說明如何使用。這邊取1個經典案例及1個我參與過的歷史線上故障復盤案例舉例（當時復盤沒有使用5個why分析，所以我們可以看看區別）。

經典案例

現象：一個博物館的東邊外墻面上有非常嚴重的腐蝕，需要經常涂刷新的油漆。

淺顯的分析及措施：經過調查以后，你發現，原來博物館的清潔人員在洗墻的時候，用了一種高腐蝕度的清潔劑，這才導致了墻面的腐蝕。所以后續的措施是，在噴刷修補了這一次的墻面以后，要求清潔人員下次清洗墻面時換用低腐蝕度的清潔劑。

5個Why分析及措施：

第一個why：為什么這個清潔工要用高腐蝕度的清潔劑？

答：因為東邊的墻上經常有很多鳥糞粘著，用一般的清潔劑洗不干凈

第二個why：為什么東邊的墻上有很多鳥糞？

答：因為墻上有很多蜘蛛，而這些鳥以蜘蛛為食，所以經常在墻附近活動

第三個why：為什么墻上有很多蜘蛛？

答：因為墻上有很多小蟲子，而蜘蛛以這些小蟲子為食

第四個why：為什么墻上有很多小蟲子？

答：因為東面墻上有幾扇窗子，晚上，博物館里的光會從這里透出去，而這些趨光性很強的蟲子就被光吸引過來了。

所以解決方案是：在窗戶那里安裝遮光性很強的厚窗簾，每天太陽落山之前拉上窗簾。

好了，我們似乎拿到了根因及解決方案，我們反過來再推導一遍：

1. 厚窗簾拉上后趨光性很強的蟲子就不會被吸引【符合邏輯】

2. 趨光性很強的蟲子不再聚集，蜘蛛不會再來聚集【符合邏輯】

3. 蜘蛛不再來聚集，吃蜘蛛的鳥不再經常來活動【符合邏輯】

4. 吃蜘蛛的鳥不再經常來活動，東面的墻不再有很多鳥糞【符合邏輯】

5. 東面的墻不再有很多鳥糞，清潔工不需要用高腐蝕度的清潔劑【符合邏輯】

6. 不適用高腐蝕度的清潔劑，墻面不再總是被腐蝕【符合邏輯】

至此，我們確定拿到了根因及正確的解決方案。

故障復盤案例

現象：商戶使用銀行打款流水號查詢賬單發現交易記錄缺失

淺顯的分析及措施：（之前沒有使用5個why分析得到的結論）由于get(0)只拿到了部分數據，所以研發重新做代碼的全量get(0)分析。

5個Why分析及措施：

第一個why：為什么使用流水號查詢交易記錄有缺失？

答：因為客戶期望的是能用這個流水號查詢到多筆（天）賬單信息

第二個why：為什么同一個流水號有多筆（天）賬單信息？

答：因為銀行周六、周日休息，將合并周五、周六、周日賬單一并打款，生成同一個流水號，關聯到多筆（天）賬單信息

第三個why：為什么一個流水號關聯了多筆（天）賬單信息，系統沒有返回？

答：因為代碼內使用了get(0)方法，只取了第一項數據

第四個why：為什么代碼內使用了get(0)方法？

答：因為get(0)方法在編碼中沒有被禁止/提醒，研發在開發中沒有注意到風險

所以解決方案是：在研發架構層面宣導get(0)風險，使用明確的業務語義來定義代碼處理替換get(0)，在代碼掃描工具中提醒get(0)屬于高風險編碼。

反過來推導驗證：

1. 研發架構層面了解get(0)風險，在代碼提交時被提醒為高風險編碼，研發會謹慎使用get(0)或者避免使用get(0)【符合邏輯】

2. 所有研發謹慎使用get(0)，如果選擇繼續使用get(0)，那么在提交查詢賬單的編碼中，工具提示風險【符合邏輯】

3. 工具提示get(0)風險后，在設計編碼時，研發關注業務場景是否存在一對多的場景【符合邏輯】

4. 研發關注業務場景存在一對多的場景，一定程度上更有可能分析和感知到銀行合并打款場景【符合邏輯】

反向推導邏輯鏈正確，解決方案成立，且該解決方案沒有歸結于人的處理，而歸結于架構治理及工具。而之前的解決方案僅僅關注了get(0)在當時代碼里面的風險，并不持續跟蹤，所以僅僅治標未治本。