rahulsheno/cloud-incident-response

## title: Cloud 事件响应 emoji: "☁️" colorFrom: blue colorTo: blue sdk: docker pinned: false license: mit # Cloud 事件响应 Cloud Incident Response 是一个与 OpenEnv 兼容的环境，其中代理扮演 Site Reliability Engineer (SRE) 的角色，诊断并解决模拟微服务集群中的生产事故。该环境提供日志、指标、追踪、告警、特性标志和爆炸半径上下文，然后评估代理是否识别了根本原因、应用了正确的补救措施以及是否高效解决了问题。 ## 包含内容 - 16 个综合事故场景，涵盖从运维诊断到高级系统推理 - 7 个基础生产场景 + 9 个高级分布式系统挑战 - 用于动作、观测、基础设施状态和回合结果的 Typed dataclass 模型 - 针对 `/reset`、`/step` 和 `/state` 的 FastAPI 端点，与 Gradio UI 一起挂载 - 具有可重现基准评分（范围在 `[0.0, 1.0]`）的确定性评分器 - 时间机制，包括指标漂移、服务降级和补救后效应 - 通过 `enable_hints=True` 实现的课程模式，用于渐进式训练 - 通过 `EpisodeRecorder` 实现的回合记录和事后导出 ## 场景概览 | 场景 | 类别 | 根本原因挑战 | 基准 | |---|---|---|---:| | `memory_leak` | 基础 | 导致 OOM 的应用版本回归 | `0.920` | | `db_connection_exhaustion` | 基础 | 负载峰值下的连接池限制 | `0.960` | | `silent_corruption` | 基础 | 伪装成健康指标的数据完整性降级 | `0.979` | | `thundering_herd` | 基础设施 | 触发缓存一致性丢失的基础设施故障 | `0.972` | | `byzantine_failure` | 基础 | 具有矛盾信号模式的应用 Bug | `0.981` | | `cascading_failure` | 基础设施 | 由单一根本原因引发的分布式系统级联 | `0.988` | | `fix_creates_regression` | 运维 | 需要多步补救序列的局部修复 | `0.978` | | `cloud_cost_spike` | 基础设施 | 编排系统中的不受控资源供给 | `0.965` | | `configuration_drift` | 运维 | 部署与运行时之间的配置状态分歧 | `0.955` | | `stale_cache_poisoning` | 应用 | 具有指标矛盾的缓存失效故障 | `0.970` | | `service_version_mismatch` | 应用 | 跨服务版本的 API 兼容性问题 | `0.950` | | `distributed_consensus_failure` | 分布式系统 | 需要强制领导权的状态机脑裂 | `0.945` | | `cascading_timeout_storm` | 分布式系统 | 通过重试循环的指数级故障传播 | `0.935` | | `recursive_deadlock_service_mesh` | 分布式系统 | 导致相互阻塞的循环服务依赖 | `0.910` | | `resource_leak_under_pattern` | 应用 | 由负载模式触发的资源耗尽 | `0.905` | | `adversarial_chaos_injection` | 运维 | 伪装成真实事故的合成故障 | `0.900` | ## 项目布局 ``` . |-- app.py |-- inference.py |-- openenv.yaml |-- run_baseline.py |-- env/ | |-- environment.py | |-- models.py | |-- recorder.py | `-- test_environment.py |-- graders/ | `-- graders.py `-- server/ `-- app.py ``` ## 快速开始 ``` pip install -r requirements.txt python env/test_environment.py python inference.py --all --json ``` 在本地运行 UI 和 HTTP server： ``` python app.py ``` FastAPI 接口暴露： - `POST /reset` - `POST /step` - `GET /state` - `GET /health` - `GET /tasks` ## 编程方式使用 ``` from env.environment import IncidentResponseEnv from env.models import Action, ActionType from graders.graders import grade_episode env = IncidentResponseEnv(task_id="memory_leak", seed=42) obs = env.reset() obs, reward, done, info = env.step( Action(ActionType.INSPECT_LOGS, target_service="payment-service") ) obs, reward, done, info = env.step( Action(ActionType.ROLLBACK_DEPLOYMENT, target_service="payment-service") ) obs, reward, done, info = env.step(Action(ActionType.RESOLVE_INCIDENT)) result = grade_episode(env.result()) print(result.final_score) ``` ## 推理提交 提交入口是仓库根目录下的 `inference.py`。 ``` python inference.py --all python inference.py --all --json python inference.py --task byzantine_failure --seed 42 ``` 推理客户端使用的环境变量： - `API_BASE_URL` — OpenAI 兼容的 LLM 端点 - `MODEL_NAME` — 用于推理的模型标识符 - `HF_TOKEN` — LLM 代理的 API token 如果这些变量未设置，脚本将回退到基于确定性规则的候选选择并成功完成。 ## 基准结果 使用 `python inference.py --all --json` 复现当前基准： **基础场景 (0.920–0.988):** - `memory_leak`: `0.920` - `db_connection_exhaustion`: `0.960` - `silent_corruption`: `0.979` - `thundering_herd`: `0.972` - `byzantine_failure`: `0.981` - `cascading_failure`: `0.988` - `fix_creates_regression`: `0.978` **运维场景 (0.955–0.970):** - `cloud_cost_spike`: `0.965` - `configuration_drift`: `0.955` - `stale_cache_poisoning`: `0.970` - `service_version_mismatch`: `0.950` **分布式系统场景 (0.900–0.945):** - `distributed_consensus_failure`: `0.945` - `cascading_timeout_storm`: `0.935` - `recursive_deadlock_service_mesh`: `0.910` - `resource_leak_under_pattern`: `0.905` - `adversarial_chaos_injection`: `0.900` **总体平均分: 0.9513 (95.13%)** ## 场景分类 ### 基础场景 这些场景测试核心 SRE 能力：从可观测性数据中识别根本原因并应用适当的补救措施。 - **memory_leak**: 应用版本回归检测与通过回滚进行的补救 - **db_connection_exhaustion**: 资源约束诊断与多步补救（扩容 + 配置） - **silent_corruption**: 被健康指标掩盖的数据质量问题；需要日志分析 - **thundering_herd**: 通过缓存一致性丢失级联的基础设施故障 - **byzantine_failure**: 具有矛盾信号模式的应用正确性故障 - **cascading_failure**: 单一根因向下游传播的分布式系统级联 - **fix_creates_regression**: 引入次要问题且需要完整序列的补救 ### 运维场景 这些场景测试运维意识和配置管理专业知识。 - **cloud_cost_spike**: 需要基础设施干预的不受控资源供给 - **configuration_drift**: 运行时部署的配置与预期状态发生分歧 - **stale_cache_poisoning**: 具有矛盾指标模式的缓存失效故障 - **service_version_mismatch**: 需要定向回滚的 API 兼容性问题 ### 分布式系统场景 这些场景测试关于复杂状态机、分布式系统中的因果关系以及模式识别的推理能力。 - **distributed_consensus_failure**: 需要领导选举的状态机脑裂 - **cascading_timeout_storm**: 通过重试放大的指数级故障 - **recursive_deadlock_service_mesh**: 具有相互阻塞的循环依赖 - **resource_leak_under_pattern**: 由负载模式触发且需要行为诊断的耗尽 - **adversarial_chaos_injection**: 通过检查区分合成故障与真实故障 ## 评估指标 每个场景的评分器将评分分解为透明的组件： - **诊断**: 对告警和降级服务的正确调查 - **补救**: 应用正确的修复动作 - **排序**: 按照正确的依赖顺序应用修复 - **效率**: 相对于场景 max_steps 的解决速度 - **惩罚**: 不必要的动作、错误的目标、信号误读 代理可以检查 `EpisodeResult.partial_scores` 以了解评分构成。 ## 训练进阶 场景组织用于渐进式训练： 1. 单服务诊断 (memory_leak, db_connection_exhaustion) 2. 数据完整性问题 (silent_corruption, stale_cache_poisoning) 3. 多服务协调 (cascading_failure, service_version_mismatch) 4. 基础设施关注点 (cloud_cost_spike, thundering_herd) 5. 配置管理 (configuration_drift, fix_creates_regression) 6. 分布式系统 (distributed_consensus_failure, cascading_timeout_storm) 7. 系统死锁 (recursive_deadlock_service_mesh) 8. 行为模式 (resource_leak_under_pattern, adversarial_chaos_injection) 9. 信号矛盾 (byzantine_failure) 启用 `enable_hints=True` 以进入带有渐进指导的课程模式。 ## 回合记录器 ``` from env.recorder import EpisodeRecorder recorder = EpisodeRecorder(env) obs = recorder.reset() while not obs.episode_done: obs, reward, done, info = recorder.step(your_agent(obs)) recorder.save_json("incident-report.json") recorder.save_markdown("incident-postmortem.md") ``` ## 时间机制 该环境模拟真实的事故动态： - **指标漂移**: 服务指标每一步都会随机变化，反映自然方差 - **服务降级**: 未解决的降级服务会随时间恶化 - **补救传播**: 修复需要多个步骤才能完全生效 - **次生效应**: 某些场景仅在初始补救后才会显现潜在问题 ## 设计原则 **信号真实性**: 可观测性数据结合了准确信号与现实的噪声、误导性信息和部分信息。 **因果复杂性**: 根本原因涵盖单服务 Bug、多服务交互、基础设施故障和行为模式。 **排序**: 许多场景需要按特定顺序进行修复；错误的顺序会导致部分或失败的补救。 **指标可能误导**: 健康检查和关键指标有时会与实际系统状态冲突，这会奖励仔细的日志分析。 **运维上下文**: 某些场景奖励基础设施层面的推理（节点隔离、runbook 触发），而非本地服务修复。 ## License MIT

标签：API集成, ASM汇编, AV绕过, Docker, FastAPI, Gradio, OOM, OpenEnv, REST API, SRE, 事故处理, 云计算, 代理支持, 仿真环境, 偏差过滤, 内存泄漏, 分布式系统, 压力测试, 可观测性, 后端开发, 告警, 响应大小分析, 安全防御评估, 库, 应急响应, 快照半径, 拜占庭故障, 指标, 故障诊断, 数据库连接池, 日志, 根因分析, 站点可靠性工程, 级联故障, 缓存一致性, 自动化评估, 规则引擎, 训练场景, 请求拦截, 运维, 逆向工具, 链路追踪