混沌工程（ChaosEngineering）初识.pdf

胡笃珍

698

10页

1次

2022-05-17

5墨值下载

混沌工程（混沌工程（ChaosEngineering）初识）初识

混沌工程是在分布式系统上进行实验的学科，目的是建立对系统抵御生产环境中失控条件的能力以及信心。

一、概述

工程师团队最不愿碰到的便是大半夜被电话叫醒，开始紧张地查验问题，处理故障以及恢复服务。也许就是因为睡前的一个很

小的变更，因某种未预料到的场景，引起蝴蝶效应，导致大面积的系统混乱、故障和服务中断，对客户的业务造成影响。特别

是近几年，尽管有充分的监控告警和故障处理流程，这样的新闻在 IT 行业仍时有耳闻。问题的症结便在于，对投入生产的复

杂系统有多少信心。监控告警和故障处理都是事后的响应与被动的应对，那有没有可能提前发现这些复杂系统的缺陷呢？

混沌工程在分布式系统上进行由经验指导的受控实验，观察系统行为并发现系统缺陷，以建立对系统在规模增大时因意外条件

引发混乱的能力和信心。

1. 混沌工程的发展简史

2008年8月， Netflix 主要数据库的故障导致了三天的停机， DVD 租赁业务中断，多个国家的大量用户受此影响。之后 Netflix

工程师着手寻找替代架构，并在2011年起，逐步将系统迁移到 AWS 上，运行基于微服务的新型分布式架构。这种架构消除

了单点故障，但也引入了新的复杂性类型，需要更加可靠和容错的系统。为此， Netflix 工程师创建了 Chaos Monkey ，会随

机终止在生产环境中运行的 EC2 实例。工程师可以快速了解他们正在构建的服务是否健壮，有足够的弹性，可以容忍计划外

的故障。至此，混沌工程开始兴起。

图中展示了混沌工程从2010年演进发展的时间线：

2010年 Netflix 内部开发了 AWS 云上随机终止 EC2 实例的混沌实验工具：Chaos Monkey

2011年 Netflix release了其猴子军团工具集：Simian Army

2012年 Netflix 向社区开源由 Java 构建 Simian Army，其中包括 Chaos Monkey V1 版本

2014年 Netflix 开始正式公开招聘 Chaos Engineer

2014年 Netflix 提出了故障注入测试（FIT），利用微服务架构的特性，控制混沌实验的爆炸半径

2015年 Netflix release了 Chaos Kong ，模拟AWS区域（Region）中断的场景

2015年 Netflix 和社区正式提出混沌工程的指导思想 – Principles of Chaos Engineering

2016年 Kolton Andrus（前 Netflix 和 Amazon Chaos Engineer ）创立了 Gremlin ，正式将混沌实验工具商用化

2017年 Netflix 开源 Chaos Monkey 由 Golang 重构的 V2 版本，必须集成 CD 工具 Spinnaker（持续发布平台）来使用

2017年 Netflix release了 ChAP （Chaos Automation Platform, 混沌实验自动平台），可视为应用故障注入测试（FIT）的加

强版

2017年由Netflix 前混沌工程师撰写的新书“混沌工程”在网上出版

2017年 Russell Miles 创立了 ChaosIQ 公司，并开源了 chaostoolkit 混沌实验框架

Netflix公司介绍

2. Chaos Monkey & Simian Army

为了更好的理解混沌工程，这里我们再着重介绍一下Chaos Monkey和Simian Army。Chaos Monkey 通过关停一个或多个虚

拟机来模拟 service 实例的失效。Chaos Monkey 的名字来源于其工作的方式：如同一只野生的、武装了的猴子，在数据中心

释放后，造成的严重破坏。

Chaos Monkey 的原则：避免大多数失效的主要方式就是经常失效。失效一定会发生，并且无法避免。在大多数情况下，我们

的应用设计要保证当服务的某个实例下线时仍能继续工作，但是在那些特殊的场景下，我们需要确保有人在值守，以便解决问

题，并从问题中进行经验学习。基于这个想法，Chaos Monkey 仅会在工作时间内被使用，以保证工程师能发现警告信息，并

作出适当的回应。

混沌工程实验像 Chaos Monkey 只是杀杀机器而已？这是错误的理解。回溯混沌工程发展的时间线，业界对混沌工程的理解

