故障问题处理指南

简介 一、概述线上故障问题处理一般分为以下几个步骤:故障发现故障处理故障复盘在故障处理期间,无论是哪一个阶段,要记住我们的首要目标是“止损”,尽快恢复、消除故障影响,这并不代表我们完全定位了故障问题,也不代表解决方案是完美的,因为这些是可以恢复后复盘的。二、故障发现及时发现故障是处理故障的前提,越早发现问题,就越能减少故障带来的影响,我们应当尽可能通过自动化的方式主动发现问题。主动发现是指通过技术指标监

一、概述

线上故障问题处理一般分为以下几个步骤:

  • 故障发现

  • 故障处理

  • 故障复盘

在故障处理期间,无论是哪一个阶段,要记住我们的首要目标是“止损”,尽快恢复、消除故障影响,这并不代表我们完全定位了故障问题,也不代表解决方案是完美的,因为这些是可以恢复后复盘的。

二、故障发现

及时发现故障是处理故障的前提,越早发现问题,就越能减少故障带来的影响,我们应当尽可能通过自动化的方式主动发现问题。

主动发现

是指通过技术指标监控报警,业务指标监控报警,巡查手段发现线上问题。值班期间应当主动巡查负责系统的各项指标,各类监控是否正常。

常用的监控类型:

监控类型

监控指标

备注

服务器监控

负载、内存、IO等


服务监控吞吐量、接口性能、响应时间等
业务监控访问量,业务量,错误率,转化率等
Paas

类型监控项mysql慢查询、负载、线程数、死锁squirrel慢查询、大key、单机/集群qpsrocketmq消息积压数、消息量等


被动发现

被动发现是非自身技术监控发现的问题,如通过其他系统负责人、产品、运营、客服的反馈才发现问题,团队应当确保团队成员都加入到问题处理群:

渠道

关注

钉钉xxx群


三、故障处理

核心原则:

  • 语音沟通 优于 文字沟通

  • 团队协作 优于 孤军奋战

  • 优先止损 优于 优先究因

  • 断臂防崩 优于 深陷泥潭

识别

无论主动或是被动,值班人员接到故障后,第一件需要做的事情是识别故障的特征。业务高峰期值班我们要求接到问题立刻开始处理

识别问题的优先级

级别

描述

判断标准

举例

P0

重要且紧急

  • 大范围的问题。

  • 影响 金钱 的问题。

  • 关键渠道核心路径的问题

  • 多起用户反馈的问题。

  • 用户无法下单、价格计算错误。

  • C端关键路径无法走通,用户无法上课。

P1

重要不紧急

  • 小范围影响核心路径的问题

  • 延迟处理可以完全fix的问题

  • 个别用户使用很老的版本无法上课。

  • 数据统计有问题,可以刷数据解决。

P2

不重要不紧急

  • 体验问题

  • UI变形,但没有遮挡关键信息

总结判断点,

  • 范围,影响面

  • 金钱,影响金额

  • 关键渠道,新东方在线、新东方在线中小学、小程序。

  • 核心路径,上课,购买流程 

处理

故障处理方法的核心要点有三,团队作战,优先止损,深究根因。

在当前服务化架构的线上系统环境下,我们最看中的指标是系统的可用性,特别是核心业务流程的业务可用性。 

因此最怕的是线上故障造成系统雪崩,导致长时间的不可用。线上故障处理也可以有“黄金5分钟”的概念,在大流量下,故障发生最初的5分钟如果介入处理,快速定位到根因,作出正确的决策处理,能最大程度避免系统出现雪崩,出现长时间不可用的情况。 

团队

业务高峰期间进行故障处理,尽量组成团队作战。这个团队有如下几种角色分工:

 

角色

职责

举例

指挥者
  • 对外通报进展

  • 通报问题确认,影响范围

  • 通报预计的处理时间

  • 通报处理进展

  • 通报处理完成

处理者
  • 提出止损方案

  • 拍板处理方案

  • 追究问题原因

  • 通过报警,监控查找可能的根因,并提出三种方案供讨论

  • 确认使用降级方案,低峰期再修改代码fix

  • 查找问题代码变更历史,确认逻辑 / 联系 DBA 确认数据库资源问题

操作者
  • 执行各类操作

  • 流控平台找到对应接入点操作打开限流。操作完成后通报

  • 降级平台找到对应降级点,操作降级。操作完成后通报

附故障通报格式

故障标题:

影响范围:

发现时间:

原因简述:

处理人:

预计恢复时间:

 

止损

故障处理的第一要务 优先止损!优先止损!优先止损!  

  • 非关键流程的功能故障,优先选择降级。以快速屏蔽问题功能为第一目标。

  • 关键流程的资源故障,优先操作限流。以保护系统不被拖垮,不雪崩为第一目标。

  • 非同步流程的功能故障,优先选择降级。

通常来讲,立即回滚刚上线的代码都是有效的。

究因

止损操作完成后,还需要进一步确认问题的根因是什么。

如果是功能类故障,需要及时找到问题逻辑,修改代码,在当天的低峰期上线完成fix,恢复降级。如果是资源类故障,需要及时申请资源,完成扩容或者替换,恢复限流。

四、故障复盘

每个人都会犯错,主要的区别在于,成功人士能从错误中吸取教训,而普通人则不能。我们允许犯错,但不容忍妄顾教训、一错再错。

通过编写CaseStudy总结问题, CaseStudy的目的不是为了追究责任,是要避免同类型问题的发生,模板参考YYYYMMDD-用户产品研发部CaseStudy模板。


Top Top