软件混沌工程原则以及应用介绍(PRINCIPLES OF CHAOS ENGINEERING)

Chaos Engineering(混沌工程)，相信搞互联 的或多或少都听过，Netflix 发明了 Chaos Monkey，经过 区的发展回馈，慢慢形成了 Chaos Engineering。

混沌工程是在分布式系统上进行实验的学科, 目的是建立对系统抵御生产环境中失控条件的能力以及信心。

混沌工程原文地址：
https://github.com/wizardbyron/principlesofchaos_zh-cn

大规模分布式软件系统的发展正在改变软件工程。作为一个行业，我们很快采用了提高开发灵活性和部署速度的实践。紧随着这些优点的一个迫切问题是：我们对投入生产的复杂系统有多少信心/p>

即使分布式系统中的所有单个服务都正常运行, 这些服务之间的交互也会导致不可预知的结果。 这些不可预知的结果, 由影响生产环境的罕见且破坏性的事件复合而成，令这些分布式系统存在内在的混沌。

我们需要在异常行为出现之前，在整个系统内找出这些弱点。这些弱点包括以下形式:

• 当服务不可用时的不正确回滚设置;
• 不当的超时设置导致的重试风暴;
• 由于下游依赖的流量过载导致的服务中断;
• 单点故障时的级联失败等。

我们必须主动的发现这些重要的弱点，在这些弱点通过生产环境暴露给我们的用户之前。我们需要一种方法来管理这些系统固有的混沌, 通过增加的灵活性和速率以提升我们对生产环境部署的信心, 尽管系统的复杂性是由这些部署所导致的。

我们采用基于经验和系统的方法解决了分布式系统在规模增长时引发的问题, 并以此建立对系统抵御这些事件的能力和信心。通过在受控实验中观察分布式系统的行为来了解它的特性，我们称之为混沌工程。

混沌工程实践

为了具体地解决分布式系统在规模上的不确定性，可以把混沌工程看作是为了揭示系统弱点而进行的实验。这些实验遵循四个步骤：

• 首先，用系统在正常行为下的一些可测量的输出来定义“稳定状态”。
• 其次，假设这个在控制组和实验组都会继续保持稳定状态。
• 然后，在实验组中引入反映真实世界事件的变量，如服务器崩溃、硬盘故障、 络连接断开等。
• 最后，通过控制组和实验组之间的状态差异来反驳稳定状态的假说。

破坏稳态的难度越大，我们对系统行为的信心就越强。如果发现了一个弱点，那么我们就有了一个改进目标。避免在系统规模化之后被放大。

高级原则

以下原则描述了应用混沌工程的理想方式，这些原则基于上述实验过程。对这些原则的匹配程度能够增强我们在大规模分布式系统的信心。

1、建立一个围绕稳定状态行为的假说

要关注系统的可测量输出, 而不是系统的属性。对这些输出在短时间内的度量构成了系统稳定状态的一个代理。 整个系统的吞吐量、错误率、延迟百分点等都可能是表示稳态行为的指标。 通过在实验中的系统性行为模式上的关注, 混沌工程验证了系统是否正常工作, 而不是试图验证它是如何工作的。

2、多样化真实世界的事件

混沌变量反映了现实世界中的事件。 我们可以通过潜在影响或估计频率排定这些事件的优先级。考虑与硬件故障类似的事件, 如服务器宕机、软件故障 (如错误响应) 和非故障事件 (如流量激增或伸缩事件)。 任何能够破坏稳态的事件都是混沌实验中的一个潜在变量。

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

系统的行为会依据环境和流量模式都会有所不同。 由于资源使用率变化的随时可能发生, 因此通过采集实际流量是捕获请求路径的唯一可靠方法。 为了保证系统执行方式的真实性与当前部署系统的相关性, 混沌工程强烈推荐直接采用生产环境流量进行实验。

4、持续自动化运行实验

手动运行实验是劳动密集型的, 最终是不可持续的。所以我们要把实验自动化并持续运行，混沌工程要在系统中构建自动化的编排和分析。

5、最小化爆炸半径

在生产中进行试验可能会造成不必要的客户投诉。虽然对一些短期负面影响必须有一个补偿, 但混沌工程师的责任和义务是确保这些后续影响最小化且被考虑到。

混沌工程是一个强大的实践, 它已经在世界上一些规模最大的业务系统上改变了软件是如何设计和工程化的。 相较于其他方法解决了速度和灵活性, 混沌工程专门处理这些分布式系统中的系统不确定性。 混沌工程的原则为我们大规模的创新和给予客户他们应得的高质量的体验提供了信心。

blade 指令

ps：其中 prepare、create、destroy、revoke 四个指令用的比较多，prepare 是运行 java 程序的时候需要提前使用的一个指令，提前 attach 到 jvm 上

blade 默认支持场景

其中 network、jvm、mysql、docker 都是一些热门组件的异常模拟场景。

下面看看 jvm 的，jvm 支持以下五个场景：

ps：其中 delay、throwCustomException 都是需要指定到方法级别的，如果测试人员对业务代码了解深入的话，可以利用这个特性做破坏性测试。

看着支持的场景很多，其实在 Chaosblade 没出现之前，cpu、disk、network、process、k8s 这些场景都是可以通过 linux 下面的某些命令来模拟的，如果是阿里生态系的，jvm、druid、dubbo 这三个需要熟练的使用， 如果官方能提供 oracle 的异常场景就更好了。

blade 启动注意

blade 需要和待测试的运行进程属于同一用户，且 JAVA 版本、JAVA_HOME 要设置正确。针对系统层面的设置，则需要管理员权限。

blade 模拟接口延时

1、准备 attach 一个 jvm

ps：2679c66005a0aadd 需要记住，如果忘记也可以通过 query 查询

2、模拟接口延迟

ps：注意针对接口的延迟需要管理员权限才能操作

3、测试接口延迟

ps：可以看到针对 url 的访问明显失败

4、查看有哪些 chaos 实验

5、销毁创建的 chaos 实验

6、撤销 chaos 工程

Chaosblade 模型

阿里 Chaosblade 项目地址： https://github.com/chaosblade-io/chaosblade/wiki/%E6%96%B0%E6%89%8B%E6%8C%87%E5%8D%97