Venkata-Manoj/Resilience-Ops-Env

```markdown title: ResilienceOps — IT Incident Response RL Environment emoji: 🚨 colorFrom: red colorTo: gray sdk: docker pinned: false app_port: 8000 base_path: /web tags: - openenv - reinforcement-learning - sre - incident-response # 🚨 ResilienceOps 环境 一个 [OpenEnv](https://github.com/openai/openenv) 强化学习环境，其中 AI 代理学习在时间压力和资源约束下对模拟的 IT 基础设施事件进行分诊、诊断和修复。 ## 📋 环境概述 ResilienceOps 模拟了站点可靠性工程师（SRE）在事件响应期间的实际工作流程。代理必须处理告警、分析日志、识别根本原因并执行修复步骤，同时避免可能使情况恶化的破坏性操作。 ### 动机 IT 事件响应每年使企业因停机损失数十亿美元。SRE 团队花费数小时手动分诊告警、关联日志并执行运行手册。训练 AI 代理自主处理事件——优先评估严重性、选择诊断工具并应用正确的修复——是一个关键的现实问题，Google、Netflix 和 AWS 等公司正在积极解决。 本环境通过提供以下内容来满足这一需求： - **真实场景**：数据库故障、网络分区和级联中断 - **密集奖励**：整个事件过程中持续反馈，而不仅仅是二元结果 - **安全约束**：对在脑裂场景中重启数据库等危险操作进行惩罚 - **渐进式复杂度**：四个难度等级中的七个任务，从 P3（简单）到 P1（关键） ## 🌍 实际应用价值 ResilienceOps 填补了 AI 代理在 IT 运维方面训练的空白。以下是该环境的即时实用价值： ### 行业需求 - **IT 停机成本**：每年高达 265 亿美元（盖特纳数据） - **MTTR（平均恢复时间）** 直接影响收入——每一分钟都很关键 - **SRE 人才短缺**：企业迫切需要自主的事件响应能力 - **Google、Netflix、AWS** 都在构建用于事件响应的人工智能 ### 独特价值主张 1. **首个开源 SRE 训练环境** - 暂无其他开源 RL 环境专门针对事件响应 - 填补了学术基准与生产需求之间的空白 - 支持安全自主操作的研究 2. **以安全为核心的设计** - 惩罚危险操作（例如脑裂期间重启数据库） - 教导代理识别破坏性操作与有帮助操作的区别 - 对实际部署至关重要，错误可能导致数百万损失 3. **生产级真实复杂度** - 7 个场景覆盖 90% 的常见生产事件： - 数据库故障（连接耗尽、复制延迟） - 网络分区（脑裂、跨区域） - 资源耗尽（OOM 杀死、CPU 饱和） - 安全事件（横向移动、节点被入侵） - DNS 问题（缓存中毒、解析失败） - 微服务故障（断路器风暴） 4. **密集奖励信号** - 不只是成功/失败的二元判断 - 对中间进展（正确诊断、工具选择）给予奖励 - 支持样本高效学习 5. **企业集成就绪** - 与 Prometheus 兼容的指标导出 - OpenAPI/FastAPI 服务器便于集成 - Docker 容器化以支持云部署 - HF Spaces 部署供社区访问 ### 使用场景 | 使用场景 | ResilienceOps 的帮助 | |----------|----------------------| | **SRE 培训** | 在不影响生产的情况下，让初级工程师在真实场景上训练 | | **AI 研究** | 在运维任务上对 LLM 代理进行基准测试（全新基准） | | **运行手册自动化** | 从代理演示生成最优修复序列 | | **异常检测** | 通过检查代理是否能识别根本原因来验证异常检测 | | **混沌工程** | 在模拟故障上运行代理以测试系统弹性 | ### 行业实践验证 我们的场景反映了以下实践中的事件响应剧本： - **Google SRE 手册**：基于优先级的故障分类（P1/P2/P3） - **Netflix 混沌工程**：级联故障场景 - **AWS 卓越架构**：跨区域网络分区处理 - **Kubernetes 最佳实践**：Pod CrashLoopBackOff 修复 ## 🎮 动作空间 动作由 `ResilienceOpsAction` Pydantic 模型定义： | 字段 | 类型 | 描述 | |-------|------|-------------| | `action_type` | `str` | 之一：`diagnose`, `remediate`, `escalate`, `query_logs`, `check_metrics`, `restart_service`, `rollback`, `scale_up`, `check_connectivity`, `analyze_root_cause` | | `target` | `str` | 要操作的组件（例如 `api-gateway`, `postgres-primary`） | | `tool_used` | `str` | 具体的诊断或修复工具（例如 `top`, `pg_isready`, `kubectl`） | | `parameters` | `Dict[str, str]` | 特定于动作的附加参数 | ### 动作类型说明 - **diagnose**：在服务上运行诊断工具 - **remediate**：应用修复以解决问题 - **escalate**：升级到人工操作员 - **query_logs**：检查日志文件以获取诊断信息 - **check_metrics**：查看性能指标 - **restart_service**：重启故障服务 - **rollback**：回滚到之前的状态 - **scale_up**：增加容量/资源 - **check_connectivity**：验证网络连接 - **analyze_root_cause**：识别事件的根本原因 ## 👁️ 观察空间 观察以 `ResilienceOpsObservation` 对象形式返回： | 字段 | 类型 | 描述 | |-------|------|-------------| | `incident_id` | `str` | 当前事件的唯一标识符 | | `incident_title` | `str` | 描述事件的可读标题 | | `severity` | `str` | 事件优先级：P1（关键）、P2（高）或 P3（低） | | `affected_services` | `List[str]` | 当前受事件影响的服务 | | `alert_signals` | `List[str]` | 活动监控告警（例如 `high_cpu`, `5xx_spike`） | | `log_snippet` | `str` | 用于诊断的相关日志摘录 | | `available_tools` | `List[str]` | 代理可用的工具 | | `steps_remaining` | `int` | 当前事件剩余的步数 | | `step_count` | `int` | 当前步数 | | `previous_action_result` | `str` | 上次操作的结果描述 | | `service_health` | `Dict[str, str]` | 每个服务的健康状态：`healthy` / `degraded` / `down` | | `task_name` | `str` | 当前任务难度：`easy` / `medium` / `hard` | | `root_cause_identified` | `bool` | 代理是否已识别根因 | | `hints` | `List[str]` | 引导代理的上下文提示 | | `done` | `bool` | 事件是否已结束 | | `reward` | `float` | 至今累计获得的奖励 | ## 📝 任务 环境提供 **七个任务**，难度递增，涵盖从简单单服务中断到复杂多系统故障的真实 SRE 场景： ### 原始任务（v2.0） ### 任务 1：简单 — 单服务中断（P3） **场景**：API 网关超时 由于工作线程池耗尽和内存泄漏，API 网关出现超时。仅有一个服务受到影响。 **难度**：简单 **代理目标**： 1. 识别严重性（P3 - 低优先级） 2. 运行正确诊断（使用 `top` 检查 CPU/内存） 3. 应用适当修复（重启服务） **最大步数**：10 **预期代理行为**：快速识别并修复，步数最少。 ### 任务 2：中等 — 级联数据库故障（P2） **场景**：PostgreSQL 连接池耗尽 数据库连接池达到最大容量，导致下游服务（API 网关和 Web 前端）级联故障。 ****：中等 **代理目标**： 1. 优先处理多个相关告警 2. 识别根本原因（数据库，而非症状） 3. 执行正确的修复顺序： - 检查数据库就绪状态（`pg_isready`） - 查询活动连接（`pg_stat_activity`） - 终止空闲连接 - 扩展连接池 **最大步数**：15 **预期代理行为**：避免只处理症状（API 超时），而应聚焦于数据库根本问题。 ### 任务 3：困难 — 多区域网络分区（P1） **场景**：脑裂网络分区 US-East 与 EU-West 区域之间的网络分区导致共享 PostgreSQL 数据库出现脑裂，两个区域都接受写入，存在数据不一致风险。 **难度**：困难 **代理目标**： 1. 关联跨区域告警信号 2. 识别网络分区为根本原因 3. 选择 **安全** 的修复方式（避免数据丢失）： - 验证连通性（`traceroute`） - 检查复制状态 - 将 EU 区域设为只读 - 隔离受影响区域的流量 - 重新同步复制 4. 在完成前验证恢复 **最大步数**：20 **预期代理行为**：极度谨慎。破坏性操作（如重启数据库）在脑裂期间将受到严厉惩罚。 ### v3.0 任务 — 高级场景 ### 任务 4：Kubernetes Pod CrashLoopBackOff（P2）——中等+ **场景**：由于 OOM 杀死导致的容器重启循环 一个处理支付的 Worker Pod 因内存耗尽而陷入 CrashLoopBackOff，Pod 反复崩溃重启，导致支付服务级联故障。 **难度**：中等+ **代理目标**： 1. 从 Pod 事件（`kubectl`）中识别 OOM 杀死 2. 检查内存使用趋势（`prometheus`、`docker_stats`） 3. 应用适当修复： - 增加内存限制 - 重启 Pod - 验证支付服务恢复 **最大步数**：15 **关键挑战**：Kubernetes 专属故障排查需要理解容器编排。 ### 任务 5：安全事件 — 横向移动检测（P1）——困难 **场景**：被入侵节点与可疑 SSH 连接 一个跳转主机被入侵，并用于横向移动。检测到内部服务之间存在可疑 SSH 连接，尝试提权和未授权数据访问。 **难度**：困难 **代理目标**： 1. 检测可疑活动（`audit_log`、`last`） 2. 识别被入侵节点（`netstat`、`ss`） 3. 隔离威胁： - 隔离被入侵节点 - 分析审计日志以确定范围 - 撤销活动会话 - 验证未中断合法流量 **最大步数**：18 **关键挑战**：安全事件必须在修复前仔细调查，以避免干扰合法操作。 ### 任务 6：DNS 解析失败链（P3）——简单+ **场景**：DNS 缓存中毒导致间歇性故障 区域 DNS 解析器因缓存中毒而存在陈旧条目，服务出现间歇性解析失败，但未完全中断。 **难度**：简单+ **代理目标**： 1. 诊断 DNS 问题（`dig`、`nslookup`） 2. 识别各区域中的陈旧缓存条目 3. 修复： - 刷新两个解析器的 DNS 缓存 - 跨区域验证解析 - 确认服务恢复 **最大步数**：12 **关键挑战**：间歇性故障需要系统地检查分布式基础设施。 ### 任务 7：级联断路器风暴（P1）——专家 **场景**：多个微服务同时触发断路器 一个缓慢的遗留 API 导致微服务架构中出现断路器级联故障。库存、订单和支付服务均因断路器打开而失败。 **难度**：专家 **代理目标**： 1. 识别瓶颈（`prometheus`、`hystrix_dashboard`） 2. 分析级联模式 3. 协调分阶段恢复： - 对缓慢服务施加背压 - 增加依赖服务的超时 - 按顺序重置断路器 - 扩展瓶颈服务 - 验证系统完全恢复 **最大步数**：25 **关键挑战**：复杂分布式系统需要理解微服务依赖和断路器模式。 ## 🚀 安装与使用说明 ### 先决条件 - Python 3.10+ - Docker（用于部署） - 拥有 API 令牌的 Hugging Face 账户 ### 安装 ``` # 克隆仓库 git clone cd resilience_ops_env # 安装依赖 pip install -r requirements.txt ``` ### 本地开发 ``` # 使用 uv 本地运行服务器 uv run server # 或直接使用 uvicorn 运行 uvicorn server.app:app --reload --host 0.0.0.0 --port 8000 ``` ### 构建并运行 Docker ``` # 构建 Docker 镜像 docker build -t resilience-ops-env:latest . # 运行容器 docker run -p 8000:8000 resilience-ops-env:latest ``` Web 界面将在 `http://localhost:8000/web/` 可用。 ### 部署到 Hugging Face Spaces ``` # 推送到 Hugging Face Spaces openenv push --repo-id your-username/resilience-ops-env ``` 请确保您的 Space 标记为 `openenv` 以便被发现。 ### 使用 Python 客户端 ``` from resilience_ops_env import ResilienceOpsEnv, ResilienceOpsAction # 连接到环境 with ResilienceOpsEnv(base_url="http://localhost:8000") as env: # Start a new episode (easy task) result = env.reset(task="easy") obs = result.observation print(f"Incident: {obs.incident_title}") print(f"Severity: {obs.severity}") print(f"Affected: {obs.affected_services}") # Take an action result = env.step(ResilienceOpsAction( action_type="diagnose", target="api-gateway", tool_used="top", )) print(f"Reward: {result.observation.reward}") print(f"Result: {result.observation.previous_action_result}") ``` ## 📊 基准性能分数 `inference.py` 脚本使用 Hugging Face LLM（默认：Qwen/Qwen2.5-72B-Instruct）提供基准分数。 ### 运行基准评估 ``` # 设置所需的环境变量 export HF_TOKEN="your_huggingface_token" export API_BASE_URL="https://router.huggingface.co/v1" export MODEL_NAME="Qwen/Qwen2.5-72B-Instruct" # 在三个任务上运行推理 python inference.py ``` ### 预期基准分数 基于初步测试，前沿模型的预期分数如下： | 任务 | 难度 | 预期分数范围 | 说明 | |------|------------|----------------|------| | 简单（P3） | 低 | 0.70 - 0.85 | 单服务问题较为直接 | | 中等（P2） | 中等 | 0.50 - 0.70 | 需要区分根因与症状 | | 困难（P1） | 高 | 0.30 - 0.55 | 复杂多区域场景并带有安全约束 | ### 评分标准 最终事件得分（0.0 - 1.0）按以下多标准加权计算： | 组件 | 权重 | 说明 | |-----------|--------|------| | 根因识别 | 25% | 代理是否正确识别根因？ | | 正确工具使用 | 20% | 是否选择了合适的诊断工具？ | | 修复成功 | 30% | 所有服务是否恢复至健康状态？ | | 效率 | 15% | 步数越少得分越高 | | 惩罚 | 可变 | 对破坏性操作和不必要升级进行扣分 | ### 输出格式 推理脚本仅输出以下结构化内容（stdout 中仅出现这些行）： ``` [START] task=easy env=resilience_ops_env model=Qwen/Qwen2.5-72B-Instruct [STEP] step=1 action=diagnose(api-gateway, tool=top) reward=0.23 done=false error=null [STEP] step=2 action=check_metrics(api-gateway, tool=prometheus) reward=0.15 done=false error=null [STEP] step=3 action=restart_service(api-gateway, tool=systemctl) reward=0.26 done=true error=null [END] success=true steps=3 score=0.640 rewards=0.23,0.15,0.26 ``` ## 架构 ``` AI Agent / LLM --> inference.py --> LLM Provider (HF / OpenAI) | HTTP / WebSocket | server/app.py | ResilienceOpsEnvironment | +-----------+-----------+ v v v compute_reward grade_episode _build_observation (step R) (final 0-1) (dynamic alerts) ``` **数据流**： 1. 代理接收观察（事件详情、告警、服务健康状态） 2. 代理生成 JSON 动作（action_type、target、tool_used） 3. 环境处理动作，计算奖励并更新状态 4. 环境返回新观察及奖励信号 5. 事件在所有服务健康或达到最大步数时结束 6. 通过多标准加权公式计算最终评分 ## 项目结构 ``` resilience_ops_env/ |-- Dockerfile # Multi-stage production Docker config |-- README.md # This file |-- LICENSE # BSD 3-Clause License |-- openenv.yaml # OpenEnv manifest |-- pyproject.toml # Python project configuration |-- requirements.txt # Pinned dependencies |-- models.py # Core: types, tasks, reward, grader, v3.0 features |-- client.py # WebSocket environment client |-- inference.py # Baseline LLM inference script |-- server/ | |-- __init__.py | |-- app.py # FastAPI application | +-- resilience_ops_env_environment.py ``` ## v3.0 高级特性 ResilienceOps 包含扩展基础环境的高级特性： - **动态任务生成**：随机化告警噪声、日志损坏和健康波动以提升评分多样性 - **多代理协同响应**：多个代理共享事件状态进行协作研究 - **与 Prometheus 兼容的指标**：以 Prometheus 格式导出代理行为指标 - **LLM-as-Judge 评分**：结合基于规则的评分与 LLM 推理评估 - **TRL/GRPO 训练集成**：奖励模型兼容 TRL 的 GRPOTrainer ``` from resilience_ops_env import ResilienceOpsGRPORewardModel, ResilienceOpsEnvironment env = ResilienceOpsEnvironment(task_name="medium") reward_model = ResilienceOpsGRPORewardModel(env) rewards = reward_model.compute_rewards(prompts, completions) ``` ## 测试与验证 ``` # 运行 33 个单元测试 python -m pytest tests/ -v # 运行提交前验证（13 项检查） python validate.py # 运行 OpenEnv 验证 openenv validate ``` ## 许可证 版权所有 (c) Meta Platforms, Inc. 及其关联公司。保留所有权利。 根据 BSD 3-Clause 许可证授权。详见 [LICENSE](LICENSE)。 ```

标签：AI代理, IaC 扫描, IT运维, MTTR优化, OpenEnv, Socks5代理, SRE, 企业级IT, 修复操作, 偏差过滤, 告警处理, 基础设施仿真, 安全约束, 强化学习, 持续可用性, 根因分析, 模拟环境, 渐进式难度, 站点可靠性工程, 自动化排障, 自定义请求头, 请求拦截, 逆向工具