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绕过, 站点可靠性工程, 级联故障, 自动化运维, 请求拦截, 运维, 逆向工具