混沌工程 ChaosMeta 的全新版本 V0.5 现已正式发布！该版本包含了许多新特性和增强功能，为用户提供了支撑混沌工程各个阶段的平台能力，以及降低使用门槛的用户界面。

ChaosMeta V0.5 核心新特性介绍

当前版本主要是发布了平台界面组件（chaosmeta-platform）、度量组件（chaosmeta-measure-operator）以及流量注入组件（chaosmeta-flow-operator）。

▌平台界面

提供产品层操作界面方便用户更友好地使用 ChaosMeta 产品功能，当前产品层功能主要有：

1. 空间管理：根据组织或活动隔离数据，确保数据的安全性和隐私性。

2. 用户权限管理：为不同角色提供访问权限的控制，可有效管理混沌工程实验的使用。

3. 编排实验：通过拖拉拽可视化操作，使实验编排更加友好和灵活，提高用户的工作效率。

4. 实验结果：提供实验执行详情的追溯功能，让用户随时了解实验的执行情况和结果，方便用户进行数据分析和决策。

▌度量引擎

当前包括 4 种度量能力：

• monitor：对监控项的值进行预期判断，比如某个机器的 cpu 使用率监控值是否大于 90%，默认支持 prometheus

• pod：对 pod 相关数据进行预期判断，比如某个应用的 pod 实例数是否大于 3

• http：对 http 请求进行预期判断，比如进行指定的 http 请求时，返回状态码是否为 200

• tcp：对 tcp 请求进行预期判断，比如测试某个服务器的 8080 端口是否能通

▌流量引擎

当前流量注入的能力只实现了 HTTP 流量类型的注入，后续会逐步补充 RPC、DB client、redis client 等其他类型的流量注入能力。底层实现是基于开源组件 jmeter 实现的，每个流量注入任务启动一个 jmeter 的 job 执行。

ChaosMeta 核心设计理念

ChaosMeta 设计上主要是想要解决下面几个业界内普遍存在的问题：

1. 混沌工程演练各个阶段的能力整合

当前业界主流混沌工程项目主要都是只关注如何制造故障的问题，而经常做演练相关工作的工程师，应该明白每次演练还有以下重复性工作的痛点：检测当前环境是否符合演练预设条件（演练准入）、业务流量是否满足（流量注入）、注入后判断故障效果是否符合预期（故障度量）、是否在预设时间内恢复了业务服务（恢复度量）、复盘分析总结风险点。

基于业界现状和上面的问题分析，结合蚂蚁集团在混沌工程领域的多年经验，ChaosMeta 平台从设计上覆盖了“准入检测”、“流量注入”、“故障注入”、“故障度量”、“恢复度量”、“注入恢复”等各个阶段的技术支撑，解放各阶段的人力。

2. 故障实验设计的经验可复用性

我们在做混沌工程演练前，还有一个会消耗大量人力的工作，那就是在演练实验的设计上。这一部分当前主要还是得依靠人的设计能力，目前很难完全依赖机器去自动设计。但是我们可以把其中的可复用经验系统化抽象出来，整理成册，在对同一类组件进行混沌工程演练的时候，就可以快速复用起来，这个就是风险目录的设计初衷。

风险目录前期主要是以理论的方式开源，后期会以平台能力的方式内置到 ChaosMeta 项目中。

3. 云原生基础设施的环境复杂性

当前大部分公司的基础设施环境都是在 Kubernetes 上的，无论是云自身还是云原生应用的稳定性都是至关重要的，传统的故障注入手段可能难以解决问题。为此我们希望 ChaosMeta 能从设计上解决以下问题：

- 对 Kubernetes 自身稳定性的故障注入能力

主要是围绕 Kubernetes 自身的稳定性，比如 APIServer、Scheduler 等核心组件，各类资源的状态异常处理流程，Operator 应用的异常等

- 平台支持云原生部署

ChaosMeta 设计上是基于 operator 开发的云原生架构（详见用户文档），因此天然支持云原生环境的部署

- 平台支持管理云上容器并进行故障注入

如果使用传统的方式对容器进行故障注入，需要把单机故障注入工具传输到目标容器内并执行命令，但是一般的业务容器的基础镜像都是极简版的，很多命令工具比如 tc、fallocate 等都不支持，导致容器故障注入被环境因素受限过大。

ChaosMeta 使用“容器化注入”的方式对集群内的 Pod 以及 Node 进行故障注入，单机故障注入工具 chaosmetad 支持对宿主机上的容器进行故障注入，而不需要把 chaosmetad 拷贝到容器内，通过在宿主机上选择性进入目标容器的目标 linux namespace，达到使用宿主机的工具对容器的相应 namespace 产生异常的效果

- 平台支持管理云下容器并进行故障注入

每个公司都还有很多还没上云的业务，这类业务要么是在普通的物理机/虚拟机上部署，要么是在此基础上裸容器启动的（比如 docker 容器）。这个时候也需要平台能支持管理这部分集群外的目标，ChaosMeta 的单机故障注入工具 chaosmetad 支持以 agent 模式启动，定时上报机器的容器信息到平台中，平台可以直接选择集群外的目标下发故障注入任务。

- 多集群管理

虽然我们推荐每个集群部署一个管控平台，但是仍然有很多用户换机是希望能集中式管理的，ChaosMeta 的平台能力设计上也是支持管理不同集群的 kubeconfig 以及跨集群进行故障注入的。

4. 可自动化的道路

平台技术的最后目标都是希望能解放人力，往自动化、智能化的方向演进的，或许当前还没能完全做到，但是至少需要走在正确的道路上。

ChaosMeta 的自动化混沌工程思想主要是以混沌工程演练的各阶段平台能力为技术支撑，“风险目录”作为理论支撑，使 ChaosMeta 朝着自动化混沌工程的方向逐步演进。

2023 年 roadmap

今年的目标主要是把平台能力进行完善，并且各阶段的基本能力都补全，还会跟其他开源社区（比如 OceanBase、SOFA 等）进行进一步的合作，争取达到 1.0 完整版。

平台能力

• 支持全部编排节点类型的能力

• 内置一些开源组件的通用实验模板

• 提供 Agent 管理界面，管理云上以及云下的物理机以及容器

• 支持跨集群管理

各阶段基本能力

• 流量注入能力，基于 jmeter 提供更多的流量注入能力

• 度量能力，提供更多云原生方向的状态度量能力

• 故障注入能力，主要往组件级别的故障注入能力上演进，比如集成对 OceanBase、MySQL、Redis、Etcd 等开源组件的故障注入能力

风险目录

正式对外开源理论版本，内置到 ChaosMeta 平台中的能力主要以上述的“通用实验模版”以及“组件级别的故障注入能力”两种方式。

加入我们

作为一个开放的项目，我们认可开源的研发模式，并致力于将 ChaosMeta 社区打造成一个开放和有创造力的社区。后续，所有的研发、讨论等相关工都会在社区透明运行。

我们欢迎任何形式的参与，包括且不限于提问、代码贡献、技术讨论、需求建议等。期待收到社区想法和反馈，以推动项目往前进一步发展。

如果对我们的项目或者设计理念感兴趣，请 star 我们的项目给予支持。

项目 GitHub 地址：

https://github.com/traas-stack/chaosmeta

官方文档：

https://chaosmeta.gitbook.io/chaosmeta-cn

微信群：请添加负责人好友（微信号：KingsonKai）邀请入群

钉钉群：21765030887

也欢迎大家关注 ChaosMeta 公众号，项目最新动态我们都会在这里发布。