Pranavpro23/incident-response-env

title: Incident Response Env emoji: 🚨 colorFrom: red colorTo: red sdk: docker app_port: 8000 pinned: false tags: - openenv - sre - incident-response # Incident Response 环境 一个 **OpenEnv** 环境，用于训练 AI agent 扮演随叫随到的 Site Reliability Engineers (SRE)，响应生产事故。该 agent 会调查系统告警、诊断根本原因、执行修复步骤并解决事故——这与人类工程师在真实生产系统中遵循的工作流程相同。 ## 动机 随叫随到的事故响应是软件工程中风险最高、时间最紧迫的任务之一。工程师必须： - 对嘈杂的、多服务的告警风暴进行分流 - 从日志、指标和部署历史中识别根本原因 - 执行正确的修复操作而不造成进一步损害 - 在关闭事故前验证恢复情况 此环境填补了当前 agent 基准测试的一个空白：它需要在模糊性下进行**因果推理**、**多步规划**以及**工具使用规范**——所有这些都在一个具有直接现实世界价值的领域中。 ## 动作空间 ``` class IncidentAction(Action): command: str # one of the commands below parameters: Dict[str, str] # command-specific key-value pairs reasoning: str # agent's chain-of-thought (encourages deliberate action) ``` | Command | Parameters | Description | |---|---|---| | `check_alerts` | — | 列出所有活跃告警 | | `check_service_health` | `service=` | 健康状态、错误率、延迟、CPU/内存 | | `view_logs` | `service=` | 服务的近期日志条目 | | `view_metrics` | `service=` | 详细指标（错误率、延迟、吞吐量） | | `check_dependencies` | `service=` | 上游/下游依赖图 | | `view_deployment_history` | `service=` | 近期部署及其版本和备注 | | `classify_incident` | `severity=P1\|P2\|P3`, `affected_service=` | **任务 1 终止** — 对事故进行分类 | | `identify_root_cause` | `cause=`, `component=` | **任务 2 终止** — 提交根本原因 | | `restart_service` | `service=` | 重启服务（任务 3） | | `scale_service` | `service=`, `replicas=` | 扩缩容服务（任务 3） | | `rollback_deployment` | `service=` | 回滚到先前版本（任务 3） | | `resolve_incident` | `resolution=` | **任务 3 终止** — 关闭事故 | ## 观察空间 ``` class IncidentObservation(Observation): message: str # situation summary incident_id: str # e.g. "INC-20240315-001" task_name: str # current task step_number: int # current step max_steps: int # episode limit active_alerts: List[str] # live alert list command_output: str # output of last command available_commands: List[str] # commands for this task task_objective: str # what the agent must accomplish services_summary: Dict[str, str] # service → HEALTHY/DEGRADED/CRITICAL/CRASHING done: bool # episode ended reward: float # step reward ``` ## 任务 ### Task 1: `alert_triage` — 简单 **场景：** 支付服务在凌晨 2:47 宕机。多个下游告警正在触发。 **目标：** 识别事故严重程度（P1/P2/P3）和主要受影响服务。 **最大步数：** 8 **终止动作：** `classify_incident` **评分：** | Component | Score | |---|---| | 正确的严重程度 (P1) | +0.45 | | 正确的服务 (payment-service) | +0.45 | | 效率奖励（≤ 3 次调查步骤） | +0.10 | | 调查动作（最多 4 次） | 每次 +0.05 | ### Task 2: `root_cause_analysis` — 中等 **场景：** Orders API 返回 503。数据库过载。25 分钟前运行了一次迁移。 **目标：** 识别根本原因类别和负责的具体组件。 **最大步数：** 12 **终止动作：** `identify_root_cause` **评分：** | Component | Score | |---|---| | 准确原因 (`missing_database_index`) | +0.50 | | 部分原因（如 `slow_database_query`） | +0.20 | | 准确组件 (`orders-db`) | +0.40 | | 部分组件（如 `orders-api`） | +0.10 | | 调查动作（最多 4 次） | 每次 +0.05 | ### Task 3: `incident_remediation` — 困难 **场景：** Auth 服务（v2.4.0，2小时前部署）存在内存泄漏，导致 OOM 崩溃。API 网关熔断器已开启。 **目标：** 诊断、回滚故障部署、验证恢复、解决事故。 **最大步数：** 20 **终止动作：** `resolve_incident` **评分：** | Step | Score | |---|---| | 调查动作（最多 4 × 0.05） | 最高 0.20 | | `rollback_deployment auth-service`（正确修复） | +0.35 | | 回滚后 `check_service_health auth-service`（健康） | +0.10 | | auth 恢复后 `check_service_health api-gateway`（健康） | +0.10 | | `resolve_incident`（基础） | +0.10 | | 解决奖励：auth 已验证 | +0.10 | | 解决奖励：gateway 已验证 | +0.10 | **错误动作：** `restart_service`（临时性，+0.05），`scale_service`（无效，0），回滚错误服务（−0.05）。 ## 奖励设计 奖励函数在整个轨迹中提供**密集的部分进展信号**： - **调查动作**每次获得 `+0.05`（上限为 4 个不同命令，最高 `0.20`），以鼓励在采取行动前进行系统诊断 - **正确的终止动作**提供主要分数（0.40–0.90，取决于正确性） - **错误的修复**会导致小幅扣分（`-0.05`），以阻止随机操作 - 任务 3 中的**验证步骤**单独奖励（每个 `+0.10`），以鼓励确认恢复情况 - 任务 1 中的**效率奖励**奖励自信正确的分类 这种设计避免了稀疏奖励问题，同时仍要求 agent 正确诊断。 ## 基准分数 通过 HuggingFace 路由使用 `Qwen/Qwen2.5-72B-Instruct` 测量： | Task | Score | Notes | |---|---|---| | `alert_triage` | **1.000** | 在 2 步内正确分类为 P1 + payment-service | | `root_cause_analysis` | **0.550** | 正确组件 (orders-db)，部分原因匹配 | | `incident_remediation` | **0.850** | 在 7 步内回滚 + 验证 + 解决 | 任务 3 旨在挑战前沿模型——它要求 agent 停止重新调查并执行 `rollback_deployment` 动作，然后在解决前验证恢复。如果模型在调查中循环而不采取行动，得分会很低。 ## 设置 ### 前置条件 - Python 3.10+ - Docker - `pip install openenv-core>=0.2.3` ### 本地运行（不使用 Docker） ``` cd incident_response_env pip install -r requirements.txt uvicorn server.app:app --host 0.0.0.0 --port 8000 ``` ### 使用 Docker 运行 ``` docker build -t incident-response-env . docker run -p 8000:8000 incident-response-env ``` ### 运行推理脚本 ``` # 针对运行中的本地服务器： export API_BASE_URL="https://router.huggingface.co/v1" export MODEL_NAME="Qwen/Qwen2.5-72B-Instruct" export HF_TOKEN="your-token" export ENV_BASE_URL="http://localhost:8000" python inference.py # 针对 Docker 镜像： export LOCAL_IMAGE_NAME="incident-response-env:latest" python inference.py ``` ### 验证 ``` openenv validate ``` ## 项目结构 ``` incident_response_env/ ├── models.py # IncidentAction, IncidentObservation, IncidentState ├── scenarios.py # Scenario data for all 3 tasks ├── client.py # IncidentResponseEnv (typed WebSocket client) ├── server/ │ ├── app.py # FastAPI app (openenv create_app) │ └── incident_environment.py # Environment logic, reward & grader ├── inference.py # Baseline inference script ├── openenv.yaml # OpenEnv spec metadata ├── pyproject.toml # Project dependencies & entry points ├── requirements.txt ├── Dockerfile └── README.md ```

标签：AIOps, AI智能体, API集成, Docker, SRE, 人工智能, 偏差过滤, 可观测性, 因果推理, 多步规划, 安全防御评估, 故障恢复, 故障排查, 根因分析, 生产环境, 用户模式Hook绕过, 站点可靠性工程, 自动化运维, 警报管理, 训练环境, 请求拦截, 运维, 逆向工具