背景：为什么 AI 系统需要专门的 SRE
传统 SRE 已经用 SLI/SLO、Error Budget、On-Call、Postmortem 让互联网服务稳定运行了二十年。但 AI 系统引入了新的不确定性和失效模式，使得传统方法必须扩展。
传统 SRE 与 AI SRE 的差异
| 维度 | 传统服务 | AI 系统 |
|---|---|---|
| 失败信号 | HTTP 5xx、超时、CPU 高 | 幻觉、偏见、输出质量下降、模型漂移 |
| 输入空间 | 相对确定 | 开放自然语言，几乎无限 |
| 延迟特征 | 单次请求 P99 | TTFT + ITL + 端到端延迟 |
| 成本模型 | CPU/内存/存储 | Token 用量、GPU 时长、embedding 调用 |
| 变更源 | 代码、配置 | 模型版本、prompt、temperature、检索索引 |
| 可观测对象 | 服务边界 | 模型调用、工具调用、Agent 步骤、RAG 检索 |
AI 系统特有的故障模式
- 模型幻觉：服务返回 200 OK，但内容错误。
- 输出质量漂移：模型或 prompt 微小变化导致答案质量下降。
- 长尾延迟：某些输入触发超长生成，拖垮 P99。
- 成本爆炸：循环 Agent 或失控的 token 消费导致账单激增。
- 工具/检索失败：Agent 调用错误工具，RAG 召回空结果或低质量片段。
- 安全与合规风险：生成有害内容、泄露 PII、越狱攻击成功。
- 依赖不确定性：外部模型 API 行为变化、rate limit、版本下线。
为什么传统监控不够
- 200 OK 不等于正确：HTTP 成功不能证明输出正确。
- 平均延迟掩盖问题：TTFT 和 ITL 比端到端延迟更能反映用户体验。
- 日志不够语义化：需要记录 prompt、completion、tool I/O、retrieval chunks。
- 静态阈值失效：模型行为会随输入分布变化，需要动态基线。
AI SRE 的核心目标
- 可见性：看清每一次模型调用、Agent 步骤、RAG 检索的内部状态。
- 可度量：定义质量、成本、延迟、安全四位一体的 SLI/SLO。
- 可控制：通过路由、降级、熔断、缓存、采样控制成本与风险。
- 可恢复：建立 runbook、自动化修复与事后复盘机制。
小结
AI SRE 不是把 Prometheus 和 Grafana 套到 LLM 上，而是要把不确定性纳入工程治理。下一章将从 trace、metrics、logs、SLI/SLO、AIOps 等核心概念开始，搭建这套体系。