轉(zhuǎn)載美團博客：https://tech.meituan.com/5whys-method.html

前言

網(wǎng)站的質(zhì)量和穩(wěn)定性對于用戶和公司來說至關(guān)重要，但是在網(wǎng)站的快速發(fā)展過程中，由于各種原因?qū)е率鹿什豢杀苊獾陌l(fā)生，這些大大小小的事故對公司難免會造成一些負面的影響，為了避免同類事故的再次發(fā)生，美團的工程師們從事故中不斷學習，對每次事故進行深入分析和總結(jié)，形成了一種Casestudy文化，并結(jié)合一套科學的分析方法-5whys分析法，深入分析事故背后的根本原因和流程漏洞，使得事故發(fā)生的頻率大大降低。

在本文中，首先對5whys分析法的進行簡單介紹，然后再結(jié)合美團工程師Casestudy的案例去分享這套分析法的在美團的實踐。

5whys分析法

5whys分析法，又名why-why分析法，它是根本原因分析（Root Cause Analysis） 的一種具體方法，適用于去分析一些簡單和難度適中的問題。簡單的說，就是針對問題持續(xù)的問5個為什么(通常需要至少5個“為什么”，但5個why不是說一定就是5個，可能是1個，也可能是10都沒有抓到根原)，通過這樣一種分析思路，能很快找到問題深層次的根本原因以及工作流程上的漏洞，并據(jù)此再制定預(yù)防措施，防止問題重新出現(xiàn)或再次發(fā)生，大大降低解決問題的成本。

在美團，5whys分析法作為每個工程師需要掌握的一種工作方法，已經(jīng)廣泛應(yīng)用到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）分析法來對事故進行描述，說清楚事故發(fā)生的時間，地點，發(fā)現(xiàn)人，怎樣解決的，解決的時間等等。

• What：描述下發(fā)生了什么問題。
• Who：描述下責任人是誰，誰發(fā)現(xiàn)的問題，誰解決的問題。
• Where：描述下在哪里發(fā)現(xiàn)的事故。
• When：描述下事故的時間因素，什么時候發(fā)現(xiàn)的事故，什么時間解決的事故。
• Why：描述下為什么是個事故，強調(diào)事故的影響。
• How：描述下事故是怎樣被解決的。
• How much：描述下事故的可量化的影響范圍和造成的損失，影響了多少用戶，造成了多少損失等等。

#####Step 2：提問：為什么這問題會發(fā)生？

識別并確認導致當前問題發(fā)生的直接原因。如果原因是可見的，驗證它。如果原因是不可見的，考慮潛在原因并核實最可能的原因。

#####Step 3：檢驗上一步中發(fā)現(xiàn)的原因是否是根本原因？

檢查上一步中的回答的原因是否是導致事故的根本原因，如果不是，則重復(fù)Step2和Step3，直至找到事故發(fā)生的根本原因為止，最終通過這樣一個過程建立一個通向根本原因的原因/效果關(guān)系鏈。這個過程一般需要持續(xù)5次為什么（可能少于或多于5個），這也是5whys分析法名字的由來。

#####Step 4：找到問題發(fā)生的根本原因，制定執(zhí)行計劃并修復(fù)

找到問題發(fā)生的根本原因后，采取明確的措施和手段去處理問題，預(yù)防和避免類似問題的再次發(fā)生。對于采取的糾正措施和手段，需要問問“采取后能否避免問題的再次發(fā)生”，如果不能，再找到其他的解決之道。

#案例分析

2014年某月某日，某內(nèi)部App ios版應(yīng)用相關(guān)負責人小美接到大量用戶投訴，ios的App啟動時出現(xiàn)閃退現(xiàn)象，導致大量用戶不能進入應(yīng)用，雖說接到反饋后及時修復(fù)，但還是造成了一些不良的影響，針對此次事故，領(lǐng)導要求對事故進行總結(jié)，要求深入分析事故的原因。

