码迷,mamicode.com
首页 > 其他好文 > 详细

关于运维之故障复盘篇-Case Study

时间:2019-07-01 01:13:16      阅读:441      评论:0      收藏:0      [点我收藏+]

标签:就是   厂商   mysq   问题   数据   tle   很多   处理   adc   

关于故障的事后复盘,英文名 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),第三就是看有什么具体的改进措施以及优化,避免再次出现同类故障。

 

关于运维之故障复盘篇-Case Study

标签:就是   厂商   mysq   问题   数据   tle   很多   处理   adc   

原文地址:https://www.cnblogs.com/topicjie/p/11111805.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!