是逐步深入的。Netflix 开发的 Chaos Monkey 成为了混沌工程的开端，但混沌工程不仅仅是 Chaos Monkey 这样一个随机终

止 EC2 实例的实验工具。随后混沌工程师们发现，终止 EC2 实例只是其中一种实验场景。因此， Netflix 提出了 Simian

Army 猴子军团工具集，除了 Chaos Monkey 外还包括：

Chaos Gorilla：Chaos Monkey的升级版，模拟整个Amazon Availability Zone的故障，以此验证在不影响用户，且无需人工干

预的情况下，能够自动进行可用区的重新平衡。

Chaos Kong：Chaos Gorilla的升级版，模拟整个region（一个region由多个Amazon Availability Zone组成）的故障。

Latency Monkey：在RESTful服务的调用中引入人为的延时来模拟服务降级，测量上游服务是否会做出恰当响应。通过引入长

时间延时，还可以模拟节点甚至整个服务不可用。

Conformity Monkey：查找不符合最佳实践的实例，并将其关闭。例如，如果某个实例不在自动伸缩组里，那么就该将其关

闭，让服务所有者能重新让其正常启动。

Doctor Monkey：查找不健康实例的工具，除了运行在每个实例上的健康检查，还会监控外部健康信号，一旦发现不健康实例

就会将其移出服务组。（隔离出服务，并且给相关人员足够的纠错时间，最终再关闭。）

Janitor Monkey：查找不再需要的资源，将其回收，这能在一定程度上降低云资源的浪费。

Security Monkey：这是Conformity Monkey的一个扩展，检查系统的安全漏洞，同时也会保证SSL和DRM证书仍然有效。

10-18 Monkey：进行本地化及国际化的配置检查，确保不同地区、使用不同语言和字符集的用户能正常使用Netflix。

使用 Simian Army 进行混沌工程实验，看起来似乎已经很完美。类似像 Latency Monkey 的引入，由于服务之间的调用链传

递，到最后这个小的扰动到底会引发多大的故障，没有人可以预测。在生产上做这样不可控的实验，是很危险的。随着故障注

入测试（FIT，Failure Injection Testing）的提出，社区开始关注利用应用架构的特性（特别是微服务架构）来控制实验的爆

炸半径，比如 Netflix 使用 Zuul 强大的流量检查和管理功能，将受影响的请求隔离到特定的测试帐户或特定设备，避免100％

的混乱。（本文来自公众号：朱小厮的博客，ID: hiddenkafka）

进一步分析发现， FIT 的执行过程也影响了整个系统的监控指标，即实验群体与其他非实验群体的统计指标混合不可分辨：无

法确定实验的进行时间，无法评估其影响是否超过了系统本身的噪音。为了进一步的区分，则需要进行更多更大的实验，这将

有可能给用户带来不必要的中断。因此需要对实验集群和非实验群集的流量配比进行精细控制，同时因应无人值守的实验要

求，则引入微服务架构中的断路器，如其超出预定义的误差预算，自动结束实验。这就是为何 Netflix 提出了新的 ChAP 以加

强故障注入测试。

综上所述，混沌工程的发展不是一蹴而就的， Chaos Monkey 是其开端，但社区对混沌工程的理解在逐步深入，从对基础设

施的扰动（ EC2 实例随机终止等），到利用应用网关控制爆炸半径，再到精细化流量配比以区分影响，直至引入断路器实现

真正的无人值守。

