pratik0620/incident-response-triage-openenv

GitHub: pratik0620/incident-response-triage-openenv

这是一个基于OpenEnv的强化学习环境,通过模拟真实微服务生产事故,训练AI智能体利用日志、指标和告警进行根因分析与故障修复。

Stars: 1 | Forks: 0

title: Incident Response Triage Env emoji: 🚨 colorFrom: red colorTo: yellow sdk: docker pinned: false app_port: 7860 tags: - openenv - incident-response - devops - sre - reinforcement-learning # Incident Response 响应分流环境 一个 [OpenEnv](https://github.com/meta-pytorch/OpenEnv) 强化学习环境,供 AI 智能体诊断现实世界中的生产事故。智能体从模拟的微服务系统中读取日志、指标和告警,必须识别根本原因、提出修复方案,并在步数预算内高效完成。 为 **Meta × SST OpenEnv Hackathon 2026** 构建。 ## Environment 概览 现实中的 SRE 团队通过阅读日志和指标、形成假设并提出补救措施来响应生产事故。本环境模拟了涵盖三个难度级别的 15 个真实事故场景的完整工作流。 每个回合都会向智能体呈现一个实时事故:级联服务故障、充满噪声的告警以及旨在误导的干扰服务。智能体必须梳理证据,识别真正的根本原因并提出具体的修复方案——所有这些都必须在有限的步数预算内完成。 ## Agent-Environment 交互 每个回合遵循智能体与环境之间的结构化交互循环: 1. **Reset** → 环境返回初始观察(日志、指标、告警) 2. **Act** → 智能体选择一个动作(例如,`read_logs`、`check_metrics`、`identify_cause`、`propose_fix`、`escalate`) 3. **Observe** → 环境返回更新后的观察(日志、指标、告警)+ 奖励 4. **Repeat** → 直到执行终止动作或达到步数预算 ![Agent Environment Interaction](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/3209d8cec8175032.png) ## 为什么该环境是现实的 本环境反映了 SRE 团队使用的现实世界事故响应工作流: - **Multi-signal debugging** — 智能体必须关联日志、指标和告警,而不是依赖单一来源 - **Cascading failures** — 问题在服务之间传播,需要进行依赖追踪 - **Noise and red herrings** — 并非所有告警都相关,迫使进行选择性推理 - **Action cost trade-offs** — 过度的调查会降低分数,模拟生产事故中的时间压力 - **Fix quality matters** — 不仅仅是识别问题,还要提出正确且完整的补救措施 与合成基准不同,本环境奖励 **因果推理、证据支撑和决策效率**。 ## 动作空间 | Action | Type | Cost | Description | |---|---|---|---| | `read_logs` | Investigative | -0.02/step | 获取当前场景的带时间戳的日志条目 | | `check_metrics` | Investigative | -0.02/step | 获取每个服务的 CPU、内存、错误率和 p99 延迟 | | `identify_cause` | Terminal | — | 声明根本原因服务和故障类型。结束回合。 | | `propose_fix` | Terminal | — | 声明根本原因并提出完整的修复方案。结束回合。 | | `escalate` | Terminal | — | 当无法诊断时移交处理。返回固定的 0.2 奖励。 | **Action schema:** ``` { "action_type": "identify_cause", "reasoning": "The logs show connection pool exhausted on postgres-primary...", "answer": "db_connection_pool_exhaustion", "service": "postgres-primary" } ``` ## 观测空间 每一步返回一个 `IncidentResponseTriageObservation`,包含: | Field | Type | Description | |---|---|---| | `logs` | `list[LogEntry]` | 带时间戳的日志条目(服务、级别、消息) | | `metrics` | `list[MetricSnapshot]` | 每个服务的 CPU%、内存%、错误率、p99 延迟 | | `alerts` | `list[Alert]` | 触发的告警,包含严重性(P1–P4)和消息 | | `step` | `int` | 当前步数 | | `max_steps` | `int` | 该难度的步数预算 | | `previous_actions` | `list[str]` | 已采取的动作类型历史 | | `task_description` | `str` | 事故的纯英文描述 | | `reward` | `float` | 当前步的奖励 | | `done` | `bool` | 回合是否结束 | | `final_score` | `float \| None` | 最终 0.0–1.0 分数(当 done=True 时设置) | ## 任务 | Difficulty | Scenarios | max_steps | Description | |---|---|---|---| | **Easy** | 5 | 10 | 单个服务故障,具有清晰的日志信号且无干扰项。智能体应在 2–4 步内完成诊断。 | | **Medium** | 5 | 15 | 跨 2–3 个服务的级联故障,包含 1 个干扰服务。智能体必须追踪依赖链。 | | **Hard** | 5 | 20 | 嘈杂的多服务日志,包含 2 个以上干扰项以及混合的偶发/真实故障。智能体除了识别根本原因外,还必须对故障类型进行分类(real, flaky, env_specific)。 | ### 简单场景示例 ### 困难场景示例 ## 奖励函数 分数由一个具有难度加权信号的 6 信号确定性评分器计算得出: | Signal | Easy | Medium | Hard | Description | |---|---|---|---|---| | **A** Root cause | 0.35 | 0.25 | 0.15 | 识别出正确的服务和故障类型 | | **B** Fix quality | 0.30 | 0.20 | 0.15 | 分级:重启 (0.3) → 功能修复 (0.7) → 修复 + 预防 (1.0) | | **C** Reasoning | 0.10 | 0.25 | 0.30 | 因果链质量:日志 → 原因 → 结果 | | **D** Faithfulness | 0.10 | 0.15 | 0.20 | 推理基于实际的日志内容,而非幻觉 | | **E** Noise handling | 0.10 | 0.10 | 0.15 | 正确忽略干扰服务 | | **F** Efficiency | 0.05 | 0.05 | 0.05 | 步数预算使用情况(非线性:≤25% 预算 → 1.0,≤50% → 0.8,...) | **加权求和后应用的调整规则:** - 如果根本原因分数 < 0.3 → 总分 × 0.5(正确的修复但错误的诊断 = 运气) - 如果修复质量分数 − 推理分数 > 0.5 → −0.15(高修复 + 低推理 = 照搬答案) - 如果噪声分数 < 0.3 → −0.10(过度猜测惩罚) ## 设置 **Requirements:** Python 3.10+, Docker ``` git clone https://github.com/pratik0620/incident-response-triage-openenv cd incident-response-triage-openenv pip install -e ".[dev]" ``` **Start the server locally:** ``` uvicorn server.app:app --host 0.0.0.0 --port 8000 ``` **Run inference API (HF-compatible):** ``` export HF_TOKEN=your_token export API_BASE_URL=https://router.huggingface.co/v1 export MODEL_NAME=Qwen/Qwen2.5-7B-Instruct export ENV_BASE_URL=http://localhost:8000 uvicorn inference:app --host 0.0.0.0 --port 7860 ``` **Run baseline inference:** ``` export HF_TOKEN=your_token export API_BASE_URL=https://router.huggingface.co/v1 export MODEL_NAME=Qwen/Qwen2.5-7B-Instruct export ENV_BASE_URL=https://pratik234567-incident-response-triage-env.hf.space python inference.py ``` **Run via Docker:** ``` docker build -t incident-response-env:local . docker run -p 7860:7860 incident-response-env:local ``` **Test Endpoints:** ``` curl http://localhost:7860/health curl http://localhost:7860/grade/task_easy curl http://localhost:7860/grade/task_medium curl http://localhost:7860/grade/task_hard ``` ## 基准分数 通过 HuggingFace router 使用 `Qwen/Qwen2.5-7B-Instruct` 进行评估。 | Difficulty | Final Score | Steps | Success | |---|-------------|---|------| | Easy | 0.88 | 3 | true | | Medium | 0.69 | 3 | true | | Hard | 0.56 | 3 | true | ## 来自 Baseline Agent 的观察 在评估过程中,我们观察到当满足以下条件时,智能体性能会显著提升: - **答案字段包含显式的因果推理**,而不仅仅是标签 - 智能体使用诸如 *"日志显示"*、*"由于"* 和 *"导致"* 之类的短语来形成清晰的因果链 - **明确提及服务名称和故障类型** - 在中等和困难任务中,使用 `propose_fix` 而不是 `identify_cause` 可以解锁额外的奖励信号 - 答案基于 **日志和指标证据**,提高了忠实度分数 这些观察结果表明,该环境奖励 **结构化推理、证据支撑和决策效率**,而非简短或隐含的答案。 ## Environment API ``` from incident_response_triage_env.client import IncidentResponseTriageEnv from incident_response_triage_env.models import IncidentResponseTriageAction async with IncidentResponseTriageEnv(base_url="https://huggingface.co/spaces/pratik234567/incident-response-triage-env") as env: result = await env.reset(difficulty="easy") obs = result.observation action = IncidentResponseTriageAction( action_type="identify_cause", reasoning="Logs show connection pool exhausted on postgres-primary", answer="db_connection_pool_exhaustion", ) result = await env.step(action) print(result.observation.final_score) # 0.0–1.0 ``` ## 项目结构 ``` incident_response_triage_env/ ├── inference.py # Baseline inference script ├── models.py # Pydantic Action, Observation, State models ├── client.py # EnvClient (WebSocket) ├── openenv.yaml # Environment manifest ├── Dockerfile # Container definition ├── graders/ │ ├── composite_grader.py # Master grader — routes to sub-graders │ ├── signals.py # 6 independent scoring signals (A–F) │ ├── weights.py # Difficulty-based weight tables │ └── synonyms.py # Cause type synonym and fix tier maps ├── scenarios/ │ ├── easy/ # 5 easy incident scenarios │ ├── medium/ # 5 medium incident scenarios │ └── hard/ # 5 hard incident scenarios └── server/ ├── app.py # FastAPI application └── incident_response_triage_env_environment.py # Environment logic ``` ## 作者 - **Pratik Morkar** - **Nishant Ninawe** - **Surabhi Nikam** Built with [OpenEnv](https://github.com/meta-pytorch/OpenEnv) · [HuggingFace](https://huggingface.co) · [Meta PyTorch](https://github.com/meta-pytorch)
标签:AIOps, Apex, Docker, Docker容器, OpenEnv, PyTorch, SRE, 事故分类, 人工智能代理, 仿真环境, 偏差过滤, 告警管理, 安全防御评估, 库, 应急响应, 强化学习, 性能监控, 指标监控, 攻击面发现, 故障诊断, 智能运维, 机器学习, 根因分析, 站点可靠性工程, 系统调试, 级联故障, 网络安全, 请求拦截, 运维自动化, 逆向工具, 隐私保护, 黑客松项目