故障治理：如何進行故障覆盤

故障覆盤的重要性無需多說，每一次故障都是寶貴的學習機會，本人接手故障覆盤工作已經半年有餘，從一開始的手足無措，慢慢變得遊刃有餘。以下內容為本人從網上查閱學習多個專家經驗，並結合工作經歷總結而來，僅供參考。

一、故障覆盤目的

通過覆盤總結教訓，找到根因，從根本上進行優化和改進，後期工作中規避問題再發生。
有策略的、系統性的去組織覆盤踩過的坑，還原事實，找到薄弱點加以改進。
最終目的是鼓勵做事，而不是處罰失敗。

二、故障覆盤原則

鼓勵做事和質量改進，反對推諉扯皮不作為；鼓勵公開透明，反對掩蓋問題；鼓勵整體的系統思考和團隊協同，反對把問題推給個人。
明確宗旨，拒絕甩鍋：故障覆盤的目的是為了找出問題，明確改進方案避免再次踩坑。要儘量對事不對人，避免形成對某一方的批評會。
心態開放，理性務實:敢於承認自己的問題，接受自己的不足。同時，在尊重他人的前提，每個人都可以就故障過程充分發表觀點和看法。
鼓勵快速恢復、鼓勵通過演練發現更多的線上問題等。

三、故障覆盤運作機制

3.1 故障覆盤前準備

3.1.1 提交故障報告

故障直接原因方（非最終認定的故障責任方）在故障發生後3個工作日內提交故障報告。如故障原因涉及多個部門，需跨部門共同協助撰寫故障報告。

3.1.2 確定覆盤owner

每次故障覆盤都必須有唯一的覆盤owner，故障覆盤owner負責主動引導大家，推動覆盤進度。覆盤owner的主要職責如下：

覆盤開始前，由覆盤owner根據故障處理報告初稿來推動所有故障干係方完成時間線的梳理，比如某時間點做了哪些操作，產生了什麼結果等；蒐集故障影響範圍，與各個關聯方核實影響的資料，包括業務指標、系統指標、其他指標(客訴、輿情影響等)。關鍵資訊通過截圖等進行佐證，結合故障處理報告形成故障覆盤報告初稿。
覆盤會議中，覆盤owner要主動引導參會人員，推動覆盤進度，避免出現一些無意義的指責、與故障無關的發散討論等。
覆盤會議後，結合故障處理報告形成故障覆盤報告定稿，發給所有故障干係人及相關領導。

3.1.3 確定故障干係人

覆盤owner確定故障直接原因方、關聯(受影響)方等與故障有關的干係人。

3.1.4 組織覆盤會議

確定故障覆盤時間、形式及地點、參會人員等，並組織召開復盤會議。

時間要求：故障發生後一週內,時間拖到久容易遺忘故障細節
參會人員要求：故障干係人必須全部參與，覆盤owner在覆盤檔案中記錄參會人員名單，必要時抽調SRE專家團隊，視故障的危害程度來確定是否需要更高層級的管理人員到場

3.2 故障覆盤關鍵流程步驟(包括但不限於)

3.2.1 故障背景概述

故障的背景要解釋清楚本次故障的基本情況，即發生了什麼故障，影響了什麼業務(產品)等。

3.2.2 對齊故障影響範圍

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

3.2.3 故障時間線回放

故障時間線回放是指從故障的最源頭開始，從旁觀者的角度重新梳理一遍故障的詳細過程，包括每個時間點的人員操作、指標變化、監控告警、系統異常、業務實際情況等等。注意對以下幾個關鍵時間點進行識別。

故障發生時間點: 即這個故障實際上是從什麼時候開始的。
業務指標變化時間點: 業務指標開始下跌、開始恢復等。
監控告警發出時間點: 即監控是從什麼時候發現異常的，告警什麼時候發出的。告警的級別、接收人是否響應超時等相關資訊都要記錄進來。
人員介入響應時間點: 故障對應的系統值班owner是從什麼時候開始響應的。
異常定位時間點：即定位到故障的異常點。
關鍵操作時間點:是否做了一些應急預案，包括重啟、恢復、止血、高可用設定等。還需要理清楚每個操作的結果，即每個操作之後，報錯面有無縮小、系統資源水位有無變化等。
確認故障恢復時間點: 通過測試驗證或者觀測業務指標、系統紀錄檔等確認系統已經恢復。

