分布式系统常见依赖故障治理及技术演进

首先抛一个问题，什么情况下你会认为淘宝网挂了？ 我相信关注这个问题的人很多，不过能给出确切答案的人并不多。因为这个看似简单的问题，真要回答起来好像也不是那么容易。今天的分享，我先试着给大家回答一下这个问题。

让我们从一张“简单”的页面说起。这张页面叫做商品详情页，对于大部分人来讲，这张页面是他们在淘宝完成一笔订单的第一步。而商品详情页的使命就是把商品的信息没有保留的展示给大家，引起大家的兴趣，引导大家完成购买或是收藏。从信息展示的角度来讲，商品详情页确实是一张非常简单的页面。

我们再来看一下商品详情页应用的后台架构。商品详情页是阿里最早实现静态化应用之一。那些与浏览者无关信息，比如商品标题、图片信息、销售属性组合等信息均直接进入缓存，其他和用户相关的，如优惠、库存、物流、服务等动态信息则通过异步调用方式填充至静态化后的页面框架内。为了在一张页面展示足够多可供决策信息，撩起用户的购买欲望，详情后台必须去依赖非常多的服务应用，聚合足够多的信息。少则几十，多则成百。从这个角度来讲，商品详情页面又是阿里依赖最复杂的应用之一。

互联网业务的一个主要特点是，业务迭代非常快，每天有新需求，每周都有新发布，每年都有大重构，每一次变化都有可能导致状况的发生。越是贴近用户的系统，受下游服务影响越大。那么我们不仅好奇，对于详情这个阿里最复杂的应用，下游发生一些状况时，系统会变成怎样？我们通过两个实验来观察一下：

实验一：假设后端的优惠、库存、物流发生故障，我们来观察一下商品详情页的表现。

乍一看，好像没什么问题。只是觉得页面清爽了一些。或许在这个信息过暴的时代，看着这么清新脱俗的页面，还有一点点暗爽。

在现场做了两个调查，观察大家对实验一的反映。调查 1 是请认为详情页故障了的同学请举手。结果是现场没有人举手（也可能是现场氛围还比较冷）；调查 2 是请大家来找茬，前后两个详情页有多少处不同？这次有一个妹子说出了正确的答案（同时也向妹子赠送了电子工业出版社出版的讲述阿里双 11 技术演进的《尽在双 11》书籍）。

没有对比就没有伤害，一共有 6 处不同。从功能角度，这铁定是一个故障页面。不过从用户体验和业务角度讲，少了这些信息也不影响商品购买，不影响核心用户体验。好像又是没故障？有点纠结，对吧？ 您先纠结一会儿，我们来进行第二个实验。

实验二：当商品详情的"商品"出了问题，商品详情会怎样？

详情还是那个详情，只不过是商品详情变成了错误详情。第一张页面：很抱歉，你查看的商品找不到了。有可能是你访问的方式不对，比如 URL 上面少了一些参数，也可能是后台真的出问题，对于用户还算是比较温柔的一种方式。第二张页面：很可能就是网站真的出问题了。比较可能的原因是后台没有合理的处理超时导致前端异常。不过说实话，这个页面我也非常少的见到。如果真的出现了，那基本就是一次非常严重的事故。

通过上面的两个实验，相信大家应该对于我们今天要介绍的一个概念"强弱依赖"有一些模糊的感觉了。 从感性的角度来讲，就是当下游依赖服务出现问题时，当前系统会受到一些影响，让用户有感觉的是强依赖，没感觉的是弱依赖。

不过这种定义不够严谨，因为总不能说没有用户访问时，就不算故障吧。所以也需要从理性角度定义一下：首先应该发生状况，其次应该是核心业务，最后是否带来损失。不影响核心业务流程，不影响系统可用性的依赖都可以叫做弱依赖，反之就是强依赖。

终于解释清楚什么是强弱依赖，那么做好强弱依赖治理到底有什么意义？抛开依赖模型来看强弱，意义不大。严谨的依赖模型应该包括关系、流量、强弱三个组成部分。

