關於運維之故障覆盤篇-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），第三就是看有什麼具體的改進措施以及優化，避免再次出現同類故障。