分布式系统韧性测试：用大模型辅助自动生成 Jepsen 混沌故障注入脚本

在分布式系统领域，Jepsen 一直是混沌工程测试的“黄金标准”。但说实话，维护一套健壮的 Jepsen 测试套件极其痛苦。Clojure 的语法门槛、对分布式原理的深刻理解、以及繁琐的故障注入配置，往往让团队望而却步。最近，我尝试引入大模型（LLM）来自动生成 Jepsen 的故障注入脚本，并结合 Rust 构建安全网关，效果出乎意料。今天就来聊聊这套“AI+Rust"辅助测试架构的实战落地。

核心架构：AI 生成，Rust 兜底

直接用 LLM 写 Clojure 代码风险很大，幻觉可能导致调用不存在的 API 或逻辑死锁。我的方案是：LLM 负责生成高层的“故障意图”，Rust 负责将其编译为安全的执行计划，并校验边界条件。

sequenceDiagram
    participant Dev as 开发人员
    participant LLM as 大模型 (LLM)
    participant RustGuard as Rust 安全网关
    participant Jepsen as Jepsen Runner
    participant System as 分布式集群

    Dev->>LLM: 描述故障场景 (如：网络分区)
    LLM->>RustGuard: 生成原始故障计划 (JSON)
    RustGuard->>RustGuard: 校验节点合法性/超时限制
    alt 校验失败
        RustGuard-->>LLM: 返回错误修正建议
        LLM-->>RustGuard: 重新生成
    else 校验通过
        RustGuard->>Jepsen: 注入 Clojure 测试脚本
        Jepsen->>System: 执行故障注入 (tc/iptables)
        System-->>Jepsen: 返回一致性检查结果
        Jepsen-->>RustGuard: 测试报告
    end

Rust 安全网关实现

为什么用 Rust？因为我们需要在脚本执行前进行严格的类型检查和资源边界控制。下面是一段生产级别的 Rust 代码，用于验证 AI 生成的故障注入计划。它确保不会发生“分区不存在的节点”或“超时时间过长”等低级错误。

use serde::{Deserialize, Serialize};
use std::collections::HashSet;
use anyhow::{Result, Context};

#[derive(Debug, Serialize, Deserialize)]
pub struct FaultPlan {
    pub fault_type: String,
    pub target_nodes: Vec<String>,
    pub duration_ms: u64,
    pub severity: Severity,
}

#[derive(Debug, Serialize, Deserialize, PartialEq)]
#[serde(rename_all = "lowercase")]
pub enum Severity {
    Low,
    Medium,
    Critical,
}

pub struct ChaosValidator {
    active_nodes: HashSet<String>,
    max_duration_ms: u64,
}

impl ChaosValidator {
    pub fn new(nodes: Vec<&str>, max_duration: u64) -> Self {
        Self {
            active_nodes: nodes.into_iter().map(|s| s.to_string()).collect(),
            max_duration_ms: max_duration,
        }
    }

    pub fn validate(&self, plan: &FaultPlan) -> Result<()> {
        // 1. 校验目标节点是否存在
        for node in &plan.target_nodes {
            if !self.active_nodes.contains(node) {
                anyhow::bail!("节点 {} 不在当前集群拓扑中", node);
            }
        }

        // 2. 校验故障时长是否超出安全阈值
        if plan.duration_ms > self.max_duration_ms {
            anyhow::bail!("故障时长 {}ms 超过系统安全阈值", plan.duration_ms);
        }

        // 3. 校验故障类型白名单
        let allowed_faults = ["network_partition", "latency", "kill_process"];
        if !allowed_faults.contains(&plan.fault_type.as_str()) {
            anyhow::bail!("不支持的故障类型：{}", plan.fault_type);
        }

        Ok(())
    }
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_invalid_node_validation() {
        let validator = ChaosValidator::new(vec!["node-1", "node-2"], 5000);
        let plan = FaultPlan {
            fault_type: "network_partition".to_string(),
            target_nodes: vec!["node-3".to_string()],
            duration_ms: 1000,
            severity: Severity::Medium,
        };
        assert!(validator.validate(&plan).is_err());
    }
}

这段代码通过 HashSet 快速校验节点拓扑，利用 anyhow 提供清晰的错误上下文，确保 AI 生成的脚本在进入 Jepsen 执行引擎前，已经过了一层严格的“编译时”安全过滤。

生产环境落地的三个深坑

虽然架构很美好，但在实际生产中，有几个坑是只有亲手踩过才知道的。

1. LLM 的 API 幻觉与版本漂移
Jepsen 的 API 会随着版本更新变化。大模型训练数据可能滞后，它可能会生成已经废弃的 Clojure 函数调用。

• 避坑策略：不要直接把 Prompt 扔给模型。要在 System Prompt 中嵌入当前项目使用的 Jepsen 版本 API 文档片段，甚至提供一个 Rust 生成的 Schema 约束，强制 LLM 按照 Schema 输出，而不是自由生成 Clojure 代码。

2. 网络分区的时间精度陷阱
AI 生成的脚本往往使用简单的 sleep 来控制故障时长。但在高并发分布式系统中，sleep 的精度远远不够，且无法模拟真实的丢包或乱序。

• 避坑策略：故障注入必须依赖底层工具（如 Linux 的 tc 或 iptables），而不是应用层 sleep。Rust 网关应负责调用 sudo tc 命令来配置网络延迟，而不是让 AI 生成 Clojure 代码去尝试模拟网络延迟。确保故障注入是内核级的，而非用户态的。

3. 测试状态的脏数据泄漏
分布式测试最怕前后用例相互影响。AI 生成的脚本有时会忘记清理临时文件、数据库记录或网络规则。一旦某次测试失败，后续测试全部报错。

• 避坑策略：在 Rust 网关中实现“反向操作注册”。当 AI 生成一个“开启分区”的动作时，必须强制要求生成对应的“关闭分区”的清理动作，并使用 Drop trait 或 finally 块确保即使在测试崩溃时也能执行清理。此外，每个测试用例应使用独立的命名空间或容器 ID。

结语

用大模型辅助编写 Jepsen 脚本，本质上是用算力换人力，但安全边界必须牢牢掌握在确定性代码手中。Rust 在这里扮演的不是替代者，而是守门员。这套方案能显著降低混沌工程的门槛，但切记，分布式系统的复杂性不会因为 AI 的存在而消失，它只会转移到你如何验证 AI 的输出上。

关于这套架构的实现细节，或者你在 Jepsen 测试中遇到的诡异 Bug，欢迎在评论区留言，咱们一起切磋交流。