企業(yè)運維故障復盤步驟及改進方法

企業(yè)運維故障復盤步驟及改進方法

數(shù)智萬物下，運維組織面臨不斷變化的內(nèi)外部環(huán)境，不僅要應對每天海量

信息轟炸，還需要對信息進行有效思考，沉淀經(jīng)驗轉(zhuǎn)化為能力，推動學習型組

織文化。通常來說，學習包括三種：一種是向前人學習，比如看書，吸收前人

的歸納總結(jié)，獲得知識；第二種是周邊經(jīng)驗學習，比如向周圍的朋友、領先的

資訊知識、舉一反三經(jīng)驗等學習；第三種是向自己（個人或組織）學習，通過

自己的分析、討論、思考，將自己經(jīng)驗轉(zhuǎn)化為能力或知識。而“向自己學

習”，最常見方法就是復盤，即對過去所做事情重新思考、分析，找出影響結(jié)

果的因素，將好的行為或不足之處進行梳理，形成自己的經(jīng)驗知識，并最終轉(zhuǎn)

化為能力。

本文嘗試借鑒“復盤”的關鍵內(nèi)涵，建立一條圍繞“確定故障復盤方式、

梳理故障應急時間軸、還原故障處置行動、根因分析及經(jīng)驗沉淀、問題及改進

措施跟蹤、編寫故障報告并發(fā)布“六個步驟的故障復盤改進方法。

1、關于復盤

故障管理閉環(huán)周期分為“故障預防、故障發(fā)現(xiàn)、故障響應、故障定位、

故障恢復、復盤改進“，其中“復盤改進”是從“總結(jié)改進”中改動而來，

相比“總結(jié)”，“復盤”需要有一定套路和方法，強調(diào)客觀回顧、持續(xù)學習。

我嘗試用我個人時間管理例子對比一下總結(jié)與復盤的差異.以前我的

時間管理相對隨意，比如將日常臨時性安排登記為任務，不定期反思收獲。

今年以來，我使用手帳做時間管理，用法如下：每天上班路上登記當天需關

注事項，在每天的碎片時間段中將己完成事項標注“done"，下班路上則根

據(jù)手帳上己完成事項串起一天過程，通過手帳儀式感的例行反思，能持續(xù)在

每日復盤中收獲，比如：

哪些待安排事項沒安排好：這類事不一定我自己親自做，但需要自己提

前安排任務，作好計劃。

哪些需要提前溝通的事沒有做：這類事只需要提前溝通即可減少后續(xù)

的被動。

哪些工作可以做得更好：針對已經(jīng)完成的工作。

哪些目標沒完成：忘了？未就緒？延續(xù)到下一天？暫停？

與預期不符的事背后合理的理由是什么：工作總會有些不順，關鍵要調(diào)

整心態(tài)。

相比而言，以前的不定期反思是“總結(jié)”，最近的每日時間管理手帳可

以歸為“復盤”。前者主要是反思總結(jié)，后者則在反思總結(jié)基礎上增加了一

些因素：持續(xù)性（每天）、有方法（登記目標事項，標注完成）、我（親身

經(jīng)歷者）、串起過程（回顧過程）、收獲（影響目標的分析，收獲經(jīng)驗）。

可能通過“復盤”一詞原意可以進一步抽象復盤關鍵要素。復盤來自圍棋,

指棋手在下完一盤棋后，重新在棋盤把對弈過程擺一遍，看哪里下得好，哪里下

得不好，以從全局角度重新分析、研討棋局過程，了解不足與優(yōu)點，找到更好的

經(jīng)驗方法，從而提升棋力。綜上，我們可以將復盤歸納為5個要素：持續(xù)性復盤

（復盤棋局是常規(guī)操作）、參與者真實經(jīng)歷（棋手）、描述完整經(jīng)歷（對弈過程）、

分析研討對錯（分析、研討棋局）、轉(zhuǎn)化為能力（收獲經(jīng)驗，提升棋力）。

2、關于故障復盤

通常，一個嚴重的生產(chǎn)故障是多個層面上的連續(xù)性保障均失效的結(jié)果，

比如：架構(gòu)的高可用、人員應急處置能力、常規(guī)預防準備工作、監(jiān)控發(fā)現(xiàn)能

力、自動化工具應急能力等。這與海恩法則的描述統(tǒng)一：

海恩法則：一起重大的飛行安全事故背后都會有29個事故征兆，每個

征兆背后又有300個事故苗頭，每個苗頭背后還有1000個事故除患。由此

可見，對隱患、苗頭、征兆的忽略，是導致意想不到的安全事故發(fā)生的罪魁

禍首。

海恩法則強調(diào)兩點：?是事故的發(fā)生是量的積累的結(jié)果；二是人自身的

素質(zhì)和責任心。站在運維角度，作為業(yè)務連續(xù)性最后一道防線，可以從技術(shù)

手段與管理手段進行可用性能力建設。所以，故障復盤是對事前與事中環(huán)節(jié)

復盤，不僅關注引發(fā)故障根源性問題，還需要推動應急協(xié)同、工作機制、人

