故障问题处理指南

一、概述

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

• 故障发现
• 故障处理
• 故障复盘

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

二、故障发现

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

主动发现

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

常用的监控类型：

被动发现

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

三、故障处理

核心原则：

• 语音沟通 优于 文字沟通
• 团队协作 优于 孤军奋战
• 优先止损 优于 优先究因
• 断臂防崩 优于 深陷泥潭

识别

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

识别问题的优先级

• 大范围的问题。
• 影响 金钱 的问题。
• 关键渠道核心路径的问题
• 多起用户反馈的问题。
• 用户无法下单、价格计算错误。
• C端关键路径无法走通，用户无法上课。

P1重要不紧急

• 小范围影响核心路径的问题
• 延迟处理可以完全fix的问题
• 个别用户使用很老的版本无法上课。
• 数据统计有问题，可以刷数据解决。

P2不重要不紧急

• 体验问题
• UI变形，但没有遮挡关键信息

总结判断点，

• 范围，影响面
• 金钱，影响金额
• 关键渠道，新东方在线、新东方在线中小学、小程序。
• 核心路径，上课，购买流程

处理

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

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

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

团队

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

• 对外通报进展
• 通报问题确认，影响范围
• 通报预计的处理时间
• 通报处理进展
• 通报处理完成

处理者

• 提出止损方案
• 拍板处理方案
• 追究问题原因
• 通过报警，监控查找可能的根因，并提出三种方案供讨论
• 确认使用降级方案，低峰期再修改代码fix
• 查找问题代码变更历史，确认逻辑 / 联系 DBA 确认数据库资源问题

操作者

• 执行各类操作
• 流控平台找到对应接入点操作打开限流。操作完成后通报
• 降级平台找到对应降级点，操作降级。操作完成后通报

附故障通报格式

故障标题：

影响范围：

发现时间：

原因简述：

处理人：

预计恢复时间：

止损

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

• 非关键流程的功能故障，优先选择降级。以快速屏蔽问题功能为第一目标。
• 关键流程的资源故障，优先操作限流。以保护系统不被拖垮，不雪崩为第一目标。
• 非同步流程的功能故障，优先选择降级。

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

究因

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

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

四、故障复盘

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

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