小美基于5W2H分析法先對事故進行描述：

事故起止時間：2014年某月某日 10時30分-2014年某月某日 10時40分

責任人：小美

事故詳情：小美對此次事故進行了詳細描述，包含整個事故經(jīng)過的時間、事件，在什么時間節(jié)點什么人做了什么事，誰發(fā)現(xiàn)的問題，誰解決的問題，怎樣解決的問題。

影響范圍：此次事故造成的影響和損失。

然后小美再結(jié)合5whys分析法中的原因分析實踐深刻總結(jié)造成此次事故的所有原因：

1）為什么會發(fā)生此次事故？

事故的直接原因是由于某個服務(wù)端API的返回值新增加了一個字段導致此次事故的發(fā)生。

2）為什么服務(wù)端API的返回值變更會影響ios版app的崩潰而android版正常？

主要還是由于ios版代碼兼容性問題，服務(wù)端api的變更導致了類似空指針異常的發(fā)生。

3）為什么事故發(fā)生前未能發(fā)現(xiàn)程序代碼的兼容性問題而導致質(zhì)量低的代碼到線上？

一方面是由于小美是新人;另一方面組內(nèi)缺少對代碼進行質(zhì)量控制的手段。

4）為什么組內(nèi)沒有對代碼進行質(zhì)量控制的手段呢？

一方面由于組內(nèi)人手不足；另一方面缺少一個比較好的代碼review流程去推動質(zhì)量控制。

5）為什么不盡早推動這套代碼review流程去預(yù)防類似事故的發(fā)生？

組內(nèi)人員對代碼質(zhì)量的重視程度不夠，存在僥幸心理。

結(jié)合5whys分析法的實踐，從以下3個層面分析了此次事故的原因：

1、為什么會發(fā)生？

2、為什么沒有提早發(fā)現(xiàn)？

3、為什么沒有從系統(tǒng)或流程上預(yù)防事故？

表面上看因為服務(wù)端API的變動造成了此次事故，次級原因是由于IOS程序的兼容性導致，但其發(fā)生的根本原因還是在于開發(fā)人員對于代碼質(zhì)量存在僥幸心理并且上線流程上有漏洞，未能建立一套合理的代碼reivew和審核機制，只有制度或流程上的改進才能盡量避免類似問題的再次發(fā)生。

找到根本原因后，小美所在團隊針對此次事故做了一個Casestudy總結(jié)，強調(diào)代碼質(zhì)量的重要性，并將代碼Review的流程提上日程，利用公司Git平臺提供的fork和pull request機制建立起一套合理的代碼review流程，并要求組內(nèi)人員遵守這套規(guī)則，使得代碼質(zhì)量大大提升，降低了事故的風險。

#總結(jié)

Casestudy作為美團工程師的必修課之一，如果不去結(jié)合5whys分析法去實踐，只顧解決表面原因而不管根本原因，可能事故發(fā)生后采取臨時措施改進后就忘了，問題免不了要復(fù)發(fā)；但通過5whys分析法這樣一種分析過程，工程師們學會分析問題由表入里，直指問題要害，大大降低了解決問題的成本，從而間接提高了工作效率。

對于工程師的成長，技術(shù)能力至關(guān)重要，但是職業(yè)技能和通用素質(zhì)的提高對于工程師的長期成長來說也是很重要的。在美團的工作中，工程師們不光在技術(shù)能力得到提高，并且還能掌握很多科學的工作方法，5whys分析法僅僅是其中之一，后續(xù)再分享其他方法給大家。

#參考

• • 根本原因分析
  • 為什么一為什么分析法
  • 精益創(chuàng)業(yè)
  • Stash 1.3: Enterprise Git Gets Social with Pull Requests

轉(zhuǎn)載于:https://www.cnblogs.com/robinunix/p/8410362.html

總結(jié)

以上是生活随笔為你收集整理的5whys分析法在美团工程师中的实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。