面向AI的SRE

面向AI的SRE

本节摘要:AI SRE 用基于基础设施数据(日志、运行手册、服务拓扑)经 RAG 接地的 LLM,自动化调查、文档、协调阶段。2026 的架构范式是多智能体编排——专精智能体(日志、指标、运行手册)由 supervisor 协调;AI 提出假设与查询,人类批准判断性动作。Datadog Bits AI 与 Azure SRE Agent 以托管产品形态提供。运行手册在进化:NeuBird Hawkeye 用对抗式评估(两个模型分析同一事故;一致=高置信,分歧=不确定需升级);操作记忆跨人员流动持久化。自动修复保持克制:AI 建议、人类批准。完全自主的动作范围很窄(重启 Pod、回滚特定部署),且有严护栏——任何卖「设了就忘」的人都在过度承诺。新兴前沿:事故前预测。MIT 研究报告一个在历史日志 + GPU 温度 + API 错误模式上训练的 LLM,提前 10~15 分钟预测了 89% 的停机。预测:2026 年底 95% 的企业 LLM 具备自动故障转移。

对应原课程:Phase 17 · Lesson 23 · 23-sre-for-ai(原英文 phases/17-infrastructure-and-production/23-sre-for-ai/docs/en.md)。

学习目标

阅读完本节,你应当能够:

1. 画出多智能体 AI SRE 架构:supervisor + 专精智能体(日志、指标、运行手册)+ 人类批准门。
2. 解释为什么自动修复是窄的(重启 Pod、回滚部署)而非宽的(重构服务)。
3. 说出对抗式评估范式(NeuBird Hawkeye):两模型一致=置信,分歧=升级。
4. 引用 MIT 89% 提前检测的结果,以及操作约束:没有动作的预测只是仪表盘。

一、问题与直觉

凌晨三点,值班工程师被叫醒。「结账高错误率」。查 Datadog、Loki、三份运行手册、部署日志。30 分钟后他们意识到根因是 KV 缓存尖峰引发的 vLLM OOM。重启 Pod,错误清除。

2026 年,那段调查的前 20 分钟是可自动化的。按服务分组日志、关联近期部署、匹配运行手册——全是 RAG + 工具调用。一个有监督的智能体能在人类打开 Datadog 之前完成首轮分诊并给出假设。

完全自主的修复是另一回事。重启 Pod:安全。扩 GPU 池:策略允许就安全。重构服务:绝对不行。这门学科就是画那条窄线。

二、核心概念

多智能体架构

supervisor 把事故拆成子查询。专精智能体有工具访问权(日志检索、PromQL、文档检索)。supervisor 综合后,把假设 + 证据交给人类。人类批准或重定向。

自动修复范围

安全(窄):重启 Pod、回滚特定部署、在预批准范围内扩缩池、启用预批准的特性 flag。

不安全(宽):改服务拓扑、改资源上限、部署新代码、改 IAM、改数据库。

任何卖「设了就忘」的人都在过度承诺。安全集合随 AI SRE 成熟会扩大,但边界是真实的。

对抗式评估(NeuBird Hawkeye)

两个模型独立分析同一事故。若它们对根因达成一致,置信度高。若分歧,带着两个假设升级给人类。简单模式,对幻觉根因的有效过滤器。

操作记忆

团队流动是传统 SRE 的隐性杀手——部落知识随人离开。AI SRE 把运行手册 + 复盘存进向量库;每次新事故智能体都去检索。新人加入时,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 —— 事故指挥官 + 协调。

运行手册即代码

运行手册从 Confluence 页面进化为带结构化段(症状、假设、验证、动作)的版本化 markdown。结构化运行手册喂给 RAG 检索效果更好。任何 AI SRE 落地,都从把非结构化运行手册结构化开始。

你该记住的数字

• MIT 提前检测:89% 的停机,10~15 分钟提前量。
• 多智能体分诊:supervisor + (日志、指标、运行手册)+ 人类。
• 安全自动修复集合:重启 Pod、回滚部署、范围内扩缩。
• 对抗式评估:两模型独立;一致=置信。

三、从零实现:多智能体分诊模拟

原课程 code/main.py 模拟多智能体分诊:日志智能体发现错误、指标智能体发现 CPU 尖峰、运行手册智能体匹配到已知问题。supervisor 给假设排序。下面给最小可读的假设合成骨架。

