跳转至

Deep Research: [76] SRE：Service Level Objectives（SLO）：把可靠性写成可交易的预算

  • Source: https://sre.google/sre-book/service-level-objectives/
  • Note: ../notes/ref-076-sre-slo.md
  • Snapshot: ../sources/md/sre-google-sre-book-service-level-objectives-7b9a3e66dbb9.md
  • Category: Deployment & Operations (ops)
  • Chapters: 17-deployment, 18-evaluation, 07-engineering, 20-governance

TL;DR

SLO（服务等级目标）不仅仅是运维指标，而是一种将可靠性量化为错误预算（Error Budget）的产品管理工具。它通过明确允许系统出错的额度，在新功能发布速度与系统稳定性之间建立了一个客观、可交易的决策机制。

核心观点

  1. 三位一体的定义：需严格区分 SLI（指标，如延迟）、SLO（目标，如 <100ms）、SLA（协议，涉及商业赔偿）。SRE 主要关注 SLI 和 SLO，SLA 是商业和法务的范畴。
  2. 可靠性是产品功能：设定 SLO 必须由产品负责人（Product Owner）参与，因为这本质上是在定义用户多大程度上能容忍服务不可用。
  3. 错误预算（Error Budget）是核心资产：100% 的可靠性既不可能也不划算。剩余的不可靠空间（如 0.1%）就是错误预算，可用于发布新功能、架构重构或混沌工程实验。
  4. 平均值掩盖真相：在长尾效应显著的系统中（如 AI 推理），平均延迟毫无意义。必须使用百分位数（Percentiles）（如 P95, P99, P99.9）来定义 SLO，因为长尾请求往往对应最糟糕的用户体验。
  5. 不要过度交付：如果系统长期显著优于 SLO（例如目标 99.9%，实际 99.999%），用户会产生错误的心理预期。Google Chubby 团队甚至会主动制造故障来消耗多余预算，以强制依赖方处理故障。
  6. 从用户视角出发：服务器端的成功不代表用户端的成功（例如 CDN 故障或 JS 错误）。理想的 SLI 应尽可能贴近用户真实体验（如客户端埋点）。
  7. 标准化模板：为了降低认知负荷，应对 SLI 的定义进行标准化（如聚合间隔、测量位置、请求类型），避免每次从头定义。
  8. 动态调整：SLO 不是刻在石头上的。初期可以设定较宽松的目标，随着对系统理解的加深逐步收紧。

可落地做法

1. 定义阶段（面向产品/研发）

  • 第一步：识别关键路径。不监控所有指标，只关注直接影响用户体验的核心链路（如：推理响应生成、数据库读写）。
  • 第二步：选择指标类型。
    • 用户服务系统：可用性、延迟、吞吐量。
    • 存储系统：延迟、可用性、数据持久性。
    • AI/大数据系统：端到端延迟、吞吐量、结果正确性（Quality）。
  • 第三步：设定阈值与分布。拒绝平均响应时间 < 200ms，采用99% 的请求在 200ms 内完成。

2. 实施阶段（面向工程）

  • 埋点与采集：优先使用 Prometheus/Borgmon 等时序数据库采集服务端指标，有条件时补充客户端日志。
  • 可视化看板：建立实时看板，不仅显示当前值，更要显示剩余错误预算的燃烧速率（Burn Rate）。

3. 治理阶段（面向运维/SRE）

  • 预算耗尽策略：一旦错误预算耗尽（例如本月不可用时间已超额），触发熔断机制：
    • 冻结非紧急的功能发布。
    • 全员通过 Code Freeze 投入稳定性修复。
    • 仅在预算恢复后（如进入下一个统计周期）才解锁发布。

检查清单：SLO 定义完备性自查表

在正式公布一个 SLO 之前，请通过以下问题进行核验：

  • [ ] 指标明确性：是否明确了具体的测量对象？（例如：是所有 HTTP GET 请求还是仅搜索接口的请求）
  • [ ] 测量位置：是在负载均衡器（LB）、应用服务器内部，还是客户端测量的？
  • [ ] 统计窗口：是否有明确的聚合时间窗口？（例如：过去 30 天还是滚动 7 天）
  • [ ] 排除项：是否定义了哪些流量不计入考核？（例如：爬虫流量、压测流量、< 1s 的短连接中断）
  • [ ] 阈值合理性：目标设定是基于历史数据还是用户真实需求？（避免拍脑袋定 99.99%）
  • [ ] 行动指南：如果违反了该 SLO，是否有明确的、非个人的后果？（例如：停止发布，而不是扣绩效）
  • [ ] 逃生出口：是否有机制处理不可抗力（如云厂商故障）导致的预算消耗？

常见坑与对策

常见坑 潜在后果 对策
把 SLO 当 KPI 团队通过掩盖问题而非解决问题来达标，甚至不敢尝试新技术。 明确 SLO 是用来控制发布的节奏，而不是惩罚个人的工具。
基于当前性能定 SLO 系统可能本身就很烂，或者因为过度优化而好得过分，导致目标锁定在错误水平。 从用户能忍受的底线反向推导，或者参考竞品标准。
追求绝对值 试图让系统永远可用或延迟无限低，导致成本指数级上升。 接受并拥抱故障是常态，用错误预算来量化这种接受度。
仅关注服务端指标 用户断网或 CDN 挂了，服务端指标依然全是 200 OK，但用户体验为零。 引入黑盒监控（Black-box probing）或客户端真实用户监控（RUM）。
SLO 太多 告警风暴，核心问题被淹没。 仅保留 3-5 个最关键的用户体验指标（如：推理成功率、首字延迟）。

可用于丰富《AI 辅助软件产品》的写作点

  • 第 9 章：后端架构 MVP

    • 写作点：在设计后端 MVP 时，不要只写功能需求，要同步定义AI 服务的 SLO。例如，对于 LLM 应用，传统的 QPS 可能不是最重要的，首字延迟（TTFT）和完整生成延迟的 P95/P99 才是核心 SLI。
    • 案例：区分流式输出（Streaming）与非流式输出的 SLO 差异。

  • 第 17 章：部署与运维

    • 写作点：将错误预算概念引入 AI 产品的发布流程。AI 模型的不确定性天然容易消耗预算（如幻觉率飙升）。
    • 策略：当新模型版本的幻觉率或拒绝服务率消耗了过多的错误预算时，自动回滚到旧模型（Shadow Mode -> Canary -> Production 晋级策略的量化门禁）。

  • 第 18 章：评测与门禁（Evaluation）

    • 拓展概念：将 SLO 从可用性拓展到质量。
    • Quality SLO：例如，95% 的回答被 Judge 模型判定为‘有帮助’。这比单纯的 HTTP 200 更能反映 AI 产品的健康度。
    • 数据完整性 SLO：对于 RAG 系统，定义知识库索引延迟的 SLO（例如：新文档上传后 5 分钟内必须可被检索）。