都2021年了，你还不知道混沌工程（ Chaos Engineering）？

混沌工程是什么

• 混沌工程是一门新兴的技术学科，初衷是通过实验性的方法，让人们建立对于复杂分布式系统在生产中抵御突发事件能力的信心。
• 混沌工程是一门相对高级的系统稳定性治理方法论，它提倡采用探索式的研究实验，发现生产环境中的各种风险。
• 混沌工程也同样适用于传统行业，如大型金融机构，制造业和医疗机构。交易依赖复杂系统吗？有大型银行正在使用混沌工程来验证交易系统是否有足够的冗余。在美国，混沌工程在许多方面被当做模型应用在了临床试验系统中，从而形成了美国医疗验证的黄金标准。横跨金融、医疗、保险、火箭制造、农业机械、工具制造、再到数字巨头和创业公司，混沌工程正在成为复杂系统改进学科的立足点。

混沌工程的价值

混沌工程正是一套通过在系统基础设施上进行实验，主动找出系统中的脆弱环节的方法学。这种通过实证的验证方法显然可以为我们打造更具弹性的系统，同时让我们更透彻的掌握系统运行时的各种行为规律

混沌工程详解

认识混沌工程

混沌工程和测试的区别

1. 在测试中，我们要进行断言：即给定一个特定的条件，系统会输出一个特定的结果。测试一般来说只会产生二元的结果，验证一个结果是真还是假，从而判定测试是否通过。严格意义上来说，这个实践过程并不能让我们发掘出系统未知的或尚不明确的认知，它仅仅是对我们已知的系统属性可能的取值进行测验
2. 实验可以产生新的认知，而且通常还能开辟出一个更广袤的对复杂系统的认知空间。实验的可能性是无限的，根据不同的分布式系统架构和不同的核心业务价值，实验可以千变万化。
   一些混沌工程实验的输入样例：

• 模拟整个云服务区域或整个数据中心故障；
• 跨多实例删除部分 Kafka topic 来重现生产环境中发生过的问题；
• 挑选一个时间段，和针对一部分流量，对其涉及的服务间调用注入一些特定的延时；
• 方法级别的混乱（运行时注入）：让方法随机抛出各种异常；
• 在代码中插入一些指令可以允许在这些指令之前运行故障注入；
• 强制系统节点间的时间不同步；
• 在驱动程序中执行模拟 I/O 错误的程序；
• 让某个 Elasticsearch 集群 CPU 超负荷。

混沌工程的前提条件

1. 系统已经具备一些弹性来应对真实环境中的一些异常事件，像某个服务异常、或网络闪断、或瞬间延迟提高这样的事件。
2. 监控系统，你需要用它来判断系统当前的各项状态。 如果没有对系统行为的可见能力，就无法从实验中得出有效的结论。

混沌工程原则

1. 假设稳定的状态：混沌工程的演练需要一个把预期会发生的事情和实际会发生的事情进行比较的指标来衡量系统在稳定时候的状态。
2. 多样化现实世界事件做验证：故障事件的分析、故障场景的抽象、故障注入与恢复的实现
3. 在生产环境进行实验：混沌工程实验的环境越真实，混沌工程的实验越有价值。
4. 自动化实验以持续运行：自动和常态化，降低实验成本。
5. 最小化爆炸半径：控制风险，可放可收。

混沌工程实验设计

1. 选定假设： 你需要做的第一件事就是选定你要验证的假设。例如，你希望验证主从数据库配置，在主数据库故障时可以无缝切换到从数据库
2. 设定实验的范围： 两个原则：在生产环境运行实验”和“最小化爆炸半径”
3. 识别出要监控的指标： 明确了假设和范围之后，我们需要选定用来评估实验结果的指标, 要尽可能基于你的指标来验证假设。例如假设是“主数据库故障时，所有服务都正常”，那么在运行实验之前，你需要清晰定义什么是“正常”。
4. 在组织内共同到位：第一次执行的时候，你可能需要协调好每个需要参与的，对结果感兴趣的，以及对生产影响有顾虑的团队及其成员
5. 执行实验： 执行实验了！要盯住那些指标，因为你可能随时需要终止实验。
6. 分析实验结果： 实验结束后，拿当时的指标数据来验证之前的假设是否成立
7. 扩大试验范围： 扩大实验范围的目的是进一步暴露小范围实验无法发现的一些问题。例如，微服务架构中一些小量的超时或许不会有什么问题，但超过一定比例就可能会导致整体瘫痪
8. 自动化实验： 当你有信心手动执行混沌工程实验之后，就可以开始周期性自动化运行实验，持续从中获得更大的价值。

