公司使用 JumpServer 堡垒机作为远程办公的入口，并且搭建了高可用环境，不过两个节点都是部署在国内某云的海外节点上的。上个月有一次海外光缆出了问题，直接导致使用该远程办公的同事全部提前下班了。基于如何避免以上未知的故障去研究了混沌工程相关内容，虽然这个已知的故障场景用一些网络命令就能复现，用混沌注入颇有点大炮打蚊子的感觉，但是混沌工程主要是用来模拟出现那些未知故障的，也算是借着这个场景了解下最近很火的混沌工程。研究的过程中发现了另一个问题，每次操作都需要手动写命令，我自己练习完了下次没办法再次自动执行。正好那段时间 JumpServer 交流群里在推他们团队的另外一款测试平台产品 ——?MeterSphere，里边的接口自动化能力非常强大，任务定时执行还支持 cron 表达式的图形化方式，可以让我这种对 cron 不是那么懂的人都能用的飞起，感觉可以通过这个平台把混沌测试中的故障注入和接口测试结合起来。心动不如行动，逐开始进行操作。
混沌工程相关的概念不是本篇文章的重点，这里不再赘述，用个人理解的一句话介绍 ChaosBlade：ChaosBlade 是阿里开源的一个混沌注入的工具，所谓混沌注入可以理解为制造各种可能发生的故障（比如 CPU、存储、网络等故障），来模拟线上环境可能会发生的一些问题，通过判断注入后系统是否还能保持稳定来分析和测试出系统的健壮性，从而进一步改善系统。
下面就来简单介绍一下，通过 MeterSphere 是如何调用 ChaosBlade 完成一个场景自动化测试的。
一、准备工作：
1.1 准备好被测系统，这里是单节点 JumpServer一台，这里因为只是实验，配置不做多要求，参考?JumpServer?的推荐配置即可；
1.2 准备一台服务器用于安装 MeterSphere 测试平台，具体操作和使用可参考官网文档，这里不做介绍；
1.3 从 ChaosBlade 的 github 地址上下载基于 Linux 环境的最新安装包，下载完成后传到被测服务器上并解压即可，无需编译。
比如解压到了服务器的 /opt 目录下，进入解压后的文件夹，可以看到以下内容：
├── bin
│ ├── chaos_burncpu
│ ├── chaos_burnio
│ ├── chaos_changedns
│ ├── chaos_delaynetwork
│ ├── chaos_dropnetwork
│ ├── chaos_filldisk
│ ├── chaos_killprocess
│ ├── chaos_lossnetwork
│ ├── jvm.spec.yaml
│ └── tools.jar
├── blade
└── lib
└── sandbox其中 blade 是可执行文件，即 chaosblade 工具的 cli，混沌实验执行的工具。
在这里先简单介绍一下如何使用这个工具：
我们拿 CPU 满载(CPU 使用率 100%) 演练场景举例（！！注意，在不清楚影响面的情况下，此命令切勿直接在韧性不够的生产系统机器上执行），执行以下命令实施实验：
./blade create cpu fullload执行结果返回：
{"code":200,"success":true,"result":"7c1f7afc281482c8"}通过?top?命令查看 CPU 使用率
CPU usage: 93.79% user, 6.20% sys, 0.0% idle此时命令已经生效，停止混沌实验，执行：
./blade destroy 7c1f7afc281482c8返回以下结果，表示停止实验成功
{"code":200,"success":true,"result":"command: cpu fullload --debug false --help false"}再去观察 CPU 情况，CPU 负载已回到正常状态：
CPU usage: 6.36% user, 4.74% sys, 88.88% idle一次 CPU 满载演练完成。
二、配置相关：
我们知道 MeterSphere 可以做到创建场景接口自动化测试，测试的流程包括：
1）确定一个观察的稳定的指标，如JumpServer的资产列表查询；
2）在 MeterSphere 上定义一个查询稳定指标的接口用例：调用JumpServer的资产列表查询的接口；
可以看到，在没有外界干扰的情况下，能够正常调用JumpServer的接口查询资产列表。
3）定义第二个接口用例：这个用例执行目的在于引入混沌测试发起故障注入。（这里选择提高服务器 CPU 负载到 100%）
4)? 定义第三个接口用例：这个用例目的在于查询上一个混沌注入测试的注入状态。参数 result 为上一个混沌测试所返回响应的 result 值。
可以通过如下命令查看 CPU 使用率：
iostat -c 1 1000
可以看到，这次请求的响应时间比较长，说明服务器 CPU 负载的提升，对系统的稳定性有一定的影响，可能会影响后续接口的正常调用。
5）定义第四个接口用例：这个用例目的在于验证混沌注入后是否影响对 Jumpserver接口正常的调用，以及观察与第一次调用接口时候的差别。?
可以看到对比之前请求，响应时间延长了，原先的 56ms 变成了 192ms。但是依然还是能够正常的请求接口获取数据，说明 CPU 满负载还不能破坏我们预先设定的稳定指标。（正常查询资产列表）
6）定义第五个接口用例：这个用例目的在于销毁此次的混沌注入测试，把之前的 CPU 满负载混沌注入效果销毁。即使服务器恢复为初始状态。
7）定义第六个测试用例：该用例与第三个用例可以复用，这个用例目的在于查询上一个混沌注入测试的注入状态。参数 result 为 MS 在前面用例定义好的变量 result 的值。
可以看到，当成功销毁混沌实验后，服务器的 CPU 负载情况已经恢复原始状态。
8）定义第七个测试用例：该用例也是此次接口场景自动化测试的最后一个用例，就是再次调用JumpServer 的查询资产列表，观察响应结果。
可以看到，这一次请求查询中间件列表的接口，响应时间 63ms，对比在混沌注入后的接近 200ms 又恢复变快了，说明服务器 CPU 的负载对于接口响应时延还是有一定影响，到此实验结束。
三、结果展示：
上面只是列出了每个测试用例的截图，这里将完整的场景接口自动化做一个展示：
点击执行，观察结果：
结果分析：
7 个步骤均执行完成，该流程场景测试成功。并且能看出，在混沌注入前后，对接口请求的效果是有一定的影响。明显在注入之后的系统响应时间变长，但是也可以看出 CPU 满负载依然不能破坏稳态，系统依然能稳定运行，访问JumpServer也能正常访问。
四、实验小结&补充：
1）安装 ChaosBlade 之后，后台启动 blade，会暴露出 web 服务，上层可通过 http 调用。请求格式是 chaosblade?cmd= 具体命令，例如执行 CPU 满载，则请求是 chaosblade?cmd=create%20cpu%20fullload（%20 相当于 unicode 的一个空格）。
命令
start 启动 server 模式, 暴露 web 服务
stop 停止 server 模式, 关闭 web 服务?start 命令参数
-p, --port string 服务端口号，默认是 9526?案例
# 启动 server 模式，服务端口是 8080
blade server start --port 8080
success, listening on 8080
# 触发 CPU 负载 50% 场景
curl "http://xxx.xxx.xxx.xxx:8080/chaosblade?cmd=create%20cpu%20load%20--cpu-percent%2050"
{"code":200,"success":true,"result":"e08a64a9af02c393"}
# 销毁实验场景
curl "http://xxx.xxx.xxx.xxx:8080/chaosblade?cmd=destroy%20e08a64a9af02c393"
# 停止 blade server
blade server stop
{"code":200,"success":true,"result":"pid is 12619"}2）相关链接说明：
MeterSphere github 地址：https://github.com/metersphere/metersphere
ChaosBlade 地址：https://github.com/chaosblade-io/chaosblade/wiki/%E6%96%B0%E6%89%8B%E6%8C%87%E5%8D%97
ChaosBlade web 服务 http 接口地址：https://chaosblade-io.gitbook.io/chaosblade-help-zh-cn/blade-server
3）感觉 MeterSphere 好像挺适合做这种自动监控的事情的，不知道其它使用者有用 MeterSphere 搞出来一个自动监控平台的没，有的话可以一并分享下。
MeterSphere的官网链接：https://metersphere.io/
以上就是我在用 MeterSphere 调用 ChaosBlade 开源混沌注入工具的简单实践，若有不足之处或错误的地方请多指出，谢谢。