m-zest/incident-response-openenv

## 标题: SRE 事件响应模拟器 emoji: 🚨 colorFrom: red colorTo: gray sdk: docker pinned: false ## 问题背景 当生产系统在凌晨 3 点宕机时，站点可靠性工程师（SRE）必须对警报进行分类、追踪依赖链、区分真实故障和干扰信息，并在时间压力下修复系统。当今的 AI 智能体可以编写代码和回答问题，但它们能应对级联数据库故障吗？能识别伪装成内存泄漏的加密货币挖矿攻击吗？能处理两个数据库节点都声称自己是主节点的脑裂分区吗？ 本环境正是为了测试这些能力。 ## 架构 ### 两种模式，同一评分 环境以两种模式运行，评估人员可以通过**仪表板切换**进行比较： | | 模拟模式 | 混合真实模式 | |---|---|---| | **运行方式** | 本地，inference.py，无需 Docker | Docker 内 / HF Space 内运行 | | **日志** | 从场景 JSON 预构建 | 后台工作进程写入的真实文件 | | **指标** | 硬编码的 CPU/内存/磁盘 | 实时 Redis INFO、SQLite 查询、磁盘统计 | | **进程** | 场景定义的虚假 PID | 通过 psutil 获取的真实 PID + 场景 PID | | **混沌注入** | 不适用 | 真实故障：Redis 洪水、数据库锁、CPU 耗尽 | | **评分** | 确定性公式 | **相同的确定性公式** | 评分器追踪**行为，而非文本**。它统计调查了哪些服务、是否应用了正确的修复方案、是否识别了根本原因。两种模式评分完全相同。 **为什么混合真实模式重要：** 评估真实世界实用性（占 30% 权重）的人员可以看到真实的基础设施，而非模板。智能体看到的是生产级真实的输出和干扰信息——这与真实 SRE 面临的挑战相同。 ## 基线：人类 vs AI | 等级 | AI（Nemotron 120B）| 人类 SRE | 差距 | 场景数 | |------|:---:|:---:|:---:|:---:| | **简单** | 0.80 | 0.90 | 0.10 | 5 | | **中等** | 0.57 | 0.80 | 0.23 | 4 | | **困难** | 0.28 | 0.70 | 0.42 | 3 | | **专家** | 0.09 | 0.74 | 0.65 | 2 | 所有 14 个场景都是可解的。人类 SRE 在 9 步内完成专家级脑裂场景，得分 0.74。120B 模型在相同场景上仅得分 0.09。 **差距存在的原因：** - **简单** — 单个警报，修复方案显而易见。AI 可以处理。 - **中等** — 需要多服务关联。AI 在高效追踪依赖链方面存在困难。 - **困难** — 安全 ambiguity。AI 无法区分加密货币挖矿和内存泄漏，也无法区分 DDoS 和流量峰值。需要使用 `check_process_list` 来发现伪装成其他进程恶意软件。 - **专家** — 跨分区系统进行取证调查，且工具在情节中期被撤销。AI 陷入调查循环而无法收敛。 ## 场景 ### 简单（5 个场景，最多 10 步） 具有清晰诊断路径的单一服务故障。 | 场景 | 根本原因 | 关键命令 | |----------|-----------|-------------| | 日志服务器磁盘满 | /var/log 达 98%，轮转停止 | check_logs → restart_service | | 工作队列进程崩溃 | MemoryError，OOM 杀死 | check_logs → get_metrics → restart | | API Gateway 部署失败 | v3.2.1 中的 NullPointerException | check_logs → rollback_deploy | | 用户服务内存泄漏 | 堆内存攀升至 96% | get_metrics → restart_service | | TLS 证书过期 | 自动续期失败（ACME）| check_network → restart_service | ### 中等（4 个场景，最多 15 步） 具有级联故障的多服务关联。 | 场景 | 根本原因 | 挑战 | |----------|-----------|-----------| | 数据库连接池耗尽 | 慢查询 + 锁竞争 | 必须从用户服务错误追踪回主数据库 | | Redis 缓存驱逐风暴 | 内存压力 → 87% 未命中率 | 缓存故障级联至数据库过载 | | 消息队列积压 | 消费者崩溃 → 45K 待处理任务 | 必须区分队列深度和 worker 故障 | | 内部 DNS 解析失败 | 区域文件损坏 → SERVFAIL | 多个服务出现间歇性故障 | ### 困难（3 个场景，最多 20 步） 需要取证调查的安全/SRE ambiguity。 | 场景 | 根本原因 | AI 失败原因 | |----------|-----------|-------------| | 加密货币挖矿攻击 | 隐藏的 `xmrig` 进程伪装成 `[jvm-gc-thread-4]` | 看起来像内存泄漏。必须使用 `check_process_list` 发现恶意软件。`restart_service` 仅暂时有效——恶意软件会重新启动。 | | 级联配置故障 | 配置服务器错误轮转证书 | 配置服务器没有警报。必须将 3 个服务的 TLS 错误追踪回配置推送。 | | DDoS vs 流量峰值 | 僵尸网络的容量性 DDoS | 必须在日志中分析源 IP 多样性和地理分布，以区分合法的病毒式流量。 | ### 专家（2 个场景，最多 25 步） 具有工具撤销和分区系统的取证调查。 | 场景 | 根本原因 | AI 失败原因 | |----------|-----------|-------------| | 脑裂分区 | 两个数据库节点独立接受写入 | 必须比较主节点和副本节点的 WAL 位置。网络交换机是根本原因，而非数据库。重启数据库会使情况恶化。 | | 供应链攻击 | 受损的 npm 依赖正在泄露环境变量 | 后门跨越 3 个服务。安全锁定在情节中期撤销 `restart_service` 和 `scale_up`。必须仅使用 `kill_process` 和取证命令。 | ## 评分公式 ``` S = max(0, (H_final - H_initial) / (100 - H_initial) × ω − φ − ψ) ``` | 变量 | 描述 | |----------|-------------| | **ω** | 1.0 正确诊断 · 0.8 已修复但超时 · 0.6 已修复但诊断错误 · 0.3 两者都未做到 | | **φ** | 每超出最优步骤 0.02（最高 0.3）| | **ψ** | 每个破坏性动作 0.15 | **步骤奖励：** +0.08 调查根本原因服务，+0.25 正确修复，+0.30 正确诊断，−0.05 重启健康服务，−0.10 错误诊断。 ## 动作空间（17 个命令） | 命令 | 描述 | |---------|-------------| | `check_logs {service}` | 查看最近的日志条目（混合模式下为真实文件）| | `get_metrics {service}` | CPU、内存、磁盘、延迟、连接数（混合模式下为真实 Redis/SQLite 统计）| | `list_alerts` | 所有触发的警报，包括自动解决的干扰警报 | | `check_dependencies {service}` | 上游/下游服务依赖关系 | | `get_dependency_graph` | 完整依赖树，包含健康状态和 PageRank 影响 | | `trace_failure {service}` | 追踪上游依赖、下游爆炸半径、不健康路径 | | `restart_service {service | 重启服务（重量级服务需要 2 步）| | `scale_up {service}` | 增加副本数 | | `rollback_deploy {service}` | 回滚到上一版本 | | `kill_process {service}` | 按 PID 终止进程（需要先执行 `check_process_list`）| | `check_process_list {service}` | 运行中的进程（混合模式下为真实 PID，可检测伪装恶意软件）| | `check_network {service}` | 网络连接（可检测 C2 数据泄露）| | `add_note {text}` | 将观察保存到证据板 | | `view_notes` | 查看已保存的观察 | | `get_runbook` | 事件类型的标准操作程序 | | `get_dependency_graph` | 包含 PageRank 影响分析的 NetworkX 图 | | `submit_root_cause {description}` | 声明诊断结果（结束情节，触发评分）| ## 观察空间 ``` class SREObservation(BaseModel): output: str # Command result text alerts: List[Alert] # Active alerts with service, severity, message system_health: float # 0-100%, degrades over time step_count: int # Current step number max_steps: int # Step limit for this tier score: float # Running score 0.0-1.0 available_commands: List[str] # Commands (may change during security lockdowns) reward: float # Step reward signal done: bool # Episode complete ``` ## 主要特性 - **渐进式恶化** — 系统每步恶化（CPU +0.5，延迟 ×1.08，健康 −1.5/步），在第 4 步后级联到依赖服务 - **干扰警报** — 干扰警报（备份、GC、自动扩展）与真实警报一起出现，在 2-3 步后自动解决 - **混沌引擎** — 真实故障注入：Redis 内存洪水、SQLite 连接耗尽、CPU 耗尽进程、 divergent 副本数据库 - **工具撤销** — 专家场景在情节中期动态撤销命令（安全锁定） - **恶意软件重生** — `restart_service` 仅能暂时修复加密货币挖矿；恶意软件在 2 步后重新出现 - **证据板** — `add_note` / `view_notes` 用于跨步骤追踪假设 - **MCP 工具发现** — `GET /mcp/tools` 返回 JSON 模式，反映锁定状态 - **事后报告** — 结构化事件时间线，包含效率评分 - **种子可重现性** — `reset(seed=42)` 生成相同情节 - **仪表板** — 交互式 Web UI，包含服务依赖图、健康时间线图表和模式切换 - **演练** — 所有 4 个等级的优化分步解决方案在基线标签页中 - **TRL 集成** — `examples/train_with_trl.py` 展示 HuggingFace GRPOTrainer 设置 ## 快速开始 ### 使用 Docker 运行（混合真实模式） ``` docker build -t sre-env . docker run -p 7860:7860 sre-env # 打开 http://localhost:7860 ``` ### 从源码运行（模拟模式） ``` git clone https://github.com/m-zest/incident-response-openenv.git cd incident-response-openenv pip install -e ".[dev]" uvicorn incident_response_env.server.app:app --port 7860 ``` ### 运行基线推理 ``` export HF_TOKEN=your-api-key export API_BASE_URL=https://integrate.api.nvidia.com/v1 export MODEL_NAME=nvidia/nemotron-3-super-120b-a12b python inference.py ``` ### 运行测试 ``` pytest # 40 tests covering environment, API, grading, scenarios ``` ## API 端点 | 端点 | 方法 | 描述 | |----------|--------|-------------| | `/` | GET | 交互式仪表板 | | `/health` | GET | 健康检查 | | `/tasks` | GET | 任务列表，包含模式 | | `/baseline` | GET | 评分 + 优化演练 | | `/grader` | GET | 情节结束后的评分结果 | | `/postmortem` | GET | 结构化事件报告 | | `/state` | GET | 当前环境状态 | | `/env/state` | GET | 详细环境状态 | | `/mcp/tools` | GET | MCP 工具发现 | | `/reset` | POST | 开始情节：`{"task_id": "easy"}` | | `/step` | POST | 执行：`{"action": {"command": "...", "target": "...", "parameters": {}}}` | | `/web/reset` | POST | 仪表板重置 | | `/web/step` | POST | 仪表板步骤 | | `/web/hybrid-status` | GET | 真实服务检测状态 | ## 项目结构 ``` incident-response-openenv/ ├── incident_response_env/ │ ├── models.py # Pydantic Action/Observation/State │ ├── client.py # OpenEnv client │ ├── scenarios/ # 14 scenario definitions │ │ ├── easy.json (5) │ │ ├── medium.json (4) │ │ ├── hard.json (3) │ │ └── expert.json (2) │ ├── server/ │ │ ├── app.py # FastAPI + dashboard + all endpoints │ │ ├── environment.py # OpenEnv Environment (reset/step/state) │ │ ├── infrastructure.py # SimulatedCluster + hybrid enrichment │ │ └── grader.py # Deterministic scoring formula │ └── services/ # Hybrid-real infrastructure │ ├── setup_db.py # SQLite seed data (85K rows) │ ├── fake_worker.py # Background log writer │ ├── real_metrics.py # Redis/SQLite/psutil queries │ └── chaos_engine.py # Real failure injection ├── tests/ │ ├── test_environment.py # 25 environment tests │ └── test_api.py # 15 API integration tests ├── examples/ │ └── train_with_trl.py # HuggingFace TRL/GRPO training ├── inference.py # Baseline inference script ├── start.sh # Docker entrypoint (Redis + DB + worker) ├── Dockerfile ├── openenv.yaml └── requirements.txt ``` ## 作者 **Mohammad Zeeshan** AI 研究员

标签：AI训练环境, Docker, PB级数据处理, Python, Redis, SQLite, SRE, 偏差过滤, 内存泄漏, 分布式系统, 加密挖矿攻击, 告警处理, 响应大小分析, 基础设施, 子域名变形, 安全运维, 安全防御评估, 库, 应急响应, 强化学习, 搜索引擎查询, 故障排查, 故障注入, 数据库故障, 无后门, 混沌工程, 特权检测, 监控, 站点可靠性工程, 脑裂, 自定义DNS解析器, 请求拦截, 运维自动化, 逆向工具, 配置错误