【IT168 评论】线上故障是我们技术同学经常遇到，也是技术成长中经常要经历的事。从故障中我们可以吸取到很多教训，变得越来越有经验。

　　但是并不是每一个团队/技术同学在应对故障的处理方式上，都能做到合理和科学。

　　下面就从工作中遇到的实际情况，结合最近读陈皓文章心得，来聊一聊我对线上故障处理的看法。

　　故障发生时的处理：

　　1、快速定位故障

　　在复杂的系统架构中，尤其是微服务架构中，一旦发生故障可能会出现“多米诺骨牌效应”，系统会由一个故障点波及到其他关联的模块。 那么一旦定位不及时，不仅仅会扩大故障，还可能会由于多个模块都在报错、报警，给故障源的定位带来困难。

　　因此我们要有一套快速的故障定位方法。我比较推荐的就是 全链条投入排查。即一旦发现线上故障，当前系统以及相关系统所对应的开发、运维、测试等方向，各抽调对口人，全都叫到线上去处理问题，各自排查各自模块/服务，如果排查自己负责的范围没有问题就可以在旁边待命，以备在需要的时候进行配合。重点就是从一开始就一起介入。

　　不要小看这一点，看似平淡无奇，但实际场景下，要能保证有序的这么去做到，还是挺难的，亚马逊都是通过一套制度和任务分配系统来保障这种全链路排查方案得以持久实施的。

　　其实这么做的目的就是在跟故障抢时间。

　　我们平时大多数情况下是怎么做的呢，收到一个线上功能的错误报告，然后对应功能的前端同学开始排查，排查了半天，发现是后端接口不正常，将问题转到后端同学继续排查，后端同学经过一段时间排查后，发现是运维问题或者是依赖的其他模块的问题，就再次将问题转到运维或者其他项目组，然后后者接手开始排查。这样来来去去，等定位到真正故障源的时候，黄花菜都凉了，不仅导致服务长时间的不可用，而且故障随着时间的推移也在不断扩大波及面，问题也越来越难以定位。

　　2、故障止损和恢复

　　在故障源定位之后，一般恢复系统的常用手段无非下面几种：

　　重启：部分问题是可以通过重启的手段来临时恢复的，以保障系统的暂时可用，但后续还需有其他方法彻底解决问题

　　限流和降级：这其实还是一个临时手段，通过将部分非核心系统进行降级和限制流量处理，来避免核心业务受到影响

　　回滚：如果属于更新的代码BUG导致的问题，一般可通过回滚上一个程序版本来迅速恢复，不过会导致部分新功能不可用

　　紧急更新：这个方式会经常被用到，明确定位问题源后，迅速修复代码或组件，然后快速更新上线，比较依赖整个团队的上线协同能力

　　故障发生前的准备

　　设定故障等级：这是一个所有项目共同认定的等级划分，一般无须为单独项目设定

　　服务-资源图：需要针对项目有完整的服务与资源对应图，以便能够速查

　　项目指标和应急方案：给系统设定风险阈值，超出阈值有应急方案提前准备着

　　故障演练：针对特定的重大的风险点，进行演练，以验证上述的应急方案可用性

　　灰度发布：也就是对要发布的新版本进行A/B测试，是一种非常有效的产品验证和功能改进的方法

　　故障发生后的复盘

　　说到故障后复盘，离不开的一个话题就是程序员的追责和惩罚。这其实是另一个主题了，不过这里，我简单的提一下我的建议：对于线上事故，理应追究责任，但无需惩罚(特别严重的问题或特别不能容忍的错误以外)，最重要的其实是做好善后工作，避免下次再犯，从根本上反思，刨根问底，找出问题的根源。这其实也就是下面要聊到的 “Ask Some Whys”。

　　重点来聊聊复盘要做的事情吧

　　记录故障处理全过程： 需要详细的记录下故障发现的时间，什么途径发现的，用了什么样的排查手段，什么样子的处理流程，处理过程中，几点几分做了什么事情，将整个过程都一一的记录下来。

　　分析故障原因： 需要将团队成员聚在一起，进行讨论，分析故障发生的原因，这里的原因不是指表象的原因，需要剖析出问题的根源。

　　故障整改计划： 针对当前故障要做哪些改进措施，应对类似问题，如何预防。给出可实施的方案以及时间计划。同时对故障等级进行认定，以及团队成员责任的追究和备案(但不提倡惩罚)。

　　另外就是 Ask Some Whys： 多问几个为什么，这也是需要团队成员在一起问自己和问对方的。比如：为什么没有进行灰度发布(如果灰度发布能避免问题的话)，为什么测试没有覆盖到，为什么故障处理耗时这么久，等等，根据当前故障进行层层反问和深挖。