依赖关系定义依赖的方向，我依赖谁，谁依赖我。流量定义着每个应用、服务、方法调用的次数，强弱则定义着依赖的松紧程度。依赖治理就是通过科学的手段持续稳定地拿到关系、流量、强弱的数据。强弱依赖主要可以被应用到下面的场景：

• 系统改造验收：对于分布式系统，至少应该做到运行态中不会因为我依赖的系统出现故障，而引起当前应用出现可用性的问题，比如进程挂掉，频繁 FullGC，负载飙高等，何时何地都具备快速止血的能力。

• 限流降级参考：对于弱依赖，一般都要配置限流或是自动降级策略，比起通过拍脑袋或是经验值来设定，倒不如通过实际的故障测试来进行微调，比如对于下游出现超时情况，就可以通过实验得出基于线程池限流到底要填写多少数值。

• 应用启动顺序：理想情况下，应用启动更应该做到 0 强依赖启动。不过有一些情况无法做到。因此应用启动的依赖顺序也需要实时关注。特别是新 IDC、机房建站时，那个蜘蛛网一样的依赖关系，最好是通过系统方式获得。

• 故障根源定位：后台系统的故障，往往通过上一层的业务故障表现出来。故障处理讲究的是争分多秒，良好的强弱依赖，对于系统自动化诊断有非常大的助力作用。

• 依赖容量评估：正常调用链路下系统容量需要评估，当某个弱依赖挂掉时，整体的容量是否有变化。

  
  

说完背景，终于可以聊一下强弱依赖的技术实现。在阿里，强弱依赖的技术演进整体上分了 3 个阶段，每个阶段的方案的诞生都有其独特的时代背景和业务难点。现在回头看来，也可以看到当时技术的局限性和突破。

熟悉淘宝技术发展史的同学都知道，2008 年阿里刚刚完成一个代号为五彩石的项目，完成从巨石系统向服务化系统的改造。业务和开发模式上有了较大的发展，不过网状的依赖关系也带来了非常多的问题。这个纪元的主要特点是：故障频发，技术思路和方法都是以结果为导向，糙一点、结果精度差一点可以忍受。

模拟依赖故障技术上有三招，改代码 + 发布，远程 Debug+ 重启，登陆机器去执行一些 shell 命令操作。 好处是灵活随意，可以一定程度达到效果；坏处是成本高，影响环境稳定，你测试的时候其他人处于无法工作状态，影响效率。此外，这个阶段，因为分布式链路追踪技术还没起步，所以模拟依赖故障时，经常会漏掉一些主机或某些服务。故障的粒度也比较粗，对于一些 Linux 的命令，都是主机级别的。

阿里内部有一套日常环境，主要做上线前的集成测试。为了尽量减少对环境的影响。我们通过修改服务版本的方式，形成一个独立的测试环境。记得 11 年下半年，我开始做第一版的时候，我搭了淘宝 12 个核心应用的日常环境，踩坑无数，纯体力活，也算前无古人，后无来者了。

通过这套环境跑了几次结果，发给核心的业务 TL，大家很兴奋，貌似找到一条治理的路子。不过很快 了新问题，比如环境的运维归属问题，开发机器的干扰问题，以及对于业务的了解程度和测试粒度问题，所以在很长一段时间测试的范围都局限在交易核心链路。

第二个阶段的核心就是提效，从第一个阶段的痛点入手，解决人的成本和环境的问题。这个阶段之后，基本可以摆脱手工方式，效率上有大幅度提升。

这个阶段也引入了一些测试技术，其中用的比较多的是 Selenium，通过这种技术可以提前录制用户行为并转化为测试脚本，并且每一个步骤都可以截图记录，方便问题复查。

