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