故障处理佳实践与应对策略精要.pdfVIP

17|故障处理最佳实践：应对故障

2017-11-28

17|故障处理最佳实践：应对故障

朗读人：柴巍09′12′′|4.22M

或多或少我们都会经历线上的故障。在我的职业生涯中，就经历过很多的线上故障。老实说，线上

故障是我们技术人员成长中必须要经历的事。从故障中我们可以吸取到很多教训，能让我们学到很

多书本上学不到的知识。坑踩多了，我们会变得越来越有经验，也就成为老了。

不过，我看到很多公司处理线上故障的方式并不科学，而且存在很多问题，所以，想写文章来

一些我的经验。这些经验主要来自亚马逊和阿里这两家互联网公司，以及我个人的经验总结。希望

这套方法能够对你有帮助。

故障发生时

在故障发生时，最重要的是快速恢复故障。而快速恢复故障的前提是快速定位故障源。因为在很多

分布式系统中，一旦发生故障就会出现“多米诺骨牌效应”。也就是说，系统会随着一个故障开始一

点一点地波及到其它系统，而且这个过程可能会很快。一旦很多系统都在，要想快速定位到故

障源就不是一件简单的事了。

在亚马逊，每个开发团队至少都会有一位oncall的工程师。在oncall的时候，工程师要专心处

理线上故障，轮换周期为每人一周。一旦发生比较大的故障，比如，S1全部不可用，或S2某功能

不可用，而且找不到替代方案，那么这个故障就会被提交到一个工单系统里。几乎所有相关团队

oncall的工程师都会被叫到线上处理问题。

工作流是，先线上签到，然后自查自己的服务，如果自己的服务没有问题，那么就可以在旁边待命

（standby），以备在需要时进行配合。如果问题没有被及时解决，就会自动升级到，直到

SVP级别。

大家都知道，在亚马逊，不是按技能分工，而是按职责分工，也就是一个团队不是按前端、后端、

运维等来分工，而是按所负责的Service来分工。所以，亚马逊的开发人员都是前端、后端、测

试、运维全部都要干的。而亚马逊有很多的服务，一旦出现问题，为了避免一个工单在各个团

队流转，需要所有团队上线处理，这样是最快的。

如果我们的系统架构是分布式服务化的，那么一个用户的请求可能会经过很多的服务，开发和运维

起来是非常的。此时，跨团队跨部门的开发和运维就变得非常的重要了。就我的经历而言，在

故障发生时，亚马逊的处理过程是比较有效和快速的，尤其是能够快速地定位故障源。对于被影响

的其他团队也可以做一定的处理，比如做降级处理，这样可以控制故障的范围不被扩散。

故障源团队通常会有以下几种来恢复系统。

重启和限流。重启和限流主要解决的是可用性的问题，不是功能性的问题。重启还好说，但是限

流这个事就需要相关的流控中间件了。

回滚操作。回滚操作一般来说是解决新代码的bug，把代码回滚到之前的版本是快速的方式。

降级操作。并不是所有的代码变更都是能够被回滚的，如果无法回滚，就需要降级功能了。也就

是说，需要挂一个停止服务的故障公告，主要是事态扩大。

紧急更新。紧急更新是常用的，这个需要强大的自动化系统，尤其是自动化测试和自动化发

布系统。假如你要紧急更新1000多台服务器，没有一个强大的自动化发布系统是很难做到的。

也就是说，出现故障时，最重要的不是debug故障，而是尽可能地减少故障的影响范围，并尽可能

快地修复问题。

国内的很多公司，都是由专职的运维团队来处理线上问题的。然而，运维团队通常只能处理一些基

础设施方面的问题，或是非功能性的问题。对于一些功能性的问题，运维团队是完全没有能力处理

的，只能通过相应的联系人，把相关的开发人员叫到线上来看。而可能这个开发人员看到的是别的

系统有问题，又会叫上其它团队的人来。所以，一级一级地传递下去，会浪费很多时间。

故障前的准备工作

为了能够在故障时做得有条不紊，我们需要做一些前期的准备工作。这些准备工作做得越细，

那么故障处理起来也就越有条理。我们知道，故障来临时，一切都会变得。此时，对于需要处

理故障的我们来说，事可以乱，但人不能乱。如果人跟着事一起乱，那就是真正的了。

所以，我们需要做一些故障前的准备工作。在这里，我给出一些我的经验。

以用户功能为索引的服务和资源的全视图。首先，我们需要一个系统来记录前端用户操作界面和

后端服务，以及使用到的硬件资源之间的关联关系。这个系统有点像CMDB（配