kriti768/Incident-Response-Commander

GitHub: kriti768/Incident-Response-Commander

这是一个基于强化学习的微服务事故指挥模拟器,通过模拟真实停机场景训练智能体进行回滚、扩容及故障排查等运维决策。

Stars: 0 | Forks: 0

## Incident Response Commander emoji: "🚨" colorFrom: blue colorTo: red sdk: docker app_port: 7860 pinned: false license: mit short_description: 用于 RL agents 的停机命令模拟器。 # Incident Response Commander Incident Response Commander 是一个 RL 风格的事故模拟器,其中 agent 在实时停机期间扮演生产指挥官。不同于玩具式的导航或抽象控制任务,其动作空间在操作上是可识别的:捕获证据、回滚有问题的部署、扩展饱和的依赖项、禁用代价高昂的特性开关、排空失败的区域、重启队列 worker,或保持稳定足够长的时间以确认恢复。 它的设计旨在让人感觉像是一个真正的 SRE 控制问题: - 根据事故情况存在多条有效的轨迹 - 快速减少客户痛苦可获得高回报 - 对冒险、不必要或嘈杂的动作给予惩罚 - 在增加调试难度之前保留证据可获得明确奖励 ## USP Incident Response Commander 将事故管理转化为一个具体的决策游戏:生产环境起火,客户受损,每个动作都在速度、风险和信息之间进行权衡。UI 在几秒钟内就能使其清晰可读,三个场景从回滚到级联故障再到区域性部分停机自然扩展,且验证器(validator)逻辑保持简洁,因为基准是确定性的,模型是类型化的,评分器会将分数钳制在 `0.0` 和 `1.0` 的不安全边缘之外。 一句话概括:这是一个具有强大演示表面和验证器友好后端的现实停机命令模拟器。 ## What Makes It Stand Out - 任务基于真实的运维工作,而非抽象控制。 - 三个场景支持多条合理的缓解路径。 - 回报与有用的行为挂钩:快速恢复、避免鲁莽操作、保留证据。 - UI 让环境对于不熟悉微服务的人来说也易于理解。 - 代码库结构旨在确保提交的可靠性,具有类型化模型、确定性回退和干净的 OpenEnv 打包。 ## Why this project works - 真实的事故响应是具体的、高风险的,且易于演示。 - 三个场景自然支持不同的缓解轨迹。 - 评分器将分数钳制到对验证器安全的 `(0, 1)` 区间内。 - 基准策略是确定性的,但当存在 `API_BASE_URL`、`MODEL_NAME` 和 `API_KEY` 这些变量时,`inference.py` 已准备好通过 OpenAI 客户端使用它们。`HF_TOKEN` 也被接受作为兼容性的回退选项。 ## Demo story 1. 从简单场景开始,展示错误的部署回滚路径。 2. 切换到中等场景,演示依赖感知的缓解路径,而不是盲目回滚。 3. 在困难的区域停机场景结束,展示为什么捕获证据、加上流量转移以及 worker 恢复很重要。 这一过程既展示了真实性,又展示了复杂性的递增,而不需要冗长的解释。 ## How To Demo It 1. 在 `task1_bad_deploy` 上打开应用。 2. 指出客户影响仪表、推荐面板和奖励反馈。 3. 快速解决简单场景以展示反馈循环。 4. 切换到中等场景,展示深思熟虑的缓解胜过随机操作。 5. 在困难场景结束,展示在嘈杂信号下的证据捕获、路由和队列恢复。 最好的演示是简短而果断的。一旦第一步操作落地,环境就会不言自明。 ## Project layout - `server/` 包含类型化模型、确定性场景、环境类和 FastAPI 应用。 - `tasks/` 包含三个独立的评分器,分别用于简单、中等和困难任务。 - `inference.py` 运行基准策略,并仅输出 `[START]`、`[STEP]` 和 `[END]` stdout 行。 - `web/` 包含一个用于交互式演示的轻量级浏览器 UI。 - `openenv.yaml` 描述了环境入口点和所需变量。 ## Tasks 1. `task1_bad_deploy`(简单):识别有问题的 checkout 部署并干净地回滚。 2. `task2_cascading_latency`(中等):通过减少扇出和扩展饱和的依赖项来缓解级联延迟。 3. `task3_region_outage`(困难):保留证据,排空失败区域,恢复队列 worker,并在嘈杂的遥测信号下等待稳定。 ## Reward Design 该环境奖励的行为看起来像合格的事故响应: - 快速减少客户影响 - 恢复健康的服务状态 - 避免不必要或有害的操作 - 在进行破坏性缓解之前保留证据 评分器将最终分数钳制在一个远离 `0.0` 和 `1.0` 的安全范围内,这使得提交验证器友好,同时仍然奖励更好的轨迹。 ## Why RL Fits Here 这是一个很好的 RL 设置,因为 agent 不仅仅是预测标签或遵循静态脚本。它在一个变化的系统中选择干预措施,其中: - 动作有副作用 - 时机至关重要 - 存在多条有效轨迹 - 短期胜利可能会造成长期风险 这使得环境易于人类理解,同时保留了真正的顺序决策结构。 ## Local run 安装依赖: ``` pip install -r requirements.txt ``` 启动 API: ``` uvicorn server.app:app --host 0.0.0.0 --port 7860 ``` 运行基准推理跟踪: ``` python inference.py ``` ## Required environment variables 在运行时环境中定义这些变量: - `API_BASE_URL` - `API_KEY` - `MODEL_NAME` - `HF_TOKEN` 基准策略不需要它们,但任何实时 LLM 调用都将在可用时通过使用 `API_BASE_URL` 和 `API_KEY` 的 OpenAI 客户端进行路由。`HF_TOKEN` 仍被支持作为回退选项。 ## Validation notes - `reset()`、`step()` 和 `state()` 通过 FastAPI 应用公开。 - Docker 镜像在端口 `7860` 上启动 API。 - 评分器通过将分数钳制到 `0.10` 到 `0.90` 之间,使分数严格远离 0 和 1。 - `inference.py` 位于项目根目录,并避免额外的 stdout 汇总行。 ## Submission Links - GitHub: [kriti768/Incident-Response-Commander](https://github.com/kriti768/Incident-Response-Commander) - Hugging Face Space: [kriti98/incident-response-commander](https://huggingface.co/spaces/kriti98/incident-response-commander)
标签:Docker, Petitpotam, RL, SRE, 事故响应, 人工智能, 仿真器, 偏差过滤, 决策支持, 安全防御评估, 开源自建, 强化学习, 故障恢复, 故障模拟, 环境模拟, 生产环境, 用户模式Hook绕过, 自动化运维, 请求拦截, 运维指挥, 逆向工具