本篇參考：
https://max.book118.com/html/2017/1126/141669829.shtm
https://baike.baidu.com/item/5why%E5%88%86%E6%9E%90%E6%B3%95/575907
上課在項目質量管理的章節的管理質量中提出了根本原因分析工具，提了一下5 why分析法，感覺工作中這種思想還是會用到，所以簡單查閱以後，閒聊一下5- why root cause分析法，並且以一個相關的項目例子來帶入對自己也更好的瞭解。
5 why root cause分析
我們在做項目時，通常會遇見客戶或者自己查到的問題，遇見問題以後，我們便會找到root cause，進行快速的緊急處理。當然，有的場景，這種root cause識別只是指標的對策，無法從根本上抑制這種問題以後繼續發生。以後出現這種情況，包括但不限於繼續在手動修改數據或者定期執行腳本修復等等。這種儘管可以解決問題，但是客戶總歸是不開心或者不一定買賬的，這種root cause也不是真正意義上打破砂鍋問到底的root cause。
5 why分析法主要用於在品質問題分析和解決上，所謂5why分析法，又稱“5問法”，也就是對一個問題點連續以5個“爲什麼”來自問，以追究其根本原因。雖爲5個爲什麼，但使用時不限定只做“5次爲什麼的探討”，主要是必須找到根本原因爲止，有時可能只要幾次，有時也許要十幾次，5why法的關鍵所在：鼓勵解決問題的人要努力避開主觀或自負的假設和邏輯陷阱，從結果着手，沿着因果關係鏈條，順藤摸瓜，直至找出原有問題的根本原因。5 why分析法可以通過4步來進行分解和操作。
一. 瞭解問題/ 現狀
針對當前的問題，我們需要先了解現狀，通常可以分成以下的幾個步驟：
1. 識別/確認問題： 在最開始的階段，你可能會得到一定的情報，但是無法得到詳細的描述。這時候更關注的是我知道什麼。比如當前頁面崩了或者數據沒有獲取到。
2. 澄清(clarify)問題：在第一步的基礎上，這步需要獲取更精確的情報，而進行問題澄清繼續提問。比如當前操作的步驟，正常的操作會發生什麼？現在發生了什麼？比如進行一個表單的提交，有一些條件沒有滿足，正常操作應該是在本頁面提示哪些有問題，現在是直接跳轉到共用的error頁面了。
3. 分解(breakdown)問題：如果當前的問題，不是一個小的維度問題，需要進行更細化更獨立元素，則需要進行問題的分解，比如關於當前的問題，我還知道什麼？還有什麼子問題嗎？比如我們在做多系統交互集成時，出現了問題，澄清問題以後，可能還需要進一步的分解當前問題，纔可以定位到哪一方的具體問題。
4. 查找原因要點(Point Of Cause)：既然我們已經將一個問題分解成更細化的元素，這個階段我們就需要找到這個問題原因的實際要點。爲了確認root cause有必要進行逆向追溯，比如我需要看什麼？誰可能更瞭解這個問題的信息？
5. 把握問題的傾向和特徵： 什麼時間？在哪？ 什麼頻率？等等信息。比如這個問題什麼時間發生的？ 怎麼操作的？ 錯誤頻率什麼樣是否可以復現等等。
注意點： 在我們問 why以前，瞭解上述問題很有必要
二. 調查原因
1. 識別並確認異常現象的直接原因。問題復現時，如果原因是可見的，驗證它。如果原因是不可見的，考慮潛在原因並覈實最可能的原因。這裏可以問：
- 爲什麼會發生這個問題？
- 我能否看到這個問題的直接原因？
- 如果不能看到直接原因？ 我懷疑什麼是潛在原因？
- 怎麼覈實最可能的潛在原因？
- 怎麼確認最直接原因？
2. 爲了原因/ 影響關係使用 5 why調查方法，提出疑問。這裏可以問：
- 我們選定的root cause能否預防這個問題再次發生？
- 如果無法預防的情況下，能否發現下一個階段的原因？
- 如果發現不了下一個階段原因， 能否懷疑什麼是潛在原因？
- 如何檢查和確認下一階段原因？
- 處理這個水平(下一階段)原因，能否預防這個問題再次發生？
針對必須處理以防止再發生的原因處停止的情況下問，需要問：
- 我已經找到問題的根本原因了嗎？
- 解決這個問題能否預防再發生？
- 這個原因是否跟事實爲依據的原因/影響有聯繫？
- 這個鏈通過 'therefore'測試了嗎？
- 如果再問爲什麼，我還會遇到什麼問題嗎？
除此之外，確認已經使用“5個爲什麼”調查方法來回答這些問題。
- 爲什麼我們有了這個問題？
- 爲什麼問題會到達顧客處？
- 爲什麼我們的系統允許問題發生？
三. 問題糾正措施
1. 實施糾正措施，至少是臨時措施。這裏需要根據糾正措施還是臨時措施來問：
- 臨時措施會遏止問題直到永久解決措施能被實施嗎？
- 糾正措施會防止問題發生嗎？
四. 防止錯誤預防
1. 防止root cause對策
2. 記錄教訓
demo引入
上面的概念都比較偏向於客觀概念，很難讀進去以及瞭解，下面以一個例子融入進去進行更好的通過 5 why 方式去穿插。
上圖中是我們的一個項目的集成流向圖。主要的需求爲：
SF爲某些表的源數據，比如SF爲account的source of truth，前端系統想要使用account信息只能通過SF來同步，SF的account數據變化了也要實時的同步到前端系統。前端會作爲一些自定義表的數據入口，然後通過 rest 調用中間件，中間件將報文整合以後，通過標準salesforce的REST API插入到salesforce,後續實現報表等需求。
每個平臺都有一個 team lead，根據約定的開始幹活了，等到客戶UAT的時候，發現了一個問題： 前端數據做了數據(包含父子層級)以後，當在前端針對這個父層級的數據繼續創建子以後，報錯了。報錯內容： 你所插入的數據，父數據在SF中不存在。你作爲項目經理，如何通過5 why方式去找到 root cause並且去更好的給出方案？
第一部分，先了解問題和現狀：
1. 根據這個報錯，先澄清問題。正常現象應該是第一次已經發送了父子數據，SF端已經包含了父的數據，第二次直接創建子數據會關聯到SF父數據，可以正常創建。實際問題是，當前端創建子數據時報錯，SF端父數據不存在。
2. 分解一下問題。既然涉及到3端的系統，先詢問一下SF的lead，這條父記錄是否在SF端生成，是否按照前端的描述，SF端沒有父數據。詢問一下前端，除了這條數據是否還包括其他的數據？父子層級操作以前是否有什麼特殊的報錯信息等。
3. 查找問題要點(POC)。SF端反饋父端數據以及第一次子表數據已經順利進入到SF端數據庫了，不存在前端說的不存在場景。中間件端查看報文確實前端發送的報文中不包含父表數據ID，同時中間件端反饋沒有通過LOG查看到中間件端沒有訂閱到這條數據的ID相關的數據消息。
4. 問題特徵： 偶發性，不可復現。
第二部分，調查原因：
通過第一部分了解問題現狀以後，我們發現 前端發送了父子表給SF端，SF端收到了，但是前端沒有接收到SF端父子數據的ID，然後第二次創建子時，獲取不到父的數據導致了報錯。
1. 識別並確認異常現象的直接原因。直接原因是不可見的，潛在原因最可能的是： 當前端數據通過REST插入到SF以後，SF發送了 push topic，中間件會將ID信息再給掛到前端DB指定數據。但是 push topic因爲SF國內沒有服務器，會有延時，導致偶爾不會實時的廣播出去，或者中間件端握手失敗。前端獲取到這條數據ID就會有延遲，在這個期間，再創建子數據時，就會報錯，因爲這條數據的ID還沒有回寫到前端。
2. 使用 5 why調查方法：這個選定的 root cause能否預防問題發生？不能，客戶不會接受因爲產品限制導致的這種偶發性的問題。如果不能情況下，我們想一下下一階段的root cause，前端在做這個以前，需要先進行一下validation check，如果沒有，則不執行，或者延後執行。繼續思考，這個 root cause能否預防問題發生？答案是還是不能。因爲如果 push topic半天才回來或者掛了今天就沒有，但是這條數據着急，終端用戶會很着急，是一個workaround方案，但是用戶不一定會採納這個建議。繼續思考下一個階段的 root cause， ID這種信息，中間件通過rest api調用成功以後，就可以獲取到，這時就直接返回給前臺，前臺解析然後更新到DB，就可以不用 push topic發送ID信息，這樣就可以大概率減輕問題發生。root cause能否預防問題發生？ 貌似可以。
第三部分，問題糾正：
糾正措施：排期讓中間件的response body修改一下，將父子文件的ID作爲報文傳回。前端修改一下解析部分，直接將ID更新到DB中，push topic只用於將 source of truth數據傳遞。
臨時措施：有問題的情況下，AO先手動跑腳本保證數據正常運行。畢竟數據量不大，而且修改難度不高，不會block住後續流程運行。
第四部分，防止錯誤預防：
此問題更多是中間件的team member不太清楚rest api的文檔內容，在解析處沒有思考到直接傳回，而是使用通用的push topic方式去接收，儘管省了effort，但是容易導致這種性能問題。SF端的同事也應該給予一些技術的支持和建議。
總結：不是所有的問題都一定適應這種模型分析，本質上這種情況適用於品質提升打破砂鍋問到底的場景。以上的整理並不一定完全的合理，只是用於自己更好的瞭解這個步驟分析。篇中有錯誤地方歡迎指出，有不懂歡迎留言。