混沌工程详细介绍——Netflix持续交付实践探寻

内容来源：DevOps案例深度研究 – Netflix的文化与工程实践战队（本文只展示部分案例PPT及研究成果，更多细节请关注案例分享活动，及本公众号）。
本案例内容贡献者：高金梅，李晓莉，潘雄鹰，潘晓华，任广印，孙亚雄，王英伟
本次案例解读：潘晓华
原文首发于简书-潘晓华Michael

640?wx_fmt=jpeg

（捣乱猴子）

本篇来自于本人6月-7月参加的“DevOps案例深度研究”活动Netflix案例研究的第五部分，详细介绍了Netflix的混沌工程。

经过一个月的战斗，四个版本的迭代，Netflix战队最后交付了让所有人满意的战果，并获得了全场唯一的案例研究最佳小组奖杯。感谢我们的战友，还有指导老师，姚冬老师和徐磊老师。

640?wx_fmt=jpeg

（本案例所有研究人员）

一、Netflix实施混沌工程的背景

640?wx_fmt=jpeg

（混沌工程）

08年Netflix决定把它的业务迁移到aws上，从自身运维的角度考虑，它有很多担忧的地方。

很长时间内有两套系统在同时运行，运维的复杂度更高了。
Netflix的用户量已经达到了1亿，对应用稳定性依赖很高，如果出现故障对用户的影响非常大，甚至是致命的。
它的业务不断复杂，引入微服务架构，对应用的高可用性要求越来越高。
生产环境非常复杂，是多样性的，很难在测试环境中完全模拟生产的状态。

因此，Netflix决心探索一种在生产环境验证应用高可用性的一种方法，这就是现在大家所熟知的混沌工程。

二、混乱工程的发展

640?wx_fmt=jpeg

（混乱工程的发展）

2010年，捣乱猴子诞生
2011年，猴子军团，有了更多场景下的工具集
2012年，开源了捣乱猴子的代码，建立社区，影响了越来越多的公司混沌工程的发展
2014年，Netflix创建了新的工作角色，混沌工程师，代表了Netflix将混沌工程融入了公司的运维文化中
2015年，Netflix与社区正式提出混沌工程原则，从此混沌工程不只是一些工具的集合，而有了一套理论支撑
2016年，Netflix前员工Kolton Andrus创立了Gremlin，正式将混沌实验工具商用化，可以看到混沌工程影响着越来越多的企业。
2017年，Chaos Monkey 2.0

从一只猴子，发展成庞大的猴子军团，是Netflix在生产实践中不断探索与不断进化的结果。

三、Netflix猴子军团

640?wx_fmt=jpeg

（Netflix猴子军团）

Netflix猴子军团包括很多工具：

Chaos Monkey，捣乱猴子，可以随机关闭生产环境中的实例，确保网站系统能够经受故障的考验，同时不会影响客户的正常使用。
Latency Monkey，延迟猴子，在RESTful服务的调用中引入人为的延时来模拟服务降级，测量上游服务是否会做出恰当响应。通过引入长时间延时，还可以模拟节点甚至整个服务不可用。
Conformity Monkey，一致性猴子，查找不符合最佳实践的实例，并将其关闭。例如，如果某个实例不在自动伸缩组里，那么就该将其关闭，让服务所有者能重新让其正常启动。
Doctor Monkey，医生猴子，查找不健康实例的工具，除了运行在每个实例上的健康检查，还会监控外部健康信号，一旦发现不健康实例就会将其移出服务组。
Janitor Monkey，守卫猴子，查找不再需要的资源，将其回收，这能在一定程度上降低云资源的浪费。
Security Monkey，安全猴子，这是Conformity Monkey的一个扩展，检查系统的安全漏洞，同时也会保证SSL和DRM证书仍然有效。
10-18 Monkey，本地化猴子，进行本地化及国际化的配置检查，确保不同地区、使用不同语言和字符集的用户能正常使用Netflix。
Chaos Gorilla，捣乱大猩猩，Chaos Monkey的升级版，可以模拟整个Amazon Availability Zone故障，以此验证在不影响用户，且无需人工干预的情况下，能够自动进行可用区的重新平衡。
Chaos Kong，捣乱金刚，Chaos Gorilla的升级版，可以模拟整个Region的故障。

这些工具向我们展示了Netflix的一套方法论，混沌工程并不是一些测试工具的集合，而是一种思想：在生产实践中遇到问题时，利用混沌工程的思想，实施自己的一些混沌实践，引入新的猴子。相信以后会有越来越多的猴子加入到猴子军团。

使用 Simian Army 进行混沌工程实验，看起来似乎已经很完美。在生产上做这样不可控的实验，是很危险的。

四、混沌工程的原则

640?wx_fmt=jpeg

（混沌工程的原则）

