#一分鐘精華速覽 # 怎麼樣做好故障覆盤？是否只要把事故要定責到人就能解決問題？

這是很多企業/團隊都要面對的問題，有著超10年系統穩定性保障經驗的李道兵老師給我們分享了他的觀點：

故障覆盤的三大關鍵問題：

1. 怎麼有效降低故障的影響？
2. 事故處理的流程和原則有哪些？
3. 相關管理制度怎麼設定比較合理？

故障覆盤的四大注意項：

1. 事故覆盤不是給人定責的，要有系統思維將優化項實際落地才能推動系統優化；
2. 事故報告的重點應該是事故提升項，監控、定位、根因、架構四個部分都必須涉及；
3. 事故報告的價值不僅僅是記錄覆盤故障，集中管理起來是很好的培訓資料，能避免新人入職後走彎路；
4. 架構師review是整個事故報告價值最大化重要的一部分，可以橫向幫助企業研發團隊相互借鑑避坑。

道兵老師結合實踐經驗分享了許多幹貨，感興趣的可以往下閱讀完整內容。

很多人應該都有關注SpaceX，從MK1到SN12所有的飛行器都沒有成功，那這個實驗到底是失敗了還是成功了呢？借用埃隆·馬斯克話來說這是一次成功的失敗，他們公司從這些失敗中汲取的經驗遠比一次成功的飛行多的多。SpaceX 的成功，讓我們看到如果能夠系統地從失敗中學習，我們的進化速度能有多快。今天就從下面幾個方面來給大家分享一些我的經驗心得：

1. 怎麼有效降低故障的影響？
2. 事故處理的流程和原則有哪些？
3. 相關管理制度怎麼設定比較合理？

一、怎麼有效降低故障的影響？

不同產品不同的系統它其實完全不一樣，有的以產品功能、使用者體驗為護城河，像美團、支付寶這種，我不瞭解。從2010年到2020年我做了差不多十年的雲，以穩定性和信任為護城河的系統，這一塊我略懂一點，今天就想分享一下我這一塊的經驗。要做好雲要有很重的資本投入，要有解決方案架構師團隊，要有好的產品，再細分就是功能、成本和穩定性，今天就專注穩定性這塊跟大傢俱體聊一聊。

1、確定高可用目標，然後拆分它

降低故障影響首先要明確你的高可用目標，再圍繞目標去做具體的拆分和優化。提到穩定性就會想到可用性，可用性達到3個9每個季度有2小時的不可用時間，4個9每個季度有13分鐘不可用時間，5個9每個季度就只有1.3分鐘的不可用時間。今天講的內容是為了幫助大家達成3個9和4個9 的，也是大部分企業當前的目標，想要衝擊5個9的就要做自動化了，用機器代替人力，那就需要一個完全不同的設計了。

不可用時長最簡單的計算公式是：不可用時長=90天/MTBF*MTTR。MTBF指的是兩次故障之間的間隔時長，MTTR指的是單次故障從發生到恢復所花費的時間。要想縮減不可用時長，從公式上來看很簡單，就是增大MTBF或者減少MTTR。

2、從不同角度去想，具體能做些什麼

2.1 增大MTBF

想要增大MTBF，有3個方向是可以做的——

• 首先是開發過程的質量控制，這個很重要；
• 其次是壓測規範，因為很多不可用都來自壓力過大，壓力過大導致系統直接爆了，所以壓測需要規範起來；
• 最後是上線流程，很多故障都發生在上線的瞬間，因為上線就意味著變更，變更就是事故的一個常見來源，明確上線前如何進行灰度，問題怎麼排查怎麼回滾，這些上線流程做好了也能規避掉一些事故。

2.2 減少MTTR

單純的增大MTBF一定是不夠的，舉個極端的例子，你已經一年連續4個季度不出故障，考核沒事了，第五個季度來了個影響時長超5小時的大故障，你可能就直接被幹掉了，所以減少MTTR也是必須要做的事情。

將MTTR分解來看，主要分成故障發現、故障診斷和修復止損3個階段，那這3個階段我們應該做些什麼來降低這部分的時間呢？

1）故障發現階段

針對這個部分你得先搞清楚你的故障是客戶發現的還是你自己發現的，如果是客戶發現的那這部分的時間就不可控了，能不能變成自己發現的，變成自己發現起碼能減少一部分的時間，那自己發現的能不能通過一些手段來縮短髮現時間也是一個點。

2）故障診斷階段

