前言

大家好,我是老马。

这一节我们来介绍一下混沌工程的准则,这里是对原文的一个简单翻译,方便大家学习查阅。

混沌工程原理

最后更新:2019年3月(变更)

混沌工程是通过在系统中进行实验,建立对系统在生产环境中承受复杂条件能力的信心的学科。

大规模分布式软件系统的进展正在改变软件工程的游戏规则。

作为一个行业,我们很快就采纳了能够提高开发灵活性和部署速度的实践。但随之而来的紧迫问题是:我们对投入生产的复杂系统可以有多大的信心?

即使分布式系统中的每个单独服务都能正常运行,这些服务之间的交互也可能导致不可预测的结果。不可预测的结果,加上罕见但具有破坏性的现实世界事件(如生产环境中的硬件故障或网络中断),使得这些分布式系统天生具有混沌性。

我们需要在这些弱点导致系统出现异常行为之前将其识别出来。

系统性弱点可能表现为:服务不可用时的错误回退设置;因超时未正确调整而引发的重试风暴;下游依赖接收过多流量时导致的宕机;单点故障崩溃时的级联故障等。我们必须主动解决这些最严重的弱点,防止它们影响到生产中的客户。我们需要一种方式来管理这些系统固有的混沌,利用不断提高的灵活性和部署速度,同时对生产部署充满信心,尽管这些系统本身非常复杂。

一种基于经验的、系统化的方法可以应对分布式系统的混沌,并建立对这些系统在现实条件下承受能力的信心。我们通过在受控实验中观察分布式系统的行为来了解其表现。我们称之为“混沌工程”。

混沌工程实践

为了专门应对大规模分布式系统的不确定性,混沌工程可以被看作是进行实验以揭示系统性弱点的过程。这些实验遵循四个步骤:

  1. 定义“稳态”:将系统的某个可测量输出定义为表示正常行为的“稳态”。

  2. 假设稳态持续:假设控制组和实验组的稳态会保持一致。

  3. 引入真实世界事件的变量:模拟真实世界中的事件,如服务器崩溃、硬盘故障、网络连接中断等。

  4. 验证假设:通过对比控制组和实验组的稳态,试图证明假设不成立。

如果扰乱稳态变得更加困难,我们对系统行为的信心就越强。如果发现了弱点,我们就可以在这些弱点在系统中大规模显现之前进行改进。

高级原则

以下原则描述了混沌工程的理想应用,应用于上述实验过程。遵循这些原则的程度与我们对大规模分布式系统的信心密切相关。

1. 以稳态行为为中心构建假设

专注于系统的可测量输出,而非系统的内部属性。对这些输出进行短时间内的测量,作为系统稳态的代表。系统的总体吞吐量、错误率、延迟百分位等,都是可能反映稳态行为的指标。通过专注于实验中的系统行为模式,混沌工程验证系统是否有效运作,而非验证它是如何运作的。

2. 变化真实世界事件

混沌变量应反映真实世界中的事件。根据事件的潜在影响或预估频率来优先考虑。考虑与硬件故障相关的事件,如服务器崩溃、软件故障(如错误响应)、非故障事件(如流量激增或扩展事件)等。任何可能扰乱稳态的事件,都可能成为混沌实验中的变量。

3. 在生产环境中运行实验

系统在不同的环境和流量模式下表现不同。由于利用模式随时可能发生变化,因此采样真实流量是唯一可靠捕捉请求路径的方法。为了确保系统行为的真实性和与当前部署系统的相关性,混沌工程强烈建议直接在生产流量上进行实验。

4. 自动化实验以持续运行

手动运行实验既费时又不可持续。应该将实验自动化,并持续运行。混沌工程通过在系统中构建自动化,推动协调和分析。

5. 最小化影响范围

在生产环境中进行实验可能会导致不必要的客户痛苦。虽然允许实验在短期内产生一些负面影响,但混沌工程师有责任确保实验的后果被最小化和控制在可接受范围内。

总结

混沌工程是一种强有力的实践,已经在一些世界最大规模的操作中改变了软件的设计和工程方式。

当其他实践关注于速度和灵活性时,混沌工程专门应对这些分布式系统中的系统性不确定性。

混沌工程的原理为快速创新提供了信心,并在大规模下帮助确保客户获得应有的高质量体验。

欢迎加入混沌工程原理的持续讨论,参与混沌社区的交流。

小结

希望本文对你有所帮助,如果喜欢,欢迎点赞收藏转发一波。

我是老马,期待与你的下次相遇。

参考资料

https://principlesofchaos.org/