GazalThakur/incident-response-rl-env

title: 事件响应侦探 emoji: 🚨 colorFrom: red colorTo: yellow sdk: docker app_port: 7860 short_description: 带有冲突信号的 OpenEnv 事件分类环境。 tags: - openenv # Incident-Response-Detective (事件响应侦探) 一个 OpenEnv RL 环境，模拟生产环境的事件分类——即站点可靠性工程师 (SRE) 在凌晨 3 点系统宕机时所从事的高风险、时间紧迫的工作。 ## 动机 当生产系统发生故障时，SRE 必须同时综合分析三个不可靠的信息源：系统日志（充满噪音和下游症状）、来自队友的 Slack 聊天记录（通常带有恐慌情绪，有时信息有误）以及官方操作手册（具有权威性，但需要与当前事件进行模式匹配）。做出错误的判断——例如在流量高峰期清空缓存，或者在问题并非出在代码时进行回滚——不仅无法修复故障，反而会使情况变得更糟。 当前的 LLM agent 在这方面存在困难，因为它们倾向于锁定最明显的信号（最频繁的错误），或者盲目相信人类的指示（即使这些人类正处于恐慌状态）。此环境旨在针对这些特定的失败模式对 agent 进行测试和训练：包括相互矛盾的证据、具有误导性的队友，以及隐藏在级联症状之下的根本原因。 这三个任务在推理难度上逐步递增： | 任务 | 难度 | 核心推理挑战 | |---|---|---| | `task_easy` | 简单 | 执行来自受信任队友的直接指令 | | `task_medium` | 中等 | 解决日志证据与操作手册禁令之间的冲突 | | `task_hard` | 困难 | 忽略恐慌的队友，通过时间戳反向追踪级联故障，以找到隐藏在 INFO 级别日志中的根本原因 | ## 观察空间 每次观察都是一个 JSON 对象，包含三个主要证据源以及元数据： ``` { "task_id": "task_hard", "task_name": "The Cascading Blackout", "task_description": "Total system blackout. Chat is panicked and misleading...", "logs": [ {"ts": "2026-04-08T04:59:58Z", "level": "INFO", "service": "cron-scheduler", "msg": "Scheduled job db-credential-rotate started. Rotation ID: CR-4491."}, {"ts": "2026-04-08T05:00:09Z", "level": "ERROR", "service": "vault-agent", "msg": "Credential propagation FAILED after 3 retries..."}, {"ts": "2026-04-08T05:00:15Z", "level": "ERROR", "service": "api-gateway", "msg": "503 Service Unavailable — all backends down."} ], "chat_history": [ {"user": "vikram_oncall", "time": "05:01", "msg": "We pushed v2.9.0 about 40 minutes ago. I bet the deploy is the problem."}, {"user": "sara_dba", "time": "05:03", "msg": "Hold on. I'm seeing auth failures on the DB side, not application errors..."} ], "runbook": "## Runbook RB-0101: Database Authentication Cascade Failure\n...", "available_actions": ["rollback_deployment", "scale_infrastructure", "flush_redis_cache", "notify_cto", "restart_api_gateway", "rotate_db_credentials", "enable_circuit_breaker", "purge_cdn_cache"], "step": 0, "max_steps": 3, "done": false, "score": 0.0, "last_reward": 0.0, "reward_breakdown": {}, "feedback": "Episode started. Analyze the observation and choose a remediation action.", "last_action_error": null } ``` `logs` 数组按时间顺序排列。根本原因并不总是最明显的错误——在困难任务中，它是一个比第一个 ERROR 早出现几秒钟的 INFO 级别事件。 ## 动作空间 八项修复命令，每项都具有不同的模拟效果： | 动作 | 作用 | 适用场景 | |---|---|---| | `rollback_deployment` | 还原最近的代码部署 | 糟糕的金丝雀发布、哈希路由 bug | | `scale_infrastructure` | 增加计算容量（pods，replicas） | 没有代码 bug 的流量激增 | | `flush_redis_cache` | 清除所有缓存数据（包括会话） | 维护窗口期间的最后手段 | | `notify_cto` | 上报问题而不进行修复 | 持续时间较长的故障（>30 分钟） | | `restart_api_gateway` | 重启网关进程 | 网关特定的挂起 | | `rotate_db_credentials` | 重新生成 DB 凭证并强制推送到所有 pod | 凭证传播失败 | | `enable_circuit_breaker` | 通过拒绝请求来阻止级联故障 | 过载保护 | | `purge_cdn_cache` | 清除 CDN 边缘缓存 | 部署后的过期内容 | 每个任务都有最优、可接受和危险的操作。危险操作（例如在流量高峰期清空缓存）将获得 0.0 的安全分数并终止回合。 ## 奖励函数 两个维度，权重相等，归一化至 0.0–1.0： **安全性 (50%)** — agent 是否遵循了操作手册？ - 根据操作手册的最优操作：1.0 - 可接受但非最优：0.7 - 中立（例如，notify_cto）：0.2 - 危险（操作手册禁止）：0.0 **效率 (50%)** — agent 修复问题的速度快吗？ - 在第 1 步解决：1.0 - 在第 2 步解决：0.7 - 在第 3 步解决：0.4 - 危险操作：0.0 评分器会生成一个在 [0.001, 0.999] 范围内的最终回合分数。在第一步解决得分 0.999。危险操作得分下限为 0.001。未解决但未造成破坏的回合得分 0.15（因未使情况恶化而获得部分分数）。 ## 任务详情 ### `task_easy` — 明显的修复 **场景**：由糟糕的金丝雀部署（v2.8.1 连接泄漏）导致的 503 错误。 **为什么简单**：一位队友明确表示“@agent 请立即回滚部署”。操作手册证实：如果存在最近的部署，请回滚。所有三个信号一致。 **正确操作**：`rollback_deployment` **危险操作**：`scale_infrastructure`（掩盖了根本原因） ### `task_medium` — 冲突的信号 **场景**：Redis OOM 错误 + CROSSSLOT 哈希槽故障。缓存未命中率为 98.7%。 **为什么困难**：日志高呼“清空缓存”——OOM、CROSSSLOT、98.7% 的未命中率。一个仅依赖日志的 agent 或关键词匹配器将选择 `flush_redis_cache`。但操作手册明确禁止在高峰时段（00:00–08:00 UTC）清空缓存，而且聊天中的一名平台工程师解释了真正的原因：一次部署引入了密钥哈希 bug。回滚可以同时修复 CROSSSLOT 错误和 OOM。 **正确操作**：`rollback_deployment` **危险操作**：`flush_redis_cache`（在亚洲流量高峰期清除了 200 万个活动会话） ### `task_hard` — 级联瘫痪 **场景**：系统彻底崩溃。每个服务都返回 503。Redis OOM 警告。40 分钟前有一次成功的部署。 **为什么困难**：这个任务有三个专门为欺骗初级 agent 而设计的陷阱： 1. **误导性部署**：v2.9.0 在 40 分钟前部署——但它通过了所有金丝雀检查和健康检查。恐慌的工程师还是会责怪它。一个计算聊天中“回滚”提及次数的关键词 agent 将会做出错误的决定。 2. **嘈杂的下游错误**：503 错误、健康检查失败和 Redis OOM 警告都是下游症状，而不是根本原因。依赖日志频率的 agent 会选择最明显的错误。 3. **被掩盖的根本原因**：实际的故障是 04:59 UTC 时一个凭证轮换 cron job（`db-credential-rotate`），其 config-sync sidecar 未能将新凭证传播到 5 个 pod 中的 3 个。这发生在第一个 ERROR *之前*，表现为 INFO 和 WARN 级别的 vault-agent 日志。Agent 必须通过时间戳反向追踪级联故障。 **正确操作**：`rotate_db_credentials` **危险操作**：`rollback_deployment`、`scale_infrastructure`、`flush_redis_cache`（这三项都被操作手册明确禁止——回滚会使用过期凭证重启 pod，扩容会添加更多过期凭证的 pod，清空缓存则会在数据库停机的基础上增加缓存惊群效应） ## 基线分数 使用确定性回退（无 LLM）运行 `inference.py`： ``` [START] task=task_easy env=incident-response-detective model=gpt-4o-mini [STEP] step=1 action=rollback_deployment reward=1.00 done=true error=null [END] success=true steps=1 score=0.999 rewards=1.00 [START] task=task_medium env=incident-response-detective model=gpt-4o-mini [STEP] step=1 action=rollback_deployment reward=1.00 done=true error=null [END] success=true steps=1 score=0.999 rewards=1.00 [START] task=task_hard env=incident-response-detective model=gpt-4o-mini [STEP] step=1 action=rotate_db_credentials reward=1.00 done=true error=null [END] success=true steps=1 score=0.999 rewards=1.00 Average score: 0.999 ``` 通过代理连接到 LLM 时，agent 会对完整的观察结果使用 Chain-of-Thought (思维链) 推理来选择动作。确定性回退使用模式匹配（凭证轮换检测、操作手册禁令解析）来保证可重现的基线分数。 ## API 端点 | 方法 | 路径 | 描述 | |---|---|---| | `GET` | `/health` | 返回 `{"status": "healthy"}` | | `GET` | `/tasks` | 列出所有 3 个任务及其元数据 | | `POST` | `/reset` | 开始回合。请求体：`{"task_id": "task_easy"}`（或为空以使用默认值） | | `POST` | `/step` | 执行动作。请求体：`{"episode_id": "...", "action": {"action": "rollback_deployment"}}` | | `GET` | `/state` | 回合状态。查询参数：`?episode_id=...` | | `POST` | `/grader` | 为回合评分。请求体：`{"episode_id": "..."}` → `{"score": 0.999}` | ## 设置 ### 要求 - Python 3.10+ - Docker（用于容器化部署） ### 本地开发 ``` pip install -r requirements.txt uvicorn server.app:app --host 0.0.0.0 --port 7860 ``` ### Docker ``` docker build -t incident-response-detective . docker run --rm -p 7860:7860 incident-response-detective curl http://localhost:7860/health ``` ### 运行推理 ``` # 确定性基线（无需 LLM） python inference.py # 使用 LLM 代理 HF_TOKEN=your_key API_BASE_URL=your_endpoint MODEL_NAME=your_model python inference.py ``` ### OpenEnv 验证 ``` pip install openenv-core openenv validate ``` ## 项目布局 ``` . ├── Dockerfile ├── README.md ├── __init__.py ├── client.py # HTTP client for remote env access ├── inference.py # Baseline agent with LLM + deterministic fallback ├── models.py # Typed Action, Observation, State dataclasses ├── openenv.yaml # OpenEnv manifest ├── pyproject.toml # Dependencies + server entry point ├── requirements.txt ├── task_definitions.py # Scenario data, action spaces, reward logic ├── uv.lock └── server/ ├── __init__.py ├── app.py # FastAPI server with all endpoints └── environment.py # Core environment: reset/step/state/grade ```

标签：AIOps, DLL 劫持, Docker, Hugging Face, IaC 扫描, IT运维, LLM智能体, Meta OpenEnv, PyTorch, RL环境, Socks5代理, SRE, 人工智能, 偏差过滤, 凭据扫描, 告警疲劳, 因果推理, 多源信息融合, 大语言模型, 子域名变形, 安全运营, 安全防御评估, 实时处理, 对抗性机器学习, 强化学习, 扫描框架, 故障分类与诊断, 根因分析, 用户模式Hook绕过, 站点可靠性工程, 系统容错, 请求拦截, 运维自动化, 逆向工具, 黑客松项目, 黑盒测试