發現問題之後，如何進行快速診斷是重點。如果完全依賴人工，當你知道故障發生、開啟電腦進入系統排查可能你的不可用時長就已經超標了，所以系統的自檢能力建設很重要。自檢結果是否有彙總面板，能否快速縮小故障範圍，能不能一鍵讓系統自己跑一套標準的測試來告訴你問題出在哪裡，這些都是可以優化的點。

3）修復/止損階段

這個部分我首先要問你一個問題，針對故障你是否有對應的預案，預案是否有過演練是否可實施，有預案可以快速響應止損解決一部分的問題。那修復止損難道就是改bug嗎，顯然不是，因為改bug真的很慢，也許你從2個9衝擊3個9還可以考慮採取這種方式，但當你要衝擊更高的穩定性目標的時候，就要學會使用其他更高效的修復方式了，比如針對故障的模組進行快速降級。

如果遇到不得不修復的問題，那有幾個要點可以來縮短這部分的時間：

• 值班制度：要求隨時有一個人能夠拿到電腦來操作解決問題；
• 雙人互備制度：當一個模組只有一個人瞭解具體的邏輯，萬一這個人不能及時支援就會出問題，所以在研發的時候就要考慮到這個，每個模組都起碼有2個對整體理解透徹的人；
• 現場指揮制度：每次遇到大型事故現場都會非常混亂，所以這塊的設計就顯得很重要，也能有效縮減修復的時間。

二、事故處理的流程及原則有哪些？

大部分大型系統從上線到能夠完全平穩地執行，都需要一個打磨過程，短則幾個月長則需要幾年。除了系統本身的差異，是否有利用好每一次事故來改進自己的系統也是一個重要的點。每次事故都會有事故報告和事故覆盤的過程，如果不明晰這些流程的目的，那麼就會流於形式，也喪失了通過事故來改進系統的機會。 作為架構師團隊的負責人，根據以往的工作經驗我設計出一套事故的處理流程：止損—定位—快速覆盤—事故報告—架構師review—整改跟進，配套的還有一系列處理原則可以去指導我和我的團隊更好地處理事故。

1、止損

1）止損永遠是第一優先順序

為什麼要特意強調這個，因為所有的工程師都有很重的好奇心，在事故現場他們最想做的事情就是搞懂究竟發生了什麼而不是優先恢復系統服務。如果你有提前準備預案，那麼就嚴格按照預案執行即可。

2）在保證止損效果的同時儘可能的保留事故現場

這可以為後續的定位工作提供方便，可如果保留現場會影響止損，那麼還是止損優先，之後再考慮如何通過改造系統來提升在止損時保留事故現場的能力。比如說搭建一個好的日誌系統，將所有的異常請求都記錄下來，這也能幫助我們後續去還原事故現場。

3）止損現場要有一個決策人

決策人需要快速判定如何止損，同時分工協調現場人員去達到止損的目的。現場最怕的狀況就是隻有兩三個人忙的團團轉，而其他人不知道自己該幹什麼，也不敢去做相關的決策。

4）止損現場保持溝通

最好的狀況就是大家都在現場，那麼一起快速搬進會議室面對面地溝通協作，如果不能做到這個，決策人應該立刻發起電話會議，保證大家的資訊及時同步，增加遠端協作的效率。

5） 及時通知客服團隊

這一點很好懂，有問題不通知客服團隊，對外溝通出現問題，客服團隊一定會投訴過來。

以上這些止損的原則其實都是為了幫助你更好更快地完成止損的動作，止損之後再開始考慮後續的定位工作。

2、定位

1） 止損基本完成前不要花精力在定位上

止損基本完成前不要花精力在定位上，除非止損本身需要定位。如果說不進行定位止損就做不了了，那麼應該立即派遣團隊最優秀的人和最熟悉該模組的人一起專心定位。為什麼要兩個人來做這個事情，因為最熟悉的人很容易陷入自己的思維誤區，認為自己做的就是對的，這時就需要另一個人來共同梳理，分析業務邏輯裡面有沒有可能出漏洞的地方。這時現場決策人就需要做一些分工，讓大家去分頭收集資訊並觀察異常狀況，有什麼資訊都要及時彙總。

2）不要輕易中止定位

有時因為壓力產生的故障，當流量高峰過去，故障也就消失了，這時不要輕易中止定位，避免未能發現問題根因或者因為巧合導致問題消失。

3） 定位相關資訊要時時記錄

這是我經常遇到的情況，很多定位人員定位結束了，但整個邏輯鏈條裡面很多證據都沒有儲存好，雖然得出了定位結論，但過程證據並不充分。所以我會給他們提一個要求，在定位的過程中手邊要開一份文件，最好能貼上圖片，隨時把定位過程中的資訊拷貝到文件裡，方便後續檢視。

4） 定位的結論可以是無法定位，但要給出後續改進意見