在这个时期，阿里中间件的技术有一定发展，分布式追踪技术出现，可以把用户访问的链条串联起来，排查问题的效率有了一定提升。同时所有的中间件，如 Nginx、消息、分布式服务调用、分布式数据库、软负载和配置中心等都做了改造，支持用户流量的标记、追踪和路由控制。基于上述这些技术进展，环境的问题就有非常大的突破。

在内部我们称为叫二套环境。它的核心原理是在基础环境之上，动态区分出一些小环境，他们分别是某个业务的子集。项目之间彼此独立，不会互相调用，只有当依赖的服务不在时，才会去访问基础环境的服务。数据库和缓存是公用的。

在这个阶段，我们不必再去修改代码的服务版本，每次发布后，代码的版本等能够自动化的保持一致，运维成本有所降低，野服务干扰的情况也有所缓解，人的介入非常的少。不过还是有一些问题亟待解决：

首先，二套环境的路由策略是和用户绑定的，也就是说需要提前去做一些配置；其次，域名上也有一些限制，加了 second 等前缀，测试路径中 URL 等复用率低的问题没有完全解决；第三，测试的粒度仍然很粗，独占机器，规模化推广时，机器成本和用例运行的成本还是很高；第四，故障场景缺失，只存在于基础环境的服务没法模拟的故障，如：数据库故障，缓存故障等。

2014 年的时候，我们的思维方式有了比较大的突破。我们不再纠结于环境和外部手段的改进，而是回归到强弱依赖关注最核心的部分。那就是业务影响和系统设计。能否实现一种只与代码设计和业务相关，而与外部环境无关的方案呢？

这期间有两个关键思路或是推论：

• 推论 1：我们要的是下游依赖出现故障现象，不必真的是下游服务提供方出现故障。只要消费方感觉下游出现故障即可。从这个思路来讲，商品详情如果要做强弱依赖测试，只要自己玩就 OK，不需要去折腾下游依赖的几十个应用。

• 推论 2：我们之所以需要单独搭建环境，为的就是控制故障的影响范围。那么我们可以换一下思路，就是我们只影响要发生故障的请求，其他的业务流量都放过。是不是就可以达到目的。本质上是一种对业务流量的筛查能力。

  
  

有了上面的思路，第一问题就是如何拦截用户的请求？拦截用户请求，让用户改造成本最低，没有什么地方比中间件更适合了。每个通用的远程调用接口，都是可以做文章的点，并且中间件之上的业务系统不用做任何改造。

下一个问题就是故障规则和业务识别，我们曾考虑在用户请求的入口就打上标记，置入故障规则，不过发现对于 post 请求，异步 js 请求，定时任务等都有比较大的改造成本，且有安全隐患。 所以就增加了一个服务端，直接下发故障规则到依赖插件上。

故障插件通过对流量的调用拦截 + 业务识别，唯一确定影响哪一个请求，然后通过故障规则判断是注入异常还是超时，从而达到模拟故障的效果。 因为插件可扩展的设计，所以我们默认是可以同时注入多种故障场景的，同时插件也会把影响到请求的详细信息异步上报给服务端做分析。

理论上通过上述的方案，在业务流量输入方面，我们没有任何要求。无论是人的自发测试行为，还是机器的测试行为，都没有任何限制。只不过为最大限度复用已有的测试用例积累，提高自动化程度，我们设计了一套用例注解，封装了和强弱依赖服务端的通信。利用 Junit 生命周期的特点，完成故障规则的下发和清除。

任何一个测试用例，20 秒之内改造成一个强弱依赖的测试用例。在结果输出方面，会详细的展示一次强弱依赖检测的过程，以及测试用例涉及到的链路的依赖变化。到此阶段，强弱依赖真正达到了一个相对里程碑的版本，2014 年开始，强弱依赖也作为双 11 必做的一个横向项目。

下面是强弱依赖注解和依赖系统的示例：

总的来说，整个强弱依赖技术演进历史，就是对数据准确性，稳定性，成本、效率的不懈追求，并在这几者之间达成一个动态平衡。

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

众所周知，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 能力。

  
  

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

原创：周洋

