线上故障处理原则

墨菲定律

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

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

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

应急目标

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

应急原则

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

应急方法与流程

线上应急一般分为 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 原则来跟进

参考

  • 分布式服务架构原理、设计与实战

原文地址:http://blog.51cto.com/13527416/2073644

时间: 2024-10-10 02:30:03

线上故障处理原则的相关文章

记一次线上故障处理

前言 下面信息裁剪了一些,有的不确定了就拍脑袋定了,大体情况还是和实际相似. 整体过程 最开始接到告警 一个周六的 9:00 接到钉钉告警A应用线上 499 数量大量增加, A应用的背景介绍 先说下A应用的背景,我们A应用每天上亿次访问,主要是给别的厂商买接口的,按照各个厂商的调用量收钱,A 应用的实例数有几十个,接入的 nginx 也有 10 个以上,分布在 3 个机房,平均RT时间 15 ms,一般 499 数量多是某个tomcat或者某个机房的资源有问题导致的,这种问题登录我们收集了 ng

关于线上故障的思考

周末早上,一个哥们突然@我,问是否有线上故障处理和定级的规范或者模板,虽然手头有既有文档,但内容显的太具象了,跟我们的业务有很强的关联性,并不是那么好直接复制到他的团队中.因此,个人对过去的线上故障处理进行了回顾和思考,并进行了简要的归纳,望帮助到需要的同学.文本将按事中处理.事后总结和事前预防的顺序进行介绍,不足之处望大家不吝赐教. 换个角度来说,其实故障处理的过程,和小朋友发高烧的处理过程类似.首先mama会带孩子上医院,如果温度高医生会要求打退烧针,类似发布回滚,之后再通常吃对症的药物慢慢

线上MYSQL同步报错故障处理总结(转)

前言 在发生故障切换后,经常遇到的问题就是同步报错,数据库很小的时候,dump完再导入很简单就处理好了,但线上的数据库都150G-200G,如果用单纯的这种方法,成本太高,故经过一段时间的摸索,总结了几种处理方法. 生产环境架构图 目前现网的架构,保存着两份数据,通过异步复制做的高可用集群,两台机器提供对外服务.在发生故障时,切换到slave上,并将其变成master,坏掉的机器反向同步新的master,在处理故障时,遇到最多的就是主从报错.下面是我收录下来的报错信息. 常见错误 最常见的3种情

关于线上优化服务器视频笔记1-----调优线上服务器

linux服务器调优的经验 目录: 1.系统故障排除思路 重视报错信息 永远不要忘记日志文件 分析.定位.解决问题 2.影响linux性能的因素 服务器硬件因素 操作系统的相关因素 程序因素 3.系统性能优化工具 Cpu性能优化工具 vmstat,iosta,sar 内存性能检测工具 free,top,sar,pidstat 磁盘性能评估工具 iostat,sar 网络性能分析工具 ping,mtr,netstat 4.系统性能分析与标准 5.性能调优的思路与技巧分享 几个故障鼓励案例和性能优化

听说”双11”是这么解决线上bug的

--Android线上热修复的使用与原理 预备知识和开发环境 Android NDK编程 AndFix浅析 Android线上热修复的原理大同小异.这里仅仅针对眼下最火的框架AndFix进行解说.主要从AndFix的使用.原理以及优缺点三个方面进行阐述. 使用方式 介绍 AndFix是一个AndroidApp的在线热补丁框架. 使用此框架,我们可以在不反复发版的情况下,在线改动App中的Bug.AndFix就是 "AndroidHot-Fix"的缩写. 就眼下来说,AndFix支持An

业务技术协同线上化的硬盘式研发管理实践

摘要: 在云效平台策划推出的<持续集成与交付:阿里最佳实践>专题中,阿里云效产品专家代平为大家深入浅出地分享了互联网的研发管理理念,解析了企业研发管理面临的挑战和困难,揭密了如何结合云效产品进行业务技术协同线上化的硬盘式研发管理实践. 摘要:在云效平台策划推出的<持续集成与交付:阿里最佳实践>专题中,阿里云效产品专家代平为大家深入浅出地分享了互联网的研发管理理念,解析了企业研发管理面临的挑战和困难,揭密了如何结合云效产品进行业务技术协同线上化的硬盘式研发管理实践. 以下内容根据演讲

Linux线上安全操作手册

背景为了保证生产环境的持续.稳定.高效地运转,并且使新同学更快的掌握线上操作的基本方法,本文从禁忌,强制点出发,整理出"操作手册",并加入一些平时遇到的问题,总结成操作条款.如有违反,请自行认领各类惩罚吧. 线上变更操作条款01:禁止流量高峰进行影响cache的升级 内容:对影响cache的升级操作禁止在流量高峰进行. 正确:应该在服务流量低峰期进行上线或操作. 说明:减少上线或操作对用户的影响,在异常时候减少损失.条款02:禁止程序线上"裸奔" 内容:禁止程序在线

线上服务应急与技术攻关方法论

海恩法则和墨菲定律 海恩法则指出: 每一起严重事故的背后,必然有29次轻微事故和300起未遂先兆以及1000起事故隐患. 海恩法则强调两点: (1)事故的发生是量的积累的结果: (2)再好的技术,再完美的规章,在实际操作层面,也无法取代人自身的素质和责任心. 根据海恩法则,一起重大事故发生之后,我们要在处理事故和解决问题的同事,还要及时的对同类问题的「事故征兆」和「事故苗头」进行排查并处理,以防止类似问题的再次发生,将问题在萌芽状态就将其解决掉,这可以作为互联网企业线上应急的指导思想. 墨菲定律

数据库操作:编辑表向线上表更新

需求:表edit需要将数据更新到表release,里边会涉及增删改操作,如何做比较好??? 1.edit表是最新的数据,release表是线上表. 2.会有不同的容器调用release表,也就是需要解决容器之间的锁的问题,其他容器只有读操作,正在操控的容器有读写操作,因为更新操作无法做到原子,所以在操作之间可能会遇到其他容器查询为空或读了一半等出错的状态 a.   在另外一张表version里,打上到底使用哪张表.   即读取数据的时候是在两个表之间来回跳跃的 以下操作在我们做update的容器