Neeln11/SRE-Bench

title: SRE-Bench 故障响应环境 emoji: 🚨 colorFrom: red colorTo: red sdk: docker pinned: false tags: - openenv - sre - incident-response - rl-environment - agent-evaluation # 🚨 SRE-Bench: 故障响应环境 一个 **OpenEnv** 环境，其中 AI 代理扮演值班站点可靠性工程师（SRE）。代理将面对一个实时的生产故障，必须读取日志、运行诊断、确定根本原因并应用正确的修复方案——所有这些都通过结构化的终端 API 进行。 ## 🎯 为什么这个环境很重要 每家科技公司都有工程师全天候待命。当生产数据库在凌晨 3 点宕机时，你不能只是让一个标准聊天机器人去“修复它”。在工程团队信任 AI 担任自主 SRE 之前，他们需要一个安全、沙盒化的方式来证明 AI 在尝试解决中断时不会意外删除客户数据。 **SRE-Bench 提供了这样一个确切的验证平台。** ## 💻 为什么是基于文本的“聊天”界面？ 你可能想知道为什么代理通过 JSON 命令（`read_log`、`check_metrics`）进行交互，而不是使用传统的 UI。这是有意为之的： - **真正的工程师使用终端：** 当人类调试服务器时，他们会 SSH 进入终端，运行 `htop`，检查 `tail -f logs`，并运行 bash 脚本。 - **工具使用：** 通过为 LLM 提供严格的基于文本的 API，我们迫使它像使用 CLI 工具的真正工程师一样与系统交互。 - **推理循环：** 代理必须观察终端输出，“思考”（思维链）其含义，并决定下一个逻辑命令。这评估了真正的代理推理能力。 ## 🚀 最终目标：二级值班自动化 此类系统的核心价值在于**防止职业倦怠**。目前，如果磁盘满了，人类会在半夜收到警报。有了经过 SRE-Bench 验证的代理，未来的工作流程将变为： ## 🖥️ 交互式 Web 界面 SRE-Bench 配有两个精美的前端 UI 来可视化基准测试： 1. **Gradio 控制面板 (`http://localhost:7860`)**：一个精致的中心，用于手动触发健康检查、批量执行压力测试，或一键启动推理代理。 2. **实时操作仪表板 (`http://localhost:8000/`)**：一个时尚、动态的终端 UI（灵感来自暗色模式 IDE），你可以在其中直观地观看 AI 代理的推理、命令执行以及微服务的实时健康状况。 ## 🌍 环境描述 代理与一个由多个服务（API、数据库、认证、履约、财务）组成的模拟生产系统进行交互。每个回合呈现不同的故障。代理必须： - 观察故障警报和当前的服务健康状况 - 运行诊断命令以收集信息 - 确定根本原因 - 应用正确、有针对性的修复 - 验证服务是否恢复 ## ⚡ 动作空间 | 命令 | 描述 | 示例参数 | |---|---|---| | `read_log` | 读取服务日志 | `{"service": "api"}` | | `check_metrics` | 检查服务/基础设施指标 | `{"target": "disk"}` | | `run_diagnostic` | 运行诊断查询 | `{"type": "deploy_history"}` | | `apply_fix` | 应用补救措施 | `{"fix_type": "delete_log", "target": "/var/log/app/app.log.2024-01-14"}` | | `rollback` | 回滚服务 | `{"service": "orders"}` | | `restart_service` | 重启服务 | `{"service": "auth"}` | | `escalate` | 从高级 SRE 获取提示 | `{}` | ## 👁️ 观察空间 | 字段 | 类型 | 描述 | |---|---|---| | `terminal_output` | string | 上一条命令的输出 | | `services` | list | 服务健康对象：名称、状态、错误率、延迟 p99_ms | | `step` | int | 当前步骤（最多 15 步） | | `sla_remaining` | int | 违反 SLA 之前的步数（如果在 12 步内解决，则获得 SLA 奖励） | | `incident_description` | string | 初始的 PagerDuty 风格警报 | | `last_command_error` | string\|null | 如果命令无效则显示错误 | ## 📋 任务 ### 任务 1 — 磁盘已满 *(简单)* - **故障：** API 服务降级 — 45% 错误率，4.2s p99 延迟。 - **根本原因：** 一个 40GB 的轮转日志文件从未被压缩，导致 `/var/log` 使用率达到 100%。 - **代理必须执行的操作：** `check_metrics(disk)` → `read_log(app)` → `apply_fix(delete_log, correct_file)`。 - **为什么简单：** 单一根因，2–3 条命令，线性推理。 ### 任务 2 — 数据库连接池耗尽 *(中等)* - **故障：** API p99 = 8.1s，错误率 38%。50 分钟前逐渐开始。 - **根本原因：** Auth 服务在每次登录失败时泄漏一个数据库连接。50 分钟后，所有 50 个池连接都被 auth 占用，阻塞了其他所有操作。 - **代理必须执行的操作：** 读取 API 日志 + DB 指标 + auth 日志，关联连接所有权数据，然后应用 `restart_auth_with_connection_cleanup`。如果代理未读取至少 2 个来源，则修复无效。 - **为什么中等：** 根本原因在任何单个日志中都不可见 — 需要多源关联。 ### 任务 3 — 静默数据损坏 *(困难)* - **故障：** 低优先级工单：财务报告约 180 张重复发票。无服务错误。无延迟警报。 - **根本原因：** 45 分钟前的一次部署将 orders 服务序列化程序更改为 `json_v2`，它会静默地将无法识别的字符替换为 `?`。Orders 写入损坏的 `item_id` 字段 → fulfillment 静默丢弃这些行 → 财务在重试时重复计费。 - **代理必须执行的操作：** 读取 orders + fulfillment + finance 日志，检查部署历史，回滚配置更改，然后触发重新处理 — 且不删除 orders 表（这会导致 -0.50 的惩罚）。 - **为什么困难：** 没有单个日志显示全貌。Orders 服务看起来很健康。代理必须连接 4 个独立的数据源，理解因果关系，并按正确顺序应用两步修复。 ## 🏆 奖励函数 ``` Per step: +0.05-0.10 Running correct diagnostic commands +0.07-0.10 Reading relevant logs (each source) +0.20-0.30 Identifying root cause +0.20-0.30 Applying correct fix +0.20 Service health fully restored +0.05 SLA bonus (fast resolution) Penalties: -0.05 Wrong fix attempted (no data loss) -0.30 Destructive action on wrong target -0.50 Permanent data loss (hard task) ``` 所有奖励严格限制在 `(0.0, 1.0)` 之间 — 不包含两端点。 ## 🔌 API 端点 | 方法 | 路径 | 描述 | |---|---|---| | GET | `/health` | 健康检查 | | GET | `/tasks` | 列出所有任务 | | POST | `/reset` | 开始新回合 | | POST | `/step` | 执行一个动作 | | GET | `/state` | 获取完整的内部状态 | | POST | `/grade` | 获取最终评分 | ### 示例用法 ``` import requests # 开始 episode obs = requests.post("https://neel-110-sre-bench-env.hf.space/reset", json={"task_id": "disk_full", "session_id": "test"}).json() # 执行一步 result = requests.post("https://neel-110-sre-bench-env.hf.space/step", json={ "action": {"command": "check_metrics", "params": {"target": "disk"}}, "session_id": "test" }).json() print(result["observation"]["terminal_output"]) print(result["reward"]) ``` ## 🛠️ 设置与本地运行 ``` # Clone and install git clone https://github.com/Neeln11/SRE-Bench cd SRE-Bench pip install -r requirements.txt # 运行 environment server (FastAPI) 和 Gradio Web UI python app.py # （可选）手动运行 inference script set HF_TOKEN=your_token set API_BASE_URL=https://router.huggingface.co/v1 set MODEL_NAME=Qwen/Qwen2.5-72B-Instruct python inference.py ``` ### Docker ``` docker build -t sre-bench . docker run -p 7860:7860 \ -e HF_TOKEN=your_token \ -e API_BASE_URL=https://router.huggingface.co/v1 \ -e MODEL_NAME=Qwen/Qwen2.5-72B-Instruct \ sre-bench ``` ## 📊 基线分数 通过 HuggingFace 路由使用 `Qwen/Qwen2.5-72B-Instruct` 获得的分数： | 任务 | 难度 | 基线分数 | |---|---|---| | disk_full | 简单 | ~0.90 | | db_pool_exhausted | 中等 | ~0.85 | | data_corruption | 困难 | ~0.25 | 困难任务约 0.25 的分数显示了有意义的难度递进 — 代理通常能识别出 orders 日志异常，但未能追踪完整链条并应用了错误的修复。 ## 🔧 环境变量 | 变量 | 必填 | 描述 | |---|---|---| | `HF_TOKEN` | 是 | 用于推理的 HuggingFace / API 密钥 | | `API_BASE_URL` | 是 | LLM 端点 URL | | `MODEL_NAME` | 是 | 模型标识符 | | `SRE_BENCH_URL` | 否 | 环境 URL（默认：http://localhost:7860） | | `TASK_ID` | 否 | 要运行的任务：`all`、`disk_full`、`db_pool_exhausted`、`data_corruption` |

标签：AI智能体, Benchmark, BurpSuite集成, DLL 劫持, DNS解析, Docker, LLM, On-call, OpenEnv, RL环境, SRE, Unmanaged PE, 事故响应, 值班自动化, 偏差过滤, 大语言模型, 安全防御评估, 开源项目, 强化学习环境, 故障响应, 智能运维, 根因分析, 沙箱环境, 环境评估, 站点可靠性工程, 系统诊断, 终端模拟, 自动化运维, 请求拦截, 运维自动化, 逆向工具