關于故障復盤的一些總結
有句話說，常在河邊走，哪有不濕鞋。我身邊經常會看到不少數據故障。每每碰到這些問題，原因都是讓人唏噓不已。
而碰到故障的時候，除了通常都會說的后續改進，其實很多人對于問題的認識和理解還不夠深入，這里主要包含幾個方面：
1)害怕承擔更多責任，會選擇性的縮小問題影響范圍和通知范圍
2)如果問題不是出在自己身上，切身的感受不夠深刻，覺得是在討論別人的事情，持旁觀態度
3)對于問題的改進方向錯誤，比如說因為手工誤操作導致故障，如果反思是直接杜絕任何手工操作，就簡單粗暴，而且很難落地了
4)關注的還是問題本身，沒有從更高的角度來看待問題，通常故障都是和規范，標準，流程相關的
所以對于故障的復盤，我覺得可以從兩個大的方向來進行思考和總結，也參考了很多資料，直接搬過來了。
1)如果快速高效的處理故障，是直面故障時信息的快速上傳下達
2)如何避免后續出現此類故障，潛臺詞就是可以規避，如果規避不了，參考第1條。
所以順著故障的背景信息來展開，我們可以嘗試用如下的兩個表格來進行故障復盤和總結。
1)如何快速高效的處理故障
|
復盤項 |
問題點 |
總結改進 |
|
監控報警 |
監控是否足夠完備？ |
流程監控 |
|
報警是否足夠及時？ |
秒級監控、自動報障 |
|
|
故障響應 |
故障響應時間是否過長、能否縮短、如何縮短？ |
故障電話、主備負責人 |
|
故障定位 |
故障定位時間是否過長、能否縮短、如何縮短？ |
故障看板、調用網格 |
|
故障修復 |
故障修復時間是否過長、能否縮短、如何縮短？ |
故障緊急發布通道、大招系統 |
|
故障流程 |
故障信息同步是否及時？ |
故障信息流轉系統 |
|
用戶投訴反饋是否關注到？ |
投訴反饋自動聚合上報 |
|
|
客戶端故障公告是否按預期周知到位？ |
聯動客服，定期演習；及時彈公告安撫用戶 |
|
|
是否還存在不符合流程規范的問題 |
引起二次故障的一些操作等 |
2)如何避免后續出現此類故障
|
復盤項 |
問題點 |
總結改進 |
|
防患于未然 |
有沒有故障征兆？ |
系統缺陷的發現機制：運維系統風險工單 |
|
故障征兆為何沒有及時扼殺？ |
系統缺陷的跟進與升級機制 |
|
|
不可抗力 |
挖斷光纖 |
備用專線 |
|
機房斷電 |
柴發續供 |
|
|
上聯交換機故障 |
帶狀態服務打散，避免交換機聚集 |
|
|
外網故障 |
客戶端容災，自研解析 |
|
|
用戶群體性行為 |
容量靈活伸縮能力 |
|
|
驅動因素 |
為什么要做這個變更操作？ |
必要性把關 |
|
變更方案和代碼變動有沒有審核review？ |
變更風險評估 |
|
|
影響面控制 |
是否先發布到測試環境和預發布環境驗證效果？ |
增加變更測試和預發布驗證的強制流程 |
|
測試環境和預發布環境，為什么沒有感知和攔截異常？ |
預發布驗證流程監控反饋建設 |
|
|
這個變更操作有沒有灰度 |
強制灰度 |
|
|
這個變更操作是否支持回退？ |
變更前置的回退評估 |
|
|
回退是否足夠及時快速？ |
升級加速渠道 |
|
|
系統架構 |
過載保護是否符合預期 |
review分析有效輸出比例 |
|
環境耦合情況評估 |
頂層高扇出，底層高扇入 |
|
|
是否柔性可用 |
有損大招機制 |
|
|
變更管理 |
變更權限管理 |
按負責人收斂權限 |
|
變更計劃性 |
嚴控緊急上線行為 |
|
|
變更時間窗口 |
非工作時間限制變更 |
|
|
變更質量反饋 |
變更監控建設 |
上面的這些問題感覺還是挺不錯的，可以作為一個復盤總結時的切入點，把大大小小的故障和問題的處理過程都總結出來。
運維無小事，如果按照復盤的思維總結很多問題，那么你的知識集會越來越豐富。而相應的處理機制也會越來越健全。
我經常和團隊成員說：你怎么證明你做的事情是正確的，如果能夠按照這種自證的方式解決問題，那么完全就是一種自驅模式，前途不可限量。
本文轉載自微信公眾號「楊建榮的學習筆記 」，可以通過以下二維碼關注。轉載本文請聯系楊建榮的學習筆記公眾號。