我經常會強調一個觀點，定位的結論可以是無法定位，但一定要給出事故再次發生後如何定位的改進意見。有時候故障就是消失了，定位不到也是可能發生的，但在事故報告中要明確之後該怎麼做，這樣當再次遇到這個故障時才能快速精準地定位。

3、快速覆盤

在定位完成之後我一般會進行快速覆盤的動作，拉上兩三個人開站立會議，一般由負責定位的人來主講，講清楚事故發生的邏輯，其他人來給出資訊補充或者提出質疑。當無法排除合理懷疑時，就需要繼續定位了，直到完全定位結束。當你的邏輯都理清楚了，就到了討論事故提升項環節，這塊後面我會再展開講。負責人在這裡還要做一件事情就是安排大家收集事故報告的必要資訊，並安排人來撰寫事故報告。

4、事故報告

事故報告並不是因為出了事故，你搞砸了，我要懲罰你去寫書面文件，而是說這些內容很有價值，後續也會成為培訓的資料。當新人進來，他可以通過這些事故報告去了解以前系統出過哪些問題，後續又是怎麼解決的，所以事故報告的邏輯一定要完整。

根據我的經驗，事故報告應該要包括事故影響、事故時間線、事故原因分析、事故提升項這幾部分的內容。

1）事故影響

這部分一定要把對應的監控圖給及時截取出來並儲存下來，因為監控系統不會一直保留之前的資料，幾個月或者一年之後可能資料就沒有了。

2）事故時間線

事故的時間線記錄很簡單，要從事故的第一次上線開始講，此外你不要去加邏輯，就是簡單地把事故處理過程中每個時間點系統發生了什麼變化，對應的人都幹了什麼做了哪些嘗試這些東西梳理清楚。

3）事故原因分析

這裡是需要把邏輯講清楚的，你要多畫示意圖，通過示意圖來清晰展現這個架構下導致故障的原因。這裡有個很重要的點就是不能揣測事故的原因，要排除大量的合理懷疑。單講清楚事故發生的邏輯是不夠的，還要講清楚為什麼其他的合理懷疑是不成立的，避免大家花費大量的時間最後得出的是錯誤的結論，做了錯誤的優化。

4）事故提升項

這部分我要詳細說說，這塊我是有具體的標準要求的，監控、定位、根因、架構四個部分都必須要有，哪個部分經過分析確實沒有提升項就寫“無”。

• 監控：兩個自檢的方向，事故發生後你是否第一時間收到了監控告警，事故發生前有徵兆，徵兆的內容是否監控到了，如果這兩個部分都OK那基本可以說監控部分沒有問題。
• 定位：現有的定位流程是否通暢，有沒有什麼改進的點，比如說需要一些工具，或者說完善日誌的全文檢索能力、日誌的格式化與視覺化能力，以此來提升定位的效率。
• 根因：根因是整個事故報告裡最簡單的部分，什麼原因導致的事故修復優化了哪些東西。額外要說的一點是一個系統必須有2層防禦能力，只有這樣才能放心，不用擔心下一次會出現一樣的問題。
• 架構：有些問題是需要通過更加巨集觀的變更來解決的，這部分要明確如何通過架構的變更來從根本上來消除事故的隱患。

5、架構師review

架構師review是整個事故報告價值最大化很重要的一部分。建議大型集團都將高等級的架構師彙集到一起組成架構師委員會，這不是一個名稱榮譽，是需要他們來幹實事的，其中一個部分工作就是定期開會review事故報告，大概2-3週一次。

review事故報告有幾個點很重要：

• 督促大家產出的事故報告得合格，必須資訊完整、根因分析透徹合理、提升項沒有問題；
• 在各個團隊間進行舉一反三，對類似的風險點進行排查；
• 提供一個不同團隊之間高等級的架構師的交流平臺，互相學習；

6、整改跟進

每個事故報告的提升項要寫明負責人和預期的完成時間，架構方面的提升項一般用時比較長也不太緊急，但是也要寫明時間，然後由專案經理團隊持續跟進每個提升項的落實情況。最怕的就是一些中等級別的事故，事故報告的提升項洋洋灑灑寫了很多，但沒有具體落地實施，等到下次出現一樣的問題時才發現之前沒有做整改。提升項當然也是可以放棄的，但必須要有充分的理由。

前面架構師review會議產生的一些結論也是需要單獨立項跟進的，這些整改跟進都落實到位了，才能對系統的穩定性提升有實質性的幫助。

三、相關管理制度怎麼設定比較合理？

