aman-source/incident-env
GitHub: aman-source/incident-env
一个用于训练和评估 AI 智能体在生产环境中进行事件响应分诊的模拟环境，让智能体扮演值班 SRE 在时间压力下诊断和修复微服务故障。
Stars: 0 | Forks: 0
## 标题: IncidentEnv
emoji: 🚨
colorFrom: red
colorTo: yellow
sdk: docker
pinned: false
app_port: 7860
# IncidentEnv -- 事件响应分诊环境
一个 **OpenEnv 兼容环境**，用于模拟生产环境的事件响应，以训练和评估 AI 智能体。智能体扮演值班 SRE 工程师的角色：接收告警、调查微服务架构中的日志和指标、通过依赖图谱追踪故障、诊断根本原因并执行纠正措施——所有这一切都在现实的时间压力和级联系统降级的情况下进行。IncidentEnv 具有一种新颖的多维奖励函数，结合了时间衰减评分、级联故障惩罚、调查效率跟踪和感知爆炸半径的附带损害评分，产生的评估信号能够敏锐地区分复杂的推理与暴力探索。
为 **Scaler x Meta x Hugging Face OpenEnv 黑客马拉松**（印度版，70K+ 参与者）构建。
## 为什么选择事件响应？
事件响应是软件工程中认知要求最高的任务之一——也是 Meta、Hugging Face 以及每家主要科技公司的每位工程师在值班轮换期间都要执行的任务。尽管它对生产可靠性至关重要，但 **OpenEnv 生态系统中不存在事件响应环境**。IncidentEnv 填补了这一空白。
此环境评估的技能正是定义专家 SRE 工作的那些技能：
- **日志分析** —— 从包含现实时间戳、堆栈跟踪和交错条目的冗长、嘈杂的生产日志中提取信号
- **依赖追踪** —— 通过相互关联的服务追踪故障链，其中症状距离根本原因有多个跃点
- **时间关联** —— 跨时间链接事件（部署、配置更改、错误发生窗口）以识别因果关系
- **排除干扰项** —— 忽略与根本原因无关的误导性信号（排队导致的 CPU 升高、不相关的警告日志、表面性的配置更改）
- **在不确定情况下采取果断行动** —— 在存在多种选项时选择正确的纠正措施，每种措施具有不同的影响范围
- **升级判断** —— 知道何时呼叫人类团队以及以何种优先级进行
奖励设计确实新颖。与二元的通过/失败评分器不同，IncidentEnv 通过五个正交维度对智能体进行评分，并结合时间压力衰减、级联故障状态变化和防止幸运猜测的最低调查门槛。这创造了前沿模型感到真正具有挑战性的评估信号——即使是 70B 参数模型在困难任务上也只能得分 0.72。
## 任务
| 任务 | ID | 难度 | 服务数 | 最大步数 | 时间预算 | 测试内容 |
|------|----|------------|----------|-----------|-------------|---------------|
| 单服务 OOM 崩溃 | `easy_oom` | 简单 | 5 | 15 | 100s | 日志读取、单跳诊断、基本纠正措施 |
| 级联 DB 连接池耗尽 | `medium_db_pool` | 中等 | 9 | 15 | 100s | 多跳依赖追踪、排除干扰项、连接池推理 |
| 间歇性金丝雀部署 + OAuth 提供商故障 | `hard_canary` | 困难 | 15 | 15 | 100s | 时间关联、间歇性错误分析、金丝雀识别、多层干扰项 |
### 任务 1：简单 —— 单服务 OOM 崩溃
**场景**：`user-service` 返回 HTTP 503 错误。日志清楚地显示带有堆栈跟踪的 `java.lang.OutOfMemoryError: Java heap space` 条目，指向 `InMemoryStore.put()`。内存指标确认利用率为 98%。两小时前部署的 v2.4.1 引入了一个内存密集型内存缓存层，但没有调整堆限制。
**智能体必须做什么**：
1. 调查 `user-service` 日志 —— 观察堆耗尽的 OOM 错误
2. 调查 `user-service` 指标 —— 确认内存为 98%，与部署关联
3. 调查 `user-service` 部署 —— 确定 v2.4.1 为触发变更
4. 诊断：“由内存密集型部署 v2.4.1 引起的 OOM”
5. 行动：将 user-service `rollback` 到以前的版本
**为何简单**：具有一个服务的单一因果链。根本原因距离告警只有一跳。日志明确指出了错误。没有干扰项。此任务验证智能体可以读取日志、与部署历史记录关联并采取基本的纠正措施。
### 任务 2：中等 —— 级联 DB 连接池耗尽
**场景**：`payment-service` 在事务处理上超时。但根本原因在两跳之外：`user-service` 在其用户查找路径中存在未关闭的数据库连接，导致连接池泄漏。这耗尽了共享的 `database` 连接池，进而导致 `payment-service`（也依赖于数据库）在事务提交上失败。
**干扰项**：
- 昨天的 `payment-service` 部署 (v3.1.0) —— 看起来可疑但无关
- 基础设施日志中的 DNS 解析短暂故障 —— 已自动解决，无影响
- `api-gateway` 延迟升高 —— 下游故障的后果，而非原因
**智能体必须做什么**：从 payment-service 症状追踪到数据库连接耗尽，再到作为泄漏源的 user-service。至少需要 4 次调查才能建立因果链。智能体必须抵制责怪 payment-service 最近部署的诱惑，转而遵循连接池证据找到 user-service。
**为何中等**：根本原因距离呈现的症状有 2 跳。多个服务显示降级。两个不同的干扰项争夺智能体的注意力。需要理解连接池机制和依赖排序。
### 任务 3：困难 —— 间歇性金丝雀部署伴随 OAuth 提供商故障
**场景**：多个服务中间歇性出现 HTTP 5xx 错误（约 10% 的请求），没有明显的模式。根本原因：`auth-service` v2.1.0-canary 的金丝雀部署引入了一个 claims-validator 错误，该错误仅在处理来自 OAuth provider-B 的令牌时失败（provider-A 令牌工作正常）。由于只有金丝雀 Pod 受到影响，且只有 provider-B 令牌触发该错误，因此错误稀疏且间歇性。
**干扰项**（4 层）：
- `recommendation-service` CPU 峰值 —— 合法但无关的批处理
- `config-service` 最近的更新 —— 例行配置轮换，无功能影响
- `database` 慢查询日志 —— 偶尔的长运行分析查询，预先存在
- 基础设施中的证书更新活动 —— 已成功完成，无错误
**为何困难**：
- **间歇性信号**：第一次日志检查显示大部分是干净的输出 —— 30+ 个成功请求中只有 2 行隐藏的错误行。任何给定检查中错误仅出现约 30% 的时间。
- **15 个服务**：搜索空间大，有许多潜在嫌疑对象
- **金丝雀特殊性**：必须确定只有金丝雀 Pod（而非完整部署）是问题所在
- **提供商关联**：必须在稀疏的错误消息中注意到 provider-B 模式
- **时间压力**：100 秒预算，最多 15 步，意味着每次调查都必须有价值
## 基准测试结果
在所有三个任务中运行基线智能体的得分：
| 模型 | 简单 | 中等 | 困难 | 平均 |
|-------|------|--------|------|---------|
| **Llama 3.3 70B Instruct** | 0.95 | 0.76 | 0.72 | **0.81** |
| **Llama 4 Scout 17B** | 0.96 | 0.70 | 0.20 | **0.62** |
| **Llama 3.1 8B Instruct** | 0.86 | 0.70 | 0.53 | **0.70** |
**主要观察结果**：
- 简单任务可以被所有模型尺寸可靠地解决，验证了它是一个合理的基线。
- 中等任务显示约 0.70-0.76 的一致性能，差异来自调查效率和时间因子。
- 困难任务**真正挑战了所有模型**。即使是 Llama 3.3 70B 也只能得分 0.72，而 Scout 17B 降至 0.20 —— 在时间关联和间歇性错误模式方面挣扎。值得注意的是，8B 在困难任务上优于 Scout 17B（0.53 对 0.20），表明该任务测试的是推理深度而非原始参数数量。
- 简单和困难分数之间的差距（70B 为 0.95 到 0.72，Scout 为 0.96 到 0.20）展示了有意义的难度递进。
## 动作空间
所有动作都以具有四个字段的 JSON 对象提交：
```
{
"action_type": "",
"target": "",
"command": "",
"parameters": {}
}
```
### `investigate` —— 查询系统信息
| 命令 | 描述 | 示例 |
|---------|-------------|---------|
| `logs` | 查看服务的近期日志条目 | `{"action_type": "investigate", "target": "auth-service", "command": "logs"}` |
| `metrics` | 查看当前性能指标 | `{"action_type": "investigate", "target": "database", "command": "metrics"}` |
| `deployments` | 查看最近的部署历史 | `{"action_type": "investigate", "target": "payment-service", "command": "deployments"}` |
| `dependencies` | 查看上游/下游服务映射 | `{"action_type": "investigate", "target": "api-gateway", "command": "dependencies"}` |
| `config` | 查看当前服务配置 | `{"action_type": "investigate", "target": "cache", "command": "config"}` |
| `overview` | 系统范围的健康摘要 | `{"action_type": "investigate", "target": "system", "command": "overview"}` |
| `recent_changes` | 所有服务的最近变更 | `{"action_type": "investigate", "target": "system", "command": "recent_changes"}` |
### `diagnose` —— 提交根本原因诊断
```
{
"action_type": "diagnose",
"target": "auth-service",
"command": "Claims-validator bug in v2.1.0-canary causing provider-B OAuth token failures"
}
```
`target` 标识智能体认为是根本原因的服务。`command` 字段包含自由文本诊断。评分器使用针对预期根本原因的关键词匹配来对诊断准确性进行评分。
### `act` —— 采取纠正措施
| 命令 | 描述 | 何时使用 |
|---------|-------------|-------------|
| `restart` | 重启服务 | OOM、挂起的进程 |
| `rollback` | 回滚到以前的版本 | 错误的部署 |
| `scale_up` | 添加更多实例 | 资源耗尽 |
| `scale_down` | 移除实例 | 过度配置 |
| `flush_cache` | 清除服务缓存 | 陈旧/损坏的缓存 |
| `drain_connections` | 排空并重置连接池 | 连接池耗尽 |
| `kill_canary` | 终止金丝雀部署 | 错误的金丝雀发布 |
```
{
"action_type": "act",
"target": "auth-service",
"command": "kill_canary",
"parameters": {}
}
```
### `escalate` —— 呼叫人类团队
| 团队 | 处理内容 |
|------|---------|
| `backend` | 应用程序级别的问题 |
| `infrastructure` | 基础设施、网络、DNS |
| `database` | 数据库性能、复制、连接池 |
| `security` | 认证失败、可疑活动 |
| `management` | 面向客户的升级 |
```
{
"action_type": "escalate",
"target": "database",
"command": "page",
"parameters": {"priority": "p1"}
}
```
优先级：`p1`（严重，立即响应），`p2`（高，15 分钟内），`p3`（中，1 小时内）。
## 观察空间
每次调用 `reset()` 或 `step()` 都会返回一个具有以下字段的观察结果：
| 字段 | 类型 | 描述 |
|-------|------|-------------|
| `message` | `str` | 当前状态或动作结果的可读描述 |
| `alert_summary` | `dict` | 当前告警详情：`service`、`symptom`、`severity`、`triggered_at` |
| `system_status` | `dict` | 服务名称到 `{health, latency_ms, error_rate_5xx, cpu_pct, memory_pct}` 的映射 |
| `investigation_result` | `str` | 最近调查的详细输出（日志、指标、部署历史） |
| `available_actions` | `list[str]` | 当前状态下的有效动作类型 |
| `action_result` | `str` | 最近纠正措施的结果（如果有） |
| `time_elapsed` | `int` | Episode 中已消耗的模拟秒数 |
| `time_budget` | `int` | 此任务的最大模拟秒数 |
| `hint` | `str` | 可选提示（在简单任务的早期步骤中提供） |
| `done` | `bool` | Episode 是否已结束 |
| `reward` | `float` | 步骤级奖励信号 |
| `metadata` | `dict` | 附加上下文：`scenario_id`、`task_id`、`cascade_events`、`steps_taken` |
### 示例观察结果（调查日志后）
标签：AIOps, BurpSuite集成, DLL 劫持, Docker, HuggingFace, Meta, OpenEnv, Petitpotam, Scaler, SRE, 人工智能体, 代码推理, 仿真环境, 依赖追踪, 偏差过滤, 分布式系统, 响应大小分析, 大语言模型, 安全防御评估, 微服务架构, 故障诊断, 时间压力模拟, 智能运维, 根因分析, 站点可靠性工程, 系统稳定性, 级联故障, 训练环境, 请求拦截, 运维演练, 运维自动化, 逆向工具, 黑客松