本篇參考：
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端的同事也應該給予一些技術的支援和建議。
總結：不是所有的問題都一定適應這種模型分析，本質上這種情況適用於品質提升打破砂鍋問到底的場景。以上的整理並不一定完全的合理，只是用於自己更好的瞭解這個步驟分析。篇中有錯誤地方歡迎指出，有不懂歡迎留言。