員能力、預案管理、潛在風險、監(jiān)控發(fā)現(xiàn)、應急工具、架構(gòu)高可用、上下游

系統(tǒng)風險等全方位的分析。區(qū)別于運維組織通常主要圍繞“根因分析、編寫

報告、創(chuàng)建及跟蹤問題”3個故障復盤步驟，下面我嘗試將上一節(jié)總結(jié)復盤

的“持續(xù)性復盤，參與者真實經(jīng)歷，描述完整經(jīng)歷、分析研討對錯，轉(zhuǎn)化為

能力”五個要素融入進來，梳理一條圍繞“確定故障復盤方式、梳理故障應

急時間軸、還原故障處置行動、根因分析及經(jīng)驗沉淀、問題及改進措施跟

蹤、編寫故障報告并發(fā)布“六個步驟的故障復盤過程。

故障復盤過程

確定故障復植理故隨應編寫故隆報

盤方式急時間軸告并發(fā)布

watiarMWM一.產(chǎn)復角■一.1VRV

1.w?i?mc?可用.OW?torSI*.9???過?力＞

?工堂?M方式fttt?幽，‘：八

?x?ff*?n㈤隊”?ciiHfttt.me.??Sr■三方廠?

?w???9^?Q?lor*■除■*???儀化■■

254??WaftlHtl**MRe?0隊?

?■人????”),?彭■?場B.￡IM??or工KW?tvauamwt

?山&國■杜?并■?坦?—M*ei?KxBftttKW.M.5

■■??次?可?uxaumffitt)

?“?修■時問?f;。4"?a?0??kxVUKLM

?計?方?★?力武

二,ftSU二

2.1W方聾?awwa?弁?履由??■■ft

?0號人員M?MW.

.?風

?MAAft?MTTR

.?▼；?*含

?MTTK

?tA?T0tn二.M34二.Mmaeoc.

?MT7F?H映有?

.折

?MTBF??力WV.M*?XAss.ee.?*■■三方

HT

?MRfiDUWB.■????HtMi?smn

?fm??4,B?UMaw■

■/月

二.xaa?IAKR.SB.?as：?M.■行

■?BBWVHW.msnit

?■化?3MM

在分解上面六個步驟前，可能需要關注下面對故障復盤分解的步驟相

對理想化，實際情況下由于組織每天都會有大量故障，要求每個故障都進行

詳細復盤無法實現(xiàn)，組織應該通過管理機制及工具賦能，摘取部分重點關鍵

內(nèi)容，減少故障復盤手工操作環(huán)節(jié)，讓大部分故障在當天或24小時內(nèi)即完

成復盤，少數(shù)重要故障則細化復盤過程。

2.1確定故障復盤方式

每個故障都是運維團隊學習成長的機會，我們不要浪費任何一個故障,

要讓故障復盤作為故障管理的必要環(huán)節(jié)?？紤]到故障復盤涉及工作量較多,

建議運維組織建立多種復盤模板，針對不同復盤模板與參與人員范圍來應

對不同類型的故障。在模板中定義好：哪些人參加，輸出什么，設計/架構(gòu)

/故障預防/故障處置/故障發(fā)現(xiàn)等執(zhí)行情況，是否需要納入日、周、月、季

例會等。

基于明確的判斷條件提前制定故障復盤模板，比如針對故障影響級別

高低、重復性故障、權(quán)益類交易、安全風險等。建議故障復盤采用線上化的

2.3還原故障處置行動

有了故障應急時間軸，下一步是讓參與方參與進來圍繞應急時間軸還

原具體的處置行動，全面復原故障處置行為。比如：

發(fā)現(xiàn)方式：誰（機器、IT人員、客服、客戶）、什么時候（預防、及

時、較大延遲）、什么方式發(fā)現(xiàn)（監(jiān)控、巡檢、投訴）等；

響應方式：產(chǎn)品/研發(fā)/測試/運維/安全響應情況，監(jiān)控發(fā)現(xiàn)后響應效率

等；

跨團隊協(xié)同：運維團隊內(nèi)、運維與其他IT條線、IT與業(yè)務線、公司與

客戶之間協(xié)同是否順暢；

嘗試診斷：故障發(fā)生后嘗試了哪些診斷動作，是否有效，專家意見是否

快速有效；

影響分析：盤中影響分析是否到位，是否有足夠數(shù)據(jù)支持盤中快速判斷,

是否提前準備關鍵KPI指標分析；

危機升級：故障處置過程對于應急處置時間超長，高風險事件的危機升

級機制是否到位，現(xiàn)場危機組織是否到位；

情況通報：故障處置過程及恢復的信息通報是否及時、準確，話術(shù)是否

合理；

啟動預案：預案是否完整，具備可操作性，事中是否啟動預案；

處置方案：嘗試診斷中的生效應急處置.，或事中準確判斷的處置方案是

什么；

故障恢復：制定處置方案后，方案的執(zhí)行過程是否及時，跨團隊交付力

案是否快速，應急工具是否就緒；

在上述處置過程的還原上，可以考慮關注：能力（專家、預案等）、協(xié)

同（跨團隊）、機制（信息擴散、危機升級等）、工具（監(jiān)控、日志、鏈路、

