关于运维之故障复盘篇-Case Study
关于故障的事后复盘，英文名 Case Study是非常有必要做的，当然是根据故障的级别，不可能做到每个故障都Case Study，除非人员和时间充足；
文档能力也是能力的一种，一般工程师的文档能力比较薄弱或者一般 ，但是一般各种类型的文档其实都有模板，根据模板填充内容也能事半功倍。
故障要有记录， 每个公司应当都有wiki，这些复盘应当记录下来，能学习到很多。Case Study会占用大量的时间， 但是中级以及重大故障还是有必要的。
下面介绍的就是复盘的整体套路：
故障描述
xxx业务状态码报警， 存储MySQL3台云主机 宕机， 根本原因是所在的宿主机宕机.
故障复盘
- 16:00 故障开始
- 16:02 发现xxx 状态码报警
- 16:03 op查看报警，web机器正常，同时收到三台数据库机器down机报警.
- 16:06 xxxxx
- 16:11 云厂商反馈3台云主机所在的物理机异常宕机 ，目前运维同事在紧急处理
- 16:14 云厂商反馈物理机正在启动中
- 16:22 金山反馈启动成功，并进行热迁移工作
- 16:23 云主机机器启动，启动数据库报警 （此时5xx状态码报警恢复）
原因：
云主机所在的宿主机物理故障导致多台服务器同时宕机.
影响面
1. 故障时间： 06/16 16:00 ～ 06/16 16:23 （此时间段是宕机时间 23min ） 2. 影响服务： xxxx 3. 损失率： 11.35% 错误总计： 66312请求总量: 584472
后续优化
- 将云主机打散，分布在不通的物理主机上.
以上是一个简单的故障复盘模型 ， 第一步是先根据时间线还原整个故障开始到结束的过程， 第二就是找出问题点（root cause），第三就是看有什么具体的改进措施以及优化，避免再次出现同类故障。