分布式系统常见依赖故障治理及技术演进

首先抛一个问题，什么情况下你会认为淘宝网挂了？ 我相信关注这个问题的人很多，不过能给出确切答案的人并不多。因为这个看似简单的问题，真要回答起来好像也不是那么容易。今天的分享，我先试着给大家回答一下这个问题。

让我们从一张“简单”的页面说起。这张页面叫做商品详情页，对于大部分人来讲，这张页面是他们在淘宝完成一笔订单的第一步。而商品详情页的使命就是把商品的信息没有保留的展示给大家，引起大家的兴趣，引导大家完成购买或是收藏。从信息展示的角度来讲，商品详情页确实是一张非常简单的页面。

我们再来看一下商品详情页应用的后台架构。商品详情页是阿里最早实现静态化应用之一。那些与浏览者无关信息，比如商品标题、图片信息、销售属性组合等信息均直接进入缓存，其他和用户相关的，如优惠、库存、物流、服务等动态信息则通过异步调用方式填充至静态化后的页面框架内。为了在一张页面展示足够多可供决策信息，撩起用户的购买欲望，详情后台必须去依赖非常多的服务应用，聚合足够多的信息。少则几十，多则成百。从这个角度来讲，商品详情页面又是阿里依赖最复杂的应用之一。

互联网业务的一个主要特点是，业务迭代非常快，每天有新需求，每周都有新发布，每年都有大重构，每一次变化都有可能导致状况的发生。越是贴近用户的系统，受下游服务影响越大。那么我们不仅好奇，对于详情这个阿里最复杂的应用，下游发生一些状况时，系统会变成怎样？我们通过两个实验来观察一下：

实验一：假设后端的优惠、库存、物流发生故障，我们来观察一下商品详情页的表现。

乍一看，好像没什么问题。只是觉得页面清爽了一些。或许在这个信息过暴的时代，看着这么清新脱俗的页面，还有一点点暗爽。

在现场做了两个调查，观察大家对实验一的反映。调查 1 是请认为详情页故障了的同学请举手。结果是现场没有人举手（也可能是现场氛围还比较冷）；调查 2 是请大家来找茬，前后两个详情页有多少处不同？这次有一个妹子说出了正确的答案（同时也向妹子赠送了电子工业出版社出版的讲述阿里双 11 技术演进的《尽在双 11》书籍）。

没有对比就没有伤害，一共有 6 处不同。从功能角度，这铁定是一个故障页面。不过从用户体验和业务角度讲，少了这些信息也不影响商品购买，不影响核心用户体验。好像又是没故障？有点纠结，对吧？ 您先纠结一会儿，我们来进行第二个实验。

实验二：当商品详情的"商品"出了问题，商品详情会怎样？

详情还是那个详情，只不过是商品详情变成了错误详情。第一张页面：很抱歉，你查看的商品找不到了。有可能是你访问的方式不对，比如 URL 上面少了一些参数，也可能是后台真的出问题，对于用户还算是比较温柔的一种方式。第二张页面：很可能就是网站真的出问题了。比较可能的原因是后台没有合理的处理超时导致前端异常。不过说实话，这个页面我也非常少的见到。如果真的出现了，那基本就是一次非常严重的事故。

通过上面的两个实验，相信大家应该对于我们今天要介绍的一个概念"强弱依赖"有一些模糊的感觉了。 从感性的角度来讲，就是当下游依赖服务出现问题时，当前系统会受到一些影响，让用户有感觉的是强依赖，没感觉的是弱依赖。

不过这种定义不够严谨，因为总不能说没有用户访问时，就不算故障吧。所以也需要从理性角度定义一下：首先应该发生状况，其次应该是核心业务，最后是否带来损失。不影响核心业务流程，不影响系统可用性的依赖都可以叫做弱依赖，反之就是强依赖。

终于解释清楚什么是强弱依赖，那么做好强弱依赖治理到底有什么意义？抛开依赖模型来看强弱，意义不大。严谨的依赖模型应该包括关系、流量、强弱三个组成部分。

