你好，我是陈浩网名猪耳朵house.我们多多少少呢都会经历一些线上的故障。

在我自己的职业生涯中呢就经历过很多的线上故障。

说实话，线上故障是我们技术人员成长中必须要经历的事儿。

从故障中呢，我们可以吸取到很多的教训，也能让我们学到很多书本上学不到的知识。

那坑踩多了之后呢，我们会变得越来越有经验，也就成为老司机了。

不过呢我看到很多公司处理线上故障的方式并不科学，而且还存在着很多的问题。

所以啊今天这节课呢我就来分享一些我的经验。

那这些经验呢主要来自亚马逊和阿里这两家互联网公司。

希望我个人的经验总结，希望这套方法呢能够对你参考资料:https://51gx.top/detail/253有所帮助。

首先说在故障发生的时候要怎么做？那在故障发生的时候呢，最重要的是快速恢复故障。

而快速恢复故障的前提是快速定位故障源。

因为在很多分布式系统中呢，一旦发生故障，就会出现多米诺骨牌效应。

也就是说系统会随着一个故障开始一点一点的波及到其他系统，而且这个过程可能会很快。

那一旦很多系统啊都在报警，想要快速定位到故障源啊，就不是一件简单的事了。

那在亚马逊内部呢，每个开发团队啊至少都会有一位on call的工程师。

在on call的时候啊，工程师要专心处理线上的故障，轮换周期呢是每人一周。

那一旦发生比较大的故障，比如s一全部不可用，或者说s二某功能不可用，而且啊还找不到替代方案。

那么这个故障呢就会被提交到一个工单系统里啊，几乎所有相关团队on call的工程师啊都会被叫到线上去处理问题。

整个工作流是这样的，工程师先线上签到啊，然后自查自己的服务。

那如果自己的服务没有问题，那么就可以在旁边待命，以备在需要的时候进行配合。

那如果问题没有被及时解决，就会自动升级到高层，直到SVP级别。

那大家都知道啊，在亚马逊不是按技能分工，而是按职责分工。

也就是说一个团队不是按前端后端运维等来分工，而是按所负责service来分工的。

所以呢亚马逊的开发人员啊都是前端后端测试运维全部都要干的。

而亚马逊内部呢有很多的服务一旦出现问题，为了避免一个工单在各个团队流转啊，他需要所有的团队上线处理。

那这样是最快的那如果我们的系统架构呢是分布式服务化的，那么一个用户的请求就会经过很多的服务。

那开发和运维起来啊是非常麻烦的那这个时候呢跨团队跨部门的开发和运维就变得非常重要的那就我的经历来说呢，在故障发生的时候，亚马逊的处理流程是比较有效和快速的，尤其是能够快速的定位故障源。

那对于被影响的其他团队呢，也可以做一定的处理。

比如说降级处理。

那这样呢可以控制故障的范围，不被扩散。

故障源所在的团队呢通常有这么几种手段来恢复系统。

首先呢是重启和限流，而重启和限流呢主要解决的是可用性的问题，不是功能性的问题。

那重启还好说，但是限流这个事儿就需要相关的流控中间件了。

那第二呢是回滚操作。

那回滚操作一般来说啊主要是为了解决新代码的bug.那么把代码回滚到之前的版本呢是比较快速的方式。

那第三种手段呢是降级操作，因为并不是所有的代码变更都是能够回滚的那如果无法回滚啊，就需要降级功能了。

也就是说你要挂一个停止服务的故障公告，主要啊是不要把事态扩大。

那还有一种手段呢是紧急更新，紧急更新是常用的手段。

那这个呢就需要强大的自动化系统，尤其是自动化的测试和自动化的发布系统。

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

也就是说出现故障的时候呢，最重要的不是第bug故障，而是要尽可能的减少故障的影响范围，并且啊尽可能快的修复问题。

那国内的很多公司呢都是有专职的运维团队来处理线上问题的。

但是呢运维团队啊通常只能处理一些基础设施方面的问题，或者是非功能性的问题。

那对于一些功能性的问题呢，运维团队啊是完全没有能力处理的，只能通过相应的联系人把相关的开发人员叫到线上来看。

而可能这个开发人员呢看到的是别的系统有问题啊，所以又会叫上其他团队的人过来。

那这样一级一级的传递下去啊，会浪费很多的时间。

