线上服务故障处理原则

简介: 墨菲定律任何事情都没有表面看起来那么简单所有事情的发展都会比你预计的时间长会出错的事情总会出错如果担心某个事情发生,那么它更有可能发生墨菲定律暗示我们,如果担心某种情况会发生,那么它更有可能发生,久而久之就一定会发生。

墨菲定律

  • 任何事情都没有表面看起来那么简单
  • 所有事情的发展都会比你预计的时间长
  • 会出错的事情总会出错
  • 如果担心某个事情发生,那么它更有可能发生

墨菲定律暗示我们,如果担心某种情况会发生,那么它更有可能发生,久而久之就一定会发生。这警示我们,在互联网公司,对生成环境发生的任何怪异现象和问题都不要轻视,对其背后的原因一定要调查清楚。同样,海恩法则也强调任何严重的事故背后都是很多次小问题的积累,当到一定量级后会导致质变,严重的问题就会浮出水面。
那么,我们需要对线上服务产生任何现象,哪怕是小问题,都要刨根问底,对任何现象都要遵循下面问题

  • 为什么会发生 ?
  • 发生了该怎么应对 ?
  • 怎么恢复 ?
  • 怎么避免 ?

应急目标

在生成环境发生故障时快速恢复服务,避免或减少故障带来的损失,避免或减少故障对客户的影响

应急原则

  • 应第一时间恢复系统,而不是彻底解决呢问题,快速止损
  • 明显资金损失时,要第时间升级,快速止损
  • 指标要围绕目标,快速启动应急过程与止损方案
  • 当前负责人不能短时间内解决问题,则必须进行升级处理
  • 处理过程在不影响用户体验的前提下,保留现场

应急方法与流程

线上应急一般分为 6 个阶段

  1. 发现问题
  2. 定位问题
  3. 解决问题
  4. 回顾问题
  5. 改进措施

过程中要记住,应急只有一个总体目标:尽快恢复,消除影响。不管处于哪个阶段,首先想到的必须是恢复问题,恢复问题不一定能定位问题,也不一定有完美的解决方案,可能通过经验或者开关等。但这可以达到快速恢复的目的,然后保留现场,以及定位问题,解决问题和复盘

发现问题

通常我们通过系统层面、应用层面和中间件层面监控来发现问题

  • 系统层面监控包括
  1. 系统的 CPU 使用率
  2. Load average
  3. Memory
  4. I/O (网络与磁盘)
  5. SWAP 使用情况
  6. 线程数
  7. File Description 文件描述符等
  • 应用层面监控包括
  1. 接口的响应时间
  2. QPS
  3. 调用频次
  4. 接口成功率
  5. 接口波动率等
  • 中间件层面监控包括数据库、缓存、消息队列。
  1. 对数据库的负载、慢查询、连接数等监控
  2. 对缓存的连接数、占用内存、吞吐量、响应时间等监控
  3. 消息队列的响应时间、吞吐量、负载、堆积情况等监控

定位问题

分析定位过程中先考虑系统最近发生的变化,需要考虑如下几方面

  • 故障系统最近是否上过线?
  • 依赖的基础平台与资源是否升级过?
  • 依赖的系统是否上过线?
  • 运营是否在系统内做过运营变更?
  • 网络是否有波动?
  • 最近的业务量是否涨了?
  • 运营方是否有促销活动?

解决问题

解决问题要以定位问题为基础,必须清晰定位问题产生的根本原因,在提出解决问题的有效方案,没有明确原因之前,不用使用各种方法来尝试修复问题,可能还没有解决这个问题又引入了下个问题,想想刚刚提到的墨菲定律

回顾问题

解决问题后,需应急团队与相关方回顾事故产生的原因、应急过程的合理性、提出整改措施,主要聚焦在以下几个问题:

  • 类似的问题还有哪些没有发生?
  • 做了哪些事情,事故就不会再发生?
  • 做了哪些事情,及时发生故障,也不会产生影响?

改进措施

根据回顾问题提出的改进措施,以正式的项目管理方式进行统一管理,采用 SMART 原则来跟进

参考

  • 分布式服务架构原理、设计与实战
目录
相关文章
|
SQL 监控 网络协议
线上故障如何快速排查?来看这套技巧大全
有哪些常见的线上故障?如何快速定位问题?本文详细总结工作中的经验,从服务器、Java应用、数据库、Redis、网络和业务六个层面分享线上故障排查的思路和技巧。较长,同学们可收藏后再看。
线上故障如何快速排查?来看这套技巧大全
|
运维 监控 算法
稳定性保障6步走:高可用系统大促作战指南!
年年有大促,大家对于大促稳定性保障这个词都不陌生,业务场景尽管各不相同,“套路”往往殊路同归,全链路压测、容量评估、限流、紧急预案等,来来去去总少不了那么几板斧。跳出这些“套路”,回到问题的本质,我们为什么要按照这些策略来做?除了口口相传的历史经验,我们还能做些什么?又有什么理论依据?
稳定性保障6步走:高可用系统大促作战指南!
|
4月前
|
监控 测试技术
稳定性摸排问题之数据对账的目的是什么
稳定性摸排问题之数据对账的目的是什么
|
6月前
|
缓存 运维 监控
|
11月前
|
存储 前端开发 算法
微服务线上问题排查困难?不知道问题出在哪一环?那是你还不会分布式链路追踪
微服务线上问题排查困难?不知道问题出在哪一环?那是你还不会分布式链路追踪
129 1
|
算法 BI
《云上业务稳定性保障实践白皮书》——三.故障管理体系——3.故障管理全流程——3.2故障分体系
《云上业务稳定性保障实践白皮书》——三.故障管理体系——3.故障管理全流程——3.2故障分体系
376 0
|
缓存 JSON 运维
如何避免大规模线上故障
如何避免大规模线上故障
174 0
《云上业务稳定性保障实践白皮书》——三.故障管理体系——3.故障管理全流程——3.3.4 故障复盘
《云上业务稳定性保障实践白皮书》——三.故障管理体系——3.故障管理全流程——3.3.4 故障复盘
306 0
|
运维 NoSQL 容器
《云上业务稳定性保障实践白皮书》——三.故障管理体系——3.故障管理全流程——3.3.3 故障快恢
《云上业务稳定性保障实践白皮书》——三.故障管理体系——3.故障管理全流程——3.3.3 故障快恢
238 0
|
UED
《云上业务稳定性保障实践白皮书》——三.故障管理体系——3.故障管理全流程——3.1 故障等级定义
《云上业务稳定性保障实践白皮书》——三.故障管理体系——3.故障管理全流程——3.1 故障等级定义
1406 0