# 面向 AI 的 SRE —— 多 agent 事件响应、Runbook、预测性检测

> AI SRE 用 LLM，经由 RAG 接地在基础设施数据（日志、runbook、服务拓扑）上，把调查、文档和协调阶段自动化。2026 年的架构模式是多 agent 编排 —— 专门的 agent（日志、指标、runbook）由一个 supervisor 协调；AI 提出假设和查询，人来批准判断性的决定。Datadog Bits AI 和 Azure SRE Agent 把这作为托管产品发布。Runbook 在进化：NeuBird Hawkeye 用对抗式评估（两个模型分析同一事件；一致 = 置信，分歧 = 不确定）；运维记忆跨团队变动持续存在。自动修复保持谨慎：AI 建议，人批准。完全自主的动作很窄（重启 pod、回滚特定部署），带紧的 guardrails —— 任何兜售"设好就不管"的人都在夸大其词。新兴前沿：事件前预测。MIT 研究报告一个训练在历史日志 + GPU 温度 + API 错误模式上的 LLM，提前 10-15 分钟预测了 89% 的宕机。预测：到 2026 年底，95% 的企业 LLM 都有自动故障转移。

**类型：** Learn
**语言：** Python（标准库，一个玩具级多 agent 事件分诊模拟器）
**前置要求：** 阶段 17 · 13（可观测性）、阶段 17 · 24（混沌工程）
**预计时间：** ~60 分钟

## 学习目标

- 画出多 agent 的 AI SRE 架构：supervisor + 专门 agent（日志、指标、runbook）+ 人工批准闸门。
- 解释为什么自动修复是窄的（重启 pod、还原部署）而不是宽的（重构服务）。
- 说出对抗式评估模式（NeuBird Hawkeye）：两个模型一致 = 置信；分歧 = 升级。
- 引用 MIT 的 89% 早期检测结果，以及那条运维约束：没有执行的预测只是仪表盘。

## 问题背景

一个 on-call 工程师凌晨 3 点被呼叫。"结账高错误率。"他们查 Datadog、Loki、三份 runbook、部署日志。30 分钟后才意识到根因是一次 KV cache 尖峰引发的 vLLM OOM。他们重启 pod；错误消失。

2026 年，那次调查的头 20 分钟是可自动化的。按服务分组日志、关联到近期部署、对照 runbook 匹配 —— 全是 RAG + 工具使用。一个受监督的 agent 能做首遍分诊，在人打开 Datadog 之前给出一个假设。

完全自主的修复是另一个问题。重启 pod：安全。扩 GPU 池：策略允许的话安全。重构服务：绝对不行。这门纪律就是画出那条窄线。

## 核心概念

### 多 agent 架构

```
          事件
             │
             ▼
        Supervisor
        /    |    \
       ▼     ▼     ▼
  日志 agent  指标 agent  Runbook agent
       │     │     │
       └─────┴─────┘
             │
             ▼
        假设 + 证据
             │
             ▼
        人工批准
             │
             ▼
        动作 (窄集合)
```

Supervisor 把事件拆成子查询。专门 agent 有工具访问（日志搜索、PromQL、文档检索）。Supervisor 综合，把假设 + 证据呈给人。人批准或重新引导。

### 自动修复的范围

**安全（窄）**：重启 pod、还原特定部署、在预批准边界内扩池、启用预批准的 feature flag。

**不安全（宽）**：改服务拓扑、改资源限制、部署新代码、改 IAM、改数据库。

任何兜售"设好就不管"的人都在夸大其词。安全集合随 AI SRE 成熟而扩大，但那条边界是真实的。

### 对抗式评估（NeuBird Hawkeye）

两个模型独立分析同一事件。如果它们对根因一致，置信度高。如果分歧，连同两个假设一起升级给人。简单的模式，对幻觉根因是个有效过滤器。

### 运维记忆

人员流动是传统 SRE 的无声杀手 —— 部落知识随人离开。AI SRE 把 runbook + 复盘存进向量数据库；agent 在每个新事件上检索。新工程师加入时，AI 拥有全部历史。

