用 AI Agent 封装 AWS FIS：混沌工程的端到端自动化实践
混沌工程的核心矛盾：所有人都认可它的价值，但很少有团队常规化实施。
Netflix 2011 年开源 Chaos Monkey，亚马逊云科技 2021 年推出 Fault Injection Service（FIS）。工具在进化，但门槛始终没降到普通工程师能轻松使用的程度。
这篇介绍一种新的思路——用三个 Agent Skill 封装 FIS 的专业知识，形成"故障注入 → 日志采集 → 智能分析"的端到端流水线。
混沌工程为什么难普及
门槛一：FIS 学习曲线
FIS 支持几十种 action，覆盖 EC2、RDS、Aurora、ElastiCache、EKS 等服务。但要用好它，你需要：
- 理解每种 action 的适用范围和兼容性约束
- 知道
failover-db-cluster只能用于 Aurora 集群，独立 RDS 要用reboot-db-instances - 掌握 Scenario Library 4 种复合场景的 JSON 模板格式（无法通过 API 动态生成）
- 处理 EKS Pod 注入的一堆前置条件：
- 集群认证模式必须是
API_AND_CONFIG_MAP或API - 配置 K8s RBAC 资源（ServiceAccount、Role、RoleBinding）
- 确认目标 Pod 的
readOnlyRootFilesystem不为 true
- 集群认证模式必须是
从"我想测个 AZ 故障"到写出正确的 experiment template，新手可能要折腾大半天。
门槛二：应用层观测盲区
FIS 报告只覆盖基础设施层。RDS failover 30 秒完成——但应用呢？
- 连接池恢复了吗？恢复花了多久？
- 重试机制生效了吗？重试了几次？
- 用户看到错误了吗？错误率峰值多高？
- 端到端恢复时间是多少？
要回答这些，得手动采集 kubectl logs，与实验时间线逐条对齐分析。这个过程繁琐到大多数团队直接跳过了——实验做了，但"做了有什么发现"说不清楚。
混沌工程的价值不在于"注入了故障"，而在于"理解了系统如何响应故障"。没有应用层观测，价值就打了折扣。
三个 Agent Skill 的设计
Skill 1：实验准备（aws-fis-experiment-prepare）
输入：自然语言描述的测试意图
比如：
- "准备一个 AZ 断电实验，目标 us-east-1a"
- "测试 RDS 故障转移对应用的影响"
- "帮我配一个 EKS Pod 网络延迟实验，目标 payment-service"
Agent 的处理流程：
-
意图理解 → 方案选择：从几十种 action 中选择合适的方案。支持 Scenario Library 4 种复合场景 + EKS Pod 7 种故障注入 + EC2/RDS/Aurora/ElastiCache/EBS 等独立 action。
-
资源发现 → 兼容性验证：调用 AWS CLI 查询目标资源，主动检查 action 兼容性。例如自动区分 Aurora 集群和独立 RDS 实例，兼容性问题在配置阶段就暴露。
-
文档读取 → 模板提取：Scenario Library 场景自动从文档获取 JSON 模板，不用人工复制。
-
EKS 前置条件自动处理：通过 Lambda + CloudFormation Custom Resource 管理 K8s RBAC。关键特性：幂等创建（已存在则跳过）、跨实验共享（同 namespace 不重复配）、栈删除时保留（不影响其他实验）。
-
生成完整配置目录：输出 experiment template、IAM policy、CloudFormation 模板、CloudWatch 告警和 Dashboard 配置。
-
自愈式部署：先用 IAM policy simulation 预检权限，然后 CloudFormation 部署。如果部署失败，自动分析 Events → 定位根因 → 修复模板 → 删栈 → 重试，最多 5 次。
自愈式部署这个能力特别实用。CloudFormation 部署失败的原因五花八门——IAM 传播延迟、资源属性验证错误、区域服务限制、资源名称冲突。以前每次都要手动看 Events 排查，现在 Agent 自动搞定。
Skill 2：实验执行（aws-fis-experiment-execute）
核心原则：安全第一，绝不自动启动实验。
验证 CFN 栈状态
↓
提取实验模板 ID + 受影响资源清单
↓
实验分类（Pod 类型 / Non-Pod 类型）
↓
日志采集决策
↓
展示完整实验计划 → 等待用户确认
↓
执行 + 实时日志采集 + 监控
智能日志采集决策是一个设计亮点：
- Agent 分析所有 actionId，分为 Pod 类型（含
aws:eks:pod-*）和 Non-Pod 类型 - Pod 类型：自动启用应用日志采集
- Non-Pod 类型：主动询问用户"基础设施故障可能级联到应用层，是否也采集应用日志？"
为什么不自动启动？混沌工程是有风险的操作，可能影响生产服务。Agent 可以自动化所有准备工作，但"开始注入故障"这个决定必须是人做的。
Skill 3：智能分析
实验完成后 Agent 自动：
- 关联基础设施事件和应用日志的时间线
- 分析故障传播路径（注入点 → 受影响组件 → 用户可感知的表现）
- 定位恢复瓶颈
- 生成结构化报告（时间线、影响范围、恢复时长、改进建议）
这就补齐了 FIS 原生缺失的应用层观测能力。 从"注入了故障"升级到"完整理解了故障的全链路影响"。
EKS Pod 级故障注入 7 种类型
| 类型 | Action | 模拟场景 |
|---|---|---|
| 网络延迟 | aws:eks:pod-network-latency |
跨 AZ 延迟增大 |
| 丢包 | aws:eks:pod-network-packet-loss |
网络质量劣化 |
| 端口黑洞 | aws:eks:pod-network-blackhole-port |
依赖服务不可达 |
| CPU Stress | aws:eks:pod-cpu-stress |
计算资源竞争 |
| Memory Stress | aws:eks:pod-memory-stress |
OOM 风险 |
| IO Stress | aws:eks:pod-io-stress |
磁盘性能下降 |
| Pod 删除 | aws:eks:pod-delete |
节点故障/Pod 驱逐 |
所有前置条件（RBAC、IAM、集群认证模式检查）被 Agent 完全封装。用户只需指定目标 Pod 和故障类型。
安全设计
| 层面 | 设计 |
|---|---|
| 执行控制 | 人工确认后才启动 |
| 权限范围 | 每次实验独立 IAM policy |
| 预检 | IAM policy simulation |
| 止损 | FIS stop condition |
| RBAC | CFN Custom Resource 幂等管理 |
范式变化
| 维度 | 传统方式 | Agent 方式 |
|---|---|---|
| 交互 | 编写 experiment template | 描述测试意图 |
| 兼容性 | 启动时才报错 | 配置阶段主动验证 |
| EKS RBAC | 手动 kubectl apply | Lambda + CFN 自动 |
| 部署失败 | 手动排查 CFN Events | 自愈式重试 |
| 应用观测 | 手动捞日志 | 自动采集 + 分析 |
核心变化：从"先学 FIS"到"描述意图"。FIS 的能力没变，变的是交互方式。
演进视角
| 年份 | 里程碑 | 门槛 |
|---|---|---|
| 2011 | Chaos Monkey | 深度定制 |
| 2021 | 亚马逊云科技 FIS | 学 FIS |
| 2026 | AI Agent Skill | 描述意图 |
15 年的趋势：门槛持续降低。AI Agent 不是替代专家，是让非专家也能做专家级别的故障演练。
小结
混沌工程不普及的根因不是理念问题，是工具易用性问题。AI Agent 封装 FIS 专业知识后，门槛从"先成为 FIS 专家"降到"描述你想测什么"。
对于想开始做混沌工程但卡在学习成本的团队，三个 Skill 的流水线方案值得一试。
参考：
浙公网安备 33010602011771号