如何快速应对线上故障

— 1 —

及时汇报、多部门协作排查

发生故障后，不要只顾闷头排查问题，还要及时向你的直属领导汇报故障现象、影响范围、修复措施和修复进度，如果可以，最好再汇报一个大概的恢复时间。这不是浪费时间，而是让你的领导快速了解故障情况，评估风险，以便于协调内外部资源，同时争取更多的决策时间应对老板或业务部门的催促。如果是等级较高的故障就需要联系该系统相关人员一起排查，同时与该业务线的前后端开发、测试、运维及 DBA，多线程并行作战。在清楚故障现象后，各自排查自己负责的模块，最大限度地动用可利用的资源。严重的线上故障一定是要协调各方资源一起排查，因为只有掌握了足够多的信息，才能做出解决问题的正确决策。有必要的情况下，对故障升级要求更多的人投入进来解决该问题

— 2 —

稳定第一，快速止损

当你的领导一遍一遍地催促修复，何时修复？业务部门在各种群里不断报出系统不可用时，每耽误一秒都会给公司带来损失，如何快速止损和恢复，常用的几种方式如下。

1. 重启回滚

能重启解决的先重启，重启能更快的释放资源，快速恢复线上运行是首要任务，当然有条件的话最好能保留现场，把某台应用从负载中摘除，以便后续分析。重启不限于应用、虚拟机，还可能是数据库。针对数据库相关的问题，作为开发人员遇到最多的还是数据库连接池被打满的情况，此时除了重启应用释放资源，也可以让 DBA 快速杀掉慢连接，或者快速主从切换。相对于重启所消耗的时间远比看不见何时恢复业务正常运行的时间要容易评估，所以重启是个简单粗暴且往往有效的方式，当然重启的同时其他同学继续跟进排查。回滚有数据回滚、代码回滚和版本库回滚这几种常用操作，上线新功能的时候，测试场景不充分或环境因素导致某个隐藏 Bug 产生，此时需要回滚部分代码重新发布，或直接全量回退到上一个稳定版本，先保障主业务正常运行，最后兼容所有人要知道兼容上一个版本的重要性。

2. 快速修复（应用修复)

部分问题一般能通过异常快速判断、定位问题。这时可通过修改代码、修复异常数据或临时调整配置参数等方式立刻上线。

值得警惕的是,理解一个系统应该如何工作并不能使人成为专家。只能靠调查系统为何不能正常工作才行。

附赠定位思路：

常规情况下很多时候人都变成无头苍蝇 ！

人员      现象                             各自处理方式
dba      DB/redis  cpu打满  连接数异常         优先帮我解决DB问题        
运维     带宽打满了 机器资源满了                 优先帮我扩容
研发     JAVA 一直都在爆gc                     先给帮我机器加资源

作者推崇google sre 思路不防先通过业务表面点出来 谁最先开始 有深入一步步 挖掘到问题本质全面问题.

表象是什么 是订单不行 还是商品查不了,他为什么会查不了，是什么原因导致 然后具体模块在深入看看 如果是数据库连接不了 为什么数据库会连接不了 是网络问题还是数据库资源不足，一层一层从业务层往上推 多部门配合往上排查 。

研发人员必看之神书5星级强烈推荐

《SRE Google 运维解密》

JAVA性能排查工具

推荐大家使用https://github.com/alibaba/arthas

3. 限流降级

当流量异常时，限流是常用方式，减轻对底层资源的压力。限流主要包括接入层限流、应用层限流、分布式限流。算法大多采用漏桶、令牌桶、信号量。这些基础的工作需要在平时就部署完成，否则当流量来了只能是被动挨打的份了。当无法保障全部功能恢复时就需要打开降级开关，确保核心流程不受影响。降级需要开发者提前理清那些是强依赖，系统资源不足时去掉那些弱依赖或者直接自动熔断读取提前设置的常量。降级会带来用户体验上的降低，却保障了主业务流程的高可用。

4. 扩容隔离

扩容是提升系统承载能力最快的方式，一台应用扛不住就再部署一台，一个数据库不行就分库分表，做读写分离。当然数据库的扩容需要时间，需要一个有计划的演进过程。隔离是最容易被忽略的，隔离通常分资源隔离和业务隔离。举个例子，以前京东订单核心服务给所有系统调用时，出现订单服务不可用的情况，三方合作商家产生的订单在调用订单服务时，产生了很多异常数据，这是没有做好业务隔离。后来京东为三方系统单独部署了订单服务才互不干扰。

— 3 —

清扫战场，及时复盘自我检讨

复盘不是找谁背锅，而是分析问题原因，从故障中找到系统的瓶颈，做好改进计划，避免在同一个坑再次跌倒。复盘可以让团队梳理核心业务上下游的依赖，增强对故障的认识，加深对系统底层资源的理解，更能看到一个人的学习欲望和责任担当。

见过太多的故障相互推诿，不妨从故障角度出发借鉴蘑菇街赵成的复盘黄金三问：

故障原因有哪些？
我们做什么、怎么做才能确保下次不会再出类似故障？
当时如果我们做了什么，可以用更短的时间恢复业务？

聚焦这三个问题，反复讨论，直至大家认为找到了改进的措施。以上就是今天的内容，应对线上故障的第一要素就是：

在现有可利用资源的基础上怎么做才能快速恢复

“简单粗暴”远胜于“严谨优雅”