自主SRE平台

PitCrew AI🚨🏎️

基于MCP编排代理构建的自主SRE系统

PitCrew AI是一个自主的站点可靠性工程（SRE）平台，旨在使用AI代理安全地检测、诊断和补救生产事件。

该项目是以先进系统为重点的黑客马拉松的一部分，旨在展示 现实世界的人工智能基础设施编排，而不仅仅是聊天机器人功能。

该架构强调：

• 控制平面与数据平面分离
• 安全自动化
• 可观察性驱动的决策
• 治理补救
• 生产方式故障模拟

🎯 项目愿景

现代基础设施需要智能自动化，但不安全的自主性可能是灾难性的。

PitCrew AI旨在回答一个关键问题：

人工智能可以安全地操作生产系统吗？

这个项目不是构建一个简单的人工智能助手，而是专注于创建一个 结构化操作系统 其中代理：

1. 检测系统故障
2. 调查根本原因
3. 咨询操作知识
4. 根据策略验证操作
5. 执行补救措施
6. 生成事故报告

长期目标是模拟生产级自主SRE。

🧠 核心架构原则

控制平面与数据平面

本项目有意将系统职责分开：

✅ 数据平面（工作负载）

被监控的生产系统。

目前包括：

• API码头化烧瓶
• 健康监测端点
• 受控故障触发器

✅ 控制平面（操作员）

观察和控制系统的智能层。

目前包括：

• 混沌模拟脚本
• 从主机执行Docker命令
• 外部系统控制

这反映了Kubernetes和云平台使用的现实世界基础设施模式。

🏗️ 建立了什么——Day 1基金会

第一天完全专注于构建一个 现实、可控的生产环境.

在创建AI代理之前，拥有一个能够：

✅ 可预见的失败 ✅ 可靠恢复 ✅ 暴露健康信号

没有这个基础，就无法令人信服地证明可观察性和补救措施。

🐳 模块化生产服务

一个轻量级的Flask API被容器化作为“生产工作负载”

为什么选择Docker？

Docker通过打包确保服务在跨机器的一致环境中运行：

• 应用程序代码
• 依赖项
• 运行时
• 操作系统级

这消除了经典的部署问题：

“它在我的机器上工作。”

容器行为

健康状态

/health → HTTP 200 OK

故障状态

/health → HTTP 500 SERVICE UNHEALTHY

失败是通过文件系统标志触发的：

broken.flag

这允许确定性中断模拟。

💥 混沌工程设置

为了模拟真实的生产事件，创建了一个控制脚本：

chaos.py

运行在 宿主机，不在容器内。

这是故意的。

为什么？

生产系统永远不应该自毁。

故障必须由外部触发，就像运营商或意外事件影响服务的真实基础设施一样。

这强制了适当的架构分离：

控制平面→ 管理

数据平面→ 执行

混沌能力

中断服务

创建 broken.flag 在容器内部，迫使健康端点返回500。

恢复服务

删除标记并将系统恢复到健康状态。

示例流程

模拟停机：

python chaos.py
> break

恢复服务：

python chaos.py
> fix

这使得 一个命令失败演示，这对于可靠的技术演示至关重要。

📁 当前项目结构

pitcrew-ai/
│
├── victim-app/
│   ├── app.py
│   ├── Dockerfile
│   └── requirements.txt
│
├── chaos.py
└── README.md

受害者应用程序

表示生产工作负载。

chaos.py

表示能够控制系统的外部操作员。

🧱 关键工程决策

确定性故障

随机崩溃不利于演示。

可预测的故障能够实现可靠的测试和演示。

最小基础设施

故意避免使用Kubernetes，以减少资源开销并提高开发速度。

Docker提供了足够的真实感，没有不必要的复杂性。

外部控制

自动化脚本保留在容器之外，以反映真实的平台架构模式。

🔜 接下来会发生什么

有了可控的生产系统，下一阶段将引入智能可观测性。

即将推出的组件：

🔧 机械MCP代理

责任：

• 检查Docker容器
• 读取日志
• 检测不健康的服务
• 表面诊断信号

这就是系统开始从容器演示演变为 人工智能运营的基础设施平台。

未来的代理商将包括：

• 战略家→ Runbook驱动的RAG
• 官方→ 策略验证
• 风险引擎→ 动作评分
• 记者→ 自动验尸

🚀 长期架构（目标）

Incident Trigger
      ↓
Observability Agent
      ↓
Diagnosis
      ↓
Runbook Retrieval
      ↓
Policy Validation
      ↓
Risk Assessment
      ↓
Autonomous Remediation
      ↓
Incident Report

目标不是创建聊天机器人，而是 自主运营商。

💡 为什么这个项目很重要

人工智能正在生产环境中迅速获得操作权限。

挑战不再是情报。

它是 信任。

PitCrew AI探索了结构化编排、策略执行和风险感知自动化如何使AI足够安全地操作关键系统。

✅ 第1天状态

✔ 模块化生产服务 ✔ 健康监测端点 ✔ 确定性失效机制 ✔ 混沌模拟 ✔ 控制/数据平面分离

第2天——自主恢复引擎

第2天升级 PitCrew AI 从故障模拟器到 自主自愈系统.

