AI Agent 驱动的混沌工程实践：三个 Skill 实现从实验准备到应用影响分析的完整闭环

混沌工程的工程化困境

混沌工程的核心价值在于"理解系统如何响应故障"，而非"注入了故障"本身。然而在实际工程实践中，这项能力面临两个瓶颈：

瓶颈一：工具复杂度高。AWS FIS 提供了几十种 action 和 4 种 Scenario Library 复合场景，功能覆盖全面。但选型、兼容性验证、模板编写、EKS RBAC 配置等前置工作需要深入的领域知识。大部分团队没有专门的混沌工程角色，学习成本成为实施的主要障碍。

瓶颈二：观测能力不完整。FIS 实验报告提供基础设施视角（failover 耗时、节点状态等），但缺乏应用层观测——连接池恢复时间、重试机制是否生效、用户是否看到错误——这些信息需要手动收集 kubectl logs 并与实验时间线对齐。

亚马逊云科技官博近期发布的方案通过 3 个 AI Agent Skill 解决了这两个问题。本文从工程实践角度分析其设计思路和适用场景。

架构设计

三个 Skill 形成流水线，通过配置目录传递上下文：

Skill 1 (Prepare)
  用户意图 → 方案选择 → 兼容性验证 → 前置配置 → 自愈部署
  输出：配置目录（template + IAM + CFN + alarms + dashboard）
    ↓
Skill 2 (Execute)
  安全确认 → 实验分类（POD/NON-POD）→ 日志采集决策
  → 启动 → 实时监控 → 结果报告
    ↓
Skill 3 (Analyze)
  自动发现应用依赖 → 分级日志采集 → 应用层分析
  输出：错误时间线 + 模式统计 + 恢复时间 + 跨服务关联表

Skill 1 的设计亮点

兼容性验证：在实验启动前（而非报错后）发现资源与 action 的不兼容。例如 failover-db-cluster 只适用 Aurora 集群，Agent 会通过 describe-db-instances 提前判断并建议替代方案。

EKS 前置条件自动化：EKS Pod 故障注入需要集群认证模式为 API_AND_CONFIG_MAP、K8s RBAC 资源（ServiceAccount/Role/RoleBinding）、Pod 的 readOnlyRootFilesystem 为 false。Agent 通过 Lambda + CloudFormation Custom Resource 幂等管理这些资源。

自愈式部署：CloudFormation 部署失败（IAM 传播延迟、属性验证错误等）时，自动分析错误 → 修复模板 → 删除失败栈 → 重新部署，最多重试 5 次。

Skill 2 的安全设计

核心原则：绝不自动启动实验。

执行前会展示：实验类型、目标资源、影响区域、预计时长、监控中的应用列表。用户明确确认后才启动。

实验分类逻辑：分析 experiment template 中的 actionId，包含 aws:eks:pod-* 的归为 POD 类型（自动启用日志采集），其余为 NON-POD 类型（询问用户是否需要采集应用日志）。

Skill 3 的分级日志策略

优先级链：Container Insights > kubectl logs

检测逻辑：查询 amazon-cloudwatch-observability addon 或 CloudWatch agent DaemonSet → 存在则通过 CloudWatch Logs Insights 查询 /aws/containerinsights/{cluster}/application（可获取已终止 Pod 日志）→ 不存在则 fallback 到 kubectl logs --since-time（提示用户无法获取已终止 Pod 日志）。

应用发现：查询受影响服务的端点 → 搜索所有 Pod 的环境变量和 ConfigMap → 找出依赖这些服务的应用。基于 label selector 采集日志，确保捕获实验期间重建的 Pod。

效果分析

准备阶段：从"人工学习 FIS + 编写模板"（天级别）变为"描述意图"（分钟级别）
执行阶段：从"手动启动 + 手动监控"变为"确认后自动执行 + 实时分析"
分析阶段：从"手动收集 kubectl logs + 人工对齐时间线"变为"自动采集 + 结构化分析"

跨服务关联表是分析阶段的关键产出——在一张表中统一展示时间线、各服务影响和应用响应，清晰呈现故障传播路径。

工程取舍

适合：

  • 需要常规化混沌工程但缺乏专职 SRE 的团队
  • 需要理解基础设施故障对应用真实影响的场景
  • EKS 环境下的多服务故障演练

不适合：

  • 需要高度定制化实验流程的专家团队（Skill 封装了通用流程，灵活性有限）
  • 非 EKS 环境的应用层分析（Skill 3 依赖 kubectl）

与手动 FIS 的关系：不是替代而是补充。专家团队可以直接使用 FIS API 获得完全控制；非专家团队通过 Agent Skill 获得准专家级别的操作能力。

获取方式

三个 Skill 开源在 GitHub：aws-samples/sample-fis-skills

前置条件：EKS 集群、kubectl、AWS CLI、FIS 相关 IAM 权限。

参考资料

posted @ 2026-04-21 13:35  亚马逊云开发者  阅读(9)  评论(0)    收藏  举报