所以为了能在面临故障的时候做的有条不紊，我们就需要做一些前期的准备工作。

那这些准备工作做的越细，故障处理起来啊也就越有条理。

我们知道啊故障发生的时候啊，一切都会变得混乱。

那这个时候呢，对于需要处理故障的我们来说啊，事儿可以乱，但人不能乱。

那如果人跟着事儿一起乱，那就是真真的混乱了。

所以呢我们需要做一些故障前的备备作。

那在这里呢我给出一些我的经验。

第一条经验呢就是我们要做一个以用户功能为索引的服务和资源的诠释图。

首先呢我们需要一个系统来记录前端用户的操作界面和后端服务，还有服务使用到的硬件资源啊，它们之间的关键关系。

那这个系统呢有点像CMDB啊，也就是配置管理数据库。

但是啊比CMDB要大得多，因为它是以用户端的功能来做索引的。

然后呢再把后端的服务服务之间的调用关系，那服务使用到的资源都关联起来，做成一个视图。

那这个视图呢最好是由相应的自动化监控系统来生成。

那有了这个资源图之后呢，我们就可以很容易的找到处理故障的路径了。

啊，这就好像一张地图啊，如果没有地图，我们就只能像一只无头苍蝇一样乱世了。

那我的第二条经验呢，就是要给地图里面的各个服务制定关键指标，以及一套运维流程和工具，包括应急方案。

那以用户功能为索引，给每个用户功能的服务，都制定一个服务功障的检测处理和恢复手册，还有相关的检测、查错或者恢复的运维工具。

那对于基础层和一些通用的中间件呢，也需要有相应的最佳时间的方法。

比如REDISS啊，我们应该怎么检查它是否存在了问题，怎么查看它的健康和运行状态？那它的关键指标有哪些？面对常见的故障，应该怎么应对？服务不可用的服务方案是什么？服务需要回滚了，应该怎么操作等等。

这个呀就好像是一个导航仪能够告诉你怎么做，而没有导航仪呢就没有章法，就会导致混乱。

我的第三条经验呢就是要设定不同故障等级的处理方式。

比如亚马逊呢，一般就把故障分为四级，一级呢是全功障，可用有级呢是某功能不可用，而且啊没有替代方案。

那三级呢是某功能不可用，但是有替代方案。

四级呢是非功能性故障，或者是用户不关心的故障。

那阿里内部呢分类更多样一些，有时候还会根据影响用户的多少来定故障等级。

那制定故障等级呢，主要是为了确定一个故障，要牵扯多大规模的人员来处理。

那故障级别越高，牵扯进来的人啊就越多，参与进来的管理层级别啊也就越高。

就像亚马逊的全员上线uncle一样啊，这就好像是我们社会中常用的红色警报、橙色警报以及黄色警报之类的，会触发不同的处理流程。

那我的第四条经验呢就是要进行故障，演练，故障呢是需要演练的，因为故障并不是时常发生的，但是我们又需要不断提升处理故障的能力，所以呢就需要经常演练。

那一些大公司，比如netflix啊，会有一个叫chaos monkey的东西，会随机的在生产线上乱来。

那facebook呢也会有一些故障演习，比如随机关掉线上的一些服务器。

总之啊要提升故障处理水平最好的方式啊，就是实践践的多了，处理的多了才能驾轻就熟。

那故障演练呢就是一个非常好的实践。

另外呢要减少线上故障的影响范围啊，通过灰度发布系统来发布呢是一个很不错的方式。

毕竟呢我们在测试环境中啊是很难模拟出线上环境的所有情况的。

所以在生产线上进行灰度发布，或者是AB测试是一件很好的事。

那亚马逊的发布系统呢就有一个叫web lab的系统，那它就是用来做灰度发布的。

另外呢亚马逊全球啊会有多个站点，一般来说呢它会先发中国区啊，如果中国区没什么问题了，就发日本区，然后再发欧洲区。

最后呢是美国区。

那如果你没有很多个站点的话，那么就需要一个流量分配系统来做这个事儿了。

好啦，我今天就分享这么多。

我觉得啊只要能做好上面那几点，你处理起故障来啊，就一定会游刃有余了。

在这节课的末尾呢，我想发个邀请给你，请你来评论区聊一聊你所经历过的线上故障，以及有哪些比较好的故障处理方法。