1. 为什么我要把混沌实验交给 CLI 来跑
混沌工程这件事，说起来简单：在受控环境里注入故障，观察系统反应，找出薄弱点。但真到落地的时候，麻烦事一堆。你得先定义稳态假设，再设计实验模板，然后盯着监控看指标变化，最后还得手动回滚。一套流程走下来，架构师累得够呛，普通开发根本不敢碰。
我之前的做法是：在测试环境里手动改 Kubernetes 的 Deployment 副本数，或者用 Chaos Mesh 的 YAML 文件注入网络延迟。每次实验前要翻文档确认参数，实验后要切好几个控制台看日志和指标。最头疼的是，实验模板散落在各个 Git 仓库里，想复用还得先找半天。
后来我试过用 Amazon Q Developer CLI 配合 MCP 把 Amazon FIS 和 Chaos Mesh 串起来，整个流程才变得顺手。简单说，MCP 是一种让 CLI 工具能调用外部服务的协议，你可以把它理解成给命令行装了一组“插件”，每个插件负责一个专业领域。Amazon Q Developer CLI 负责理解你的自然语言，MCP 服务器负责实际执行故障注入和查询监控数据。
这套组合适合谁？我觉得三类人最受益：一是刚接触混沌工程、不想被复杂 YAML 劝退的开发者；二是需要定期做故障演练的运维团队；三是想快速验证架构韧性的系统架构师。你不需要背 FIS 的实验模板语法，也不用记 Chaos Mesh 的 CRD 字段，用日常说话的方式就能让 CLI 帮你生成并执行实验。
这篇文章我会按实际操作的顺序来写：先讲清楚整体架构和前置准备，然后给出可复制的 MCP 配置片段，接着用一个具体实验走完“生成模板→执行→验证指标→回滚确认”的闭环，最后把我在配置过程中踩过的报错整理出来。你跟着做，在测试环境里复现一套智能混沌实验闭环是没问题的。
2. 前置准备：TaoToken 与 MCP 服务器的接入配置
在开始配置 MCP 之前，我需要先解决一个实际问题：Amazon Q Developer CLI 本身是一个命令行工具，但它要调用各种模型能力来理解自然语言、生成实验模板，这中间需要一个稳定的 API 入口。我用的方案是通过 TaoToken 来统一管理模型调用，它的 API 地址是 https://taotoken.net/api，配合 API Key 就能让 CLI 正常发起请求。
这里要说明一下，TaoToken 在这里的角色是模型调用的接入层，不是替代 Amazon Q Developer CLI 本身。CLI 仍然是“混沌指挥官”，TaoToken 负责把自然语言理解、模板生成这些需要模型能力的请求转发出去。你需要在 TaoToken 的控制台创建一个 API Key，然后把它配置到 CLI 的环境变量或者配置文件中。
具体操作路径是这样的：先访问 https://taotoken.net/api-keys 创建 Key，然后参考 https://taotoken.net/doc 的接入文档，把 Base URL 设置为 https://taotoken.net/api，Model ID 根据你实际使用的模型来填。如果你用的是 Claude Code 或者类似的编码工具，配置方式也类似，Base URL 和 Key 填对就行。
接下来是 MCP 服务器的准备。这次实验会用到五个 MCP Server：Core MCP Server 负责管理和协调，Amazon EKS MCP Server 操作 Kubernetes 集群，Amazon CloudWatch Logs MCP Server 查询日志和监控数据，FIS MCP Server 集成 Amazon FIS 的托管故障注入，Chaos Mesh MCP Server 提供容器环境的故障模拟。
FIS MCP Server 和 Chaos Mesh MCP Server 推荐用 uv 来执行，这样依赖管理更干净。你需要先安装 uv，然后从对应的 GitHub 仓库拉取代码。Core、EKS、CloudWatch Logs 这三个 MCP Server 来自 awslabs/mcp 仓库，安装方式类似。
安装完成后，关键一步是配置 Amazon Q Developer CLI 的 MCP servers。CLI 的配置文件通常放在用户目录下的 .aws/amazonq/ 路径里，你需要把每个 MCP Server 的启动命令、参数、环境变量写进去。配置格式是 JSON，下面我会给出一个完整的片段。
这里有个细节要注意：FIS MCP Server 和 Chaos Mesh MCP Server 需要访问对应的云资源和 Kubernetes 集群，所以你的 CLI 运行环境里要有相应的凭证。EKS 集群的 kubeconfig 要配好，Amazon 区域的凭证要通过环境变量或者 IAM 角色提供。CloudWatch Logs MCP Server 也需要读日志的权限。
如果你在配置过程中遇到 OAuth 相关的报错，比如提示 token 过期或者权限不足，先检查 API Key 是否有效，再确认 MCP Server 的启动参数里有没有漏掉区域配置。我一开始就是忘了给 FIS MCP Server 指定 us-east-2 区域，结果它默认去了 us-east-1，导致找不到实验模板。
3. 可复制的 MCP 配置片段与实验模板
这一节我直接给出可以复制粘贴的配置。先看 Amazon Q Developer CLI 的 MCP 配置文件，路径是 ~/.aws/amazonq/mcp.json。你需要把里面的路径和区域换成自己的实际值。
{ "mcpServers": { "core-mcp": { "command": "uvx", "args": [ "awslabs.core-mcp-server@latest" ], "env": { "AWS_REGION": "us-east-2", "FASTMCP_LOG_LEVEL": "ERROR" } }, "eks-mcp": { "command": "uvx", "args": [ "awslabs.eks-mcp-server@latest", "--allow-write", "--allow-sensitive-data-access" ], "env": { "AWS_REGION": "us-east-2", "FASTMCP_LOG_LEVEL": "ERROR" } }, "cloudwatch-logs-mcp": { "command": "uvx", "args": [ "awslabs.cloudwatch-logs-mcp-server@latest" ], "env": { "AWS_REGION": "us-east-2", "FASTMCP_LOG_LEVEL": "ERROR" } }, "fis-mcp": { "command": "uv", "args": [ "--directory", "/path/to/AWS-FIS-MCP", "run", "server.py" ], "env": { "AWS_REGION": "us-east-2", "FASTMCP_LOG_LEVEL": "ERROR" } }, "chaosmesh-mcp": { "command": "uv", "args": [ "--directory", "/path/to/Chaosmesh-MCP", "run", "server.py" ], "env": { "KUBECONFIG": "/home/user/.kube/config", "FASTMCP_LOG_LEVEL": "ERROR" } } } }这个配置里，core-mcp 和 eks-mcp 用的是 uvx 直接运行 awslabs 发布的包，fis-mcp 和 chaosmesh-mcp 用的是本地克隆的仓库路径。你需要把 /path/to/AWS-FIS-MCP 和 /path/to/Chaosmesh-MCP 替换成实际路径。KUBECONFIG 也要指向你真实的 kubeconfig 文件。
配置写好后，启动 Amazon Q Developer CLI，它应该会自动加载这些 MCP Server。你可以先用一句简单的话测试连接：让 CLI 列出当前可用的 MCP 工具。如果配置正确，它会返回五个服务器的工具列表。
接下来是实验模板。我以“关闭 votingapp 应用 50% 的 Pod”为例，展示 CLI 生成的 FIS 实验模板长什么样。你可以在 CLI 里输入：
Basing Pod Deletion Template, shut down 50% of the pods of the votingapp application in the workshop eks cluster in us-east-2.CLI 会调用 FIS MCP Server，生成一个实验模板并返回模板 ID。这个模板的核心参数包括：目标资源是 EKS 集群里的 votingapp Deployment，故障类型是 Pod 删除，影响比例是 50%，执行区域是 us-east-2。你可以让 CLI 把模板详情打印出来，确认参数无误后再执行。
如果你想用 Chaos Mesh 做容器级别的故障注入，比如注入网络延迟，可以这样描述：
Create a Chaos Mesh experiment to inject 200ms network latency into the votingapp service in the workshop namespace.CLI 会调用 Chaos Mesh MCP Server，生成对应的 NetworkChaos 资源定义。你可以让 CLI 先 dry-run，确认 YAML 内容符合预期，再实际应用。
这里有个实用技巧：你可以让 CLI 把生成的实验模板保存到本地文件，方便后续复用和版本管理。比如让它把 FIS 模板导出成 JSON，或者把 Chaos Mesh 的 YAML 写到指定目录。这样下次做类似实验时，直接基于已有模板改参数就行，不用从头描述。
配置和模板都准备好后，下一步就是实际执行并验证结果。我会在下一节详细走一遍验证请求和成功结果的确认过程。
4. 验证请求与成功结果：指标对比与回滚确认
实验执行之前，我习惯先确认稳态。所谓稳态，就是系统在正常情况下的关键指标基线。对于 votingapp 这个应用，我会关注三个指标：Pod 的就绪数量、请求的 P99 延迟、以及错误率。这些指标可以从 CloudWatch Dashboard 里读到，CLI 可以通过 CloudWatch Logs MCP Server 查询。
先让 CLI 读取当前指标：
Observe the metrics in CON404-Workshop Dashboards on CloudWatch in us-east-2 and summarize the current health status of votingapp.CLI 会返回一段摘要，包括当前 Pod 数量、延迟分位数、错误率。我把这个结果记下来，作为实验前的基线。
然后执行故障注入。还是用刚才的 Pod 删除实验：
Execute the FIS experiment that shuts down 50% of the votingapp pods in the workshop eks cluster.CLI 会调用 FIS MCP Server 启动实验。执行过程中，你可以让 CLI 实时查询实验状态。FIS 实验通常有几个状态：pending、running、completed。Pod 删除这类故障注入，running 状态会持续一段时间，然后自动进入 completed。
实验完成后，再次查询指标：
Observe the metrics in CON404-Workshop Dashboards on CloudWatch in us-east-2 and analyze the impact of the last experiment on votingapp.CLI 会对比实验前后的指标变化。我实测下来，Pod 删除 50% 后，就绪 Pod 数量会先下降，然后因为 Deployment 的副本集控制器会自动拉起新 Pod，数量会逐渐恢复。延迟指标在 Pod 被删除的瞬间会有抖动，P99 可能从 200ms 跳到 500ms 左右，然后随着新 Pod 就绪慢慢回落。错误率如果配置了 PodDisruptionBudget，可能不会有明显上升；如果没有 PDB，错误率会短暂升高。
这些对比数据就是实验的价值所在。你能清楚看到系统在故障注入下的行为：哪些指标恶化了，恶化到什么程度，恢复用了多长时间。如果恢复时间超出预期，或者错误率飙升到不可接受的水平，就说明系统韧性有短板，需要优化。
回滚确认是最后一步。FIS 实验完成后，故障注入会自动停止，但你需要确认系统真的回到了稳态。让 CLI 再查一次指标：
Verify that votingapp has returned to its steady state after the experiment. Check pod count, latency, and error rate.CLI 会返回当前指标，你把它和实验前的基线对比。如果 Pod 数量恢复到原始值，延迟和错误率也回到基线附近，说明回滚成功。如果还有异常，可以让 CLI 调用 EKS MCP Server 检查 Pod 事件和日志，定位问题。
对于 Chaos Mesh 的实验，回滚方式略有不同。NetworkChaos 这类资源在实验结束后需要手动删除，或者设置 duration 让它自动过期。你可以让 CLI 删除对应的 Chaos Mesh 资源：
Delete the Chaos Mesh NetworkChaos experiment in the workshop namespace.删除后同样要验证指标恢复。我建议在实验模板里就加上 duration 参数，比如 5 分钟，这样即使你忘了手动清理，故障注入也会自动停止。
整个闭环走下来，从稳态确认到故障注入，再到指标对比和回滚验证，全部通过 CLI 的自然语言交互完成。你不需要切换多个控制台，也不用记复杂的命令参数。这套流程在测试环境里可以反复跑，每次实验的模板和结果都能沉淀下来。
5. 常见报错排查：401、local proxy failed 与 OAuth 问题
配置 MCP 和跑实验的过程中，我遇到过几类典型报错。这一节我把它们整理出来，你遇到类似问题时可以对照排查。
第一类是 401 错误。这个通常出现在 CLI 调用模型 API 的时候，提示 unauthorized。原因一般是 API Key 无效或者过期。你需要检查 TaoToken 控制台里的 Key 状态，确认没有过期，并且配置到了正确的位置。如果你用的是环境变量，确认变量名和 CLI 读取的一致。有时候 Key 复制的时候多了空格，也会导致 401，这个细节容易被忽略。
第二类是 local proxy failed。这个报错说明 CLI 在尝试连接 MCP Server 的时候失败了。可能的原因有几个：MCP Server 的启动命令路径不对，或者 uv/uvx 没有安装，或者 Python 依赖缺失。你可以先在终端里手动执行配置里的 command 和 args，看看能不能正常启动。如果手动启动报错，根据错误信息补依赖。如果手动能启动但 CLI 里报 local proxy failed，检查配置文件里的路径是不是绝对路径，相对路径有时候会解析出错。
第三类是 OAuth 相关报错。比如提示 token expired 或者 insufficient permissions。这类问题通常和云资源访问凭证有关。FIS MCP Server 需要调用 Amazon FIS 的 API，EKS MCP Server 需要访问 EKS 集群，CloudWatch Logs MCP Server 需要读日志。你需要确认运行 CLI 的环境里有对应的 IAM 权限。如果是本地运行，检查 ~/.aws/credentials 里的凭证是否有效；如果是 EC2 或容器环境，检查实例角色或任务角色的权限策略。
还有一个我踩过的坑：FIS MCP Server 启动时没有指定区域，默认去了 us-east-1，但我的实验模板都在 us-east-2。结果 CLI 列出的模板列表是空的，执行实验也报找不到资源。解决办法就是在 mcp.json 的 env 里显式设置 AWS_REGION，确保和你的实验区域一致。
另外，如果你在 CLI 里看到 reading choices 相关的报错，比如解析模型返回结果时出错，这可能是模型输出格式和 CLI 预期不一致。你可以尝试换一个 Model ID，或者在描述实验时把参数写得更明确一些，减少模型自由发挥的空间。
对于 Chaos Mesh MCP Server，常见的报错是连接 Kubernetes 集群失败。检查 KUBECONFIG 环境变量是否指向正确的配置文件，以及当前上下文是否有权限操作目标 namespace。你可以先用 kubectl 手动执行一个简单命令，确认集群连通性，再让 CLI 去调用。
排查这类问题的通用思路是：先手动复现，再对比 CLI 环境。MCP Server 本质上就是一个本地进程，CLI 通过标准输入输出和它通信。你手动能跑通的命令，配置到 CLI 里也应该能跑通。如果手动跑不通，先解决手动的问题，再回头看 CLI 配置。
6. 把智能混沌实验接入你的日常流程
这套方案跑通之后，我把它接入了日常的测试流程。具体做法是：在 CI 流水线里加一个混沌实验阶段，每次发布到测试环境后，自动触发一组预设的故障注入实验，观察系统指标是否在可接受范围内。实验模板通过 CLI 生成并保存到代码仓库，版本管理和复用都很方便。
如果你主要做长期编码和 Agent 相关的开发，可以考虑用 Coding Plan 来管理模型调用额度，这样在频繁跑实验的时候不用担心 Key 的配额问题。对于需要快速验证模型能力的场景，模型对话入口更适合做单次测试。而接入文档和 API Keys 页面则是配置阶段最常访问的地方。
我在实际使用中还有一个习惯：每次实验结束后，让 CLI 把实验报告导出成 Markdown，包括实验前后的指标对比、故障注入参数、恢复时间。这些报告积累下来，就是系统韧性的一手数据。下次做架构评审或者容量规划的时候，直接翻这些报告就行，比拍脑袋靠谱得多。
混沌工程的价值不在于工具多花哨，而在于你能不能持续地、低成本地做实验。Amazon Q Developer CLI 加 MCP 的组合，把实验门槛降到了“会说话就能做”的程度。你不需要成为 FIS 或 Chaos Mesh 的专家，也能在测试环境里跑出有价值的韧性验证结果。剩下的就是动手试，从一个小实验开始，慢慢把闭环跑顺。
