如何做一場高質量的覆盤？

經歷過多次故障覆盤，有些覆盤過程劍拔弩張針鋒相對，有些則是談笑風生以和為貴，因人而異也因事而異，每次故障覆盤過程，聽不同人的發言，都能有很多感觸和思考。

我認為最重要的是：要還原事實，找到薄弱點加以改進。

一、關於故障和覆盤的意義

提到覆盤，大多數人第一時間想到的是線上出了故障，這下又要有人背鍋了。或者是為那個可憐的兄弟暗暗擔心，也或者是因為跟自己無關，所以鬆了一口氣。那麼故障和覆盤真的都是壞事麼，我們該如何理解呢?我從以下3點講一下對故障和覆盤的理解。

1、正確地對待故障

在聊覆盤之前，先聊下對線上故障的看法，首先，在一個複雜系統中，出現故障是必然的，沒有任何系統能保證永遠不出現任何故障，因此，我們要接受故障，然後，從定性的角度來看，並非所有的故障都是壞事，有些故障是有正面意義的，比如說透過一個線上的小故障發現了一個大隱患，或者是某次故障中相關人員的意識和應急預案都很到位，但是由於故障的原因非常特殊最後仍然造成了較大的影響等等，類似這樣的故障都要找出其中的亮點。

所以，我們要用辯證的眼光去看待，避免大家“聞故障色變“。為了往這方面引導，在我們的故障管理制度上，我們也是鼓勵快速恢復(對於快速恢復的故障定級比較低)、鼓勵透過演練發現更多的線上問題(對於由於演練導致的故障有一定的豁免權)等等。但是同時，大家也應該充分意識到我們對故障的理念：即偶爾的系統失效是可以容忍的，人為的犯錯是要嚴肅對待的，比如說不符合高可用規範的系統設計模式、強弱依賴設計不合理、由於人員意識不到位帶來的故障處理時間較長、值班人員未及時接通oncall、由於對線上系統不夠重視帶來的變更隱患、不遵守變更三板斧規範等等。

2、覆盤的3個目的

總之，覆盤的目的是為了總結和改進，要充分利用好每一次故障的機會，從中汲取教訓進行學習，提升我們的經驗，完善系統的設計，我們希望達到3個目的:

1、找到根因，從根本上進行最佳化和改進，給後人帶來警醒和參考。

2、找到降低故障發生機率的方法 - 增大MTBF。

3、找到讓業務快速恢復的方法 - 縮短MTTR。

3、系統和組織都要高可用

每一次的線上故障，都是一次實戰練兵的好機會，除開系統本身的高可用，我們的組織也應該是高可用的，我們經常說好的系統架構是具有韌性的，那麼好的團隊組織也應該是反脆弱的。所以覆盤的過程中，除了找系統本身的問題，還要找工具的問題、流程機制的問題、管理的問題等等。這樣，我們才能由點及面的系統化地解決問題，即治標又治本。

二、故障覆盤的整體流程

三、覆盤前的準備

1、故障參會方

直接原因方、關聯(受影響)方必須全部參與，在覆盤文件中記錄參會人員名單。

時間線提前梳理清楚，做了哪些操作，產生了什麼結果等，先與相關人員提前梳理清楚，關鍵資訊透過截圖等進行佐證。

2、覆盤owner

每個覆盤會議，都必須有唯一的覆盤owner，故障的覆盤owner要主動引導大家，推動覆盤進度，避免出現一些無意義的指責、與故障無關的發散討論等等。

3、理念宣導

①、明確宗旨，拒絕甩鍋：故障覆盤的目的是為了找出問題，明確改進方案避免再次踩坑。要儘量對事不對人，避免形成對某一方的批評會。

②、心態開放，理性務實: 敢於承認自己的問題，接受自己的不足。同時，在尊重他人的前提，每個人都可以就故障過程充分發表觀點和看法。

四、覆盤關鍵環節

1、故障背景概述

故障的背景要解釋清楚本次故障覆盤的背景，即發生了什麼故障，影響了什麼業務(產品)等故障的基本情況。在覆盤文件中，可以透過結構化的語言進行表達。例如：“x月x日xx時，xxx系統出現異常，導致了xxx，影響了xxx業務，表象為使用者無法正常下單，點選下單按鈕出現網路開小差，出現了大量客訴等等”。

故障背景的意義在於讓別人第一眼瞭解清楚這個覆盤的來龍去脈，根因可以不用寫太多，下面會有根因環節。

2、對齊故障影響範圍

講清楚本次故障的影響範圍，包括影響時間段、影響的業務(產品)線、影響的系統(服務)、訂單量、使用者量、客訴量，以及有無產生資損等等。

3、故障時間線回放

提升系統可靠性的兩個關鍵手段：降低故障發生機率和縮短故障持續時間。回放故障的時間線，即先從旁觀者的角度來理一遍故障過程，是為了思考如何縮短故障持續時間(MTTR)，MTTR即故障的平均修復時間，我們對MTTR其進行拆解，得到如下幾個時間段:

