大规模分布式软件系统的发展正在改变软件工程。作为一个行业，我们很快采用了提高开发灵活性和部署速度的实践。紧跟着这些好处的一个紧迫问题是：我们对投入生产的复杂系统中有多少信心？
即使分布式系统中的所有单个服务都正常运行, 这些服务之间的交互也会导致不可预知的结果。 这些不可预知的结果, 由影响生产环境的罕见但破坏性的真实事件复合而成，令这些分布式系统存在内在的混沌。
我们需要在异常行为出现之前，在整个系统的范围内找出这些弱点。 系统弱点包括以下形式: 当服务不可用时的不正确回退设置;不当的超时设置导致的重试风暴;由于下游依赖项流量过载导致的服务中断;单点故障时的级联失败等。我们必须主动的发现这些重要的弱点，在这些弱点通过生产环境暴露给我们的客户之前。我们需要一种方法来管理这些系统固有的混沌, 通过增加的灵活性和速率以提升我们对生产环境部署的信心, 尽管系统的复杂性是由这些部署所导致的。
基于经验和系统的方法解决了分布式系统在规模增大时引发的混乱问题, 并以此建立了对这些系统抵御现实条件的能力的信心。 我们通过在受控实验中观察分布式系统的行为来了解它的特性。 我们称之为混沌工程。
混沌工程实践
为了具体地解决分布式系统在规模上的不确定性，可以把混沌工程看作是为了揭示系统弱点而进行的实验。这些实验遵循四个步骤：
首先，用系统在正常行为下的一些可测量的输出来定义“稳态”。
假设这个稳定状态在控制组和实验组都会继续存在。
引入反映真实世界事件的变量，如服务器崩溃、硬盘故障、网络连接断开等。
试图通过假设控制组和实验组之间的稳态差异来反驳这个假设。
破坏稳态的难度越大，我们对系统行为的信心就越强。如果发现了一个弱点，那么我们就有了一个改进目标。避免在系统规模化之后被放大。
高级原则
以下原则描述了应用混沌工程的理想方式，这些原则基于上述实验过程。 对这些原则的匹配程度能够增强我们在大规模分布式系统的信心。
建立一个围绕稳定状态行为的假说
要关注系统的可测量输出, 而不是系统的属性。 对这些输出在短时间内的度量构成了系统稳定状态的一个代理。 整个系统的吞吐量、错误率、延迟百分点等都可能是表示稳态行为的指标。 通过在实验中的系统性行为模式上的关注, 混沌工程验证了系统是否正常工作, 而不是试图验证它是如何工作的。
多样化真实世界的事件
混沌变量反映了现实世界中的事件。 我们可以通过潜在影响或估计频率排定这些事件的优先级。 考虑与硬件故障类似的事件, 如服务器宕机、软件故障 (如错误响应) 和非故障事件 (如流量激增或缩放事件)。 任何能够破坏稳态的事件都是混沌实验中的一个潜在变量。
在生产环境中运行实验
系统的行为会依据环境和流量模式都会有所不同。 由于资源使用率变化的随时可能发生, 因此通过采集实际流量是捕获请求路径的唯一可靠方法。 为了保证系统执行方式的真实性与当前部署系统的相关性, 混沌工程强烈推荐直接采用生产环境流量进行实验。
持续自动化运行实验
手动运行实验是劳动密集型的, 最终是不可持续的，所以我们要把实验自动化并持续运行。 混沌工程要在系统中构建自动化的编排和分析。
最小化爆炸半径
在生产中进行试验可能会造成不必要的客户投诉。虽然对一些短期负面影响必须有一个补偿, 但混沌工程师的责任和义务是确保这些后续影响最小化且被考虑到。
混沌工程是一个强大的实践, 它已经在世界上一些规模最大的业务系统上改变了软件是如何设计和工程化的。 相较于其他方法解决了速度和灵活性, 混沌工程专门处理这些分布式系统中的系统不确定性。 混沌工程的原则为我们大规模的创新和给予客户他们应得的高质量的体验提供了信心。
