5whys分析法在美團工程師中的實踐
前言
網站的質量和穩定性對于用戶和公司來說至關重要，但是在網站的快速發展過程中，由于各種原因導致事故不可避免的發生，這些大大小小的事故對公司難免 會造成一些負面的影響，為了避免同類事故的再次發生，美團的工程師們從事故中不斷學習，對每次事故進行深入分析和總結，形成了一種Casestudy文 化，并結合一套科學的分析方法-5whys分析法，深入分析事故背后的根本原因和流程漏洞，使得事故發生的頻率大大降低。
在本文中，首先對5whys分析法的進行簡單介紹，然后再結合美團工程師Casestudy的案例去分享這套分析法的在美團的實踐。
5whys分析法
5whys分析法，又名why-why分析法，它是根本原因分析（Root Cause Analysis） 的一種具體方法，適用于去分析一些簡單和難度適中的問題。簡單的說，就是針對問題持續的問5個為什么(通常需要至少5個“為什么”，但5個why不是說一 定就是5個，可能是1個，也可能是10都沒有抓到根原)，通過這樣一種分析思路，能很快找到問題深層次的根本原因以及工作流程上的漏洞，并據此再制定預防 措施，防止問題重新出現或再次發生，大大降低解決問題的成本。
在美團，5whys分析法作為每個工程師需要掌握的一種工作方法，已經廣泛應用到Casestudy的原因分析中去。
利用5why分析法來進行Casestudy原因分析的幾個步驟
Step 1：對事故進行詳細描述
“If I had an hour to save the world,I would spend 59 minutes defining the problem and one minute finding solutions.”
– Albert Einstein
對于事故進行定義和描述比較重要，這一步不可省略。在描述事故時，我們基于5W2H（What，Who，Where，When，Why，How，How much）分析法來對事故進行描述，說清楚事故發生的時間，地點，發現人，怎樣解決的，解決的時間等等。
- What：描述下發生了什么問題。
- Who：描述下責任人是誰，誰發現的問題，誰解決的問題。
- Where：描述下在哪里發現的事故。
- When：描述下事故的時間因素，什么時候發現的事故，什么時間解決的事故。
- Why：描述下為什么是個事故，強調事故的影響。
- How：描述下事故是怎樣被解決的。
- How much：描述下事故的可量化的影響范圍和造成的損失，影響了多少用戶，造成了多少損失等等。 </ul>
Step 2：提問：為什么這問題會發生？
識別并確認導致當前問題發生的直接原因。如果原因是可見的，驗證它。如果原因是不可見的，考慮潛在原因并核實最可能的原因。
Step 3：檢驗上一步中發現的原因是否是根本原因？
檢查上一步中的回答的原因是否是導致事故的根本原因，如果不是，則重復Step2和Step3，直至找到事故發生的根本原因為止，最終通過這樣一個 過程建立一個通向根本原因的原因/效果關系鏈。這個過程一般需要持續5次為什么（可能少于或多于5個），這也是5whys分析法名字的由來。
Step 4：找到問題發生的根本原因，制定執行計劃并修復
找到問題發生的根本原因后，采取明確的措施和手段去處理問題，預防和避免類似問題的再次發生。對于采取的糾正措施和手段，需要問問“采取后能否避免問題的再次發生”，如果不能，再找到其他的解決之道。
案例分析
2014年某月某日，某內部App ios版應用相關負責人小美接到大量用戶投訴，ios的App啟動時出現閃退現象，導致大量用戶不能進入應用，雖說接到反饋后及時修復，但還是造成了一些不良的影響，針對此次事故，領導要求對事故進行總結，要求深入分析事故的原因。
小美基于5W2H分析法先對事故進行描述：
事故起止時間：2014年某月某日 10時30分-2014年某月某日 10時40分
責任人：小美
事故詳情：小美對此次事故進行了詳細描述，包含整個事故經過的時間、事件，在什么時間節點什么人做了什么事，誰發現的問題，誰解決的問題，怎樣解決的問題。
影響范圍：此次事故造成的影響和損失。
然后小美再結合5whys分析法中的原因分析實踐深刻總結造成此次事故的所有原因：
1）為什么會發生此次事故？
事故的直接原因是由于某個服務端API的返回值新增加了一個字段導致此次事故的發生。
2）為什么服務端API的返回值變更會影響ios版app的崩潰而android版正常？
主要還是由于ios版代碼兼容性問題，服務端api的變更導致了類似空指針異常的發生。
3）為什么事故發生前未能發現程序代碼的兼容性問題而導致質量低的代碼到線上？
一方面是由于小美是新人;另一方面組內缺少對代碼進行質量控制的手段。
4）為什么組內沒有對代碼進行質量控制的手段呢？
一方面由于組內人手不足；另一方面缺少一個比較好的代碼review流程去推動質量控制。
5）為什么不盡早推動這套代碼review流程去預防類似事故的發生？
組內人員對代碼質量的重視程度不夠，存在僥幸心理。
結合5whys分析法的實踐，從以下3個層面分析了此次事故的原因：
1、為什么會發生？
2、為什么沒有提早發現？
3、為什么沒有從系統或流程上預防事故？
表面上看因為服務端API的變動造成了此次事故，次級原因是由于IOS程序的兼容性導致，但其發生的根本原因還是在于開發人員對于代碼質量存在僥幸 心理并且上線流程上有漏洞，未能建立一套合理的代碼reivew和審核機制，只有制度或流程上的改進才能盡量避免類似問題的再次發生。
找到根本原因后，小美所在團隊針對此次事故做了一個Casestudy總結，強調代碼質量的重要性，并將代碼Review的流程提上日程，利用公司 Git平臺提供的fork和pull request機制建立起一套合理的代碼review流程，并要求組內人員遵守這套規則，使得代碼質量大大提升，降低了事故的風險。
總結
Casestudy作為美團工程師的必修課之一，如果不去結合5whys分析法去實踐，只顧解決表面原因而不管根本原因，可能事故發生后采取臨時措 施改進后就忘了，問題免不了要復發；但通過5whys分析法這樣一種分析過程，工程師們學會分析問題由表入里，直指問題要害，大大降低了解決問題的成本， 從而間接提高了工作效率。
對于工程師的成長，技術能力至關重要，但是職業技能和通用素質的提高對于工程師的長期成長來說也是很重要的。在美團的工作中，工程師們不光在技術能力得到提高，并且還能掌握很多科學的工作方法，5whys分析法僅僅是其中之一，后續再分享其他方法給大家。