MTTR = MTTI + MTTK + MTTF + MTTV。

1、Mean Time To Identify (MTTI): 從故障開始到應急響應介入的時間，一般是考察監控告警、人員值班oncall的合理性。

2、Mean Time To Know (MTTK):從應急響應介入到故障定位的時間，主要考察根因分析、可觀測性等工具的能力。

3、Mean Time To Fix (MTTF): 從故障定位到故障恢復的時間，主要考察應急預案、快恢體系的能力。

4、Mean Time To Verify (MTTV):從故障恢復之後到確認故障已經解決的時間，一般透過使用者反饋、自動化測試等確認恢復。

因此在回放時間線的過程中，也要注意對以下幾個關鍵時間點進行識別，然後逐個溝通討論如何縮短其中的每一個環節耗時。

需要注意提前識別出來的關鍵時間點:

故障引入時間點: 即這個故障實際上是從什麼時候開始的，可能是某次變更釋出/線上操作/其他等。

業務指標變化時間點: 業務指標開始下跌、開始恢復等

監控告警發出時間點: 即監控是從什麼發現異常的，告警什麼時候發出的。告警的級別、接收人是否響應超時等相關資訊都要記錄進來。

人員介入響應時間點: 故障對應的系統值班owner是從什麼時候開始響應的。

異常定位時間點: 即定位到故障的異常點，注意:故障處理過程中的根因定位，並非是最底層的根本原因，而是指初步確認了故障的異常點，可以進行下一步的應急止血動作。

關鍵操作時間點:是否做了一些應急預案，包括重啟、恢復、止血、高可用配置等。還需要寫清楚每個操作的結果，即每個操作之後，報錯面有無縮小、系統資源水位有無變化等。

確認故障恢復時間點: 透過測試驗證或者觀測業務指標、系統日誌等確認系統已經恢復。

4、深挖根因

一般情況下，故障是由兩類原因引起的，包括直接(誘發)原因和根本原因，也就是所謂的誘因和根因。

因此在覆盤過程中，既要明確誘因，更要深挖根因。比如說，某個業務系統由A/B/C 3個服務組成，依賴關係依次是A依賴B、B依賴C，某次開發同學修改了線上C服務的一個配置，使用了錯誤的格式，導致了整個業務系統不可用。那麼在原因分析過程中，把配置檔案修改為錯誤的格式這個動作肯定是直接原因，但是也要注意，B服務對C服務的依賴關係是強依賴麼?如果C服務出現異常的情況下，B服務是否要進行兜底?等等。

可以基於5why分析法深挖根因，多問幾個為什麼，層層遞進，比如說這樣的一個場景: 線上系統執行過程中，某個ES節點突然抖動，RT時間明顯變長，95線由200ms升至800ms，然後引發了上游業務異常。那麼在分析原因的時候，要問以下幾個問題:

1、為什麼ES會抖動?

2、ES的可用性標準是什麼?

3、ES抖動之後，有出現告警嗎?相關人員有第一時間介入處理嗎?

4、ES抖動之後，上游直接使用它的服務有兜底措施嗎?是否為強依賴?

5、對於這個業務場景來說，ES的直接上游系統是這條鏈路的核心依賴嗎，從整個鏈路上有無兜底機制?

要層層遞進深挖根因，千萬不要淺嘗輒止，那樣可能會錯過真正的改進事項。從以往的故障來看，很多問題背後都是系統設計的問題，這樣的問題挖得越深，我們的系統可用性才會越強，才能慢慢朝我們理想中的高可用架構前進。

5、改進項彙總

把時間線和根因分別確認清楚之後，就能推匯出我們對於本次故障覆盤的改進事項了。在梳理改進事項的時候，除了與故障相關係統的改進項之外，還需要從整個故障處理過程來看，在故障的各個環節中有無需要最佳化改進的地方。

比如說某個故障是靠人工(使用者投訴)發現的，那麼要考慮下這個業務的監控告警是否完善，是否能夠降低故障觸達時間;比如說某個故障的告警發出之後，遲遲沒有人響應，那麼要從管理制度來看，對於應急值班政策的執行是否到位;比如某個故障的排查過程中，定位比較苦難，很多地方要靠人工去梳理很多資訊，那麼要考慮相應的排障工具是否好用、應急預案機制是否完善等等。

還有很多其他的問題，大家可以參考上面的MTTR分解環節和故障根因分解環節，自己展開思考下，這也是上面說要深挖根因和詳細分析時間線的目的，這樣我們才能不浪費每一次故障的機會。

在記錄改進項的時候，可以考慮結合SMART原則來設計改進項:

1、S - 必須是具體的(Specific)，改進項必須是可以落地的，不要泛泛而談，例如”最佳化系統設計“這類就屬於反例。重新設計A系統對B系統的依賴關係，使其能夠對異常進行兜底，這種就屬於具體的。

