关于运维之故障复盘篇-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），第三就是看有什么具体的改进措施以及优化，避免再次出现同类故障。