數智萬物下，運維組織面臨不斷變化的內外部環境，不僅要應對每天海量信息轟炸，還需要對信息進行有效思考，沉淀經驗轉化為能力，推動學習型組織文化。通常來說，學習包括三種：一種是向前人學習，比如看書，吸收前人的歸納總結，獲得知識；第二種是周邊經驗學習，比如向周圍的朋友、領先的資訊知識、舉一反三經驗等學習；第三種是向自己（個人或組織）學習，通過自己的分析、討論、思考，將自己經驗轉化為能力或知識。而“向自己學習”，最常見方法就是復盤，即對過去所做事情重新思考、分析，找出影響結果的因素，將好的行為或不足之處進行梳理，形成自己的經驗知識，并最終轉化為能力。
本文嘗試借鑒“復盤”的關鍵內涵，建立一條圍繞“確定故障復盤方式、梳理故障應急時間軸、還原故障處置行動、根因分析及經驗沉淀、問題及改進措施跟蹤、編寫故障報告并發布”六個步驟的故障復盤改進方法。
上個月在《3.3.1 構建持續提升的故障管理能力》中，我將故障管理閉環周期分為“故障預防、故障發現、故障響應、故障定位、故障恢復、復盤改進”，其中“復盤改進”是從“總結改進”中改動而來，相比“總結”，“復盤”需要有一定套路和方法，強調客觀回顧、持續學習。
我嘗試用我個人時間管理例子對比一下總結與復盤的差異。以前我的時間管理相對隨意，比如將日常臨時性安排登記為任務，不定期反思收獲。今年以來，我使用手帳做時間管理，用法如下：每天上班路上登記當天需關注事項，在每天的碎片時間段中將己完成事項標注“done”，下班路上則根據手帳上己完成事項串起一天過程，通過手帳儀式感的例行反思，能持續在每日復盤中收獲，比如：
哪些待安排事項沒安排好：這類事不一定我自己親自做，但需要自己提前安排任務，作好計劃。
哪些需要提前溝通的事沒有做：這類事只需要提前溝通即可減少后續的被動。
哪些工作可以做得更好：針對已經完成的工作。
哪些目標沒完成：忘了？未就緒？延續到下一天？暫停？
與預期不符的事背后合理的理由是什么：工作總會有些不順，關鍵要調整心態。
相比而言，以前的不定期反思是“總結”，最近的每日時間管理手帳可以歸為“復盤”。前者主要是反思總結，后者則在反思總結基礎上增加了一些因素：持續性（每天）、有方法（登記目標事項，標注完成）、我（親身經歷者）、串起過程（回顧過程）、收獲（影響目標的分析，收獲經驗）。
可能通過“復盤”一詞原意可以進一步抽象復盤關鍵要素。復盤來自圍棋，指棋手在下完一盤棋后，重新在棋盤把對弈過程擺一遍，看哪里下得好，哪里下得不好，以從全局角度重新分析、研討棋局過程，了解不足與優點，找到更好的經驗方法，從而提升棋力。綜上，我們可以將復盤歸納為5個要素：持續性復盤（復盤棋局是常規操作）、參與者真實經歷（棋手）、描述完整經歷（對弈過程）、分析研討對錯（分析、研討棋局）、轉化為能力（收獲經驗，提升棋力）。
通常，一個嚴重的生產故障是多個層面上的連續性保障均失效的結果，比如：架構的高可用、人員應急處置能力、常規預防準備工作、監控發現能力、自動化工具應急能力等。這與海恩法則的描述統一：
海恩法則：一起重大的飛行安全事故背后都會有29個事故征兆，每個征兆背后又有300個事故苗頭，每個苗頭背后還有1000個事故隱患。由此可見，對隱患、苗頭、征兆的忽略，是導致意想不到的安全事故發生的罪魁禍首。（《百度百科》）
海恩法則強調兩點：一是事故的發生是量的積累的結果；二是人自身的素質和責任心。站在運維角度，作為業務連續性最后一道防線，可以從技術手段與管理手段進行可用性能力建設。所以，故障復盤是對事前與事中環節復盤，不僅關注引發故障根源性問題，還需要推動應急協同、工作機制、人員能力、預案管理、潛在風險、監控發現、應急工具、架構高可用、上下游系統風險等全方位的分析。區別于運維組織通常主要圍繞“根因分析、編寫報告、創建及跟蹤問題”3個故障復盤步驟，下面我嘗試將上一節總結復盤的“持續性復盤、參與者真實經歷、描述完整經歷、分析研討對錯、轉化為能力”五個要素融入進來，梳理一條圍繞“確定故障復盤方式、梳理故障應急時間軸、還原故障處置行動、根因分析及經驗沉淀、問題及改進措施跟蹤、編寫故障報告并發布”六個步驟的故障復盤過程。
在分解上面六個步驟前，可能需要關注下面對故障復盤分解的步驟相對理想化，實際情況下由于組織每天都會有大量故障，要求每個故障都進行詳細復盤無法實現，組織應該通過管理機制及工具賦能，摘取部分重點關鍵內容，減少故障復盤手工操作環節，讓大部分故障在當天或24小時內即完成復盤，少數重要故障則細化復盤過程。
2.1 確定故障復盤方式
每個故障都是運維團隊學習成長的機會，我們不要浪費任何一個故障，要讓故障復盤作為故障管理的必要環節?？紤]到故障復盤涉及工作量較多，建議運維組織建立多種復盤模板，針對不同復盤模板與參與人員范圍來應對不同類型的故障。在模板中定義好：哪些人參加，輸出什么，設計/架構/故障預防/故障處置/故障發現等執行情況，是否需要納入日、周、月、季例會等。
基于明確的判斷條件提前制定故障復盤模板，比如針對故障影響級別高低、重復性故障、權益類交易、安全風險等。建議故障復盤采用線上化的管理工具落地，高級別的故障增加一些線下的輔助手段，比如對于故障影響級別高的故障需要跨團隊參與分析，包括產品或需求團隊從需求或設計角度評估軟件邏輯設計角度評估，開發團隊從架構或程序實現角度評估，測試團隊對功能性與非功能性測試角度評估，SRE從系統穩定性、應急處置效率、應急協同、監控發現、自動化處置等角度評估，運維工具團隊從監控、自動化操作、日志等專項角度進行分析。整個故障分析盡量保持透明、公開，讓故障參與各方能夠客觀的參與進來。
除了根據明確條件判斷的故障復盤模板，還有一類故障可能風險級別未達到高級別，但是在某方面己存在較大的風險隱患，比如潛在架構性能及容量問題、針對協同不暢、管理流程、操作不當、人員能力、運維工具應用等問題。這類問題容易漏分析或執行跟蹤不到位，建議從組織管理團隊或故障流程經理驅動，以線上任務方式，指定具體責任人牽頭落實復盤目標。
2.2 梳理故障應急時間軸
第一節中，強調了復盤“參與者真實經歷、描述完整經歷”兩個區別于一般總結的要素，將這兩個要素應用于故障復盤，第一步是要建立故障應急時間軸，時間軸需要有故障處置的關鍵時點。為了標準化、線上化故障處置過程，需要將故障處置關鍵時點進行抽象。在選擇關鍵時點時，故障應急時間軸可以參考業務連續性領域的：MTBF（無故障時長）、MTTI（平均故障發現時長）、MTTK（故障定位時長）、MTTF（平均故障處理時長）、MTTR(平均故障響應時長)，MTTF(平均故障恢復時長)的思路，從故障發生時間、發現時間、響應時間、嘗試處置時間、診斷時間、生效應急處置開始時間、故障恢復時間等梳理應急處置的關鍵節點。通常，MTTI=發現時間-發生時間；MTTR =響應時間-發現時間；MTTK =定位時間-發現時間；MTTF =恢復時間-定位時間。要達成這個目標，要建立線上化的應急處置協同機制，以便上述時間點能夠在事中落地客觀數據。理想情況下，這個線上化應急處置協同機制可以在一個應急場景工具實現，或能夠將多個應急工具中的關鍵操作行為數據整合在一起。故障應急時間軸是圍繞故障應急關鍵時間點的過程還原，需要關注：客觀、在線、量化，這個過程相對容易抽象，適合運維工具團隊落地。
2.3 還原故障處置行動
有了故障應急時間軸，下一步是讓參與方參與進來圍繞應急時間軸還原具體的處置行動，全面復原故障處置行為。比如：
發現方式：誰（機器、IT人員、客服、客戶）、什么時候（預防、及時、較大延遲）、什么方式發現（監控、巡檢、投訴）等；
響應方式：產品/研發/測試/運維/安全響應情況，監控發現后響應效率等；
跨團隊協同：運維團隊內、運維與其他IT條線、IT與業務線、公司與客戶之間協同是否順暢；
嘗試診斷：故障發生后嘗試了哪些診斷動作，是否有效，專家意見是否快速有效；
影響分析：盤中影響分析是否到位，是否有足夠數據支持盤中快速判斷，提否提前準備關鍵KPI指標分析；
危機升級：故障處置過程對于應急處置時間超長，高風險事件的危機升級機制是否到位，現場危機組織是否到位；
情況通報：故障處置過程及恢復的信息通報是否及時、準確，話術是否合理；
啟動預案：預案是否完整，具備可操作性，事中是否啟動預案；
處置方案：嘗試診斷中的生效應急處置，或事中準確判斷的處置方案是什么；
故障恢復：制定處置方案后，方案的執行過程是否及時，跨團隊交付方案是否快速，應急工具是否就緒；
在上述處置過程的還原上，可以考慮關注：能力（專家、預案等）、協同（跨團隊）、機制（信息擴散、危機升級等）、工具（監控、日志、鏈路、數據等）。
2.4 根因分析及經驗沉淀
故障復盤是為了將故障處置行動過程進行分析，沉淀經驗，轉化為團隊能力。隨著業務的不斷演進，系統的數據量不斷擴大，技術棧越來越復雜，系統調用鏈路越來越長，造成信息系統中斷的事件的風險場景越來越多，中斷事件的頻率和種類持續增長，且有相當一部份事件會造成業務中斷，可用性問題越來越嚴峻。在前面《數智萬物下，重新思考運維價值》中，用業務連續性事件起因魚骨圖總結了一下影響業務連續性因素：變更問題、維護問題、性能容量問題、操作問題/誤操作、容災/應用架構高可用、應用邏輯缺陷、版本控制、產品或功能設計不足、數據質量、高可用有效性、應急方案、技術保障方案不完善、應急預案缺失、應急演練不到位、問題跟蹤不閉環、參數設置問題、配置問題、人員技能不足、流程機制不完善、外部攻擊、基礎設施異常、數據備份、數據丟失、監控發現及時性、故障處置時效性等，這些因素都可能是引發故障及導致故障影響升級的根因。
在故障復盤中，主要是對故障直接原因進行定位分析，但隨著運維復雜性不斷提升，只分析直接原因是不夠的，運維在應對復雜性能力飛輪中需要更加主動。參考前面提到的海恩法則，故障根因分析需要從技術與管理兩個角度進行多維度分析。技術手段主要是分析技術架構的高可用,非功能性需求的實現，運維的可觀察性手段是否具備，運維監控工具的故障發現能力是否覆蓋，日志等工具對于故障診斷是否有效，運維自動化工具對連續性恢復處置是否就緒等；管理手段則主要從事前預防、事中處置、事后跟蹤等多方面分解，比如生產環境管控是否到位，預案是否有效，演練是否到位，對業務、運行的理解能力是否達標，協同是否順暢等。
2.5 問題及改進措施跟蹤
通過故障原因分析得到的多個待改進事項，將納入到故障改進中，在ITIL中將這個待改進事項定義為問題。針對2.4中提到的問題，通常會給不同的角色分派改進事項，比如：
for故障處置運維團隊：加強人員對業務、運行的理解，提升監控覆蓋面，加強應急預案管理，加強運行狀態數據分析能力，加強運維工具的使用等；
for工具團隊：加強工具的運營，提升監控覆蓋面與準確率能力，提升日志等異常診斷工具能力，提升自動化工具的使用，提升運維數據分析的平臺能力；
for流程經理：完善應急處置過程的協同效率，信息傳輸及觸達效率，完善人員能力、工具平臺能力的提升；
for研發：修復程序設計邏輯缺陷，提升系統健壯性，增加日志完備度與監控埋點需求，加強版本管理優化等；
for測試：提升非功能性測試、功能性測試覆蓋面等；
for需求/產品：完善業務邏輯設計、功能設計；
for第三方廠商：完善硬件、軟件、線路等方面的健壯性等；
建立上述問題只是開始，下一步是對問題的跟蹤，需要有專項跟蹤機制，比如專項的問題管理例會，問題催辦進展與通報，問題與變更閉環，問題關閉的策略等。由于問題跟蹤的復雜性，理想情況下問題管理應該與績效關聯上。結合管理機制，還需要建立數據驅動，績效支持的協同方式來確保障高優先級的問題得到及時解決。在問題跟蹤上，建議采用全線上的閉環，打通各關聯方的工作平臺，并基于線上化的問題跟蹤數據進行自動化的催辦。
2.6 編寫故障報告并發布
最后每個故障都應該要有一份故障復盤報告。這里提的故障報告不限于一份標題為“XXXXX故障分析報告”的文檔，實際上如果將前面幾個步驟的數據線上化整合，就開始啟動了一份故障分析報告。完整的故障報告包括：故障過程、根因、影響、問題及優化措施、故障定責，以及針對個別突出問題的專項分析。通常，ITSM、故障管理系統，或運維專家知識庫可以作為故障報告的管理系統，系統最好能將故障復盤過程的時間軸關鍵時間點、操作內容、影響范圍等數字化，減少復盤的操作性工作，并提供方便的報告檢索，能夠追蹤問題的解決情況。
針對故障級別，報告有大報告與小報告之類區別，報告編寫過程中最好能建立信息分享機制，以收集跨團隊意見并修訂報告，報告完成后最好能公開發布，發布不僅是問題的警戒與改進，還包括處理過程優點的公示。針對不同類型故障有不同的發布方式，比如：風險通報、專項例會、跨團隊溝通、外部第三方等。
故障復盤改進環節是故障管理閉環周期閉環的收尾階段，是對事前與事中環節的分析，關注引發故障根源性問題的解決與故障事中處置效能的提升。缺少復盤的故障會重復發生，協同會更加低效，IT人力資源會被故障拖住，影響整個IT價值創造。采用“確定故障復盤方式、梳理故障應急時間軸、還原故障處置行動、根因分析及經驗沉淀、問題及改進措施跟蹤、編寫故障報告并發布”六個步驟，可建立一條從故障中學習的方法。在落實過程中，組織應該通過管理機制及工具賦能，摘取部分重點關鍵內容，減少故障復盤手工操作環節，讓大部分故障在當天或24小時內即完成復盤，少數重要故障則細化復盤過程。