2、M - 必須是可以衡量的(Measurable)，即改進項是可以評估的，比如說透過故障演練來檢驗依賴關係的有效性。

3、A - 必須是可以達到的(Attainable),在當前的技術環境下，這個改進項是可行的，不要寫未來太遠的無法達到的事情。

4、R - 與其他目標具有一定的相關性(Relevant)，可以理解與本次故障中其他改進項有關聯性。

5、T - 必須具有明確的截止期限(Time-bound)，要寫清楚改進項的截止時間，在到期之後進行驗收。

最後，改進事項重在閉環，這個環即PDCA迴圈，Plan(計劃)-> Do(執行)-> Check(檢查)-> Act(處理)，對於我們的故障覆盤來說，即所有的改進事項都必須經過故障演練，透過實戰演練來確保改進計劃一定是有效的。

五、覆盤過程中的幾個關鍵問題

在覆盤過程中，可能很多參與的同學由於經驗或者背景不一樣，大家對故障的理解不一定一致，那麼覆盤的owner要多問一些問題，來引發大家的討論和思考，從以往的經驗中，我們總結了幾類問題，大家可以把這個作為討論的框架:

1、故障的根因是什麼?

當前我們在聊的這個是根因嗎?從業務場景對應的鏈路上看，這個系統(元件)是強依賴嗎?依賴是否合理、有無兜底機制。這次的變更流程是否完善、三板斧落實地是否到位。對應的觀測指標是否能反映系統的真實狀態，應急策略是否有效等等。

2、故障為什麼會發生，可以避免或者降低發生機率嗎?

也就是所謂的提升MTBF，如果是變更引起的，那麼要考慮變更流程是否完善，是否按照流程規範操作，有無對應的防禦機制。如果是某個系統元件失效導致的，那麼要評估該元件的可用性是多少，與它所在的鏈路是否匹配，這條鏈路是否要設計兜底方案等。如果是外部原因引起的，那麼我們對外部的這個依賴是否有過認真的評估，對方的可用效能夠滿足我們的訴求。

3、我們應該做什麼，才能更快地恢復業務?

①、監控告警 - 這個故障是如何被發現的，監控告警是否完善，我們能否更快地發現這個問題。

②、管理制度 - 人員值班響應oncall是否及時,關鍵人員是否就位，關鍵崗位有無backup機制，系統owner對負責的元件是否足夠熟悉。

③、定位效率 - 現有的排查工具是否好用，有無需要最佳化的地方，故障定位的時間能否再縮短一點，故障的處理原則是以止血恢復優先，當時的故障處理過程中，有無跑偏方向。

④、應急預案 - 故障處理過程中，是否有應急預案，應急預案是否奏效?日常是否透過故障演練來驗證應急預案的有效性。

⑤、架構設計 - 架構本身的高可用是否完善，是否具有容災能力。

⑥、流程規範 - 現有的制度規範是否完善，有無需要最佳化的。

六、故障定責

故障定責每家公司都有自己對應的定責制度，這裡不展開太多，只寫幾個關鍵的觀點。

1、定責對應的首先是團隊，其次是個人

很多故障只是表象，大部分根因深挖下去，都會有技術管理的因素，雖然引發故障的操作可能是個人，但是更應該從團隊的視角去看問題，避免把根因只歸結到某個人身上。

2、鼓勵快速止血和積極參與

對於故障處理過程中，積極參與定位、止血等操作的，給予正面的肯定。

3、第三方預設無責

即誰引入了第三方的技術元件，誰就要對其可用性負責。即我們在使用外部技術元件的時候，要仔細評估對方的可用性情況，以及我們的兜底方案等等。

4、紅線和軍規

紅線和軍規是我們的底線，堅決不能違反。現在的很多條款，都是以往的各個故障中沉澱出來，我們必須遵守且尊重這些紅線軍規，把它當做我們研發人員的鐵律。

5、對於重複的錯誤必須嚴肅對待

未知的故障不可怕，可以用來豐富我們的穩定性建設經驗，但是重複的踩坑就需要認真對待了，要思考為什麼以往的改進事項沒有落實到位等等。

七、小結

上面說到，覆盤不是故障的結束，改進事項經過驗收才算徹底結束，因此每一個改進事項的相關方，都應積極主動地push完成。同時，為了最大化的利用好覆盤文件的價值，我們也未來也考慮透過以下幾點來充分利用覆盤價值：

1、未來新人入職後，先組織學習以往的覆盤文件，吸收前人經驗，避免重複踩坑。

2、後續把以往故障作為考試的素材，放入團隊內部的穩定性考試中。

很多問題背後都是一系列的原因，在覆盤的過程中，除了唯一根因，還要把關聯的原因和問題一起來看，避免頭痛醫頭腳痛醫腳的情況，爭取能夠體系化的解決問題。