rajasurya-rjs/incident-response-openenv

title: 事件响应环境 emoji: 🚨 colorFrom: red colorTo: yellow sdk: docker app_port: 7860 tags: - openenv # 事件响应 / 值班排查环境 一个模拟**真实世界 SRE 事件响应**的 OpenEnv 环境。AI 代理接收跨 6 个服务的微服务架构的基础设施告警，通过检查指标和阅读日志进行调查，诊断根本原因，并采取正确的修复措施。 ## 为什么需要这个环境？ 每家科技公司都有值班工程师，他们会在凌晨 3 点收到故障报警。他们必须迅速： 1. **调查** — 检查指标，阅读多个服务的日志 2. **诊断** — 识别根本原因（可能与告警服务不同） 3. **修复** — 重启服务，回滚部署，扩容或清理磁盘 这是一个真正未解决的问题 —— 现有的 RL 环境都没有针对事件响应训练代理。这个环境通过现实场景、级联故障、误导信息和确定性评分填补了这一空白。 ## 动作空间 ``` class IncidentResponseAction(Action): command: str # What to do (see below) target: str # Which service to act on parameters: dict # Extra params (e.g., explanation for diagnose) ``` ### 可用命令 | 命令 | 类型 | 描述 | |---------|------|-------------| | `check_metrics` | 调查 | 查看服务的 CPU、内存、磁盘、错误率、延迟 | | `read_logs` | 调查 | 阅读近期的应用和系统日志 | | `check_status` | 调查 | 检查健康状态、运行时间、部署历史 | | `restart_service` | 修复 | 重启服务 | | `scale_service` | 修复 | 扩容服务副本 | | `rollback_deploy` | 修复 | 回滚到上一个部署版本 | | `clear_disk` | 修复 | 清理磁盘空间（WAL 段文件、临时文件） | | `diagnose` | 分析 | 提交根本原因分析（自由文本解释） | | `escalate` | 升级 | 升级给高级工程师（部分得分） | ### 可用服务 | 服务 | 角色 | |---------|------| | `api-gateway` | 路由传入的 HTTP 流量 | | `user-service` | 处理身份验证和用户配置 | | `order-service` | 处理订单和支付 | | `postgres-primary` | 主 PostgreSQL 数据库 | | `redis-cache` | 缓存层（会话、配置） | | `kafka-broker` | 用于异步处理的消息队列 | ## 观察空间 ``` class IncidentResponseObservation(Observation): alert_summary: str # Current alert text command_output: str # Result of the last command available_commands: List[str] # Valid commands available_services: List[str] # Valid service targets services_investigated: List[str]# Services already checked actions_taken: List[str] # Action history time_elapsed_minutes: int # Simulated time since alert severity: str # info/warning/critical/resolved # Inherited: done, reward ``` ## 任务 ### 任务 1: `disk_full` (简单) **告警**: postgres-primary 上的磁盘使用率达到 97% **根本原因**: WAL 段文件未归档，临时表膨胀 **预期**: 在 postgres 上检查指标/日志，然后清理磁盘。约 3 步。 ### 任务 2: `bad_deploy` (中等) **告警**: api-gateway 上的错误率达到 8% **根本原因**: order-service 上的错误部署导致级联 502 错误 **预期**: 从 api-gateway → order-service 追踪错误，然后回滚。约 5 步。 **挑战**: postgres-primary 看起来有问题（连接数过多），但这只是症状。 ### 任务 3: `memory_and_cache` (困难) **告警**: api-gateway 上的 p99 延迟达到 2300ms **根本原因**: 两个并发问题 —— user-service 内存泄漏 以及 redis-cache 提供陈旧数据（TTL 被禁用，99.5% 命中率具有误导性） **预期**: 找出两个根本原因，重启两个服务。约 8 步。 **挑战**: Redis 看起来健康（高命中率）但数据已陈旧 72 小时以上。代理必须推理“99.5% 命中率 + 无 TTL”的实际含义。 ### 任务 4: `kafka_lag` (中偏难) **告警**: kafka-broker 上的消费者延迟达到 10 万条消息 **根本原因**: 维护期间消费者被缩容，未恢复。流量激增 3 倍。 **预期**: 识别扩容问题，扩容 order-service。约 5 步。 ## 评分 每个任务使用确定性加权综合评分，范围 0.0 到 1.0： | 组件 | 权重 | 衡量内容 | |-----------|--------|-----------------| | 调查 | 30% | 代理是否检查了正确的服务？ | | 诊断 | 25% | 代理是否识别了根本原因？（关键词匹配） | | 修复 | 30% | 代理是否采取了正确的修复措施？ | | 效率 | 15% | 采取的步骤与最优步骤对比（越少越好） | ### 奖励塑形（每步） - 调查相关服务：**+0.05** - 执行关键检查：**+0.10** - 正确的诊断关键词：**+0.20**（按比例） - 正确的修复措施：**+0.25** - 错误的修复措施：**-0.10** - 每步时间成本：**-0.005** ## 设置与使用 ### 快速开始（远程） ``` from incident_response_env import IncidentResponseEnv, IncidentResponseAction with IncidentResponseEnv(base_url="https://.hf.space").sync() as env: result = env.reset(task_id="disk_full") print(result.observation.alert_summary) result = env.step(IncidentResponseAction( command="check_metrics", target="postgres-primary", )) print(result.observation.command_output) ``` ### 本地开发 ``` # 克隆并安装 git clone cd incident_response_env pip install -e . # 运行 server uvicorn incident_response_env.server.app:app --host 0.0.0.0 --port 8000 # 或使用 entry point python -m incident_response_env.server.app ``` ### Docker ``` docker build -t incident-response-env . docker run -d -p 8000:8000 incident-response-env # 验证 curl http://localhost:8000/health ``` ### 推理（基线） ``` # 先启动 server，然后： API_BASE_URL=https://router.huggingface.co/v1 \ MODEL_NAME=meta-llama/Llama-3.1-8B-Instruct \ HF_TOKEN=hf_... \ python inference.py # 必需的 environment variables： # API_BASE_URL LLM 的 API endpoint # MODEL_NAME 用于 inference 的 model identifier # HF_TOKEN 你的 Hugging Face / API key ``` ## 基线分数 近似分数（temperature=0）： | 任务 | 难度 | 分数 | |------|-----------|-------| | `disk_full` | 简单 | ~0.75 | | `bad_deploy` | 中等 | ~0.85 | | `memory_and_cache` | 困难 | ~0.60 | | `kafka_lag` | 中偏难 | ~0.80 | | **平均** | | **~0.75** | *分数为近似值，不同运行之间可能略有差异。* ## API 端点 | 端点 | 方法 | 描述 | |----------|--------|-------------| | `/health` | GET | 健康检查 | | `/metadata` | GET | 环境元数据 | | `/schema` | GET | 动作/观察/状态模式 | | `/reset` | POST | 重置环境（接受 `task_id`） | | `/step` | POST | 执行动作 | | `/state` | GET | 获取当前回合状态 | | `/ws` | WebSocket | 持久会话端点 | | `/docs` | GET | 交互式 API 文档 |

标签：AIOps, AI智能体, Docker, On-Call轮值, OpenEnv, SRE, 偏差过滤, 安全防御评估, 弹性伸缩, 强化学习环境, 微服务架构, 指标监控, 故障演练, 故障诊断, 根因分析, 模块化设计, 生产事故, 站点可靠性工程, 系统恢复, 自动化修复, 请求拦截, 运维培训, 逆向工具