故障演练的基本原则和最佳系统设计实践

众所周知，2017 年不大太平，业界出现了很多大故障。

2017 年 3 月 1 日，弗吉尼亚州数据中心出现故障，亚马逊 S3 服务出现了较高的错误率，直接影响到成千上万个在线服务；2017 年 1 月 31 日， GibLab 同学线上数据库变更时，遇到突发了一个情况。因为操作失误，导致整个生产数据库被误删除，丢失 6 个小时的数据；

2017 年 2 月份国内的一家经常被用来测试网络连通性的友商也出现了故障，工信部迅速关注，并紧急约谈了相关公司。同时下发紧急通知要求 BAT 等各重点互联网企业吸取教训，业界一片哗然。

这时候，有一家公司显得特别淡定，那就是 Netflix。 Netflix 是一家服务全球的在线影片租赁提供商，他的核心业务完全架设在 AWS 上面。据新闻揭露，Netflix 在亚马逊故障时可以很快的恢复正常，因为他们内部有一个"防故障"的基础设施。听起来，好像是我们需要的东西。

深入调查之后，发现防故障基础设施背后是一个猴子军团。

早在 2012 年，Netflix 就发布了 Chaos Monkey。用来在随机杀死实例，据官方数据指出，到目前累计杀死 65,000 个节点。他们的测试策略也比较有趣：在工作时间在生产和测试环境运行，目标测试系统的健壮性，训练后备人员，让恢复更简洁、快速、自动；Latency Monkey 的作用就是让某台机器的请求或返回变慢，观察系统的表现； Chaos Gorilla 的能力是搞挂一个机房，宏观验证业务容灾和恢复的能力。Netflix 发布猴子军团的原因是因为，他们很早就吃过云故障的亏，所以本能是认为云设施是不可靠的，必须在通过演练来验证软件层面的容灾。

古代有个哲学家说过"没有人曾经两次踏进同一条河流"，因为无论是这条河还是这个人都已不同。故障也是类似的，故障发生的时间地点，影响流量，与故障打交道的人都没法完全相同。从这个角度看，故障治理本身是一个伪命题，都是在解决过去某一个时刻的问题。

不过从程序员视角（我习惯叫上帝视角），任何故障的原因都是可被定位的，避免相同原因重复引发故障，是每个程序员应该执着追求的目标。电商历史上遇到了非常多有代表性的故障，为了不让故障重复发生，阿里内部也打造了一套"防故障"的基础设施。

2015 年 5 月 27 日，因为光纤中断的问题，支付宝大规模宕机事故，公司内部得出一个结论：任何基础设施、生产系统、任何流程都可能出现问题，没有经过重大灾难验证的容灾设施都是耍流氓。 启动了代号为虎虎虎的生产突袭项目，用来验证异地多活的质量。

2012 年，完成交易的同城双活后，就启动了同城容灾演练，也叫断网演练。验证核心系统的同城一个机房挂掉的情况下，是否还可以正常工作。

2011 年，开始做强弱依赖的治理和建设，希望提前发现因为依赖问题导致的系统故障，系统的代号是 EOS（出处是古希腊神话中的黎明女神，语意是能够把纷乱的依赖关系梳理清楚）。

可以看到，这三大件和 Netflix 的猴子军团从功能上基本上是对标的。那是不是就应该没有故障，安枕无忧了呢？ 答案铁定不是。

理想很丰满，现实很骨感。阿里巴巴因为其多元化的业务场景和日益复杂的技术架构，会遇到各式各样的故障，故障治理的难度相比流媒体服务故障治理，难度是也增量了几个台阶。

前面介绍过的强弱依赖和容灾演练只能覆盖到部分故障。如果对故障整体做初步画像，故障整体可以分为 IaaS 层、PaaS 层、SaaS 层的故障，每一层都可能有很多故障触发原因和表现。那么对于这么多种类繁杂的故障，内心一定是懵逼的。我们要如何重现，进而避免这么多繁杂的故障呢？

熟悉三体的同学应该听说过"降维攻击"这个词，不妨让我们把维度降低一下，换一个视角看故障：

任何故障，一定是硬件如 IaaS 层，软件如 PaaS 或 SaaS 的故障。 并且有个规律，硬件故障的现象，一定可以在软件故障现象上有所体现。

故障一定隶属于单机或是分布式系统之一，分布式故障包含单机故障。

对于单机或同机型的故障，以系统为视角，故障可能是当前进程内的故障，比如：如 FullGC，CPU 飙高； 进程外的故障，比如其他进程突然抢占了内存，导致当前系统异常等。

同时，还可能有一类故障，可能是人为失误，或流程失当导致，这部分我们今天不做重点讨论。

任何故障都可以套入到这个故障模型中。有了这个模型，我们就可以开始来设计模拟故障的演练系统。

所以在内部，我们起了一个代号叫做"大圣归来"的项目，项目名叫做"故障演练"，承载的产品叫做 MonkeyKing。MonkeyKing 是中国美猴王的意思，看重的是孙悟空高强的本领（火眼精金、七十二变）和极具反叛的精神来，希望用一种创新的思路来保证稳定性。

我们的系统实现，也是围绕前文讨论的故障模型来设计的：

在客户机器部署 OS 层的故障插件，用来模拟硬件层的故障和单机进程外的故障。

对于应用进程内的故障，提供插拔式的故障插件，也可以用户按照我们的故障 API 做自己的实现。

对于分布式故障，则通过服务端按照 IP 来控制故障的范围。

对于一些因为各种原因无法触及的应用，比如数据库。我们提供了一个故障三方实现的标准，供故障服务接入。

通过上面的方式，基本上就把技术型故障的模型就 cover 全了。

在去年的双 11 中，故障演练的应用场景主要应用在图中的几个场景。 按照业务流量、压测流量的峰值可以划为 4 个象限。具体案例如下：

预案有效性：过去的预案测试的时候，线上没有问题，所以就算测试结果符合预期，也有可能是有意外但是现象被掩藏了。

监控报警：报警的有无、提示消息是否准确、报警实效是 5 分钟还是半小时、收报警的人是否转岗、手机是否欠费等，都是可以 check 的点。

故障复现：故障的后续 Action 是否真的有效，完成质量如何，只有真实重现和验证，才能完成闭环。发生过的故障也应该时常拉出来练练，看是否有劣化趋势。

架构容灾测试：主备切换、负载均衡，流量调度等为了容灾而存在的手段的时效和效果，容灾手段本身健壮性如何。

参数调优：限流的策略调优、报警的阈值、超时值设置等。

故障模型训练：有针对性的制造一些故障，给做故障定位的系统制造数据。

故障突袭、联合演练：通过蓝军、红军的方式锻炼队伍，以战养兵，提升 DevOps 能力。

故障演练宣言：把故障以场景化的方式沉淀，以可控成本在线上模拟故障，让系统和工程师平时有更多实战机会 ，加速系统、工具、流程、人员的进步。

转载请注明出处。