TheAllanB/sre-incident-response

title: SRE 事件响应 emoji: 🚨 colorFrom: red colorTo: yellow sdk: docker pinned: false tags: - openenv - sre - incident-response - reinforcement-learning # SRE 事件响应环境 一个符合 OpenEnv 标准的环境，模拟现实世界的 SRE 值班事件分诊。AI 智能体 接收来自故障系统的生产环境告警、服务指标和日志，必须诊断 根本原因并应用正确的修复措施。 ## 环境描述 该环境向智能体展示一个处于降级状态的生产系统。在每一步， 智能体接收一个观测（活跃告警、服务健康状况、近期日志、SLO 状态）并且必须 选择一个操作来调查或补救该事件。当智能体解决事件、耗尽步数预算或升级时，该回合结束。 每个场景都包含现实中的噪声——虚假告警、看似健康的罪魁祸首和 误导性指标——要求智能体仔细推理，而不是对表面信号进行模式匹配。 ## 任务 | ID | 难度 | 最大步数 | 描述 | |----|-----------|-----------|-------------| | `single_service_crash` | 简单 | 10 | `payment-api` 因 OOMKilled 而终止。日志清晰显示了原因。查询日志 → 重启服务。 | | `cascading_failure` | 中等 | 15 | `order-service` 停机，因为其依赖项 `inventory-api` 在一次错误部署后发生故障。必须先修复根本原因，然后重启依赖服务。 | | `silent_data_corruption` | 困难 | 20 | `reporting-service` 看起来健康，但由于错误的配置标志写入了损坏的输出。下游 `analytics-service` 的日志揭示了该问题。干扰项：`cache-service` 延迟激增。 | | `db_connection_pool_exhaustion` | 中偏难 | 15 | `postgres-db` 连接池已饱和（500/500）。根本原因：`worker-service` v2.1.1 引入了连接泄漏。该 Worker 在 CPU/内存指标下显示健康。干扰项：`cache-service` 内存告警。 | | `tls_certificate_expiry` | 困难 | 20 | 91% 的用户请求失败，但 `api-gateway` 报告健康（内部 HTTP 检查通过，外部 HTTPS 失败）。TLS 证书已过期。干扰项：最近的一次后端部署。 | ## 基准智能体结果 通过 Groq 使用 `llama-3.1-8b-instant` 进行测试（兼容 OpenAI 的 API）： | 任务 | 得分 | 步数 | 结果 | |------|-------|-------|--------| | `single_service_crash` | 1.000 | 2 | ✓ | | `cascading_failure` | 1.000 | 6 | ✓ | | `silent_data_corruption` | 0.000 | 15 | ✗ | | `db_connection_pool_exhaustion` | 0.750 | 7 | ✗ | | `tls_certificate_expiry` | 0.850 | 5 | ✓ | | **平均值** | **0.720** | | **3/5 个任务** | 两个较难的任务需要多跳推理（将上游配置变更识别为根本原因，以及跨服务边界关联连接泄漏）—— 这些能力在使用更大的模型时会显著提升。 ## 观测空间 ``` { "step": 3, "done": false, "episode_id": "uuid", "alerts": [ {"id": "alert-001", "service": "payment-api", "severity": "P1", "message": "...", "firing": true} ], "services": [ {"name": "payment-api", "health": "down", "cpu_pct": 0.0, "memory_pct": 100.0, "error_rate": 1.0} ], "recent_logs": [ {"timestamp": "2026-04-06T03:11:33Z", "service": "payment-api", "level": "FATAL", "message": "OOMKilled"} ], "last_action_result": "Retrieved 5 log entries for payment-api.", "slo_status": [ { "service": "payment-api", "slo_target_pct": 99.95, "current_availability_pct": 0.0, "error_budget_remaining_pct": 31.2, "breach_estimated_minutes": 94 } ] } ``` `recent_logs` 在 `query_logs` 之后填充。`last_action_result` 包含所有其他操作类型的文本响应。`slo_status` 传达真实的 SRE 紧迫性——`breach_estimated_minutes` 表示季度错误预算消耗前剩余的时间。 ## 动作空间 ``` { "action_type": "query_logs | query_metrics | inspect_dependencies | restart_service | rollback_deploy | apply_fix | silence_alert | escalate", "target_service": "service-name", "parameters": {} } ``` | 动作 | 参数 | 效果 | |--------|-----------|--------| | `query_logs` | — | 使用服务的日志条目填充 `recent_logs` | | `query_metrics` | `window_minutes: int`（默认 60） | 返回指标；使用 ≥120 以揭示缓慢积累的问题 | | `inspect_dependencies` | — | 返回完整的服务依赖关系图 | | `restart_service` | — | 重启服务（用于 OOMKill / 进程崩溃） | | `rollback_deploy` | — | 回滚最近的部署（当部署导致故障时使用） | | `apply_fix` | `fix_id: str` | 应用在日志或扩展指标中找到的命名配置修复 | | `silence_alert` | — | 屏蔽服务的告警 | | `escalate` | — | 立即结束该回合 | ## 奖励函数 | 条件 | 奖励 | |-----------|--------| | 正确的终止动作解决了根本原因 | +1.0 | | 首次修复之前的调查动作 | +0.1 | | 针对错误的服务进行修复 | −0.2 | | 重复相同的动作 | −0.1 | | 重复调用 `inspect_dependencies` | −0.1 | | 未尝试任何修复即升级 | −0.3 | | 无效的服务名称 | −0.1 | | 所有其他有效步骤 | 0.0 | 所有奖励都被限制在 `[-1.0, 1.0]` 范围内。最终的回合得分限制在 `[0.0, 1.0]` 范围内。 成功阈值：得分 ≥ 0.8。 ## 设计亮点 - **每个场景都有干扰项** — P3 告警、看似健康的罪魁祸首和事后部署迫使智能体根据证据而不是启发式规则进行推理。 - **扩展指标** — 使用 `window_minutes=120` 的 `query_metrics` 揭示了在短时间窗口中不可见的趋势（TLS 证书过期时间戳、连接泄漏增长曲线）。基于配置的事件的 `fix_id` 只能通过扩展指标分析发现。 - **SLO 紧迫性** — 每个观测都包含剩余的错误预算和预计违规时间，奖励在预算危急时优先考虑速度的智能体。 - **部分评分评分器** — 得分反映调查质量，而不仅仅是最终动作。 找到了正确服务但应用了错误修复的智能体比随机猜测的智能体得分更高。 - **级联故障顺序** — 评分器强制执行正确的修复顺序：在重启受影响服务之前修复依赖项。 ## API 参考 | 方法 | 路径 | 用途 | |--------|------|---------| | GET | `/health` | 存活检查 — 返回 `{"status": "ok"}` | | GET | `/tasks` | 列出所有可用任务 | | POST | `/reset` | 开始回合：`{"task_id": "single_service_crash"}` | | POST | `/step` | 执行动作，返回 `{observation, reward, done, info}` | | POST | `/grader` | 直接对操作历史进行评分，无需运行回合 | | GET | `/state` | 原始回合状态，包括真实情况（调试用） | | GET | `/schema` | Action、Observation 和 Reward 的 JSON 模式 | | GET | `/docs` | 交互式 Swagger UI | ### `/grader` 用法 ``` curl -X POST /grader \ -H "Content-Type: application/json" \ -d '{ "task_id": "single_service_crash", "action_history": [ {"action_type": "query_logs", "target_service": "payment-api", "parameters": {}, "step": 1}, {"action_type": "restart_service", "target_service": "payment-api", "parameters": {}, "step": 2} ] }' # → {"task_id": "single_service_crash", "score": 1.0, "success": true} ``` ## 设置 ### 本地 ``` pip install -r requirements.txt cp .env.example .env # add your LLM API key uvicorn app.main:app --host 0.0.0.0 --port 7860 --reload ``` ### Docker ``` docker build -t sre-env . docker run -p 7860:7860 --env-file .env sre-env ``` ### 环境变量 | 变量 | 必需 | 描述 | |----------|----------|-------------| | `API_BASE_URL` | 是 | LLM API 端点（例如 `https://api.groq.com/openai/v1`） | | `MODEL_NAME` | 是 | 模型标识符（例如 `llama-3.3-70b-versatile`） | | `HF_TOKEN` | 是 | LLM 提供商的 API 密钥 | | `OPENAI_API_KEY` | 可选 | OpenAI 密钥（如果设置，优先于 HF_TOKEN） | | `DB_PATH` | 可选 | SQLite 文件路径（默认：`./sre_env.db`） | | `ENV_BASE_URL` | 可选 | inference.py 的环境服务器 URL（默认：`http://localhost:7860`） | ## 运行基准智能体 在服务器运行于端口 7860 的情况下： ``` python inference.py ``` 智能体运行所有 5 个任务并打印结构化日志： ``` [START] task=single_service_crash env=sre-incident-response model=llama-3.1-8b-instant [STEP] step=1 action=query_logs('payment-api') reward=0.10 done=false error=null [STEP] step=2 action=restart_service('payment-api') reward=1.00 done=true error=null [END] success=true steps=2 score=1.000 rewards=0.10,1.00 [START] task=cascading_failure env=sre-incident-response model=llama-3.1-8b-instant ... [END] success=true steps=6 score=1.000 rewards=0.10,0.10,0.10,0.10,0.00,1.00 [START] task=tls_certificate_expiry env=sre-incident-response model=llama-3.1-8b-instant ... [END] success=true steps=5 score=0.850 rewards=0.10,0.10,0.10,0.10,1.00 ``` 该基准使用带有 OpenAI 客户端的工具调用（兼容任何 OpenAI 规范的提供商）。

标签：AIOps, Apex, Docker, OOM, OpenEnv, Petitpotam, SLO, SRE, TLS证书过期, 事故处理, 人工智能, 代理支持, 仿真, 偏差过滤, 告警, 安全防御评估, 工作流自动化, 强化学习, 指标监控, 故障响应, 故障诊断, 数据库连接池, 数据损坏, 智能运维, 服务等级目标, 机器学习, 根因分析, 模拟环境, 用户模式Hook绕过, 站点可靠性工程, 级联故障, 自动修复, 请求拦截, 运维, 逆向工具