關於運維之故障復盤篇-Case Study

關於故障的事后復盤，英文名 Case Study是非常有必要做的，當然是根據故障的級別，不可能做到每個故障都Case Study，除非人員和時間充足；

 文檔能力也是能力的一種，一般工程師的文檔能力比較薄弱或者一般 ，但是一般各種類型的文檔其實都有模板，根據模板填充內容也能事半功倍。

故障要有記錄， 每個公司應當都有wiki，這些復盤應當記錄下來，能學習到很多。Case Study會占用大量的時間， 但是中級以及重大故障還是有必要的。

下面介紹的就是復盤的整體套路：

---

 

故障描述

       xxx業務狀態碼報警， 存儲MySQL3台雲主機 宕機， 根本原因是所在的宿主機宕機.

故障復盤

1. 16:00  故障開始
2. 16:02  發現xxx 狀態碼報警
3. 16:03  op查看報警，web機器正常，同時收到三台數據庫機器down機報警.
4. 16:06  xxxxx
5. 16:11   雲廠商反饋3台雲主機所在的物理機異常宕機 ，目前運維同事在緊急處理
6. 16:14   雲廠商反饋物理機正在啟動中
7. 16:22  金山反饋啟動成功，並進行熱遷移工作
8. 16:23  雲主機機器啟動，啟動數據庫報警 （此時5xx狀態碼報警恢復）

原因：

    雲主機所在的宿主機物理故障導致多台服務器同時宕機.

影響面

     1.   故障時間： 06/16 16:00 ～ 06/16 16:23   （此時間段是宕機時間 23min ）

     2.   影響服務： xxxx

     3.   損失率：    11.35%          

           錯誤總計： 66312 

           請求總量:    584472   

后續優化

1.  將雲主機打散，分布在不通的物理主機上.

---

以上是一個簡單的故障復盤模型 ， 第一步是先根據時間線還原整個故障開始到結束的過程， 第二就是找出問題點（root cause），第三就是看有什么具體的改進措施以及優化，避免再次出現同類故障。