它现在运行一个闭环工作流：

失败→ 诊断→ 决定→ 补救→ 验证

与现实世界保持一致 SRE自动化.

建筑

PitCrew推出了一款 数据平面/控制平面 拆分：

• 数据平面： 具有确定性故障+健康遥测的Docker化Flask工作负载
• 控制平面： 机械MCP（FastAPI）+AI驱动程序，用于可观察性和执行性

这使决策保持在工作负载之外，如生产基础设施。

核心组件

机械MCP（操作层）

• 记录、检查、重启、目标恢复
• 执行行动，从不做决定

人工智能驱动程序（大脑）

• 收集遥测数据
• 通过LLM进行诊断
• 将输出标准化为确定性操作
• 执行补救措施
• 验证恢复

关键工程获胜

• 上下文工程： 只有关键的日志信号会进入模型
• 确定性行为： 自由文本→ 稳定的命令
• 根本原因恢复： 删除故障触发器+重新启动，而不是盲目重新启动

结果

PitCrew AI现在可以执行 完全自主的自我修复:

混沌→ 观察→ 理由→ Fix → 验证

在没有人为干预的情况下，模拟真实的SRE行为，而不是演示机器人。

基础完成。

该系统现在已准备好进行智能可观测。

第3天——治理层和可靠性强化

第3天的重点是通过引入策略执行、执行安全和状态感知事件验证，将PitCrew从自主恢复脚本转变为受治理的基础设施系统。

关键架构升级

实施了一个策略引擎（“官方”），以在执行之前验证所有补救措施。
这建立了一个受控的工作流程：

健康→ 诊断→ 政策评估→ 批准的行动→ 恢复→ 验证

该系统现在展示了受控的自主性，而不是不受限制的人工智能驱动的执行。

策略引擎集成

• 构建了一个专用的FastAPI策略服务。
• 在容器修复之前进行强制批准检查。
• 为高严重性事件引入了人在环超控。
• 防止LLM直接执行到基础设施。

这使平台与现实世界的运营风险控制相一致。

严重性标准化

检测到词汇漂移导致的治理绕过(CRITICAL 对比 HIGH).
实施了严重性规范化，以执行驱动程序和策略引擎之间的严格合同。

结果：

• 消除了意外的自动审批。
• 强化决策决定论。

确定性解析

用从LLM输出中提取结构化字段代替模糊关键字检测。

优点：

• 减少行动选择中的模糊性。
• 提高自动化可靠性。
• 防止快速出血影响执行。

虚假事件预防（重大可靠性升级）

观察到历史Docker日志触发了健康服务的恢复。

添加了a 健康预检查门 在运行AI诊断之前：

实时服务状态→ 验证→ 诊断（仅在降级时）

这使系统从日志驱动行为转变为状态感知事件响应——这是一种关键的可靠性模式。

执行安全改进

• 添加了受保护的恢复流，以防止重复修复。
• 引入了安全的请求包装器，以优雅地处理服务中断。
• 针对依赖失败的强硬驱动力。

控制飞机现在安全地发生故障，而不是不可预测地发生故障。

操作可追溯性

在每个响应周期中添加事件ID，提高了可观察性，并使系统与真实的事件管理工作流程保持一致。

结果

PitCrew现在作为一个受管理的恢复平台运行，具有：

• 基于策略的执行控制
• 人为干预高风险行为
• 确定性人工智能行为
• 状态感知事件检测
• 强化编排层

这标志着从原型自动化脚本到面向可靠性的控制平面的过渡。

feat（治理）：添加风险评分、规则归因和审计跟踪

第4天——Runbook智能与决策指导

今天专注于转型 PitCrew 通过引入操作runbook智能，从自主修复系统转变为知识导向的可靠性平台。

一个专用 战略家模块 实现了基于生产日志签名检索相关Runbook。该系统现在不再允许LLM独立推断补救步骤，而是优先考虑结构化的操作知识，大大降低了幻觉风险，并使行为与现实世界的SRE实践相一致。

运行手册与应用程序逻辑分开，以强制执行适当的架构边界——将它们视为知识库而不是可执行代码。随着附加服务和Runbook的引入，这提高了长期可扩展性。

这 司机代理 升级后，将runbook检索直接整合到诊断提示中，明确指示模型将记录的程序优先于自由推理。这创建了一个受控的决策流：

Logs → 运行手册→ 诊断→ 治理→ 机械师→ 恢复

控制台输出经过改进，遵循了专业的工程风格，消除了过多的视觉噪音，同时清楚地显示了每个阶段哪个子系统（战略家、治理者、机械师）正在运行。

第4天的主要成果

• 引入了Strategist检索层
• 实现了确定性runbook匹配
• 在LLM提示符内强制执行runbook优先决策
• 加强车手的稳定性和清晰度
• 改进了知识层和执行层之间的架构分离
• 维护健康门控，防止虚假事件
• 为安全自动化保留确定性动作映射

有了这一补充，PitCrew现在的行为不再像反应式脚本，而更像是一个内部可靠性控制平面，能够在执行生产行动之前咨询作战原则。

该系统现在是稳定的、可解释的、与企业一致的，已准备好进行编排层集成。