數(shù)據(jù)等）。

2.4根因分析及經(jīng)驗沉淀

故障復盤是為了將故障處置行動過程進行分析，沉淀經(jīng)驗，轉(zhuǎn)化為團隊

能力。隨著業(yè)務的不斷演進,系統(tǒng)的數(shù)據(jù)量不斷擴大，技術(shù)棧越來越復雜，

系統(tǒng)調(diào)用鏈路越來越長，造成信息系統(tǒng)中斷的事件的風險場景越來越多，中

斷事件的頻率和種類持續(xù)增長，且有相當一部份事件會造成業(yè)務中斷，可用

性問題越來越嚴峻。在前面《數(shù)智萬物下，重新思考運維價值》中，用業(yè)務

連續(xù)性事件起因魚骨圖總結(jié)了一下影響業(yè)務連續(xù)性因素：變更問題、維護問

題、性能容量問題、操作問題/誤操作、容災/應用架構(gòu)高可用、應用邏輯缺

陷、版本控制、產(chǎn)品或功能設計不足、數(shù)據(jù)質(zhì)量、高可用有效性、應急方案、

技術(shù)保障方案不完善、應急預案缺失、應急演練不到位、問題跟蹤不閉環(huán)、

參數(shù)設置問題、配置問題、人員技能不足、流程機制不完善、外部攻擊、基

礎設施異常、數(shù)據(jù)備份、數(shù)據(jù)丟失、監(jiān)控發(fā)現(xiàn)及時性、故障處置時效性等，

這些因素都可能是引發(fā)故障及導致故障影響升級的根因。

業(yè)

務

連

續(xù)

性

小

件

設計問題

在故障復盤中，主要是對故障直接原因進行定位分析，但隨著運維復雜

性不斷提升，只分析直接原因是不夠的，運維在應對復雜性能力飛輪中需要

更加主動。參考前面提到的海恩法則，故障根因分析需要從技術(shù)與管理兩個

角度進行多維度分析。技術(shù)手段主要是分析技術(shù)架構(gòu)的高可用，非功能性需

求的實現(xiàn)，運維的可觀察性手段是否具備，運維監(jiān)控工具的故障發(fā)現(xiàn)能力是

否覆蓋，日志等工具對于故障診斷是否有效，運維自動化工具對連續(xù)性恢復

處置是否就緒等；管理手段則主要從事前預防、事中處置、事后跟蹤等多方

面分解，比如生產(chǎn)環(huán)境管控是否到位，預案是否有效，演練是否到位，對業(yè)

務、運行的理解能力是否達標，協(xié)同是否順暢等。

2.5問題及改進措施跟蹤

通過故障原因分析得到的多個待改進事項，將納入到故障改進中，在

ITIL中將這個待改進事項定義為問題。針對2.4中提到的問題，通常會給

不同的角色分派改進事項，比如：

for故障處置運維團隊：加強人員對業(yè)務、運行的理解，提升監(jiān)控覆蓋

面，加強應急預案管理，加強運行狀態(tài)數(shù)據(jù)分析能力，加強運維工具的使用

等；

for工具團隊：加強工具的運營，提升監(jiān)控覆蓋面與準確率能力，提升

日志等異常診斷工具能力，提升自動化工具的使用，提升運維數(shù)據(jù)分析的平

臺能力；

for流程經(jīng)理：完善應急處置過程的協(xié)同效率，信息傳輸及觸達效率，

完善人員能力、工具平臺能力的提升；

for研發(fā)：修復程序設計邏輯缺陷，提升系統(tǒng)健壯性，增加日志完備度

與監(jiān)控埋點需求，加強版本管理優(yōu)化等；

for測試：提升非功能性測試、功能性測試覆蓋面等；

for需求/產(chǎn)品：完善業(yè)務邏輯設計、功能設計；

for第三方廠商：完善硬件、軟件、線路等方面的健壯性等；

建立上述問題只是開始，下一步是對問題的跟蹤，需要有專項跟蹤機制,

比如專項的問題管理例會，問題催辦進展與通報，問題與變更閉環(huán)，問題關

閉的策略等。由于問題跟蹤的復雜性，理想情況下問題管理應該與績效關聯(lián)

上。結(jié)合管理機制，還需要建立數(shù)據(jù)驅(qū)動，績效支持的協(xié)同方式來確保障高

優(yōu)先級的問題得到及時解決。在問題跟蹤上，建議采用全線上的閉環(huán)，打通

各關聯(lián)方的工作平臺，并基于線上化的問題跟蹤數(shù)據(jù)進行自動化的催辦。

2.6編寫故障報告并發(fā)布

最后每個故障都應該要有一份故障復盤報告。這里提的故障報告不限

于一份標題為“XXXXX故障分析報告”的文檔，實際上如果將前面幾個步驟

的數(shù)據(jù)線上化整合，就開始啟動了一份故障分析報告。完整的故障報告包括:

故障過程、根因、影響、問題及優(yōu)化措施、故障定責，以及針對個別突出問

題的專項分析。通常，ITSM、故障管理系統(tǒng)，或運維專家知識庫可以作為故

障報告的管理系