Abhigyan-Shekhar/incident-response-env

title: IncidentResponseEnv emoji: 🚨 colorFrom: red colorTo: pink sdk: docker pinned: false app_port: 8000 base_path: / tags: - openenv # IncidentResponseEnv IncidentResponseEnv 是一个用于 SRE 值班事件分诊的 OpenEnv 环境。它为 agent 提供了一个损坏的生产系统、真实的警报和日志，以及一个受限的修复接口。agent 必须调查事件、识别真正的根本原因、执行正确的修复措施，并提交合理的诊断报告。 此环境专为 OpenEnv 黑客松要求而构建：真实世界的任务、标准的 `reset()` / `step()` / `state()` 交互、三个难度级别、`[0.0, 1.0]` 范围内的确定性评分，以及可复现的基线执行。 在线部署：[abhi1203-incident-response-env.hf.space](https://abhi1203-incident-response-env.hf.space) ## 为什么这个任务很重要 SRE 事件响应是每家软件公司实际的生产工作流程。当服务在凌晨 2 点降级时，值班工程师必须在时间压力下跟踪跨依赖关系的症状、将根本原因与爆炸半径区分开来、应用正确的修复措施并恢复服务。这使其成为一个强有力的 OpenEnv 任务： - 它是真实的人类工作，而不是玩具游戏 - 成功取决于对变化状态的顺序推理 - 错误的操作会带来运营成本 - 环境可以评估完整的轨迹，而不仅仅是最终答案 ## 环境约定 环境暴露了标准的 OpenEnv 循环： - `reset(difficulty)` 启动一个新的事件并返回初始观察 - `step(action)` 应用一个操作并返回更新后的观察和增量奖励 - `state()` 返回当前的环境状态、服务健康状况和分数明细 HTTP 服务器暴露： - `GET /health` - `POST /reset` - `POST /step` - `GET /state` 部署的 Space 在请求之间保持每个 episode 的状态，并在响应元数据中返回一个 `episode_id`，以便多步骤评估保持确定性。 ## 观察和动作模型 一个观察包含： - 事件图中的服务健康状况 - 活动警报 - 每个服务的最近日志 - 已调查的服务 - 已诊断的服务 - 已解决的服务 - 分数明细 Agent 使用类型化的 `IncidentAction` 进行操作： - `investigate` - `rollback` - `scale_up` - `restart` - `enable_circuit_breaker` - `submit_diagnosis` `submit_diagnosis` 只有在根本原因服务被调查后才会获得奖励。中等和困难场景还需要来自受影响服务的佐证，因此 agent 无法通过从单个警报猜测来获得积分。 ## 难度级别 | 级别 | 场景 | 必需行为 | | --- | --- | --- | | `easy` | `api-gateway` 因内存压力而崩溃 | 调查，识别 OOM，扩容，提交诊断 | | `medium` | 错误的 `auth-service` 部署级联导致下游超时 | 调查受影响的服务，追踪到 `auth-service`，回滚，提交诊断 | | `hard` | `db-primary`、`cache-cluster` 和 `ranking-ml` 因不同原因失败 | 消除症状歧义，遵守修复顺序，解决并诊断所有三个 | 难度递进是有意设计的。困难任务要求 agent 区分重叠的症状、调查依赖关系，并按正确顺序进行修复。 ## 确定性评分 分数是确定性的，并限制在 `[0.0, 1.0]` 范围内。 - `+0.40` 恢复进度 - `+0.25` 正确诊断得分 - `+0.15` 在修复前提交诊断的奖励 - `+0.10` 在 15 步预算内的效率奖励 - `-0.20` 每次错误的破坏性操作 对于多根本原因事件，恢复和诊断按活动问题分配。这使得奖励对轨迹敏感，而非纯粹的输赢。 ## 验证的基线结果 实时基线是针对部署的 Hugging Face Space 使用 Groq OpenAI 兼容端点进行端到端运行的： | 任务 | 分数 | 步数 | 成功 | | --- | --- | --- | --- | | `easy` | `0.75` | `3` | `true` | | `medium` | `0.7063` | `6` | `true` | | `hard` | `0.6611` | `11` | `true` | 三个任务的平均奖励：`0.7058` 这展示了一条清晰的向下难度曲线，同时仍在所有任务上展示了成功完成。 ## 快速开始 创建一个本地环境并运行确定性基线： ``` python3 -m venv .venv source .venv/bin/activate pip install -e . python3 -m pytest python3 inference.py --planner heuristic ``` 在本地启动 HTTP 服务器： ``` uvicorn server.app:app --host 0.0.0.0 --port 8000 ``` 针对 OpenEnv 进行验证： ``` source .venv/bin/activate python3 -m openenv.cli validate ``` ## LLM 基线 `inference.py` 支持： - `--planner heuristic` 用于确定性基线 - `--planner llm` 用于 OpenAI 兼容端点 - `--planner auto` 在配置时使用 LLM，否则回退到启发式 预期的环境变量： - `API_BASE_URL` - `MODEL_NAME` - `HF_TOKEN` 使用 Groq 的示例： ``` API_BASE_URL="https://api.groq.com/openai/v1" \ MODEL_NAME="llama-3.3-70b-versatile" \ HF_TOKEN="$YOUR_GROQ_API_KEY" \ python3 inference.py --planner llm ``` 端到端验证实时部署的环境： ``` source .venv/bin/activate PYTHONPATH=. python3 scripts/live_space_eval.py ``` ## 部署 此仓库包含： - `openenv.yaml` - `Dockerfile` - `server/app.py` Hugging Face Space 配置为 Docker Space，并需要： - `API_BASE_URL` 作为变量 - `MODEL_NAME` 作为变量 - `HF_TOKEN` 作为密钥 ## 仓库布局 - `incident_response_env/environment.py`: 确定性事件引擎 - `incident_response_env/scenarios.py`: 简单、中等和困难的事件定义 - `incident_response_env/agent.py`: 启发式和 OpenAI 兼容的规划器 - `inference.py`: 带有结构化 `[START]`、`[STEP]` 和 `[END]` 日志的基线运行器 - `scripts/live_space_eval.py`: 实时部署验证器 - `tests/test_environment.py`: 回归覆盖

标签：API集成, BurpSuite集成, Docker, HF Spaces, HTTP工具, OpenEnv, Petitpotam, Python, SRE, 事故响应, 偏差过滤, 可观测性, 告警处理, 子域名变形, 安全防御评估, 库, 应急响应, 强化学习, 故障修复, 故障诊断, 无后门, 无线安全, 根因分析, 模拟环境, 生产环境仿真, 站点可靠性工程, 请求拦截, 运维演练, 运维自动化, 逆向工具, 配置错误