依赖关系定义依赖的方向，我依赖谁，谁依赖我。流量定义着每个应用、服务、方法调用的次数，强弱则定义着依赖的松紧程度。依赖治理就是通过科学的手段持续稳定地拿到关系、流量、强弱的数据。强弱依赖主要可以被应用到下面的场景：

• 系统改造验收：对于分布式系统，至少应该做到运行态中不会因为我依赖的系统出现故障，而引起当前应用出现可用性的问题，比如进程挂掉，频繁 FullGC，负载飙高等，何时何地都具备快速止血的能力。

• 限流降级参考：对于弱依赖，一般都要配置限流或是自动降级策略，比起通过拍脑袋或是经验值来设定，倒不如通过实际的故障测试来进行微调，比如对于下游出现超时情况，就可以通过实验得出基于线程池限流到底要填写多少数值。

• 应用启动顺序：理想情况下，应用启动更应该做到 0 强依赖启动。不过有一些情况无法做到。因此应用启动的依赖顺序也需要实时关注。特别是新 IDC、机房建站时，那个蜘蛛网一样的依赖关系，最好是通过系统方式获得。

• 故障根源定位：后台系统的故障，往往通过上一层的业务故障表现出来。故障处理讲究的是争分多秒，良好的强弱依赖，对于系统自动化诊断有非常大的助力作用。

• 依赖容量评估：正常调用链路下系统容量需要评估，当某个弱依赖挂掉时，整体的容量是否有变化。

  
  

说完背景，终于可以聊一下强弱依赖的技术实现。在阿里，强弱依赖的技术演进整体上分了 3 个阶段，每个阶段的方案的诞生都有其独特的时代背景和业务难点。现在回头看来，也可以看到当时技术的局限性和突破。

熟悉淘宝技术发展史的同学都知道，2008 年阿里刚刚完成一个代号为五彩石的项目，完成从巨石系统向服务化系统的改造。业务和开发模式上有了较大的发展，不过网状的依赖关系也带来了非常多的问题。这个纪元的主要特点是：故障频发，技术思路和方法都是以结果为导向，糙一点、结果精度差一点可以忍受。

模拟依赖故障技术上有三招，改代码 + 发布，远程 Debug+ 重启，登陆机器去执行一些 shell 命令操作。 好处是灵活随意，可以一定程度达到效果；坏处是成本高，影响环境稳定，你测试的时候其他人处于无法工作状态，影响效率。此外，这个阶段，因为分布式链路追踪技术还没起步，所以模拟依赖故障时，经常会漏掉一些主机或某些服务。故障的粒度也比较粗，对于一些 Linux 的命令，都是主机级别的。

阿里内部有一套日常环境，主要做上线前的集成测试。为了尽量减少对环境的影响。我们通过修改服务版本的方式，形成一个独立的测试环境。记得 11 年下半年，我开始做第一版的时候，我搭了淘宝 12 个核心应用的日常环境，踩坑无数，纯体力活，也算前无古人，后无来者了。

通过这套环境跑了几次结果，发给核心的业务 TL，大家很兴奋，貌似找到一条治理的路子。不过很快 了新问题，比如环境的运维归属问题，开发机器的干扰问题，以及对于业务的了解程度和测试粒度问题，所以在很长一段时间测试的范围都局限在交易核心链路。

第二个阶段的核心就是提效，从第一个阶段的痛点入手，解决人的成本和环境的问题。这个阶段之后，基本可以摆脱手工方式，效率上有大幅度提升。

这个阶段也引入了一些测试技术，其中用的比较多的是 Selenium，通过这种技术可以提前录制用户行为并转化为测试脚本，并且每一个步骤都可以截图记录，方便问题复查。

