ParthMalhotra07/sre_incident_response_simulator
GitHub: ParthMalhotra07/sre_incident_response_simulator
这是一个基于OpenEnv的SRE故障响应模拟器，通过模拟真实生产环境故障来评估AI智能体的诊断、修复及报告撰写能力。
Stars: 0 | Forks: 0
title: SRE Incident Commander
emoji: 🚨
colorFrom: red
colorTo: yellow
sdk: docker
pinned: false
tags:
- openenv
- ai-agents
- sre
# 🚨 SRE Incident Commander
**OpenEnv Hackathon 提交项目**
**Live Demo (Hugging Face Space):** [https://huggingface.co/spaces/ParthMalhotra07/sre-incident-response-simulator](https://huggingface.co/spaces/ParthMalhotra07/sre-incident-response-simulator)
**GitHub Repository:** [https://github.com/ParthMalhotra07/sre_incident_response_simulator](https://github.com/ParthMalhotra07/sre_incident_response_simulator)
## 📖 概述
一个模拟**真实世界生产环境故障响应**的 OpenEnv 环境。AI 智能体扮演站点可靠性工程师（SRE），必须利用可观测性工具诊断根本原因，应用精确的修复措施，并提交结构化的故障报告。
故障响应是软件工程中风险最高的任务之一。该环境用于评估 AI 智能体是否能够：
- **分诊：**阅读实时警报并确定调查的优先级。
- **诊断：**查询日志、指标和部署历史以找到根本原因。
- **修复：**应用*最小化且正确的补救措施*（而非盲目重启等权宜之计）。
- **报告：**撰写结构化的故障后总结。
## 🎮 挑战（任务）
该模拟器包含 3 个递进式的故障场景，旨在测试 LLM 的推理能力、日志解析能力和架构理解能力：
### 🟢 1. 简单：“明显的崩溃” (`deployment_crash`)
`api-gateway` 在一次错误的部署后返回 HTTP 500 错误。日志明确显示 `v2.4.0` 版本中引入了损坏的数据库连接字符串。
* **预期修复：**将部署回滚到 `v2.3.1`。
* **难度：**低 —— 日志直接指向了原因。
### 🟡 2. 中等：“缓慢的内存泄漏” (`memory_leak_config`)
`payment-service` 的响应时间正在下降。*近期没有部署* —— 根本原因是配置变更将 `MAX_POOL_CONNECTIONS=10000` 设置过高，耗尽了内存。
* **预期修复：**将配置限制更新回 `100`。
* **难度：**中等 —— 会惩罚那些总是假设“糟糕的部署 = 根本原因”的智能体。
### 🔴 3. 困难：“级联故障” (`cascading_db_lock`)
三个服务同时发生故障，原因是后端的一个流氓作业（`analytics-reporting-job`）运行了一条未建索引的 SQL 查询，锁定了共享的 `postgres-primary` 数据库。
* **预期修复：**将流氓作业的副本数缩容至 `0`。
* **难度：**高 —— 需要追溯系统依赖关系至共享数据库，并理解可见的故障只是症状，而非原因。
## 🛠 工具与操作空间
智能体通过结构化的 JSON Tool Calls 与环境交互。
**可观测性（只读）**
* `get_alerts` - 查看正在触发的警报。
* `query_logs` - 搜索应用日志。
* `query_metrics` - 检查 CPU、内存和延迟。
* `get_deployment_history` - 查看最近的发布。
* `get_service_dependencies` - 追溯服务架构。
**补救（可变）**
* `rollback_deployment(service, version)`
* `scale_service(service, replicas)`
* `restart_service(service)` *（注意：权宜修复会扣分）*
* `update_config(service, key, value)`
* `create_incident_report(root_cause, summary, actions_taken)` *（结束当前回合）*
## 🏆 评分与奖励设计
奖励在整个轨迹上平滑分布，最大值为 `1.0`：
* **+0.05：**成功使用诊断工具。
* **+0.10：**对准确的根系统应用了正确的修复。
* **-0.05：**权宜修复 `restart` 操作或定位了错误的服务。
* **+0.10 - +0.35：**基于生成的故障报告的根本原因准确性给予的动态奖励。
## 🚀 快速开始与部署
### 1. 本地运行
```
git clone https://github.com/ParthMalhotra07/sre_incident_response_simulator.git
cd sre_incident_response_simulator
pip install -r requirements.txt
uvicorn app:app --port 7860
```
### 2. Docker
```
docker build -t sre-env .
docker run -p 7860:7860 sre-env
```
### 3. API Usage（针对已部署的 Space）
重置一个回合以启动模拟器：
```
curl -X POST https://parthmalhotra07-sre-incident-response-simulator.hf.space/reset \
-H "Content-Type: application/json" \
-d '{"task": "easy"}'
```
并执行操作：
```
curl -X POST https://parthmalhotra07-sre-incident-response-simulator.hf.space/step \
-H "Content-Type: application/json" \
-d '{"tool": "get_alerts", "parameters": {}}'
```
*Built with OpenEnv. Validated using `openenv validate`. Hosted on Hugging Face Spaces.*
标签：AI代理, API集成, ASM汇编, DLL 劫持, DNS解析, Docker, LLM, NIDS, SRE, Unmanaged PE, 事故响应, 人工智能, 偏差过滤, 压力测试, 可观测性, 大语言模型, 安全防御评估, 容器化, 开源框架, 开源项目, 技术债务, 持续集成, 故障模拟, 数据管道, 根因分析, 模块化设计, 用户模式Hook绕过, 自动化修复, 请求拦截, 软件工程, 运维自动化, 逆向工具