根據以上時間點計算出故障平均修復時間(MTTR)，然後逐個溝通討論如何縮短其中的每一個環節耗時。MTTR詳細釋義見附錄。

3.2.4 深挖根因

在覆盤過程中，既要明確誘因，更要深挖根因。可以基於5why分析法深挖根因，多問幾個為什麼，層層遞進。5why分析法釋義詳見附錄。

3.2.5 改進項彙總

提升系統可靠性的兩個關鍵手段：降低故障發生概率（MTBF）和縮短故障持續時間（MTTR）。參考第3步的MTTR分解環節和第4步的故障根因分解環節，推匯出我們對於本次故障覆盤的改進事項。在梳理改進事項的時候，還要從流程制度、團隊組織、系統設計、底層工具平臺綜合考慮。改進項需遵循SMART原則，SMART原則釋義詳見附錄。此外每條改進項必須有明確的責任人牽頭人，確保每一條改進措施有人跟進有人負責。

3.3 故障定級定責

覆盤owner組織所有干係人確定故障干係方部門每一方責任佔比以及故障級別，明確扣罰明細。定級定責標準參見各自故障考核管理辦法。這裡注意，故障定級定責標準規則要明確，並能夠與各方達成一致，此外，故障定級定責標準要不斷回頭看，針對有爭議的地方不斷修繕，這樣就會最大程度地減少扯皮推諉的情況出現

3.4 故障覆盤結果通告

覆盤owner根據覆盤會議及故障定責結果、最終的故障原因、改進方案等結論，在原故障報告的基礎上，修改完善並形成最終定稿，以郵件的形式發給所有故障干係人及相關領導進行上報和周知，方便干係人及領導查閱整個覆盤報告，同時讓改進計劃中涉及的各方明確知曉後續相關工作。

四、故障改進及閉環

故障覆盤後由覆盤owner(或其他)將故障資訊（也就是故障報告裡的內容）錄入故障管理系統，系統將向故障改進措施負責人派單，整改負責人整改完成後在系統回單並提交整改完成的證明材料，由覆盤owner稽核通過後方可關閉工單，這樣可以保證整改措施的，實現故障閉環管理

五、獎勵機制

根據故障覆盤過程中各位干係人及SRE專家團隊表現（是否及時提交故障報告，配合度、是否積極改進、積極獻策等維度逆向評價並給予相應獎懲，目的是鼓勵各位主動覆盤主動改進。

附錄：相關名詞解釋

一、5why分析法：所謂5why分析法，又稱「5問法」，也就是對一個問題點連續以5個「為什麼」來自問，以追究其根本原因。雖為5個為什麼，但使用時不限定只做「5次為什麼的探討」，主要是必須找到根本原因為止

二、MTBF：即平均無故障時間，即平均無故障工作時間，是衡量一個產品（尤其是電器產品）的可靠性指標。單位為「小時」。它反映了產品的時間質量，是體現產品在規定時間內保持功能的一種能力。具體來說，是指相鄰兩次故障之間的平均工作時間，也稱為平均故障間隔。

三、MTTR：即故障的平均修復時間，對MTTR進行拆解，得到如下幾個時間段:MTTR = MTTI + MTTK + MTTF + MTTV

Mean Time To Identify (MTTI): 從故障開始到應急響應介入的時間，一般是考察監控告警、人員值班oncall的合理性。
Mean Time To Know (MTTK):從應急響應介入到故障定位的時間，主要考察根因分析、可觀測性等工具的能力。
Mean Time To Fix (MTTF): 從故障定位到故障恢復的時間，主要考察應急預案、快恢體系的能力。
Mean Time To Verify (MTTV):從故障恢復之後到確認故障已經解決的時間，一般通過使用者反饋、自動化測試等確認恢復。

四、SMART原則

S - 必須是具體的（Specific），改進項必須是可以落地的，不要泛泛而談。
M - 必須是可以衡量的（Measurable），即改進項是可以評估的，比如通過故障演練來檢驗依賴關係的有效性。
A - 必須是可以達到的（Attainable）,在當前的技術環境下，這個改進項是可行的。
R - 與其他目標具有一定的相關性(Relevant)，可以理解與本次故障中其他改進項有關聯性。
T - 必須具有明確的截止期限（Time-bound），要寫清楚改進項的截止時間，在到期之後進行驗收。