引入混沌实践时需要了解混沌工程的五大原则。

1）建立稳定状态的假设

在做混沌工程实验的时候，首先得确定需要测试的指标已经做了高可用的工作，才能进行验证指标对业务的是否有影响。如果没有做好高可用工作，而引入混沌工程实验的话，对业务而言将会是一声灾难。

2）多样化现实世界事件

不能够凭空想像出一些事件来验证，而是引入那些真实存在的，频繁发生的，且影响重大的事件。对我们而言给这些事件做混沌实验才具有价值。如磁盘故障、网络延时、主机宕机等。

3）在生产环境运行实验

尽量在类生产环境中进行测试，生产环境的多样性是任何其它环境无法比拟的。混沌工程的价值就是保证生产上的业务连续不中断。

4）持续自动化运行实验

实施混沌工程实验一般最开始是人工手动操作，当我们对业务有足够的信心时，要把混沌实验做成持续自动化。在版本升级、不断迭代的过程中，持续不断自动化地做验证，最大程序保证业务的连续性验证。

5）最小化影响范围

做混沌工程的意义就是保证生产上的业务。在我们实施混沌实验时也必须保证对线上业务影响最小。在实施实验时，从小范围开始，不断扩大范围，避开高风险时段，如选择业务量最小的时候实施实验。

五、混沌工程实践步骤

640?wx_fmt=jpeg

（混沌工程实践步骤）

有了这些原则，就可以根据业务的真实场景设计混沌工程实验。

在真实展开实验时分为两个阶段：准备阶段、执行阶段。

1）准备阶段

确认本次实验需要验证的目标。遵循建立稳定状态的假设、多样化现实世界事件的原则。例如：Redis的超时不会对系统影响。代码中已经对Redis超时的情况做了相关的工作，保证业务的可靠。实验只是用来测试验证。
选择实验范围。遵循对线上业务影响最小、尽量与生产环境相近的原则。例如先测试环境验证，生产环境选择最小量用户验证。
确认监控指标。例如：订单成交量、应用请求响应时间、应用响应错误率，做好监控实时查看状态。
团队成员沟通。遵循最小化影响范围。确保团队相关成员了解实施情况，关注业务状态。准备阶段一般只是第一次实验的时候操作，一旦验证好了以后以后，后续重复执行本次工程不需要重新准备，除非对实验过程有变动。

2）执行阶段

执行实验。遵循最小化影响范围。执行过程中实时关注指标，如果有异常，随时终止实验。例如，把Redis延时调大，查看监控指标是否有异常。
分析结果。遵循最小化影响范围。根据收集的指标数据确认假设Redis的超时不会对系统影响。如果验证假设不成立，则需要分析代码，确认好原因，再组织下一次的混沌工程实验。
扩大实验范围。遵循最小化影响范围。先小范围测试，再逐步扩大测试范围。
自动化。遵循持续自动化运行实验。当对代码有足够的信心之后，将混沌工程实践做成自动化，让混沌工程实验能够持续保证业务的可用性，获得最大的价值。

六、Chaos Monkey在K8S集群下的应用

640?wx_fmt=jpeg

（Chaos Monkey在K8S集群下的应用）

Kubernetes是容器编排市场的领导者。如何保证K8S集群及运行在上面的应用能够抵御生产中动荡环境的能力和信心呢？正确地使用混沌工程实践是这里面的关键。我做了一些调研，找到了常用的三款在K8S环境下的混沌工程工具。

Kube-monkey：模拟在指定时间随机删除K8s集群中的pod。
Powerfulseal：控制K8S中的Pod及Node节点的状态。
Gremlin：是一个商业版工具。通过web/API/CLI的方式对容器、主机，提供数十种攻击方式，方便与其它工具进行集成。

总结

可见混沌工程并不仅仅是在传统运维、云平台发挥着作用，在最新的基础架构设施容器平台中也发挥着它的价值。我相信会有越来越多的企业将意识到混沌工程给系统带来的各种好处，不久的将来，混沌工程实践也许会成为基础设施运维与应用运维不可或缺的一部分。

参考文章

Netflix 混沌工程手册：https://www.infoq.cn/theme/13
Unleash the Chaos Monkey：https://www.ibm.com/developerworks/agile/library/a-devops4/index.html
Netflix的Chaos Monkey的一个实现用于Kubernetes集群：https://go.ctolib.com/kube-monkey.html
获得1.25亿用户以后，Netflix总结了这些系统可用性经验：https://www.huxiu.com/article/258949.html?rec=similar
Istio Chaos Engineering: I Meant to Do That：https://developers.redhat.com/blog/2018/04/10/istio-chaos-engineering/
AWS云上混沌工程实践之启动篇：https://aws.amazon.com/cn/blogs/china/aws-chaos-engineering-start/

拓展阅读：