mayur-dhavan/incident-response-env

GitHub: mayur-dhavan/incident-response-env

一个符合OpenEnv规范的仿真环境,用于评估AI Agent在生产环境事件响应中的故障诊断与修复决策能力。

Stars: 0 | Forks: 0

# 事件响应环境 一个符合 [OpenEnv](https://github.com/meta-llama/open-env) 规范的环境,模拟**生产环境事件响应** —— 即 SRE(网站可靠性工程师)日常执行的诊断和解决服务器中断的实际任务。 AI agent 必须调查服务健康状况、阅读日志、检查指标、确定中断的根本原因并应用正确的修复措施 —— 所有操作都在步骤预算内完成。 ## 为什么选择此领域? 生产环境事件响应是一项高风险、知识密集型任务,其特点如下: - **部分信息**是常态 —— 并非所有信息都一目了然 - 存在**误导性线索** —— 令人误解的日志条目和相关但非因果的症状 - **错误操作会有后果** —— 盲目重启服务可能会掩盖根本原因或恶化中断情况 - 需要**顺序推理** —— 先诊断,后修复 这使其成为评估 LLM agent 在现实世界决策能力的绝佳测试平台。 ## 任务 | 任务 | ID | 难度 | 描述 | 最优步骤 | |---|---|---|---|---| | OOM Killer | `task_1_oom` | 简单 | api-server 被 Linux OOM killer 终止。清晰的日志指向修复方案。 | 2 | | 内存泄漏 | `task_2_leak` | 中等 | Worker 因错误部署存在内存泄漏。API 延迟是症状而非原因。应回滚,而非重启。 | 3 | | 级联故障 | `task_3_cascade` | 困难 | 达到 Postgres 连接限制 (max_connections=25)。所有服务均不可用。nginx 日志中有来自 3 周前的误导性“磁盘已满”错误。 | 4 | ### 难度递增 - **简单**: 单个服务宕机,日志明确,修复方式为 `restart_service` - **中等**: 多个服务降级,必须区分原因和症状,错误的修复(重启)会受到惩罚 - **困难**: 全面中断,级联故障,误导性的干扰信息,需要 SQL 命令修复,盲目重启会受到惩罚且无效 ## 动作空间 ``` class IncidentAction(Action): action_type: str # one of the 6 actions below target: str # service name or command string parameters: dict # optional extra params ``` | 动作 | 目标 | 描述 | |---|---|---| | `read_logs` | 服务名称 | 读取服务的近期日志行 | | `check_metrics` | 服务名称或 `all` | 检查 CPU、内存、连接数、错误率 | | `restart_service` | 服务名称 | 重启服务(可能无法修复根本原因) | | `rollback` | 服务名称 | 回滚到之前的部署版本 | | `exec_command` | 命令字符串 | 运行诊断/修复命令 (SQL, shell) | | `check_network` | `svc1->svc2` | 检查服务间的网络连通性 | **服务**: `api-server`, `postgres`, `redis`, `worker`, `nginx` ## 观察空间 ``` class IncidentObservation(Observation): output: str # Human-readable result (log lines, metrics, status messages) services: dict[str, Any] # Current health snapshot of all services success: bool # Whether the action executed successfully error: str # Error message if success=False # Inherited from Observation: done: bool # True when episode ends reward: float # Per-step reward (score delta) ``` ## 状态(用于评分器) ``` class IncidentState(State): task_id: str actions_taken: list[dict] root_cause_identified: bool fix_applied: bool system_restored: bool current_score: float # Inherited: episode_id, step_count ``` ## 奖励设计 奖励计算为每一步**评分器分数的变化量 (delta)**: - 对于朝向根本原因的调查动作给予**正奖励** - 对于应用正确修复给予**正奖励** - 对于错误动作给予**负奖励**(例如,本应回滚却重启) - 对于冗余或中性动作给予**零奖励** 这在整个轨迹中提供密集信号,而不仅仅是二元的片段结束分数。 ### 评分标准 **任务 1 (简单)**: +0.20 读取任意日志,+0.20 读取 api-server 日志,+0.30 重启 api-server,+0.30 系统恢复 = 1.0 **任务 2 (中等)**: +0.15 任意调查,+0.20 调查 worker,+0.15 检查 worker 指标,+0.20 回滚 worker,+0.30 系统恢复。惩罚: -0.15 重启 api-server,-0.10 重启 worker。 **任务 3 (困难)**: +0.10 任意调查,+0.20 调查 postgres,+0.20 确定根本原因,+0.20 正确修复命令,+0.30 系统恢复。惩罚: -0.10 每次盲目重启 (最多 -0.20),-0.05 每次磁盘空间调查 (最多 -0.10)。 ## API 端点 | 方法 | 路径 | 描述 | |---|---|---| | POST | `/reset` | 开始新的片段。Body: `{"task_id": "task_1_oom"}` | | POST | `/step` | 执行动作。Body: `{"action": {"action_type": "...", "target": "...", "parameters": {}}}` | | GET | `/state` | 获取完整片段状态(用于评分) | | GET | `/health` | 健康检查 | | GET | `/tasks` | 列出所有包含动作模式的任务 | | POST | `/grader` | 对当前片段进行评分(返回 0.0–1.0 分) | | POST | `/baseline` | 在所有 3 个任务上运行基于规则的基线 | | GET | `/schema` | OpenEnv 模式 | ## 设置与使用 ### 本地开发 ``` # 安装依赖 pip install -e ".[dev]" # 启动服务器 uvicorn incident_response_env.server.app:app --port 7860 # 运行 baseline(基于规则,无需 API key) python incident_response_env/baseline.py --url http://localhost:7860 --rule-based # 通过 HuggingFace Inference 使用 Open LLM 运行 baseline(推荐) export HF_TOKEN=hf_... python incident_response_env/baseline.py --url http://localhost:7860 --provider hf --model meta-llama/Llama-3.1-8B-Instruct # 使用 OpenAI 运行 baseline export OPENAI_API_KEY=sk-... python incident_response_env/baseline.py --url http://localhost:7860 --provider openai --model gpt-4o-mini # 使用任何 OpenAI-compatible endpoint 运行 baseline(vLLM, Ollama 等) python incident_response_env/baseline.py --url http://localhost:7860 --api-base http://localhost:8000/v1 --model my-model ``` ### Docker ``` cd incident_response_env docker build -f server/Dockerfile -t incident-response-env . docker run -p 7860:7860 incident-response-env ``` ### Hugging Face Spaces 该环境部署于: https://huggingface.co/spaces/mayur6901/incident-response-env ## 基线分数 ### 基于规则的 Agent (确定性) | 任务 | 难度 | 分数 | 步骤 | 已恢复 | |---|---|---|---|---| | OOM Killer | 简单 | 1.0000 | 2 | 是 | | 内存泄漏 | 中等 | 1.0000 | 3 | 是 | | 级联故障 | 困难 | 1.0000 | 4 | 是 | | **平均** | | **1.0000** | | | *基于规则的 agent 使用完美的领域知识 —— 它代表了最优策略。* ### LLM Agent — 开源 LLMs (通过 HF Inference 使用 Llama 3.1 8B) | 任务 | 难度 | 分数 | 步骤 | 已恢复 | |---|---|---|---|---| | OOM Killer | 简单 | 1.0000 | 5 | 是 | *通过 HuggingFace Inference API (兼容 OpenAI) 使用 `meta-llama/Llama-3.1-8B-Instruct` 测试。* 基线脚本适用于**任何兼容 OpenAI 的端点** —— OpenAI, HuggingFace Inference, vLLM, Ollama 等。不同难度的预期分数范围: - 简单任务: 大多数模型应得分 0.7–1.0 - 中等任务: 需要区分原因和症状(预期 0.5–0.9) - 困难任务: 需要避开误导线索并执行 SQL(预期 0.3–0.7) ## 项目结构 ``` incident_response_env/ ├── models.py # Pydantic Action/Observation/State models ├── baseline.py # Baseline inference script (Open LLM / OpenAI-compatible + rule-based) ├── client.py # EnvClient wrapper for programmatic use ├── openenv.yaml # OpenEnv spec metadata ├── pyproject.toml # Package config + dependencies ├── README.md # This file ├── __init__.py └── server/ ├── app.py # FastAPI application with all endpoints ├── environment.py # Core environment logic (reset/step/state) ├── graders.py # Deterministic grading functions ├── scenarios.py # Task definitions (logs, metrics, services) ├── Dockerfile # Container for HF Spaces deployment ├── requirements.txt # Python dependencies └── __init__.py ``` ## OpenEnv 合规性 - `openenv.yaml` 中 `spec_version: 1` - Action, Observation, State 均使用类型化的 Pydantic 模型 - 完整实现 `step()` / `reset()` / `state()` - 确定性评分器返回 0.0–1.0 - 每步奖励信号(不仅是片段结束时) - 通过 `reset()` 实现清晰的片段边界 - Dockerfile 构建并运行无误 - 基线脚本适用于任何兼容 OpenAI 的 LLM (HF Inference, OpenAI, vLLM 等) - 评分器分数根据 agent 策略变化(非恒定) ## 许可证 MIT
标签:AIOps, BurpSuite集成, Hackathon项目, Linux运维, LLM评估, Meta, Ollama, OpenEnv, Petitpotam, PyTorch, SRE, 人工智能, 偏差过滤, 内存溢出, 决策制定, 强化学习, 故障诊断, 服务器中断, 根因分析, 模拟环境, 生产环境, 用户模式Hook绕过, 站点可靠性工程, 级联故障, 自动化运维, 请求拦截, 运维, 逆向工具