编译者摘要：本文提出ChaosEater—— 一款基于大语言模型（LLMs）的全自动化混沌工程（CE）系统，旨在低成本帮助用户构建高弹性的Kubernetes（K8s）软件系统；该系统通过预定义智能体工作流，将 CE 的 “假设定义、故障实验、结果分析、系统改进” 全周期拆解为细分任务并分配给不同角色的 LLM 智能体，结合Validation as Code（VaC）和Chaos Mesh工具实现自动化执行；通过对小型系统 NGINX（单周期成本 **$0.21**、耗时11分钟）和大型电商系统SOCKSHOP（单周期成本**$0.84**、耗时25 分钟）的案例研究验证，ChaosEater 能稳定完成合理 CE 周期（NGINX 5 次运行全成功，SOCKSHOP 4 次成功），且经人类工程师和 3 种 LLM（GPT-4o、Claude Sonnet 3.5、Gemini Pro 1.5）定性验证有效；其核心贡献为：首个实现 CE 全周期自动化的 LLM 系统、开源全部资源、完成定量（成本 / 时间）与定性（流程有效性）评估。
一、研究背景与动机
混沌工程（CE）定义
通过主动向分布式系统注入故障，测试系统弹性、发现薄弱点，避免生产环境故障的工程技术，标准周期含 4 阶段：假设→实验→分析→改进。
传统 CE 的痛点
- 现有工具（如 Chaos Monkey、AWS FIS）仅自动化 “实验执行” 和 “指标收集”，但假设定义、实验规划、系统改进仍需手动；
- 手动流程耗力且需 “分布式系统 + CE + 软件工程” 多领域 expertise，导致成本高、门槛高。
LLM 的解决潜力
：LLM 在自然语言处理、软件工程（代码生成 / 测试 / 调试）、网络运维等领域表现突出，且已有研究探索其在故障根因分析、日志解析等局部运维任务的应用，为 CE 全周期自动化提供可能。
二、ChaosEater 系统设计
ChaosEater 通过预定义智能体工作流，将 CE 全周期拆解为 6 个阶段，由不同角色的 LLM 智能体协作完成，核心目标是自动化 K8s 系统的 CE 流程。
| 阶段 | 核心任务 | 关键技术 / 工具 |
|---|---|---|
| 0. 预处理（Pre-processing） | 1. 通过 Skaffold 部署 K8s 系统；2. 补充输入上下文（K8s 清单总结、潜在弹性问题）；3. 过滤有害指令 | Skaffold、K8s API |
| 1. 假设（Hypothesis） | 1. 定义稳态：生成Validation as Code（VaC）脚本（Python/k6），验证可测量指标（如 Pod 数量、响应时间）；2. 设计故障场景：从 Chaos Mesh 支持的故障中选择，细化参数（故障范围 / 强度） | VaC、Chaos Mesh |
| 2. 实验（Experiment） | 1. 规划三阶段流程：预验证（正常态 VaC）→故障注入（Chaos Mesh）→后验证（恢复态 VaC）；2. 生成 Chaos Mesh 工作流清单；3. 执行实验 | Chaos Mesh、VaC 脚本 |
| 3. 分析（Analysis） | 1. 检查 VaC 脚本结果：全通过则结束周期，否则分析故障原因；2. 生成含 “原因 + 对策” 的分析报告 | LLM 智能体（日志分析） |
| 4. 改进（Improvement） | 1. 重配置 K8s 清单（增删改资源，逐步提升冗余）；2. 循环 “实验→分析→改进” 至假设满足（改进循环） | LLM 智能体（配置优化） |
| 5. 后处理（Post-processing） | 1. 生成 CE 周期总结；2. 输出优化后的 K8s 清单 + Skaffold 配置 | LLM 智能体（总结生成） |
三、案例研究
通过 2 个 K8s 系统验证 ChaosEater 的有效性，实验使用GPT-4o-2024-08-06（温度 0），每个系统执行 5 次单 CE 周期。
3.1 目标系统配置
NGINX（小型系统）
2 个 K8s 清单（Pod.yml+Service.yml），故意设
restartPolicy=Never（Pod 故障后无法重启，弹性缺陷）。SOCKSHOP（大型电商系统）
：29 个 K8s 清单，除前端 Deployment（
front-end-dep.yml）设 1 副本外，其余 Deployment 设 2 副本（前端弹性缺陷）。
3.2 定量结果（成本与时间）
| 目标系统 | 指标类型 | 总消耗 | 预处理 | 假设阶段 | 实验阶段 | 分析阶段 | 改进阶段 | 后处理 |
|---|---|---|---|---|---|---|---|---|
| NGINX | 输入 tokens | 59k | 2.6k | 25k | 13k | 4.4k | 5.5k | 8.2k |
| 输出 tokens | 5.9k | 0.5k | 2.5k | 1.7k | 0.6k | 0.2k | 0.4k | |
| API 成本（$） | 0.21 | 0.01 | 0.09 | 0.05 | 0.02 | 0.02 | 0.02 | |
| 时间 | 11min | 21s | 2.6min | 4.4min | 50s | 12s | 21s | |
| SOCKSHOP | 输入 tokens | 284k | 30k | 150k | 57k | 14k | 15k | 18k |
| 输出 tokens | 13k | 5.7k | 3.8k | 1.8k | 0.7k | 0.6k | 0.5k | |
| API 成本（$） | 0.84 | 0.13 | 0.41 | 0.16 | 0.04 | 0.04 | 0.05 | |
| 时间 | 25min | 4.6min | 4.3min | 3.3min | 36s | 4.3min | 21s |
3.3 稳定性与定性验证
稳定性
5 次运行均无运行时错误，NGINX 5/5 成功完成配置优化，SOCKSHOP 4/5 成功（1 次未优化但完成有效 CE 周期）。
定性验证
选取 1 次运行结果，由 2 名人类工程师 + 3 种 LLM（GPT-4o、Claude Sonnet 3.5、Gemini Pro 1.5）按 5 分制评估（≥3 为正面），所有阶段评分均超阈值，确认 CE 流程合理。
四、结论、局限性与未来工作
核心结论
ChaosEater 实现了 CE 全周期自动化，能以低 cost（$0.2-0.8）、短时间（11-25min）构建 K8s 系统弹性，验证了 LLM 驱动 CE 的可行性。
局限性
- 安全风险：仅可部署于开发环境；
- 优化范围窄：仅支持 K8s 清单重配置，不覆盖前端 / 应用 / 底层代码；
- 漏洞发现局限：单 CE 周期内漏洞探索能力有限。
- 未来工作
- 安全增强：控制故障影响范围，增加高层监控系统；
- 优化扩展：支持前端代码（HTML/CSS/JS）、应用代码（Python）、底层代码（Terraform）重配置；
- 长期探索：多 CE 周期迭代优化假设，适配系统状态变化。
五、主要贡献
- 业界首个实现 CE 全周期自动化的 LLM 系统，为系统弹性改进全自动化提供可行性证据；
- 开源 ChaosEater 全部资源（https://github.com/ntt-dkiku/chaos-eater），为后续研究提供基础；
- 完成定量（成本 / 稳定性）与定性（流程有效性）评估，明确系统潜力、局限与未来方向。
六. 关键问题Q&A
问题 1：ChaosEater 通过哪些核心设计实现混沌工程（CE）全周期的自动化？
答：ChaosEater 通过 “智能体工作流 + LLM 分工 + 专用工具集成” 实现全自动化，核心设计包括 3 点：
预定义 agentic 工作流
将 CE 的 “假设 - 实验 - 分析 - 改进” 周期拆解为 “预处理→假设→实验→分析→改进→后处理”6 个阶段，确保流程系统性；
LLM 智能体分工
为每个阶段的细分任务分配特定角色的 LLM 智能体（如假设阶段的 “稳态定义智能体”“故障设计智能体”，分析阶段的 “故障根因分析智能体”），无需额外微调 LLM；
专用技术与工具集成
通过Validation as Code（VaC）实现稳态验证自动化（生成 Python/k6 脚本），借助Chaos Mesh实现故障注入与实验执行自动化，结合Skaffold完成 K8s 系统部署，形成端到端自动化闭环。
问题 2：案例研究中，ChaosEater 在成本、时间效率和稳定性上的具体表现如何？是否能体现 “低成本” 优势？
答：表现如下，且显著体现 “低成本” 优势：
- 成本与时间
- 小型系统 NGINX：单 CE 周期成本 **$0.21**，耗时11 分钟；
- 大型系统 SOCKSHOP（29 个 K8s 清单）：单周期成本 **$0.84**，耗时25 分钟；即使 SOCKSHOP 资源数量是 NGINX 的 10 倍以上，成本仅增加 4 倍、时间增加 2 倍，远低于人类工程师手动执行的成本（无统计数据但直观更低）。
稳定性
5 次重复运行均无运行时错误，NGINX 5/5 成功完成配置优化（修复
restartPolicy缺陷），SOCKSHOP 4/5 成功优化（修复前端副本数缺陷），1 次未优化但仍完成有效 CE 周期，稳定性可靠。综上，无论是小型还是大型 K8s 系统，ChaosEater 均以极低的时间和 monetary 成本完成 CE 周期，“低成本” 优势明显。
问题 3：ChaosEater 当前存在哪些关键局限性？未来将通过哪些方向解决这些问题？
答：当前局限性与对应解决方案如下表：
| 局限性 | 未来解决方向 |
|---|---|
| 1. 安全风险：仅可部署于开发环境，无法用于生产环境 | 1. 控制故障影响范围，避免生产级破坏；2. 增加高层监控系统，持续监督 ChaosEater 运行状态 |
| 2. 优化范围窄：仅支持 K8s 清单重配置，不覆盖前端代码（HTML/CSS/JS）、应用代码（Python）、底层代码（Terraform） | 扩展优化能力，将重配置范围覆盖前端、应用、底层代码，实现系统弹性的全栈优化 |
| 3. 漏洞发现局限：单 CE 周期内仅能探索有限漏洞，无法适配系统状态变化 | 实现多 CE 周期迭代：LLM 智能体基于前一周期结果优化假设，动态适配系统状态变化，提升长期漏洞探索能力 |
如何学习大模型 AI ？
由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。
但是具体到个人，只能说是：
“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。
这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。
我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。
我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。
第一阶段（10天）：初阶应用
该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。
- 大模型 AI 能干什么？
- 大模型是怎样获得「智能」的？
- 用好 AI 的核心心法
- 大模型应用业务架构
- 大模型应用技术架构
- 代码示例：向 GPT-3.5 灌入新知识
- 提示工程的意义和核心思想
- Prompt 典型构成
- 指令调优方法论
- 思维链和思维树
- Prompt 攻击和防范
- …
第二阶段（30天）：高阶应用
该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。
- 为什么要做 RAG
- 搭建一个简单的 ChatPDF
- 检索的基础概念
- 什么是向量表示（Embeddings）
- 向量数据库与向量检索
- 基于向量检索的 RAG
- 搭建 RAG 系统的扩展知识
- 混合检索与 RAG-Fusion 简介
- 向量模型本地部署
- …
第三阶段（30天）：模型训练
恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。
到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？
- 为什么要做 RAG
- 什么是模型
- 什么是模型训练
- 求解器 & 损失函数简介
- 小实验2：手写一个简单的神经网络并训练它
- 什么是训练/预训练/微调/轻量化微调
- Transformer结构简介
- 轻量化微调
- 实验数据集的构建
- …
第四阶段（20天）：商业闭环
对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。
- 硬件选型
- 带你了解全球大模型
- 使用国产大模型服务
- 搭建 OpenAI 代理
- 热身：基于阿里云 PAI 部署 Stable Diffusion
- 在本地计算机运行大模型
- 大模型的私有化部署
- 基于 vLLM 部署大模型
- 案例：如何优雅地在阿里云私有部署开源大模型
- 部署一套开源 LLM 项目
- 内容安全
- 互联网信息服务算法备案
- …
学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。
如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。
