GhostRiderGaming/incident-response-env

## title: Meta OpenEnv 事件响应 emoji: 🚨 colorFrom: red colorTo: gray sdk: docker app_port: 8000 # 🚨 IncidentResponseEnv — 生产环境事件响应 RL 环境 一个符合 [OpenEnv](https://github.com/meta-pytorch/OpenEnv) 标准的强化学习环境，其中 AI 代理扮演 **值班站点可靠性工程师 (SREs)**，在模拟的微服务基础设施中诊断并修复生产环境中断。 ## 为什么选择事件响应？ 每家科技公司都实行值班轮换制度。工程师经常在凌晨 3 点被叫醒，以诊断跨越数十个微服务的级联故障。该环境训练 AI 代理： - **按严重程度**（P0-P3）对警报进行分类（Triage） - 通过追踪依赖链**诊断根本原因** - 安全地、按正确的顺序**执行修复措施** - **避免情况恶化**（错误的修复措施将受到严厉惩罚） 这填补了 RL/代理领域的一个空白——目前还没有用于训练事件响应代理的标准化环境。 ## 模拟基础设施 ``` ┌──────────────────────────────────────────────┐ │ Production System (7 services) │ │ │ │ API Gateway ──→ Auth Service ──→ DB Service │ │ │ ↑ │ │ └──→ Order Service ──→ Payment Service │ │ │ │ │ ├──→ Notification Service │ │ └──→ Cache Service (Redis) │ └──────────────────────────────────────────────┘ ``` 每个服务都具有逼真的指标（CPU、内存、错误率、延迟），生成日志条目，并以逼真的方式发生故障（CPU 过载、内存泄漏、配置错误、磁盘已满、缓存损坏、网络分区）。 ## 动作空间（10 个工具） | 工具 | 参数 | 用途 | |------|-----------|---------| | `view_alerts` | `{}` | 查看所有活动警报 | | `check_service_health` | `{"service_name": "..."}` | 检查 CPU、内存、延迟、错误率 | | `view_service_logs` | `{"service_name": "...", "lines": 20}` | 读取最近的日志 | | `check_service_metrics` | `{"service_name": "...", "metric": "cpu_percent"}` | 时间序列数据 | | `view_dependency_map` | `{}` | 服务依赖图 | | `classify_alert` | `{"alert_id": "...", "severity": "P0"}` | 对警报严重程度进行分类 | | `identify_root_cause` | `{"service_name": "...", "failure_mode": "..."}` | 诊断根本原因 | | `execute_remediation` | `{"service_name": "...", "action": "restart_service"}` | 修复问题 | | `check_resolution` | `{}` | 检查进度 | | `submit_assessment` | `{}` | 结合 episode，获取最终得分 | ## 观察空间 每个观察包括： - `tool_result`：最后一次工具调用的结果（因工具而异） - `tool_name`：被调用的工具名称 - `error`：如果动作无效时的错误消息 - `progress`：已分类的警报、已发现的根本原因、已执行的修复措施 - `available_tools`：所有可用工具的列表 - `task_info`：当前任务名称、难度、最大步数 ## 任务（3 个难度级别） ### 任务 1：警报分类 - **场景**：数据库 CPU 过载 → 5 个警报 - **目标**：按严重程度（P0-P3）对每个警报进行分类 - **最大步数**：20 - **评分**：分类准确率 ### 任务 2：根因分析 - **场景**：由磁盘耗尽引起的级联故障 → 8 个警报，6 个服务受影响 - **目标**：对警报进行分类 并确定根因服务 + 故障模式 - **最大步数**：30 - **评分**：30% 分类 + 40% 根因 + 30% 受影响服务 ### 任务 3：完整事件响应 - **场景**：双重根因（缓存内存泄漏 + 支付配置错误）→ 12 个警报 - **目标**：对警报进行分类、诊断两个根本原因、按正确顺序执行修复措施 - **最大步数**：45 - **评分**：25% 分类 + 25% 根因 + 25% 修复措施 + 25% 顺序 ## 奖励函数 奖励是**增量式**的（非稀疏），为每个动作提供反馈： | 动作 | 奖励 | |--------|--------| | 正确的警报分类 | +1.0 | | 错误的警报分类 | -0.3 | | 正确的根因 | +3.0 | | 错误的根因 | -1.0 | | 正确的修复措施 | +2.0 | | 正确的修复顺序 | +1.0 额外奖励 | | 错误的修复措施 | -1.5 | | 无效动作 | -0.5 | | 每步成本 | -0.01 | | 终端奖励 | +5.0 × final_score | ## 设置说明 ### 前置条件 - Python 3.10-3.12 - Docker（用于容器化部署） - `openenv-core` 包 ### 本地开发 ``` # Clone 并 cd cd incident_response_env # Install dependencies pip install -e . # 运行 server uvicorn server.app:app --host 0.0.0.0 --port 8000 # 打开 web interface # ENABLE_WEB_INTERFACE=true uvicorn server.app:app --host 0.0.0.0 --port 8000 # 访问 http://localhost:8000/web ``` ### Docker ``` docker build -t incident-response-env . docker run -p 8000:8000 incident-response-env ``` ### 验证 ``` openenv validate . openenv validate --url http://localhost:8000 ``` ### 运行推理 ``` export HF_TOKEN=your_token export API_BASE_URL=https://router.huggingface.co/v1 export MODEL_NAME=Qwen/Qwen2.5-72B-Instruct python inference.py ``` ## 基线性能 | 任务 | 难度 | 基线得分 | 步数 | |------|-----------|---------------|-------| | 警报分类 | Easy | ~0.60-0.80 | 12-18 | | 根因分析 | Medium | ~0.40-0.60 | 20-28 | | 完整事件响应 | Hard | ~0.20-0.40 | 30-45 | *基线得分使用 Qwen2.5-72B-Instruct 测量* ## 技术细节 - **框架**：OpenEnv (openenv-core 0.2.3) - **服务器**：FastAPI + Uvicorn - **模型**：Pydantic v2 用于类型安全的 action/observation - **评分**：完全确定性的、可复现的 - **许可证**：BSD-3-Clause

标签：AIOps, Docker, NIDS, OpenEnv, RL环境, SRE, 事件管理, 人工智能, 偏差过滤, 告警分级, 基础设施模拟, 安全防御评估, 容器化, 强化学习, 性能监控, 故障响应, 智能运维, 根因分析, 环境仿真, 生产环境, 用户模式Hook绕过, 站点可靠性工程, 系统诊断, 自动修复, 请求拦截, 运维, 逆向工具, 靶机