1. 项目概述当混沌工程遇上自然语言最近在搞稳定性保障和故障演练的团队估计都听过“混沌工程”的大名。简单说它就是通过在生产环境中故意引入故障来验证系统韧性的实践。但传统混沌工程有个老毛病门槛高、操作重。你得懂一堆工具的命令行熟悉复杂的故障场景配置每次演练从设计、执行到观测、恢复链路又长又繁琐导致很多团队“想练但不敢练”或者“练了但没练透”。我所在的团队也面临同样的问题。直到我们开始尝试用自然语言来驱动整个混沌工程流程情况才发生了根本变化。这个项目的核心就是基于阿里云开源的混沌工程工具 ChaosBlade构建一个能够理解自然语言指令的 AI Agent我们内部称之为 Blade AI Agent实现从故障场景描述、到具体演练执行、再到结果观测分析的端到端自动化。想象一下你不再需要去翻 ChaosBlade 那上百个参数的命令手册也不用在复杂的 YAML 文件里调试。你只需要对 AI Agent 说“模拟一下华东1地域的 ECS 实例 CPU 使用率飙升到 80%持续 5 分钟并且检查一下订单服务的响应时间 SLA 是否还能保持在 99.9% 以内。” 剩下的从解析你的意图、组装 ChaosBlade 命令、在目标机器执行、监控业务指标、到生成演练报告全部由这个 Agent 自动完成。这不仅仅是效率的提升更是将混沌工程从“专家技能”变成了“团队通用能力”。下面我就把我们趟过的路、踩过的坑和最终沉淀下来的实战经验毫无保留地分享出来。2. 核心思路用 AI Agent 重构故障演练工作流2.1 传统模式的痛点与自动化机遇在引入 AI 之前我们的故障演练流程是线性的但每个环节都充满手动操作和上下文切换场景设计运维或开发人员在文档或脑子里构思故障场景。工具转化将场景“翻译”成具体的混沌工程工具命令或配置比如 ChaosBlade 的blade create cpu fullload命令并精确设置cpu-percent、timeout等参数。环境准备确保目标机器安装了 ChaosBlade 客户端并获取权限。执行与监控在命令行执行命令同时打开监控系统如 Prometheus Grafana观察业务指标。恢复与验证手动停止故障注入确认服务恢复并检查数据一致性。报告编写整理监控截图、日志人工编写演练报告。这个流程的痛点非常明显高度依赖个人经验尤其是步骤2和4操作容易出错参数拼写错误、目标 IP 搞错效率低下大量重复劳动难以规模化无法同时进行多场景、多批次演练。而 AI特别是大语言模型LLM给我们带来了新的可能性。LLM 擅长理解和生成结构化文本这正是连接“人类自然语言描述”和“机器可执行指令”的完美桥梁。我们的核心思路就是构建一个智能体Agent将 LLM 作为其“大脑”用于理解用户意图和规划任务将混沌工程工具链ChaosBlade、监控系统、运维平台作为其“手脚”用于执行具体操作和感知系统状态。让这个 Agent 充当一个全能的“故障演练工程师”接收自然语言任务并驱动整个闭环。2.2 Blade AI Agent 的顶层架构设计我们的 Blade AI Agent 采用了经典的 AI Agent 架构范式并针对混沌工程领域做了深度定制。整个系统可以划分为四层第一层自然语言交互层这是用户入口可以是 Web 聊天界面、命令行工具CLI或是集成到钉钉/飞书等办公软件中的机器人。它的核心是提示词Prompt工程用于将用户的非结构化输入引导和规范成 Agent 能够处理的清晰任务描述。例如当用户输入“给订单服务加点压力”时提示词会引导模型反问“请问您想模拟哪种压力是 CPU 压力、内存压力还是网络延迟针对哪个具体服务或实例持续多久”第二层智能决策与规划层这是 Agent 的“大脑”由 LLM我们选用的是性能与成本平衡较好的开源模型驱动。它接收来自交互层的清晰任务描述并进行如下工作意图识别与槽位填充识别故障类型如 CPU、网络、应用层、目标对象如服务名、IP、K8s Pod、参数如负载百分比、延迟时间、错误码等。任务规划与分解将一个复杂任务分解为原子操作序列。例如“模拟数据库主从延迟并观察业务影响”会被分解为1. 在数据库主机注入网络延迟2. 启动业务流量监控3. 等待一段时间4. 停止故障注入5. 分析监控数据对比。工具调用决策为每个原子操作选择合适的工具。例如“注入网络延迟”对应 ChaosBlade 的网络模块“启动监控”对应调用监控平台的 API。第三层工具执行层这是 Agent 的“手脚”包含了所有可被调用的具体能力ChaosBlade 控制器封装所有 ChaosBlade 命令的创建、查询、销毁操作。它接收结构化参数如{“target”: “cpu”, “action”: “fullload”, “params”: {“cpu-percent”: “80”, “timeout”: “300”}}生成最终的命令并在目标机器通过 ChaosBlade 客户端执行。监控与观测器封装对 Prometheus、SLS 日志服务、ARMS 应用监控等系统的查询。它可以根据故障场景自动定位相关的核心业务指标如 QPS、错误率、响应时间 P99和基础设施指标如 CPU、内存。基础设施管理器用于获取和验证目标资源信息例如通过 CMDB 或 K8s API 根据服务名解析出具体的 Pod IP 列表。第四层知识反馈与记忆层为了让 Agent 越用越聪明我们设计了两个核心机制演练知识库存储历史上成功的演练场景模板、常用的监控指标大盘链接、不同服务的稳态基线数据。新的任务规划可以参考历史模板进行优化。执行反馈循环将每次工具执行的结果成功/失败、输出日志和监控数据的变化作为上下文反馈给 LLM。这使得 Agent 在后续步骤或未来任务中能进行更准确的判断。例如如果注入 CPU 负载后业务指标无变化Agent 可能会判断目标选择有误或故障未生效并触发告警或尝试其他手段。这个架构的关键在于LLM 并不直接操作系统而是通过严谨定义的“工具”Tool来交互。每个工具都有明确的输入/输出格式描述通常用 JSON SchemaLLM 通过函数调用Function Calling的方式来使用它们。这保证了操作的安全性和可控性。3. 核心模块实现从自然语言到混沌命令3.1 提示词工程让 AI 理解“故障场景”提示词是 Agent 的“第一课”教它如何理解混沌工程这个专业领域。一个糟糕的提示词会让模型胡言乱语而一个好的提示词能让它像资深 SRE 一样思考。我们的系统提示词System Prompt核心包含以下几个部分角色与能力定义 明确告诉模型“你是一个专业的混沌工程专家精通 ChaosBlade 工具和分布式系统故障模式。你的任务是将用户模糊的故障描述转化为精确、可执行、安全的混沌实验步骤。”约束与安全规则重中之重 这是防止“AI 搞垮生产”的防火墙。必须清晰列出确认原则任何涉及生产环境Prod的操作必须向用户二次确认并列出潜在影响。范围限制禁止同时对一个服务的所有实例或超过 50% 的集群节点进行破坏性演练除非用户明确指定为“熔断演练”等场景。超时机制每个自动注入的故障必须设置有最大超时时间如默认30分钟并建议用户设置监控告警。工具限制你只能使用我提供的工具列表ChaosBlade控制器、监控查询器等不能自行编造或执行任何系统命令。输出格式规范 要求模型以严格的 JSON 格式输出其“思考过程”和“决策”例如{ “user_intent”: “模拟订单服务数据库延迟” “parsed_scenario”: { “fault_type”: “network_delay”, “target”: { “type”: “service”, “name”: “order-service”, “resource_identifier”: “通过CMDB查询的数据库主机IP列表” }, “parameters”: { “time”: “200ms”, “offset”: “50ms”, “interface”: “eth0”, “duration”: “5m” } }, “action_plan”: [ {“step”: 1, “tool”: “resource_resolver”, “purpose”: “根据服务名定位数据库主机”}, {“step”: 2, “tool”: “chaosblade_controller”, “purpose”: “对目标主机注入网络延迟”}, {“step”: 3, “tool”: “monitor”, “purpose”: “监控订单服务API的响应时间P99和错误率”} ] }通过这样的结构化输出后端的程序可以轻松解析并驱动相应的工具执行。实操心得提示词的迭代最初的提示词很简单导致模型经常“幻觉”出一些不存在的 ChaosBlade 参数。我们通过记录大量“用户输入-模型输出-人工修正”的对话数据不断优化提示词。一个有效的方法是加入“少样本示例”Few-Shot Examples在提示词中直接给出几个正确解析的范例模型的学习效果立竿见影。例如我们会给一个例子 用户输入“我想让商品详情页的缓存Redis偶尔不可用一下。” 模型应输出识别为“Redis 故障”建议使用blade create redis delay或blade create redis throwCustomException并询问用户希望模拟延迟还是异常、具体的 Redis 连接地址、持续时间和触发概率。3.2 工具封装与安全调用有了好的“大脑”还需要可靠的“手脚”。我们将 ChaosBlade 的所有能力封装成了一个统一的工具类ChaosBladeController。这个类的核心方法execute_attack大致逻辑如下class ChaosBladeController: def __init__(self, blade_cli_path‘/opt/chaosblade/blade’): self.cli_path blade_cli_path # 预定义的故障场景与命令模板映射 self.scenario_templates { ‘cpu_high_load’: { ‘base_cmd’: ‘create cpu load’, ‘required_params’: [‘cpu-percent’, ‘timeout’], ‘default_params’: {‘cpu-count’: ‘0’} # 0表示使用所有CPU核心 }, ‘network_delay’: { ‘base_cmd’: ‘create network delay’, ‘required_params’: [‘time’, ‘interface’, ‘timeout’], ‘default_params’: {‘offset’: ‘10ms’} }, ‘jvm_method_delay’: { ‘base_cmd’: ‘create jvm delay’, ‘required_params’: [‘classname’, ‘methodname’, ‘time’, ‘timeout’], } # ... 其他场景 } def execute_attack(self, scenario_type, target_info, params): “”” 执行故障注入 :param scenario_type: 故障场景类型如 ‘cpu_high_load’ :param target_info: 目标信息如 {‘ip’: ‘10.0.0.1’, ‘container_id’: ‘xxx’} :param params: 参数字典如 {‘cpu-percent’: ‘80’, ‘timeout’: ‘300’} :return: (success, result, attack_uid) “”” if scenario_type not in self.scenario_templates: return False, f“Unsupported scenario: {scenario_type}”, None template self.scenario_templates[scenario_type] # 1. 参数校验与补全 for req_param in template[‘required_params’]: if req_param not in params: return False, f“Missing required parameter: {req_param}”, None full_params {**template.get(‘default_params’, {}), **params} # 2. 构建目标参数 target_flag self._build_target_flag(target_info) # 例如 ‘–container-id xxx’ 或 ‘–ip 10.0.0.1’ # 3. 构建完整命令 cmd_parts [self.cli_path, template[‘base_cmd’]] for key, value in full_params.items(): cmd_parts.append(f“–{key} {value}”) cmd_parts.append(target_flag) final_cmd ‘ ‘.join(cmd_parts) # 4. 安全执行记录日志、超时控制 logger.info(f“Executing ChaosBlade command: {final_cmd}”) try: result subprocess.run(final_cmd, shellTrue, capture_outputTrue, textTrue, timeout60) if result.returncode 0: # 从输出中解析出本次演练的UID用于后续销毁 attack_uid self._parse_uid_from_output(result.stdout) return True, result.stdout, attack_uid else: return False, result.stderr, None except subprocess.TimeoutExpired: return False, “Command execution timeout”, None except Exception as e: return False, str(e), None def destroy_attack(self, attack_uid): “””根据UID销毁故障场景””” destroy_cmd f“{self.cli_path} destroy {attack_uid}” # … 执行销毁命令关键安全设计白名单机制scenario_templates就是一个白名单模型只能选择预定义好的、经过测试的场景类型防止其调用不存在的或危险的实验场景。参数强校验对于必填参数进行严格检查防止因参数缺失导致命令执行失败或产生意外行为。执行隔离与超时使用subprocess执行命令时必须设置超时时间防止命令卡死阻塞整个 Agent。所有命令执行都有详尽的日志记录便于审计和回溯。资源预检在_build_target_flag方法中我们会先对target_info如 IP进行简单的连通性检查或从 CMDB 验证其是否存在避免对不存在的目标操作。3.3 上下文管理与多轮对话故障演练往往不是一句话就能说完的。用户可能会说“先给A服务加一点CPU压力看看。” 观察一会儿监控后又说“现在再把它的下游B服务的网络断掉。” 这就要求 Agent 具备上下文管理能力记住之前做了什么。我们为每个对话会话Session维护了一个上下文存储器主要保存已执行的故障列表每个故障的 UID、类型、目标、参数、开始时间。当前的系统状态关联的监控图表链接、关键指标的快照值。用户的对话历史最近几轮的问答记录。当用户发出新指令时我们会将当前的上下文以摘要形式连同用户新指令一起喂给 LLM。模型就能理解“再”字的含义知道是在已有演练基础上叠加新的故障从而规划出“先停止当前的 CPU 故障如果需要再注入网络中断”这样的合理步骤。注意上下文的长度需要管理。我们通常只保留最近3-4轮对话的详细内容更早的会总结成一句话摘要如“用户此前对服务A进行了CPU负载测试”以防止超出模型的上下文窗口长度也避免无关信息干扰判断。4. 全链路自动化实战一个完整演练的闭环让我们通过一个具体的例子看看 Blade AI Agent 是如何端到端地完成一次自动化演练的。假设我们的目标是验证订单服务在依赖的支付服务出现高延迟时的容错和降级能力。4.1 场景解析与任务规划用户输入“我想测试一下如果支付服务的响应变得很慢订单服务会不会出问题。模拟支付服务接口平均延迟增加500毫秒持续8分钟观察订单创建接口的成功率和延迟。”交互层Web界面接收到用户输入。决策层LLM意图识别识别出核心是“网络延迟”故障目标是“支付服务”观测对象是“订单服务”的“订单创建接口”。槽位填充与澄清由于用户描述比较清晰模型直接填充了参数fault_typenetwork_delay,target_servicepayment-service,delay_time500ms,duration8m。但它发现用户没指定“偏移量”jitter和具体网络接口。根据提示词中的规则它决定使用默认偏移量offset50ms并假设在容器网络环境下自动选择interfaceeth0。任务规划模型生成如下计划Step 1: 调用resource_resolver根据服务名“payment-service”解析出其在生产环境的所有 Pod IP 地址假设有2个实例10.1.1.1, 10.1.1.2。Step 2: 调用chaosblade_controller对这两个 IP 分别执行blade create network delay –time 500ms –offset 50ms –interface eth0 –timeout 480命令。Step 3: 调用monitor开始持续查询订单服务“/order/create”接口的 QPS、平均响应时间、P95响应时间、错误率5xx等指标持续8分钟并与故障前5分钟的基线数据进行对比。Step 4: 计划中8分钟后自动调用chaosblade_controller.destroy停止故障注入。Step 5: 计划中调用report_generator基于监控数据对比生成本次演练的分析报告。4.2 自动化执行与实时观测规划完成后Agent 开始按步骤执行资源解析resource_resolver工具调用 K8s API查询带有标签apppayment-service且环境为prod的所有 Pod成功返回两个 IP。故障注入ChaosBladeController被调用两次分别对两个 IP 执行网络延迟注入。执行结果成功并返回两个故障 UIDcn-xxxx-1,cn-xxxx-2被记录到本次会话的上下文中。监控启动monitor工具被调用。这里有个关键点它不是简单地拉取一次数据而是启动了一个后台观测任务。这个任务会立即抓取故障前5分钟内订单创建接口的指标均值作为基线。然后每30秒查询一次当前指标计算相对于基线的变化率。将数据实时可视化并生成一个临时的 Grafana 看板链接通过交互层反馈给用户。用户可以直接点击链接看到类似“响应时间从平均 50ms 上升至 550ms错误率从 0% 上升至 15%”的图表。实操心得监控指标的选择一开始我们让模型自由选择监控指标结果它有时会关注一些不相关的系统指标如主机内存。后来我们在monitor工具的描述中加强了引导“当观测应用服务时优先关注其对外接口的黄金指标流量QPS/TPS、延迟平均/P95/P99、错误率4xx/5xx、饱和度队列长度。当观测基础设施时关注 CPU、内存、磁盘 I/O、网络带宽。” 同时我们建立了一个“服务-指标”映射表让 Agent 能更精准地定位核心监控项。4.3 智能恢复与报告生成8分钟时间一到或者用户在观测过程中发现情况不对比如错误率飙升超过阈值告警可以手动触发停止。自动恢复Agent 会根据上下文里记录的故障 UID自动调用销毁命令blade destroy cn-xxxx-1和blade destroy cn-xxxx-2。这里有一个重要检查销毁命令执行后会再次调用monitor验证相关指标是否逐渐恢复到正常水平确保故障被真正清除而不是命令执行了但实际延迟还在。报告生成report_generator工具被触发。它会汇总整个时间线的关键事件故障注入时间点、监控指标变化曲线、故障恢复时间点。进行影响分析计算本次故障导致的业务影响例如“订单创建失败率峰值达15%期间可能损失约XX个订单”。评估系统韧性判断系统是否有弹性恢复能力故障消除后指标是否快速恢复正常以及是否有降级策略生效如虽然延迟高但服务未完全不可用。给出改进建议基于观测结果生成可能的技术建议。例如“观测到错误率上升建议检查订单服务调用支付服务时是否设置了合理的超时和熔断机制。” 这部分建议由 LLM 根据监控结论和领域知识生成虽然不一定完全准确但能为后续人工分析提供有价值的切入点。最终一份包含上述所有内容的 Markdown 格式报告会自动生成并可以发送到指定的钉钉群或 Confluence 页面完成整个演练闭环。5. 避坑指南与效能提升在实际开发和运营 Blade AI Agent 的过程中我们遇到了不少挑战也积累了一些关键经验。5.1 常见问题与解决方案问题现象可能原因排查与解决方案AI 解析意图错误例如把“模拟内存泄漏”解析成“注入CPU负载”。1. 用户表述模糊。2. 提示词中缺乏相关示例。3. 模型本身能力限制。1.交互层设计澄清问题当置信度不高时让 Agent 主动反问列出几个可能的选项让用户确认。例如“您指的是模拟‘内存使用率满载’还是‘内存不释放’的泄漏场景”2.丰富提示词示例库将这次误解析的案例作为反面例子连同正确解析案例一起加入提示词的 Few-Shot 部分。3.后置校验在工具执行前增加一个简单的规则校验。例如如果故障类型是“内存”但目标资源是“Redis”则给出警告提示。ChaosBlade 命令执行失败返回“target not found”或“permission denied”。1. 目标 IP/容器ID 不正确或已下线。2. 目标机器未安装或未启动 ChaosBlade 客户端。3. 执行权限不足。1.执行前预检在execute_attack前增加一个pre_check步骤通过 SSH 或 Agent 心跳检查目标机器 ChaosBlade 客户端状态。2.资源信息缓存与更新从 CMDB/K8s 查询到的资源信息在用于演练前进行二次确认如 ping 一下 IP。3.清晰的错误反馈将工具执行失败的具体原因如 stderr 信息提炼后用自然语言反馈给用户并建议其检查目标环境。监控数据无变化故障注入后业务指标纹丝不动。1. 故障未实际生效如网络策略拦截了延迟包。2. 监控的指标不对如观测了错误的接口。3. 系统本身有强容错未暴露问题。1.故障有效性验证注入故障后立即让 Agent 执行一个简单的验证命令如从另一台机器 ping 目标检查延迟是否真增加了。2.多维度观测除了业务指标也让 Agent 同时拉取目标服务器的系统指标如 CPU 软中断是否增加进行交叉验证。3.人工介入点设置阈值如果5分钟后核心业务指标仍无任何变化则主动通知用户提示可能“未击穿系统防线”建议尝试更剧烈的故障场景。多轮对话中AI 忘记之前做了什么。上下文长度限制或历史信息未被有效组织。1.关键信息摘要在每一轮对话结束后由程序而非 LLM自动生成一句当前状态的摘要如“当前已对 payment-service 注入了 500ms 网络延迟。”并将摘要放入后续对话的上下文。2.显式状态管理在交互界面上以标签或列表的形式直观展示当前会话中所有活跃的故障实验及其状态帮助用户和 AI 共同记忆。5.2 安全与权限管控的深层考量让 AI 自动操作生产环境安全是头等大事。我们采取了“最小权限流程卡点全程审计”的策略权限最小化Blade AI Agent 进程本身拥有的权限很低。它不能直接 SSH 到生产服务器。所有 ChaosBlade 命令的执行都是通过一个部署在目标环境中的、具有严格权限控制的“混沌工程执行网关”来代理完成的。这个网关只开放了 ChaosBlade 相关的有限 API。操作审批流对于预定义的“高危场景”如数据库宕机、全区域网络中断或针对核心服务的任何操作Agent 生成的执行计划不会直接运行而是会生成一个审批工单发送给指定的负责人如该服务的 SRE。只有在审批通过后任务才会继续。操作隔离与回滚每个故障注入都会生成唯一 UID 并记录。系统有一个独立的“守护进程”会定期检查所有活跃的故障实验。任何实验如果超过其预设的超时时间或者检测到 Agent 主进程异常退出守护进程都会强制将其销毁防止故障被遗忘而长期存在。完整审计日志所有自然语言对话、AI 的决策过程解析出的 JSON、执行的每一条底层命令、命令的返回结果、以及对应的用户和审批人都会打入不可篡改的审计日志满足合规要求。5.3 从自动化到智能化未来的优化方向目前我们的 Blade AI Agent 已经实现了“描述即执行”的自动化但距离真正的“智能化”还有距离。下一步我们正在探索根因分析辅助当监控指标异常时Agent 不仅能告警还能自动关联近期发生的混沌实验、系统变更、以及基础设施事件给出可能根因的初步排序大幅缩短 MTTR平均恢复时间。自适应场景推荐基于历史演练数据和系统架构拓扑Agent 可以学习到系统的脆弱点。例如它可能发现“每次对 Redis 注入延迟订单服务的错误率都会飙升”从而主动向用户推荐“根据历史数据订单服务对 Redis 延迟敏感建议下周安排一次 Redis 故障转移演练。”演练策略优化通过强化学习让 Agent 在非高峰期的沙箱环境中自动尝试不同强度、不同组合的故障观察系统反应从而为正式演练推荐“既能发现问题又不会引发事故”的最优故障参数。这条路走下来最大的体会是自然语言驱动不是要取代混沌工程专家而是将专家从繁琐重复的操作中解放出来让他们更专注于设计更有价值的故障场景、分析更复杂的系统行为。技术最终要服务于人让稳定性保障工作变得更高效、更普惠这才是我们做这个项目的初衷。 基于AI Agent与ChaosBlade的混沌工程自动化实践
1. 项目概述当混沌工程遇上自然语言最近在搞稳定性保障和故障演练的团队估计都听过“混沌工程”的大名。简单说它就是通过在生产环境中故意引入故障来验证系统韧性的实践。但传统混沌工程有个老毛病门槛高、操作重。你得懂一堆工具的命令行熟悉复杂的故障场景配置每次演练从设计、执行到观测、恢复链路又长又繁琐导致很多团队“想练但不敢练”或者“练了但没练透”。我所在的团队也面临同样的问题。直到我们开始尝试用自然语言来驱动整个混沌工程流程情况才发生了根本变化。这个项目的核心就是基于阿里云开源的混沌工程工具 ChaosBlade构建一个能够理解自然语言指令的 AI Agent我们内部称之为 Blade AI Agent实现从故障场景描述、到具体演练执行、再到结果观测分析的端到端自动化。想象一下你不再需要去翻 ChaosBlade 那上百个参数的命令手册也不用在复杂的 YAML 文件里调试。你只需要对 AI Agent 说“模拟一下华东1地域的 ECS 实例 CPU 使用率飙升到 80%持续 5 分钟并且检查一下订单服务的响应时间 SLA 是否还能保持在 99.9% 以内。” 剩下的从解析你的意图、组装 ChaosBlade 命令、在目标机器执行、监控业务指标、到生成演练报告全部由这个 Agent 自动完成。这不仅仅是效率的提升更是将混沌工程从“专家技能”变成了“团队通用能力”。下面我就把我们趟过的路、踩过的坑和最终沉淀下来的实战经验毫无保留地分享出来。2. 核心思路用 AI Agent 重构故障演练工作流2.1 传统模式的痛点与自动化机遇在引入 AI 之前我们的故障演练流程是线性的但每个环节都充满手动操作和上下文切换场景设计运维或开发人员在文档或脑子里构思故障场景。工具转化将场景“翻译”成具体的混沌工程工具命令或配置比如 ChaosBlade 的blade create cpu fullload命令并精确设置cpu-percent、timeout等参数。环境准备确保目标机器安装了 ChaosBlade 客户端并获取权限。执行与监控在命令行执行命令同时打开监控系统如 Prometheus Grafana观察业务指标。恢复与验证手动停止故障注入确认服务恢复并检查数据一致性。报告编写整理监控截图、日志人工编写演练报告。这个流程的痛点非常明显高度依赖个人经验尤其是步骤2和4操作容易出错参数拼写错误、目标 IP 搞错效率低下大量重复劳动难以规模化无法同时进行多场景、多批次演练。而 AI特别是大语言模型LLM给我们带来了新的可能性。LLM 擅长理解和生成结构化文本这正是连接“人类自然语言描述”和“机器可执行指令”的完美桥梁。我们的核心思路就是构建一个智能体Agent将 LLM 作为其“大脑”用于理解用户意图和规划任务将混沌工程工具链ChaosBlade、监控系统、运维平台作为其“手脚”用于执行具体操作和感知系统状态。让这个 Agent 充当一个全能的“故障演练工程师”接收自然语言任务并驱动整个闭环。2.2 Blade AI Agent 的顶层架构设计我们的 Blade AI Agent 采用了经典的 AI Agent 架构范式并针对混沌工程领域做了深度定制。整个系统可以划分为四层第一层自然语言交互层这是用户入口可以是 Web 聊天界面、命令行工具CLI或是集成到钉钉/飞书等办公软件中的机器人。它的核心是提示词Prompt工程用于将用户的非结构化输入引导和规范成 Agent 能够处理的清晰任务描述。例如当用户输入“给订单服务加点压力”时提示词会引导模型反问“请问您想模拟哪种压力是 CPU 压力、内存压力还是网络延迟针对哪个具体服务或实例持续多久”第二层智能决策与规划层这是 Agent 的“大脑”由 LLM我们选用的是性能与成本平衡较好的开源模型驱动。它接收来自交互层的清晰任务描述并进行如下工作意图识别与槽位填充识别故障类型如 CPU、网络、应用层、目标对象如服务名、IP、K8s Pod、参数如负载百分比、延迟时间、错误码等。任务规划与分解将一个复杂任务分解为原子操作序列。例如“模拟数据库主从延迟并观察业务影响”会被分解为1. 在数据库主机注入网络延迟2. 启动业务流量监控3. 等待一段时间4. 停止故障注入5. 分析监控数据对比。工具调用决策为每个原子操作选择合适的工具。例如“注入网络延迟”对应 ChaosBlade 的网络模块“启动监控”对应调用监控平台的 API。第三层工具执行层这是 Agent 的“手脚”包含了所有可被调用的具体能力ChaosBlade 控制器封装所有 ChaosBlade 命令的创建、查询、销毁操作。它接收结构化参数如{“target”: “cpu”, “action”: “fullload”, “params”: {“cpu-percent”: “80”, “timeout”: “300”}}生成最终的命令并在目标机器通过 ChaosBlade 客户端执行。监控与观测器封装对 Prometheus、SLS 日志服务、ARMS 应用监控等系统的查询。它可以根据故障场景自动定位相关的核心业务指标如 QPS、错误率、响应时间 P99和基础设施指标如 CPU、内存。基础设施管理器用于获取和验证目标资源信息例如通过 CMDB 或 K8s API 根据服务名解析出具体的 Pod IP 列表。第四层知识反馈与记忆层为了让 Agent 越用越聪明我们设计了两个核心机制演练知识库存储历史上成功的演练场景模板、常用的监控指标大盘链接、不同服务的稳态基线数据。新的任务规划可以参考历史模板进行优化。执行反馈循环将每次工具执行的结果成功/失败、输出日志和监控数据的变化作为上下文反馈给 LLM。这使得 Agent 在后续步骤或未来任务中能进行更准确的判断。例如如果注入 CPU 负载后业务指标无变化Agent 可能会判断目标选择有误或故障未生效并触发告警或尝试其他手段。这个架构的关键在于LLM 并不直接操作系统而是通过严谨定义的“工具”Tool来交互。每个工具都有明确的输入/输出格式描述通常用 JSON SchemaLLM 通过函数调用Function Calling的方式来使用它们。这保证了操作的安全性和可控性。3. 核心模块实现从自然语言到混沌命令3.1 提示词工程让 AI 理解“故障场景”提示词是 Agent 的“第一课”教它如何理解混沌工程这个专业领域。一个糟糕的提示词会让模型胡言乱语而一个好的提示词能让它像资深 SRE 一样思考。我们的系统提示词System Prompt核心包含以下几个部分角色与能力定义 明确告诉模型“你是一个专业的混沌工程专家精通 ChaosBlade 工具和分布式系统故障模式。你的任务是将用户模糊的故障描述转化为精确、可执行、安全的混沌实验步骤。”约束与安全规则重中之重 这是防止“AI 搞垮生产”的防火墙。必须清晰列出确认原则任何涉及生产环境Prod的操作必须向用户二次确认并列出潜在影响。范围限制禁止同时对一个服务的所有实例或超过 50% 的集群节点进行破坏性演练除非用户明确指定为“熔断演练”等场景。超时机制每个自动注入的故障必须设置有最大超时时间如默认30分钟并建议用户设置监控告警。工具限制你只能使用我提供的工具列表ChaosBlade控制器、监控查询器等不能自行编造或执行任何系统命令。输出格式规范 要求模型以严格的 JSON 格式输出其“思考过程”和“决策”例如{ “user_intent”: “模拟订单服务数据库延迟” “parsed_scenario”: { “fault_type”: “network_delay”, “target”: { “type”: “service”, “name”: “order-service”, “resource_identifier”: “通过CMDB查询的数据库主机IP列表” }, “parameters”: { “time”: “200ms”, “offset”: “50ms”, “interface”: “eth0”, “duration”: “5m” } }, “action_plan”: [ {“step”: 1, “tool”: “resource_resolver”, “purpose”: “根据服务名定位数据库主机”}, {“step”: 2, “tool”: “chaosblade_controller”, “purpose”: “对目标主机注入网络延迟”}, {“step”: 3, “tool”: “monitor”, “purpose”: “监控订单服务API的响应时间P99和错误率”} ] }通过这样的结构化输出后端的程序可以轻松解析并驱动相应的工具执行。实操心得提示词的迭代最初的提示词很简单导致模型经常“幻觉”出一些不存在的 ChaosBlade 参数。我们通过记录大量“用户输入-模型输出-人工修正”的对话数据不断优化提示词。一个有效的方法是加入“少样本示例”Few-Shot Examples在提示词中直接给出几个正确解析的范例模型的学习效果立竿见影。例如我们会给一个例子 用户输入“我想让商品详情页的缓存Redis偶尔不可用一下。” 模型应输出识别为“Redis 故障”建议使用blade create redis delay或blade create redis throwCustomException并询问用户希望模拟延迟还是异常、具体的 Redis 连接地址、持续时间和触发概率。3.2 工具封装与安全调用有了好的“大脑”还需要可靠的“手脚”。我们将 ChaosBlade 的所有能力封装成了一个统一的工具类ChaosBladeController。这个类的核心方法execute_attack大致逻辑如下class ChaosBladeController: def __init__(self, blade_cli_path‘/opt/chaosblade/blade’): self.cli_path blade_cli_path # 预定义的故障场景与命令模板映射 self.scenario_templates { ‘cpu_high_load’: { ‘base_cmd’: ‘create cpu load’, ‘required_params’: [‘cpu-percent’, ‘timeout’], ‘default_params’: {‘cpu-count’: ‘0’} # 0表示使用所有CPU核心 }, ‘network_delay’: { ‘base_cmd’: ‘create network delay’, ‘required_params’: [‘time’, ‘interface’, ‘timeout’], ‘default_params’: {‘offset’: ‘10ms’} }, ‘jvm_method_delay’: { ‘base_cmd’: ‘create jvm delay’, ‘required_params’: [‘classname’, ‘methodname’, ‘time’, ‘timeout’], } # ... 其他场景 } def execute_attack(self, scenario_type, target_info, params): “”” 执行故障注入 :param scenario_type: 故障场景类型如 ‘cpu_high_load’ :param target_info: 目标信息如 {‘ip’: ‘10.0.0.1’, ‘container_id’: ‘xxx’} :param params: 参数字典如 {‘cpu-percent’: ‘80’, ‘timeout’: ‘300’} :return: (success, result, attack_uid) “”” if scenario_type not in self.scenario_templates: return False, f“Unsupported scenario: {scenario_type}”, None template self.scenario_templates[scenario_type] # 1. 参数校验与补全 for req_param in template[‘required_params’]: if req_param not in params: return False, f“Missing required parameter: {req_param}”, None full_params {**template.get(‘default_params’, {}), **params} # 2. 构建目标参数 target_flag self._build_target_flag(target_info) # 例如 ‘–container-id xxx’ 或 ‘–ip 10.0.0.1’ # 3. 构建完整命令 cmd_parts [self.cli_path, template[‘base_cmd’]] for key, value in full_params.items(): cmd_parts.append(f“–{key} {value}”) cmd_parts.append(target_flag) final_cmd ‘ ‘.join(cmd_parts) # 4. 安全执行记录日志、超时控制 logger.info(f“Executing ChaosBlade command: {final_cmd}”) try: result subprocess.run(final_cmd, shellTrue, capture_outputTrue, textTrue, timeout60) if result.returncode 0: # 从输出中解析出本次演练的UID用于后续销毁 attack_uid self._parse_uid_from_output(result.stdout) return True, result.stdout, attack_uid else: return False, result.stderr, None except subprocess.TimeoutExpired: return False, “Command execution timeout”, None except Exception as e: return False, str(e), None def destroy_attack(self, attack_uid): “””根据UID销毁故障场景””” destroy_cmd f“{self.cli_path} destroy {attack_uid}” # … 执行销毁命令关键安全设计白名单机制scenario_templates就是一个白名单模型只能选择预定义好的、经过测试的场景类型防止其调用不存在的或危险的实验场景。参数强校验对于必填参数进行严格检查防止因参数缺失导致命令执行失败或产生意外行为。执行隔离与超时使用subprocess执行命令时必须设置超时时间防止命令卡死阻塞整个 Agent。所有命令执行都有详尽的日志记录便于审计和回溯。资源预检在_build_target_flag方法中我们会先对target_info如 IP进行简单的连通性检查或从 CMDB 验证其是否存在避免对不存在的目标操作。3.3 上下文管理与多轮对话故障演练往往不是一句话就能说完的。用户可能会说“先给A服务加一点CPU压力看看。” 观察一会儿监控后又说“现在再把它的下游B服务的网络断掉。” 这就要求 Agent 具备上下文管理能力记住之前做了什么。我们为每个对话会话Session维护了一个上下文存储器主要保存已执行的故障列表每个故障的 UID、类型、目标、参数、开始时间。当前的系统状态关联的监控图表链接、关键指标的快照值。用户的对话历史最近几轮的问答记录。当用户发出新指令时我们会将当前的上下文以摘要形式连同用户新指令一起喂给 LLM。模型就能理解“再”字的含义知道是在已有演练基础上叠加新的故障从而规划出“先停止当前的 CPU 故障如果需要再注入网络中断”这样的合理步骤。注意上下文的长度需要管理。我们通常只保留最近3-4轮对话的详细内容更早的会总结成一句话摘要如“用户此前对服务A进行了CPU负载测试”以防止超出模型的上下文窗口长度也避免无关信息干扰判断。4. 全链路自动化实战一个完整演练的闭环让我们通过一个具体的例子看看 Blade AI Agent 是如何端到端地完成一次自动化演练的。假设我们的目标是验证订单服务在依赖的支付服务出现高延迟时的容错和降级能力。4.1 场景解析与任务规划用户输入“我想测试一下如果支付服务的响应变得很慢订单服务会不会出问题。模拟支付服务接口平均延迟增加500毫秒持续8分钟观察订单创建接口的成功率和延迟。”交互层Web界面接收到用户输入。决策层LLM意图识别识别出核心是“网络延迟”故障目标是“支付服务”观测对象是“订单服务”的“订单创建接口”。槽位填充与澄清由于用户描述比较清晰模型直接填充了参数fault_typenetwork_delay,target_servicepayment-service,delay_time500ms,duration8m。但它发现用户没指定“偏移量”jitter和具体网络接口。根据提示词中的规则它决定使用默认偏移量offset50ms并假设在容器网络环境下自动选择interfaceeth0。任务规划模型生成如下计划Step 1: 调用resource_resolver根据服务名“payment-service”解析出其在生产环境的所有 Pod IP 地址假设有2个实例10.1.1.1, 10.1.1.2。Step 2: 调用chaosblade_controller对这两个 IP 分别执行blade create network delay –time 500ms –offset 50ms –interface eth0 –timeout 480命令。Step 3: 调用monitor开始持续查询订单服务“/order/create”接口的 QPS、平均响应时间、P95响应时间、错误率5xx等指标持续8分钟并与故障前5分钟的基线数据进行对比。Step 4: 计划中8分钟后自动调用chaosblade_controller.destroy停止故障注入。Step 5: 计划中调用report_generator基于监控数据对比生成本次演练的分析报告。4.2 自动化执行与实时观测规划完成后Agent 开始按步骤执行资源解析resource_resolver工具调用 K8s API查询带有标签apppayment-service且环境为prod的所有 Pod成功返回两个 IP。故障注入ChaosBladeController被调用两次分别对两个 IP 执行网络延迟注入。执行结果成功并返回两个故障 UIDcn-xxxx-1,cn-xxxx-2被记录到本次会话的上下文中。监控启动monitor工具被调用。这里有个关键点它不是简单地拉取一次数据而是启动了一个后台观测任务。这个任务会立即抓取故障前5分钟内订单创建接口的指标均值作为基线。然后每30秒查询一次当前指标计算相对于基线的变化率。将数据实时可视化并生成一个临时的 Grafana 看板链接通过交互层反馈给用户。用户可以直接点击链接看到类似“响应时间从平均 50ms 上升至 550ms错误率从 0% 上升至 15%”的图表。实操心得监控指标的选择一开始我们让模型自由选择监控指标结果它有时会关注一些不相关的系统指标如主机内存。后来我们在monitor工具的描述中加强了引导“当观测应用服务时优先关注其对外接口的黄金指标流量QPS/TPS、延迟平均/P95/P99、错误率4xx/5xx、饱和度队列长度。当观测基础设施时关注 CPU、内存、磁盘 I/O、网络带宽。” 同时我们建立了一个“服务-指标”映射表让 Agent 能更精准地定位核心监控项。4.3 智能恢复与报告生成8分钟时间一到或者用户在观测过程中发现情况不对比如错误率飙升超过阈值告警可以手动触发停止。自动恢复Agent 会根据上下文里记录的故障 UID自动调用销毁命令blade destroy cn-xxxx-1和blade destroy cn-xxxx-2。这里有一个重要检查销毁命令执行后会再次调用monitor验证相关指标是否逐渐恢复到正常水平确保故障被真正清除而不是命令执行了但实际延迟还在。报告生成report_generator工具被触发。它会汇总整个时间线的关键事件故障注入时间点、监控指标变化曲线、故障恢复时间点。进行影响分析计算本次故障导致的业务影响例如“订单创建失败率峰值达15%期间可能损失约XX个订单”。评估系统韧性判断系统是否有弹性恢复能力故障消除后指标是否快速恢复正常以及是否有降级策略生效如虽然延迟高但服务未完全不可用。给出改进建议基于观测结果生成可能的技术建议。例如“观测到错误率上升建议检查订单服务调用支付服务时是否设置了合理的超时和熔断机制。” 这部分建议由 LLM 根据监控结论和领域知识生成虽然不一定完全准确但能为后续人工分析提供有价值的切入点。最终一份包含上述所有内容的 Markdown 格式报告会自动生成并可以发送到指定的钉钉群或 Confluence 页面完成整个演练闭环。5. 避坑指南与效能提升在实际开发和运营 Blade AI Agent 的过程中我们遇到了不少挑战也积累了一些关键经验。5.1 常见问题与解决方案问题现象可能原因排查与解决方案AI 解析意图错误例如把“模拟内存泄漏”解析成“注入CPU负载”。1. 用户表述模糊。2. 提示词中缺乏相关示例。3. 模型本身能力限制。1.交互层设计澄清问题当置信度不高时让 Agent 主动反问列出几个可能的选项让用户确认。例如“您指的是模拟‘内存使用率满载’还是‘内存不释放’的泄漏场景”2.丰富提示词示例库将这次误解析的案例作为反面例子连同正确解析案例一起加入提示词的 Few-Shot 部分。3.后置校验在工具执行前增加一个简单的规则校验。例如如果故障类型是“内存”但目标资源是“Redis”则给出警告提示。ChaosBlade 命令执行失败返回“target not found”或“permission denied”。1. 目标 IP/容器ID 不正确或已下线。2. 目标机器未安装或未启动 ChaosBlade 客户端。3. 执行权限不足。1.执行前预检在execute_attack前增加一个pre_check步骤通过 SSH 或 Agent 心跳检查目标机器 ChaosBlade 客户端状态。2.资源信息缓存与更新从 CMDB/K8s 查询到的资源信息在用于演练前进行二次确认如 ping 一下 IP。3.清晰的错误反馈将工具执行失败的具体原因如 stderr 信息提炼后用自然语言反馈给用户并建议其检查目标环境。监控数据无变化故障注入后业务指标纹丝不动。1. 故障未实际生效如网络策略拦截了延迟包。2. 监控的指标不对如观测了错误的接口。3. 系统本身有强容错未暴露问题。1.故障有效性验证注入故障后立即让 Agent 执行一个简单的验证命令如从另一台机器 ping 目标检查延迟是否真增加了。2.多维度观测除了业务指标也让 Agent 同时拉取目标服务器的系统指标如 CPU 软中断是否增加进行交叉验证。3.人工介入点设置阈值如果5分钟后核心业务指标仍无任何变化则主动通知用户提示可能“未击穿系统防线”建议尝试更剧烈的故障场景。多轮对话中AI 忘记之前做了什么。上下文长度限制或历史信息未被有效组织。1.关键信息摘要在每一轮对话结束后由程序而非 LLM自动生成一句当前状态的摘要如“当前已对 payment-service 注入了 500ms 网络延迟。”并将摘要放入后续对话的上下文。2.显式状态管理在交互界面上以标签或列表的形式直观展示当前会话中所有活跃的故障实验及其状态帮助用户和 AI 共同记忆。5.2 安全与权限管控的深层考量让 AI 自动操作生产环境安全是头等大事。我们采取了“最小权限流程卡点全程审计”的策略权限最小化Blade AI Agent 进程本身拥有的权限很低。它不能直接 SSH 到生产服务器。所有 ChaosBlade 命令的执行都是通过一个部署在目标环境中的、具有严格权限控制的“混沌工程执行网关”来代理完成的。这个网关只开放了 ChaosBlade 相关的有限 API。操作审批流对于预定义的“高危场景”如数据库宕机、全区域网络中断或针对核心服务的任何操作Agent 生成的执行计划不会直接运行而是会生成一个审批工单发送给指定的负责人如该服务的 SRE。只有在审批通过后任务才会继续。操作隔离与回滚每个故障注入都会生成唯一 UID 并记录。系统有一个独立的“守护进程”会定期检查所有活跃的故障实验。任何实验如果超过其预设的超时时间或者检测到 Agent 主进程异常退出守护进程都会强制将其销毁防止故障被遗忘而长期存在。完整审计日志所有自然语言对话、AI 的决策过程解析出的 JSON、执行的每一条底层命令、命令的返回结果、以及对应的用户和审批人都会打入不可篡改的审计日志满足合规要求。5.3 从自动化到智能化未来的优化方向目前我们的 Blade AI Agent 已经实现了“描述即执行”的自动化但距离真正的“智能化”还有距离。下一步我们正在探索根因分析辅助当监控指标异常时Agent 不仅能告警还能自动关联近期发生的混沌实验、系统变更、以及基础设施事件给出可能根因的初步排序大幅缩短 MTTR平均恢复时间。自适应场景推荐基于历史演练数据和系统架构拓扑Agent 可以学习到系统的脆弱点。例如它可能发现“每次对 Redis 注入延迟订单服务的错误率都会飙升”从而主动向用户推荐“根据历史数据订单服务对 Redis 延迟敏感建议下周安排一次 Redis 故障转移演练。”演练策略优化通过强化学习让 Agent 在非高峰期的沙箱环境中自动尝试不同强度、不同组合的故障观察系统反应从而为正式演练推荐“既能发现问题又不会引发事故”的最优故障参数。这条路走下来最大的体会是自然语言驱动不是要取代混沌工程专家而是将专家从繁琐重复的操作中解放出来让他们更专注于设计更有价值的故障场景、分析更复杂的系统行为。技术最终要服务于人让稳定性保障工作变得更高效、更普惠这才是我们做这个项目的初衷。