雲平臺本身是一個很龐大的系統組織，前面說了很多標準化的處理流程以及相關的原則，但組織是個有機體，所以這裡面還涉及人的管理，這就需要管理制度來做輔助了，這邊分享幾個要點。

1、不要給低等級事故設指標

大家都會給系統事故定等級，P0、P1、P2、P3，然後針對故障等級去設立不同的目標。我為什麼說不要給低等級事故設指標，因為這個指標的設立容易讓大家隱瞞低等級的事故。即使你的目標設定的很寬鬆，比如說這一個季度P2等級的事故不能超過10個，但只要設定了目標，下面的人就會想這個事故沒有人發現那我就不上報了吧。這就會浪費一次通過故障去提升系統的機會。

2、事故報告不要追究人的責任

事故報告不要追究人的責任，因為你是在建設一個系統，事故報告的提升項就應該體現在程式碼上，或者體現在一些強有效的文件裡，比如說預案文件、值班制度文件。

3、要培訓鼓勵大家寫事故報告

大家都覺得自己腦子好，不願意去動手寫文件，這時候就需要通過培訓去要求和鍛鍊夥伴們的事故報告輸出能力，鼓勵大家多寫報告，描述清楚，瞭解它的價值。

4、事故報告要集中管理

事故報告的集中管理是為了方便後續的複用，它是很好的新人入職培訓材料。我們在書寫的過程中不會去強調具體的人的責任，讀起來會更客觀，新人在閱讀這些報告時能夠了解系統的邏輯框架，知道一些邏輯寫法會產生問題，就能更好地迴避這些。

四、一個小小的實踐分享

跟大家分享一個之前我還在雲公司的小故事，這個時間有點長了。

當時我們還沒有大範圍的去使用容器，在做一個小的上線動作時，在reload之後發現有一臺機器完全不能用了。工程師當時非常的好奇問題出在哪裡，想去做定位，我說咱們應該先把這臺機器下線然後繼續跑。後續我們要做定位的時候就發現非常的詭異，一大堆的資料沒了，其實是一整個的目錄都沒了。我們看了這臺機器的操作記錄，跟旁邊的其他機器並沒有什麼差別。當時我們的運維需要對多臺機器做批量處理，他就找了一個能同時控制多臺機器的terminal來做指令下發。運維的操作也很規範，先建立一個目錄來進行相關操作，完成之後回到上級目錄刪除這個目錄，結果就發現有臺機器出問題了。

具體是什麼問題呢？目錄的名稱是fobar，這個名稱大家都很常用，很不幸的是這臺問題機器裡某個目錄下有個叫fobar的檔案，在建立目錄的那一個環節其實就已經失敗了，沒有進入到這個新建的目錄裡面。但後續的很多操作又都成功了，所以返回上級目錄刪除時出現了問題，直接把原目錄幹掉了。這裡fobar檔案的追溯是很難的，你不知道什麼時候做了這個操作，也沒有相關的監控手段。

針對這個問題，我們後續的整改方式就是terminal一律不準再用了，轉而使用ansible來控制機器，在其他部門分享這個故障案例的時候也是獲得了一致的認同，不再使用terminal，因為不知道哪一天會出現故障，後來我們也逐步建立了ansible指令碼庫。當然現在已經進入docker時代了，這些內容已經沒有意義了，但從某種角度來講docker又是解決這個問題的一種新的架構。

五、寫在最後

2年前我離開了京東雲，其實是有很多想法沒有去落地實現的，這邊跟大家分享一下，希望能給大家更多的啟發。

1、自動根因分析

當你擁有幾萬臺機器幾千個服務的時候，就不是有沒有監控警報的問題了，你永遠都會有警報。那麼就會產生一個需求，怎麼圍繞事故現象去把相關的警報篩選出來，當時有個想法就是去做系統的邏輯自檢模組。簡單來說就是每個系統都要明確自己依賴哪幾個模組，這幾個模組對系統的影響具體是什麼。

2、黃燈與自動修復

紅燈是事故、綠燈是正常，黃燈是需要儘快修復的部分，黃燈往往是事故出現前的徵兆，圍繞黃燈來設計相關的自動運維體系，就能保證很多事故扼殺在發生前。

3、K8s+混沌測試衝擊5個9

K8s是一個非常好的自動化運維平臺，配合混沌測試的手段就可以打造一個非常穩健的系統。這個穩健並不是說我的系統沒有任何的bug，而是面向所有可能出現的情況我都有對應的預案，並且這些預案都已經固化在我K8s的腳本里面，這樣才有機會去衝擊5個9。

關注公眾號後臺回覆關鍵詞【7162】即可獲取講師PPT 講師精彩直播回放：http://news.shulie.io/?p=5016