Twilight-13/devops-incident-response

tags: - openenv - devops - incident-response - real-world - reinforcement-learning - reward-shaping license: apache-2.0 pipeline_tag: reinforcement-learning sdk: docker # DevOps 故障响应 — OpenEnv 一个符合 OpenEnv 标准的强化学习环境，AI 智能体在此学习 诊断并修复模拟微服务架构中的生产软件故障。 智能体读取日志、指标和运维手册 —— 然后执行精确操作，如 回滚、重启和升级 On-call。奖励函数对信息收集、正确诊断和精确 修复给予密集的部分奖励，同时惩罚附带损害和盲目操作。 **四项难度递增的任务：** - **简单** — 单服务 OOM 崩溃循环（具体服务随 seed 变化） - **中等** — 错误部署导致的级联故障，伴随干扰警报 - **困难** — 静默数据损坏，无错误率警报，仅有业务指标异常 - **附加** — 两个同时发生的独立故障，必须全部修复 ## 动机 现有的智能体基准测试主要集中在软件工程 (SWE-bench)、 网页导航 (WebArena) 或通用工具使用 (AgentBench)。没有一个 模拟 **运维智能** —— 即在不确定性下对 实时生产系统进行推理的能力。 然而，故障响应是软件组织中风险最高、频率最高的 任务之一。每一家运行微服务的公司每天都会面临这个问题。所需的技能正是区分 强大 AI 智能体与弱智能体的关键： - 时间压力下的 **多步骤信息收集** - 对依赖系统的 **因果推理** - **精确的动作选择**，错误的操作会导致额外损害 - **信号与噪声区分**（干扰警报、静默故障） 本环境填补了这一空白。这是第一个专为基准测试智能体在 生产故障响应上的表现而设计的符合 OpenEnv 标准的 RL 环境。 ### 与现有基准测试的对比 | Benchmark | Domain | Multi-step | Real-world | Partial obs | Dense reward | |---|---|---|---|---|---| | SWE-bench | Code repair | ✓ | ✓ | ✗ | ✗ | | WebArena | Web navigation | ✓ | ✓ | ✓ | ✗ | | AgentBench | General tools | ✓ | Partial | ✗ | ✗ | | **DevOps-IR (ours)** | **Incident response** | **✓** | **✓** | **✓** | **✓** | ### Episode 架构 ``` graph TD A[Agent] -->|Action| B[DevOpsIncidentEnv] B -->|Observation| A B --> C[ServiceStatus x N] B --> D[AlertList] B --> E[EvidenceLog] B --> F[DependencyMap] B --> G[SLAStatus] H[Grader] -->|score 0-1| I[Episode Analytics] B -->|done=True| H I --> J[steps_to_diagnosis] I --> K[info_gathering_ratio] I --> L[collateral_damage_events] ``` ### 为什么这很难 这四项任务旨在要求性质不同的 推理策略： - **简单**: 直接信号读取 —— 日志清楚地显示 OOM，修复方法显而易见 - **中等**: 依赖追踪 —— 必须跟随调用链找到根源 - **困难**: 异常关联 —— 零错误警报，信号隐藏在 WARN 日志和跨越 6 个服务的业务指标中 - **附加**: 并行诊断 —— 两个不相关的故障，智能体必须 分解并独立修复 ## 环境描述 该环境模拟一个微服务电商集群。根据 任务不同，有 3–6 个服务处于活动状态。可能出现的服务： | Service | Stack | Role | |---|---|---| | `api-gateway` | Go | 路由外部请求 | | `payment-service` | Java (Spring) | 处理支付 | | `order-service` | Python | 创建并跟踪订单 | | `inventory-service` | Java | 管理产品库存 | | `user-service` | Node.js | 认证和配置文件 | | `notification-service` | Python | 邮件和推送警报 | | `data-pipeline-service` | Python | 从事件流写入目录数据 | | `product-catalog-service` | Go | 存储并提供产品数据 | | `price-validation-service` | Python | 验证价格一致性 | | `analytics-service` | Python | 聚合业务指标 | | `ml-inference-service` | Python | 提供推荐模型服务 | | `log-aggregator` | Go | 收集并存储日志 | 每个 Episode 会以此初始化一个随机场景。相同的 seed 总是产生相同的 Episode。不同的 seed 会轮换哪个服务故障、哪个版本是坏的， 以及具体的指标数值。 ## 动作空间 | Action | Parameters | Description | |---|---|---| | `diagnose` | `root_cause` (str) | 记录你的根本原因假设 | | `read_logs` | `service` (str) | 获取某个服务的近期日志行 | | `read_metrics` | `service` (str) | 获取 CPU、内存、错误率、P99 延迟 | | `read_runbook` | `runbook` (str) | 阅读运维手册 | | `search_logs` | `service`, `query` | 搜索匹配关键字的日志行 | | `restart_service` | `service` (str) | 重启服务（清除内存/连接） | | `rollback` | `service`, `version` | 回滚到先前的构件版本 | | `scale_up` | `service` (str) | 增加副本数量 | | `alert_oncall` | `reason` (str) | 呼叫 On-call 工程团队 | | `acknowledge` | `service` (alert id) | 确认活动警报 | | `noop` | — | 不采取任何行动 | ## 观察空间 每一步返回一个 Pydantic `Observation`，包含： ``` Observation ├── step, max_steps, task_id, task_description ├── services: List[ServiceStatus] │ ├── name, status, cpu_percent, memory_percent │ ├── error_rate, latency_p99_ms │ ├── replicas_running, replicas_desired │ ├── current_version, last_deployed │ ├── sla_breach, minutes_degraded ← NEW: SLA tracking ├── active_alerts: List[Alert] ├── recent_logs: Dict[str, List[str]] ├── service_dependencies: List[ServiceDependency] ← NEW: call topology │ ├── service, calls, called_by ├── evidence_log: List[EvidenceEntry] ← NEW: accumulated reads │ ├── step, source, summary, raw ├── sla_status: Dict[str, str] ← NEW: ok/warning/breached ├── available_runbooks: List[str] ├── last_action_result, last_action_error ├── incident_start_time, elapsed_minutes ``` ## 任务 ### 任务 1 — 单服务 OOM (简单) **最大步数:** 15 | **预期强 LLM 得分:** 0.85–1.00 一个服务因内存不足 (OOM) 错误而崩溃循环。受影响的服务 按 seed 轮换 (payment-service / order-service / user-service)，并具有 不同的日志格式 (Java / Python / Node.js)。api-gateway 上会触发 次级熔断器警报。 **奖励明细:** read_logs (+0.15), read_metrics (+0.10), runbook (+0.05), 正确诊断 (+0.30), 重启正确服务 (+0.40)。 惩罚: 重启健康服务 (−0.10), 过多 noop (−0.04/步)。 ### 任务 2 — 多服务级联故障 (中等) **最大步数:** 20 | **预期强 LLM 得分:** 0.55–0.75 一次错误的部署导致 `inventory-service` 出现连接池耗尽或 NullPointerException， 进而导致 `order-service` 级联超时以及 `api-gateway` 上的 错误率升高。`notification-service` 上触发高 CPU 警报 （干扰项 —— 计划中的批处理作业）。依赖图揭示了这条链： `api-gateway → order-service → inventory-service`。 **奖励明细:** 调查 inventory (+0.20), 追踪级联 (+0.05), runbook (+0.05), 正确诊断 (+0.25), 回滚根源服务 (+0.30–0.40)。 惩罚: 追踪干扰项 (−0.05), 在根源之前处理症状 (−0.10)。 ### 任务 3 — 静默数据损坏 (困难) **最大步数:** 25 | **预期强 LLM 得分:** 0.30–0.50 所有服务显示健康状态 —— 零错误率、正常延迟、无标准 警报。信号隐藏在 `price-validation-service` 的 WARN 日志（15% 的价格 不匹配率 vs 0.2% 基线）和 `analytics-service` 的异常（平均订单 价值 $847 vs $89 基线）中。两者都与 2 分钟前 `data-pipeline-service` 的部署相关联。 三个噪声警报会分散注意力：TLS 续订、分析积压、副本延迟。 获得满分需要 **同时** 执行 rollback 和 alert_oncall。 **奖励明细:** 读取微弱信号 (+0.15–0.20), 检查 pipeline 指标 (+0.10), runbook (+0.05), 正确诊断 (+0.20), rollback pipeline (+0.25), alert_oncall (+0.15)。 惩罚: 任何 restart/scale (−0.15)。 ### 任务 4 — 同时双重故障 (附加) **最大步数:** 25 | **预期强 LLM 得分:** 0.35–0.55 两个完全独立的故障同时发生： 1. `log-aggregator` 磁盘 100% 满（每分钟丢失 48k 条日志消息） 2. `ml-inference-service` 卡在模型校验和重载循环中（CPU 99%+） 修复其中一个对另一个没有帮助。获得满分需要解决两者： alert_oncall 进行磁盘清理 以及 rollback/restart ml-inference。 ## 奖励函数设计 ``` Score = Σ(step rewards) + efficiency_bonus + diagnosis_bonus - collateral_damage_penalty - blind_action_penalty - noop_penalty ``` 关键属性： - **密集信号** — 除非真的是随机操作，否则整个 Episode 的奖励永远不会为零 - **信息优先** — 奖励先读取后操作的行为 - **要求精确** — 错误的服务会导致 0 分或负分 - **时间压力** — SLA 状态每一步都会恶化；效率奖励鼓励速度 - **双重要求** — 困难和附加任务需要多个正确操作 所有奖励限制在 **[0.0, 1.0]** 范围内。 ## 设置说明 ### Docker (推荐用于评测) ``` docker build -t devops-incident-env . docker run -p 7860:7860 devops-incident-env curl http://localhost:7860/health ``` ### 本地 Python ``` pip install -r requirements.txt uvicorn api:app --host 0.0.0.0 --port 7860 ``` ### 直接导入 ``` from env import DevOpsIncidentEnv from models import Action, ActionType env = DevOpsIncidentEnv(task_id="easy", seed=42) obs = env.reset() # 服务依赖关系图位于 obs.service_dependencies # 证据日志在阅读时累积于 obs.evidence_log result = env.step(Action(action_type=ActionType.READ_LOGS, service="payment-service")) print(result.reward) # 0.15 print(result.observation.evidence_log[-1].summary) ``` ### 验证 ``` python validate.py # 22 automated checks, exit 0 = all pass ``` ## 运行推理基线 ``` export API_BASE_URL="https://router.huggingface.co/v1" export MODEL_NAME="meta-llama/Llama-3.3-70B-Instruct" export HF_TOKEN="hf_your_token_here" python inference.py ``` ## 基线分数 使用 `meta-llama/Llama-3.3-70B-Instruct` 运行，seed=42，temperature=0.1： | Task | Score | Resolved | Steps | |---|---|---|---| | easy | 1.0000 | ✓ | 5 | | medium | 0.6800 | ✓ | 9 | | hard | 0.3500 | ✗ | 25 | | bonus | 0.3800 | ✗ | 25 | | **average** | **0.6025** | — | — | *分数随模型和 temperature 变化。使用 seed=42 运行以确保可复现性。* ## API 参考 | Endpoint | Method | Body | Description | |---|---|---|---| | `/health` | GET | — | 返回 `{"status": "ok"}` | | `/reset` | POST | `{"task_id": "easy", "seed": 42}` | 开始新 Episode | | `/step` | POST | `Action` JSON | 执行一个动作 | | `/state` | GET | — | 完整状态 + 基本事实 + 分析数据 | | `/tasks` | GET | — | 列出所有 4 个任务 | | `/validate` | GET | — | 所有任务的自我验证报告 | ## OpenEnv 合规性 ``` openenv validate . ``` 所有 Endpoints 均符合 OpenEnv 规范。`openenv.yaml` 包含完整的 元数据，包括 4 个任务定义、动作/观察空间描述、 预期分数范围以及 Docker 配置。 ## 许可证 Apache 2.0

标签：AIOps, AI智能体, Docker, OpenEnv, Ops智能, 仿真环境, 因果推理, 多步决策, 奖励塑形, 安全防御评估, 强化学习, 故障自愈, 故障诊断, 数据管道, 智能运维, 生产事故, 请求拦截, 软件工程, 逆向工具