ChaosBlade：从混沌工程实验工具到混沌工程平台

ChaosBlade 是阿里巴巴 2019 年开源的混沌工程项目，已加入到 CNCF Sandbox 中。起初包含面向多环境、多语言的混沌工程实验工具 chaosblade，到现在发展到面向多集群、多环境、多语言的混沌工程平台 chaosblade-box，平台支持实验工具托管和工具自动化部署，通过统一用户实验界面，将用户的精力聚焦在通过混沌工程解决云原生过程中高可用问题上。本文从混沌实验模型抽象、混沌实验工具开源和混沌工程平台升级项目三阶段出发，详细介绍 ChaosBlade。

在今年可信云测评中，阿里云故障演练平台以最高分首批通过可信云混沌工程平台能力要求最高等级-先进级认证。

混沌实验模型

ChaosBlade 项目覆盖基础资源、应用服务、容器服务等混沌实验场景。在实验工具设计之初就考虑了场景模型统一，便于场景扩展和沉淀，也为平台托管实验工具实现统一场景调用提供模型依据。ChaosBlade 项目中所有的实验场景均遵循此实验模型设计，下面通过实验模型的推导、介绍、意义和具体的应用来详细介绍此模型。

1、实验模型的推导

混沌实验主要包含故障模拟，我们一般对故障的描述如下：

• 10.0.0.1 机器上挂载的 A 磁盘满造成了服务不可用；
• 所有节点上的 B dubbo 服务因为执行缓慢造成上游 A dubbo 服务调用延迟，从而造成用户访问缓慢；
• Kubernetes A 集群中 B 节点上 CPU 所有核使用率满载，造成 A 集群中的 Pod 调度异常；
• Kubernetes C 集群中 D Pod 网络异常，造成 D 相关的 Service 访问异常。

通过上述，我们可以使用以下句式来描述故障：因为某某机器（或集群中的资源，如 Node，Pod）上的哪个组件发生了什么故障，从而造成了相关影响。我们也可以通过下图来看故障描述拆分：

可以通过这四部分来描述现有的故障场景，所有我们抽象出了一个故障场景模型，也称为混沌实验模型。

2、实验模型的介绍

此实验模型详细描述如下：

• Scope: 实验实施范围，指具体实施实验的机器、集群及其资源等。
• Target: 实验靶点，指实验发生的组件。如基础资源场景中的 CPU、网络、磁盘等，Java 场景中的应用组件如 Dubbo、Redis、RocketMQ、JVM 等，容器场景中的 Node、Pod、Container自身等。
• Matcher: 实验规则匹配器，根据所配置的 Target，定义相关的实验匹配规则，可以配置多个。由于每个 Target 可能有各自特殊的匹配条件，比如 RPC 领域的 Dubbo、gRPC 可以根据服务提供者提供的服务和服务消费者调用的服务进行匹配，缓存领域的 Redis，可以根据 set、get 操作进行匹配。还可以对 matcher 进行扩展，比如扩展实验场景执行策略，控制实验触发时间。
• Action: 指实验模拟的具体场景，Target 不同，实施的场景也不一样，比如磁盘，可以演练磁盘满，磁盘 IO 读写高