【问题标题】：How might Chaos Engineering look as part of a pipeline?混沌工程如何成为管道的一部分？
【发布时间】：2017-10-03 09:28:47
【问题描述】：
Chaos engineering 实践正变得非常广泛使用。一个常见的例子是 Netflix 自己的Chaos Monkey。但是，Chaos Monkey 经常针对随机目标临时运行。我很好奇混沌实验如何在典型的CI/CD pipeline 中发挥作用，以增强特定服务的弹性。
- 由于混沌实验（通常）需要一个功能齐全的环境，它们何时运行？它会与测试并行运行，还是在下游运行？
- 您会在每次提交时进行混沌实验，还是只进行一些？
- 混沌实验可以运行多长时间？例如，60 分钟的 CPU 峰值可能会干扰“快速故障”方法。
- 混沌实验会导致管道失败吗？什么会构成“失败”？
【问题讨论】：
标签：
continuous-integration
pipeline
chaos
【解决方案1】：
我们的混沌工程工作才刚刚开始，但我会就您的问题提出一些想法。
至少有三类不同的实验：
- 我们期望底层基础架构自动处理的实例/容器终止。
- 更高级别但相当局部的故障，例如缓慢或不可用的依赖项。
- 数据中心或区域停机等大规模故障。
对于构建管道，最佳位置将在中间（即更高级别但本地化的故障），因为通常软件本身在响应故障方面发挥作用。例如，该软件可能包括一个断路器，它会跳闸、节流、自动故障转移等。如果这些是软件功能，那么它们可以工作也可以不工作，构建应该发现这一点。
就故障恢复能力是系统要求而言，是的，失败的实验会使管道失败。例如，假设 build 392 有一个正常工作的断路器，而 build 393 没有。这将是一个失败，因为构建从满足要求变为不满足要求。