不管是系统报警还是业务反馈，线上故障发生后如何快速应对，本文根据自己经验分享如何应对及其方法论。
一、及时汇报、多部门协作排查
发生故障后，不要只顾闷头排查问题，还有一件需要做的事情就是向上汇报，这是很多工程师容易忽略的地方，向你的直属领导汇报故障现象，影响范围，修复措施和修复进度，如果可以最好能给一个大概的恢复时间，比如：
“下午3点收到DBA反馈，数据库连接飙升，商品系统连接池耗尽导致请求阻塞，目前已打开限流和降级，组织研发和运维排查，预计5分钟内解决”。
这不是浪费时间，而是让你的领导快速了解故障情况，评估风险，以便于协调内外部资源，同时争取更多的决策时间应对老板或业务部门的催促。
如果等级比较高故障就需要联系该系统相关人一起排查，多部门协作，包括该业务线的前后端开发、测试、更需要运维及DBA，多线程并行作战，在清楚故障现象后，各自排查自己负责的模块，最大限度的动用可利用的资源，比如业务反馈某页面打开白屏，那么根据我们的经验可能的几个原因：
- 用户手机适配问题或用户网络问题；
- 接口返回参数前端没有合理处理；
- 大流量访问导致页面加载慢；
- 机房某条线路有问题，如电信或联通出口异常；
白屏只是现象，一个白屏背后可能有多种原因造成，当然这个例子不一定合适，实际情况需要我们根据多种现象定位问题根源，这里就需要多部门协作，比如：
前端同事可以分析手机机型及安装版本、查看返回的数据格式是否解析正确；
后端监控日志，内存情况或通过APM工具查看调用链、慢查询等，同时分析代码逻辑；
运维则根据CPU负载、磁盘和网络IO等数据分析可能的原因；
产品经理也可以参与进来协助询问业务最近是否在搞活动，或者进行了什么批量操作。
你看，严重的线上故障一定是要协调各方资源一起排查，因为只有掌握了足够多的信息，才能正确的做好解决问题的决策。
二、稳定第一，快速止损
当你的领导一遍遍的催促何时修复，业务部门在各种群里不断报出系统不可用时，每耽误一秒都会给公司带来损失，如何快速止损和恢复，一般常用的几种方式如下：
重启回滚
能重启解决的先重启，重启能更快的释放资源，正所谓“重启大法好”，快速恢复线上运行是首要任务，当然有条件的话最好能保留现场，把某台应用从负载中摘除，以便后续分析。重启不限于应用，虚拟机还可能是数据库。针对数据库相关的问题，作为开发人员遇到最多的还是数据库连接池被打满的情况，此时除了重启应用释放资源，也可以让DBA杀掉慢连接。
相对于重启所消耗的时间远比看不见何时恢复业务正常运行的时间要容易评估，所以重启是个简单粗暴且往往有效的方式，当然重启的同时其他同学继续跟进排查。
回滚操作常用的有：数据回滚、代码回滚和版本库回滚，我们上线新功能的时候，测试场景不充分或环境因素导致某个隐藏Bug产生，此时需要回滚部分代码重新发布，或直接全量回退到上一个稳定版本，先保障主业务正常运行。
快速修复
大部分的问题我们一般能通过异常快速判断，比如空指针，业务参数异常等，开发人员定位后，可通过修改代码、修复异常数据或临时调整配置参数等方式立刻上线。
限流降级
当流量异常时，限流是我们常用的方式，限流主要包括接入层限流，应用层限流、分布式限流。算法上大多采用漏桶、令牌桶，信号量。这里不做过多陈述。这些基础的工作需要在平时就部署完成，否则当流量来了只能是被动挨打的份了。
限流的本质的形成流量漏斗，减轻对底层资源的压力，目的能达到，用什么“术”根据情况而定。有一次我们的系统没有做好限流，用户并发下单导致接口出现服务不可用，接入层做限流的同时迅速组织同事开发下单接口的限流，我们当时用了一个“抽签法”，首先定义了一个数组，假设[0,1,2]，在下单接口处取0~2的随机数，如果是0，则直接返回失败信息，通过这种方式阻止了1/3的用户请求。方案虽然不雅观，体验也不好，但在当时紧迫的情况下开发最容易接受，落地最快。
当无法保障全部功能恢复时就需要打开降级开关，确保核心流程不受影响。降级需要我们提前理清那些是强依赖，系统资源不足时去掉那些弱依赖或者直接自动熔断读取提前设置的常量，比如我们降级后商品详情页的评论不会加载，运费统一读取配置中心预设的常量值。降级会带来用户体验上的降低，却保障了主业务流程的高可用。
扩容隔离
扩容是提升系统承载能力最快的方式，一台应用扛不住就再部署一台，一个数据库不行就分库分表，做读写分离，当然数据库的扩容需要时间，需要一个有计划的演进过程。
隔离是最容易被忽略的，隔离通常分资源隔离和业务隔离。举个例子，以前我们的订单核心服务给所有系统调用，有一次订单服务不可用，三方合作商家产生的订单调用我方订单服务时，产生好多异常数据，这是没有做好业务隔离，后来我们为三方系统单独部署了的订单服务才互不干扰。京东在这次疫情期间的口罩预约中虽然预约页面崩了多次，但APP主流程却不受影响，这是隔离的好处。
三、清扫战场，及时复盘自我检讨
故障解决，或多或少会产生一些脏数据，比如没及时退款的赶紧退款，数据状态不对的，需要手动核对修复。同时需要跟客服同事说明哪些问题不可修复，让客服MM做好用户的安抚工作。
复盘不是找谁背锅，而是分析问题原因，从故障中找到系统的瓶颈，做好改进计划，避免在同一个坑里再次跌倒。复盘可以让团队梳理核心业务上下游的依赖，增强对故障的认识，加深对系统底层资源的理解，更能看到一个人的学习欲望和责任担当。复盘做的好可以让团队技术和系统鲁棒性提升一大个段位，“凡是杀不死我的,必使我强大”！
复盘的方式我很赞成蘑菇街赵成的复盘黄金三问：
第一，故障原因有那些？
第二，我们做什么，怎么做才能确保下次不会再出类似故障？
第三，当时如果我们做了什么，可以用更短的时间恢复业务？聚焦这三个问题，反复讨论，直至大家认为找到了改进的措施。
四、总结
应对线上故障的第一要素就是：在现有可利用资源的基础上怎么做才能快速恢复。这里我建议大家在故障解决时不要考虑哪些高大上的方案，高大上的方案往往需要一定的实施周期、软硬件资源和开发资源，此时简单粗暴远胜于严谨优雅。
海恩法则指出：每一起严重事故的背后，必然有29次轻微事故和300起未遂先兆以及1000起事故隐患。所以，我们平时还是要做好监控，刨根问底的排查每一次异常原因，同时做好code review，故障演练，接口和链路压测等方式提高代码质量和系统性能，去迎接不可预测的黑天鹅事件。
最后，我想说，线上事故的发生就意味着公司的业务及品牌遭受损失，那么作为公司团队的一员，面对如此高成本的“演练”，一定保持冷静--Keep Calm，同时请珍惜每一次解决线上事故的机会，从另一个角度讲，他也是你技术提升最快，最能脱颖而出的时候。
（Keep Calm and Carry On（保持冷静 继续前行）是1939年第二次世界大战开始时，英国皇家政府制作的海报）
作者介绍：宋子龙，某医药O2O公司技术总监，多年互联网电商经验，在新零售技术架构领域有丰富的实战经验。专注于高性能、高可靠的分布式平台设计。