在这个时期，阿里中间件的技术有一定发展，分布式追踪技术出现，可以把用户访问的链条串联起来，排查问题的效率有了一定提升。同时所有的中间件，如 Nginx、消息、分布式服务调用、分布式数据库、软负载和配置中心等都做了改造，支持用户流量的标记、追踪和路由控制。基于上述这些技术进展，环境的问题就有非常大的突破。

在内部我们称为叫二套环境。它的核心原理是在基础环境之上，动态区分出一些小环境，他们分别是某个业务的子集。项目之间彼此独立，不会互相调用，只有当依赖的服务不在时，才会去访问基础环境的服务。数据库和缓存是公用的。

在这个阶段，我们不必再去修改代码的服务版本，每次发布后，代码的版本等能够自动化的保持一致，运维成本有所降低，野服务干扰的情况也有所缓解，人的介入非常的少。不过还是有一些问题亟待解决：

首先，二套环境的路由策略是和用户绑定的，也就是说需要提前去做一些配置；其次，域名上也有一些限制，加了 second 等前缀，测试路径中 URL 等复用率低的问题没有完全解决；第三，测试的粒度仍然很粗，独占机器，规模化推广时，机器成本和用例运行的成本还是很高；第四，故障场景缺失，只存在于基础环境的服务没法模拟的故障，如：数据库故障，缓存故障等。

2014 年的时候，我们的思维方式有了比较大的突破。我们不再纠结于环境和外部手段的改进，而是回归到强弱依赖关注最核心的部分。那就是业务影响和系统设计。能否实现一种只与代码设计和业务相关，而与外部环境无关的方案呢？

这期间有两个关键思路或是推论：

• 推论 1：我们要的是下游依赖出现故障现象，不必真的是下游服务提供方出现故障。只要消费方感觉下游出现故障即可。从这个思路来讲，商品详情如果要做强弱依赖测试，只要自己玩就 OK，不需要去折腾下游依赖的几十个应用。

• 推论 2：我们之所以需要单独搭建环境，为的就是控制故障的影响范围。那么我们可以换一下思路，就是我们只影响要发生故障的请求，其他的业务流量都放过。是不是就可以达到目的。本质上是一种对业务流量的筛查能力。

  
  

有了上面的思路，第一问题就是如何拦截用户的请求？拦截用户请求，让用户改造成本最低，没有什么地方比中间件更适合了。每个通用的远程调用接口，都是可以做文章的点，并且中间件之上的业务系统不用做任何改造。

下一个问题就是故障规则和业务识别，我们曾考虑在用户请求的入口就打上标记，置入故障规则，不过发现对于 post 请求，异步 js 请求，定时任务等都有比较大的改造成本，且有安全隐患。 所以就增加了一个服务端，直接下发故障规则到依赖插件上。

故障插件通过对流量的调用拦截 + 业务识别，唯一确定影响哪一个请求，然后通过故障规则判断是注入异常还是超时，从而达到模拟故障的效果。 因为插件可扩展的设计，所以我们默认是可以同时注入多种故障场景的，同时插件也会把影响到请求的详细信息异步上报给服务端做分析。

理论上通过上述的方案，在业务流量输入方面，我们没有任何要求。无论是人的自发测试行为，还是机器的测试行为，都没有任何限制。只不过为最大限度复用已有的测试用例积累，提高自动化程度，我们设计了一套用例注解，封装了和强弱依赖服务端的通信。利用 Junit 生命周期的特点，完成故障规则的下发和清除。

任何一个测试用例，20 秒之内改造成一个强弱依赖的测试用例。在结果输出方面，会详细的展示一次强弱依赖检测的过程，以及测试用例涉及到的链路的依赖变化。到此阶段，强弱依赖真正达到了一个相对里程碑的版本，2014 年开始，强弱依赖也作为双 11 必做的一个横向项目。

下面是强弱依赖注解和依赖系统的示例：

总的来说，整个强弱依赖技术演进历史，就是对数据准确性，稳定性，成本、效率的不懈追求，并在这几者之间达成一个动态平衡。

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

众所周知，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 能力。

  
  

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

原创：周洋