def triage_supervisor(log_finding, metric_finding, runbook_match):
    """supervisor 综合三个专精智能体的发现,排序假设。

    log_finding:     {'signal': str, 'severity': 1-5}
    metric_finding:  {'signal': str, 'severity': 1-5}
    runbook_match:   {'runbook': str, 'confidence': 0-1} or None
    返回: 排序后的假设列表
    """
    hypotheses = []
    if runbook_match and runbook_match["confidence"] >= 0.7:
        hypotheses.append({
            "hypothesis": f"匹配运行手册《{runbook_match['runbook']}》",
            "score": runbook_match["confidence"] * 5,
            "evidence": [log_finding["signal"], metric_finding["signal"]],
        })
    # 日志与指标信号一致 → 提升置信
    if log_finding["severity"] >= 3 and metric_finding["severity"] >= 3:
        hypotheses.append({
            "hypothesis": "日志与指标共同指向的资源压力(如 KV 缓存 OOM)",
            "score": (log_finding["severity"] + metric_finding["severity"]) / 2,
            "evidence": [log_finding["signal"], metric_finding["signal"]],
        })
    hypotheses.sort(key=lambda h: h["score"], reverse=True)
    return hypotheses


# 案例:日志报 OOM(严重度4),指标报内存尖峰(严重度4),运行手册命中(置信0.9)
hs = triage_supervisor(
    {"signal": "vLLM OOM kill", "severity": 4},
    {"signal": "内存使用 98%", "severity": 4},
    {"runbook": "KV 缓存尖峰处理", "confidence": 0.9},
)
for h in hs:
    print(h)
​

💡 对抗式评估几乎免费:把同一组证据喂给两个不同模型,只在它们一致时自动推进,分歧就升级人类。它对「幻觉根因」的过滤效果远超单模型自评。

四、框架对比:AI SRE 产品横向对照

心法:工具选型先看「你的可观测与值班栈在哪」——Bits AI 配 Datadog、Azure SRE Agent 配 Azure、PagerDuty AIOps 配 PagerDuty。Hawkeye 的对抗式评估与操作记忆是横切能力,可叠加而非替代。

五、可复用产物

本节产出 outputs/skill-ai-sre-plan.md(原课程目录)。给定当前值班、事故量、团队成熟度,它设计 AI SRE 落地:

1. 范围界定:哪些事故类型先自动化(高频、低判断成本),哪些暂缓。
2. 多智能体拓扑:supervisor + 日志/指标/运行手册智能体的工具接入。
3. 对抗式评估门:两模型一致才自动推进,分歧升级人类的规则。
4. 安全自动修复集合:重启 Pod、回滚部署、范围内扩缩的预批准策略。
5. 运行手册结构化:把非结构化运行手册转成带症状/假设/验证/动作段的版本化 markdown。

六、练习

1. 跑通模拟器:运行 code/main.py。若日志与指标智能体分歧,supervisor 如何解决?

2. 定义安全动作:为你的服务定义三个「安全」自动修复动作。逐一论证为何安全。

3. 写运行手册模板:结构化运行手册模板——段落、必填字段、验证命令。

4. 预测策略:预测检测在 12 分钟提前量触发。你的策略——报警、预先排水,还是两者?

5. 小团队要不要上:论证一个 3 人团队在 2026 年是否该采用 AI SRE,还是再等等。考虑成熟度、事故量、风险。

本节要点回顾

1. AI SRE = LLM 经 RAG 接地基础设施数据:自动化调查/文档/协调,2026 范式是多智能体编排。
2. 多智能体拓扑:supervisor + 日志/指标/运行手册专精智能体 + 人类批准门。
3. 自动修复是窄的:重启 Pod、回滚部署、范围内扩缩——安全;重构服务、改 IAM、改库——不安全。
4. 「设了就忘」是过度承诺:AI 建议、人类批准,任何宣传完全自主的人都在卖假药。
5. 对抗式评估(NeuBird Hawkeye):两模型独立分析,一致=置信,分歧=升级,有效过滤幻觉根因。
6. 操作记忆:运行手册 + 复盘进向量库,跨人员流动持久化,新人即享完整历史。
7. 事故前预测:MIT 报告提前 10~15 分钟预测 89% 停机,但没有动作的预测只是仪表盘。
8. 运行手册即代码:从 Confluence 页进化为带症状/假设/验证/动作的版本化 markdown,喂 RAG 更准。
9. 2026 产品:Bits AI、Azure SRE Agent、Hawkeye、PagerDuty AIOps、Incident.io Autopilot。
10. 预测:2026 年底 95% 企业 LLM 具备自动故障转移——但故障转移≠完全自主修复。

下一节,我们把 SRE 推进到混沌工程——主动往 LLM 生产里注入故障,看 KV 驱逐风暴、分词炸弹、provider 429 把你的栈打到哪。