### 事件前预测

MIT 2025 研究：训练在历史日志、GPU 温度、API 错误模式上的 LLM，在测试集上提前 10-15 分钟预测了 89% 的宕机。

清醒一下：没有执行的预测就是仪表盘。运维问题是"当我们预测到时，我们做什么？"抢先排空？呼叫？自动扩缩？答案是策略特定的。

### 2026 年的产品

- **Datadog Bits AI** —— Datadog 内的托管 SRE 副驾。
- **Azure SRE Agent** —— Azure 原生。
- **NeuBird Hawkeye** —— 对抗式评估 + 运维记忆。
- **PagerDuty AIOps** —— 分诊 + 去重。
- **Incident.io Autopilot** —— 事件指挥官 + 协调。

### Runbook 即代码

Runbook 从 Confluence 页面进化成带结构化章节（症状、假设、验证、动作）的版本化 markdown。结构化 runbook 喂出更好的 RAG 检索。任何 AI-SRE 上线都从把非结构化 runbook 变成结构化开始。

### 你该记住的数字

- MIT 早期检测：89% 的宕机，10-15 分钟提前量。
- 多 agent 分诊：supervisor + （日志、指标、runbook）+ 人。
- 安全自动修复集合：重启 pod、还原部署、边界内扩缩。
- 对抗式评估：两个模型独立；一致 = 置信。

## 实际使用

`code/main.py` 模拟一次多 agent 分诊：日志 agent 找到错误，指标 agent 找到 CPU 尖峰，runbook agent 匹配到已知问题。Supervisor 给假设排序。

## 拿去用

这一课产出 `outputs/skill-ai-sre-plan.md`。给定当前 on-call、事件量、团队成熟度，设计一次 AI SRE 上线。

## 练习

1. 跑 `code/main.py`。如果日志和指标 agent 分歧呢？supervisor 怎么裁决？
2. 为你的服务定义三个"安全"的自动修复动作。论证每个。
3. 写一个结构化 runbook 模板：章节、必填字段、验证命令。
4. 预测性检测以 12 分钟提前量触发。你的策略是什么 —— 呼叫、预排空，还是两者都？
5. 论证一个 3 人团队在 2026 年是该采用 AI SRE 还是等等。考虑成熟度、量、风险。

## 关键术语

| 术语 | 大家嘴上怎么说 | 它实际是什么 |
|------|----------------|------------------------|
| AI SRE | "on-call 的 agent" | LLM 支撑的事件调查 + 协调 |
| Supervisor agent | "编排器" | 把事件拆成子查询的顶层 agent |
| 专门 agent | "领域 agent" | 带工具访问的子 agent（日志、指标、runbook） |
| 自动修复 | "AI 来修" | 窄的预批准动作；不是宽的重构 |
| 运维记忆 | "向量 runbook" | 复盘 + runbook 存进向量数据库做 RAG |
| 对抗式评估 | "双模型检查" | 独立分析；一致 = 置信 |
| NeuBird Hawkeye | "那个对抗式的" | 带对抗式评估 + 记忆模式的产品 |
| Bits AI | "Datadog 的 SRE agent" | Datadog 托管的 AI SRE |
| 事件前预测 | "早期检测" | 宕机预测有 10-15 分钟提前量 |

## 延伸阅读

- [incident.io — AI SRE Complete Guide 2026](https://incident.io/blog/what-is-ai-sre-complete-guide-2026)
- [InfoQ — Human-Centred AI for SRE](https://www.infoq.com/news/2026/01/opsworker-ai-sre/)
- [DZone — AI in SRE 2026](https://dzone.com/articles/ai-in-sre-whats-actually-coming-in-2026)
- [Datadog Bits AI](https://www.datadoghq.com/product/bits-ai/)
- [NeuBird Hawkeye](https://www.neubird.ai/)
- [awesome-ai-sre](https://github.com/agamm/awesome-ai-sre)