混沌工程9年来的发展，由浅入深，由基础设施演进到应用架构，不是单单运维看看就好。今天，许多公司(包括Google、

Amazon、Microsoft、Germlin Inc.、University of California、Github、Thoughtworks等）都使用某种形式的混沌工程实验，

来提高现代架构的可靠性。

混沌工程也同样适用于传统行业，如大型金融机构、制造业和医疗机构。交易依赖复杂系统吗？有大型银行正在使用混沌工程

来验证交易系统是否有足够的冗余。是否有人命悬一线？在美国，混沌工程在许多方面被当做模型应用在了临床试验系统中，

从而形成了美国医疗验证的黄金标准。横跨金融、医疗、保险、火箭制造、农业机械、工具制造、再到数字巨头和创业公司，

混沌工程正在成为复杂系统改进学科的立足点。

3. 混沌工程与传统测试之间的区别

混沌工程和传统测试（故障注入FIT、故障测试）在关注点和工具集上都有很大的重叠。譬如，在Netflix的很多混沌工程实验

研究的对象都是基于故障注入来引入的。混沌工程和这些传统测试方法的主要区别在于：混沌工程是发现新信息的实践过程，

而故障注入则是对一个特定的条件、变量的验证方法。

当你希望探究复杂系统如何应对异常时，对系统中的服务注入通信故障（如超时、错误等）不失为一种很好的方法。但有时我

们希望探究更多其他的非故障类的场景，如流量激增、资源竞争条件、拜占庭故障（例如性能差或有异常的节点发出有错误的

响应、异常的行为、对调用者随机性的返回不同的响应，等等）、非计划中的或非正常组合的消息处理等等。因为如果一个面

向公众用户的网站突然收到激增的流量，从而产生更多的收入时我们很难称之为故障，但我们仍然需要探究清楚系统在这种情

况下的影响。

和故障注入类似，故障测试方法通过对预先设想到的可以破坏系统的点进行测试，但是并没能去探究上述这类更广阔领域里

的、不可预知的、但很可能发生的事情。

在传统测试中，我们可以写一个断言（assertion），即我们给定一个特定的条件，产生一个特定的输出。测试一般来说只会

产生二元的结果，验证一个结果是真还是假，从而判定测试是否通过。严格意义上来说，这个过程并不能让我们发掘出对于系

统未知的、尚不明确的认知，它仅仅是对我们已知的系统属性可能的取值进行测验。而实验可以产生新的认知，而且通常还能

开辟出一个更广袤的对复杂系统的认知空间。

混沌工程是一种帮助我们获得更多的关于系统的新认知的实验方法。它和已有的功能测试、集成测试等以测试已知属性的方法

有本质上的区别。（本文来自公众号：朱小厮的博客，ID: hiddenkafka）

混沌工程实验的可能性是无限的，根据不同的分布式系统架构和不同的核心业务价值，实验可以千变万化。下面是部分混沌实

验的输入示例：

模拟整个云服务区域或整个数据中心故障；

跨多实例删除部分 Kafka 主题来重现生产环境中发生过的问题；

挑选一个时间段，和针对一部分流量，对其涉及的服务间调用注入一些特定的延时；

方法级别的混乱（运行时注入）：让方法随机抛出各种异常；

在代码中插入一些指令可以允许在这些指令之前运行故障注入；

强制系统节点间的时间不同步；

在驱动程序中执行模拟 I/O 错误的程序；

让某个 Elasticsearch 集群 CPU 超负荷。

4. 实施混沌工程的先决条件

在引入混沌工程之前先要确定你的系统是否已经具备一些弹性来应对真实环境中的一些异常事件，像某个服务异常、网络闪

断、瞬间延迟提高等。

混沌工程非常适合揭露生产系统中的未知缺陷，但如果确定混沌工程实验会导致系统出现严重的问题，那么运行这样的实验是

没有任何意义的。你需要先解决这个缺陷，然后再引入混沌工程，然后你不仅能继续发现更多不知道的缺陷，还能提高对系统

真实弹性水平（resilient）的信心。

引入混沌工程的另一个先决条件是监控系统，你需要用它来判断系统当前的各项状态。如果你没有对系统行为的可见能力，那

么也就无法从实验中得出有效的结论。

二、混沌工程的五大原则

为了具体地解决分布式系统在规模上的不确定性，可以把混沌工程看作是为了揭示系统缺陷而进行的实验。破坏稳态的难度越

大，我们对系统行为的信心就越强。如果发现了一个缺陷，那么我们就有了一个改进目标。避免在系统规模化之后问题被放

大。

以下原则描述了应用混沌工程的理想方式，这些原则来实施实验过程，对这些原则的匹配程度能够增强我们在大规模分布式系

统的信心。

1. 建立一个围绕稳定状态行为的假说（Build a Hypothesis around Steady State Behavior）

“稳定状态”是指系统正常运行时的状态。具体来说，系统的稳定状态可以通过一些指标来定义，当系统指标在测试完成后，无

法快速恢复稳态要求，可以认为这个系统是不稳定的。

of 10

5墨值下载

混沌

手

手机用户2122

关注

评论