工具介绍

实验工具

• Chaos Monkey
  早版本的Chaos Monkey，除了支持关闭服务实例之外，还支持其他一些操作系统级别的破坏，例如提高CPU占用率、阻塞网络IO、写满硬盘空间等。Chaos Monkey 2.0移除了这些功能，只支持关闭服务实例，并且必须使用Spinnaker来管理，在Spinnaker上对其进行配置。同时Chaos Monkey可以从Spinnaker获取服务部署的相关信息并通过Spinnaker关闭服务实例。
• Chaos Kong
  可以关闭整个AWS区域，每个月一次的演习
• FIT
  这个工具允许工程师在访问服务的一类请求头中注入一些失败的场景。这些被注入失败场景的请求头在系统中流转的过程中，微服务中被注入的故障锚点会根据不同的失败场景触发相应的逻辑；FIT为这方面的探索提供了一个基础，但是执行这样一个实验需要开发者字形配置，这使得它并没有能像那样，被广泛使用
• ACA
  自动金丝雀分析（AutomatedCanaryAnalysis，ACA）的内部工具，通过稳定状态的指标来验证金丝雀集群是否健康。ACA将一个金丝雀集群大小相同并运行旧代码的基准集群，和一些列系统指令进行比较，金丝雀集群的得分必须足够高才能通过金丝雀发布阶段
• Blockade
• ChAP
• LDFI
• Simoorg​
  Linkedin 开发的故障注入工具。它非常易于扩展，并且很多关键组件都是可插拔的。
• Pumba​
  基于 Docker 的混沌工程测试工具以及网络模拟工具。
• Chaos Lemur​
  可以本地部署的随机关闭 BOSH 虚拟机的工具。
• Chaos Lambda​
  随机关闭 AWS ASG 节点的工具。
• Blockade​
  基于 Docker，可以测试网络故障和网络分区的工具。
• Chaos-http-proxy​
  可以向 HTTP 请求注入故障的代理服务器。
• Monkey-ops​
  Monkey-Ops 用 Go 实现，可以再 OpenShift V3.X 上部署并且可以在其中生成混沌实验。Monkey-Ops 可以随机停止 OpenShift 组件，如 Pods 或者DeploymentConfigs。
• Chaos Dingo​
  Chaos Dingo 目前支持在 Azure 相关服务上进行实验。
• Tugbot​
  Docker 生产环境测试工具。

可参考资源整合

• 社区网站
• Google Group
• Netflix 的官方博客关于混沌工程的信息
• 其他的组织在实践混沌工程
  • Fault Injection in Production: Making the Case for Resiliency Testing
  • Inside Azure Search: Chaos Engineering
  • Organized Chaos With F#
  • Chaos Engineering 101
  • Meet Kripa Krishnan, Google’s Queen of Chaos
  • Facebook Turned Off Entire Data Center to Test Resiliency
  • On Designing And Deploying Internet-Scale Services
• Drift Into Failure by Sidney Dekker (2011)
  Dekker 的理论讲的是，在一个组织内部，事故的发生都是因为各系统随着时间慢慢滑向一个不安全的状态，而不是某个单点突发的问题造成的。你可以把混沌工程想象成专门用来对抗这种滑动过程的方法。
• To Engineer Is Human: The Role of Failure in Successful Design by Henry Petroski (1992)
  Petroski 描述了他们那里的工程师是如何从过去的失败中汲取教训来进步的，而不是从过去的成功中找经验。混沌工程正是一种既能发现系统中的问题点，又能避免大规模影响的方法论。
• Searching for Safety by Aaron Wildavsky (1988)
  Wildavksy 的主张是，为了提高整体安全性，所有风险必须要被管理好。尤其是采用不断试错的方法，长期来说会比尝试完全避免事故发生，要获得更好的结果。混沌工程也是同样的通过在生产环境进行实验来拥抱风险，以期获得系统更大的弹性的方法。

参考文献

• Netflix混沌师手册Part1: 混沌工程简介- InfoQ
• Netflix混沌师手册Part2: 混沌工程原则- InfoQ
• Netflix混沌师手册Part3: 混沌工程实践方法- InfoQ