SLO 与错误预算：量化服务可靠性

FreeGuideOnline 最新 2026-07-01

SLO 与错误预算：量化服务可靠性

在分布式系统和微服务架构中，“可靠性”是一个核心但模糊的概念。SLO（服务等级目标）和错误预算为团队提供了一套精确的量化语言，将可靠性从主观感受转化为可测量、可决策的工程指标。本文从基础概念出发，逐步拆解两者的定义、制定方法及实践价值，帮助初学者建立完整的认知框架。

一、核心概念解析

1.1 服务等级指标（SLI）

SLI 是衡量服务某一特性的具体指标，通常是随时间分布的测量值。它是制定 SLO 的数据基础。

常见 SLI 类型：

  • 可用性：成功响应请求的比例。例如，HTTP 200 或 2xx 的占比。
  • 延迟：请求返回时间低于阈值的比例。例如，95%的请求在 300ms 内完成。
  • 错误率：显式失败（5xx）或业务逻辑错误的比例。
  • 吞吐量：每秒处理的请求数，但通常作为容量指标而非直接用于 SLO。

公式示例：

可用性 SLI = 成功的请求数 / 全部有效请求数

需注意排除不合理的无效请求（如因客户端问题导致的 4xx 错误），否则会混淆责任边界。

1.2 服务等级目标（SLO）

SLO 是 SLI 在一个时间段内必须达到的目标值，通常以百分数表示。它直接定义了服务的“健康”状态。

关键特征：

  • 有明确的时间窗口：通常以滚动窗口（如 30 天）计算，而非瞬时值。
  • 以用户体验为导向：如果不达标，表示用户正在感受到问题。
  • 是承诺的边界：SLO 不是平均目标，而是必须守护的下限。

示例：

  • “过去 30 天内，99.9% 的登录请求在 500ms 内成功完成。”
  • “过去 28 天，服务可用性不低于 99.95%。”

SLO 的设定必须高于内部 SLA（服务等级协议）所承诺的外部客户保障，为问题处理留出缓冲。

1.3 错误预算

错误预算是 SLO 的直接推导产物，量化了在特定时间段内系统可以承受的最大不可靠性总量。它的计算公式极其简洁：

错误预算 = 1 - SLO

如果 SLO 为 99.9%（可用性），则对应的错误预算为 0.1%。这意味着在衡量周期内，允许有 0.1% 的故障时间或错误请求。

将百分比转化为实际时间：

  • 30 天的 99.9% SLO → 错误预算 = 0.1% × 30天 × 24 × 60 = 43.2 分钟/月
  • 30 天的 99.99% SLO → 错误预算 ≈ 4.32 分钟/月

错误预算不是“可浪费的资源”，而是可承担的合理风险。团队可以利用它来平衡功能发布与系统稳定性。

二、如何制定合理的 SLO

2.1 从用户旅程出发

SLO 必须覆盖关键用户路径，而非所有技术接口。将用户旅程拆解为关键交互点，并为每个点定义 SLI。

用户旅程示例：电商下单

  • 浏览商品 → 要求页面加载延迟 < 2s
  • 加入购物车 → API 成功率 > 99.99%
  • 提交支付 → 支付接口成功率 > 99.95%，延迟 < 500ms

只对直接体现用户体验的指标设置 SLO，避免资源浪费在低价值指标上。

2.2 选择正确的测量方式

  • 基于计数：适合可用性、成功率，将交互分为“好”与“坏”。
  • 基于分位值：适合延迟指标，如 P95、P99 延迟。直接用百分位定义 SLO：“99%的请求延迟低于 300ms”。
  • 谨慎使用平均值：均值会掩盖长尾问题，不适合用于承诺。

2.3 确定初始 SLO 数值

初学者可遵循“过去表现 + 合理预期”原则：

  1. 收集 4 周以上 SLI 数据，观察性能曲线。
  2. 定位峰值和低谷，不基于最优表现设定 SLO。
  3. 设定略低于当前表现的目标，为不可预测的故障留出空间。例如，过去 30 天可用性为 99.99%，初始 SLO 可设为 99.95%。
  4. 与干系人协商，SLO 是对业务方的一种可靠性承诺，数值需得到业务认可。

2.4 多级 SLO 策略

并非所有服务都需要同一级别的 SLO。可对服务进行分级：

  • 关键服务（如支付）：SLO 要求极高，错误预算严格。
  • 重要服务（如搜索）：可承受短暂降级，错误预算稍宽松。
  • 后台服务：仅需内部目标，甚至不对外承诺。

三、错误预算的深度解读

错误预算将“可靠性风险”货币化，使团队能够进行有数据支撑的决策。

3.1 错误预算的消耗与计量

消耗动作：

  • 计划外停机或事故。
  • 发布有缺陷的版本导致错误率上升。
  • 性能退化导致延迟 SLO 突破。

计量方式： 在时间窗口内累计所有违反 SLO 的事件所占用的错误预算。例如一个 0.1% 的错误预算中，一次持续 10 分钟的完全中断直接消耗约 10 分钟可用性预算，如果月度预算为 43 分钟，则该事件占据了约 23% 的预算。

剩余预算的可视化： 团队需要仪表板实时显示剩余错误预算百分比，当预算剩余低于某个阈值（如 50%、20%）时触发告警。

3.2 使用错误预算指导发布决策

错误预算的核心功能是调节发布速率：

  • 预算充足（>50% 剩余）：团队可以按计划正常进行功能发布、实验和变更。
  • 预算消耗过快（20%-50% 剩余）：需要提高发布标准，加强审查和灰度过程，限制风险变更。
  • 预算已耗尽或极度危险（<20% 剩余）：应暂停所有主动变更，全力投入到恢复可靠性的行动中，直到预算重新积累为止。

这种机制创造了开发速度与稳定性的客观平衡器，消除了团队间“快速迭代 vs. 保持稳定”的主观争吵。

3.3 预算耗尽后的处理准则

当错误预算降为零或负数时，必须执行可靠性冻结（Reliability Freeze）：

  • 停止一切非紧急的功能上线。
  • 全部研发资源转向改进可靠性、增加自动化测试、改善监控、优化架构等。
  • 恢复预算的唯一方法是让系统在新时间窗口内稳定下来，并自然累积新的预算。

极端情况下，团队可提前协商“预算借支”策略，例如允许透支下个周期的部分预算来发布紧急安全补丁，这必须有高层批准并承担风险。

四、实践中的关键挑战与应对

4.1 SLI 数据失真

问题：监控数据不准确，或未过滤掉噪音（如健康检查、客户端超时）。 对策：规范数据采集标准，清洗无效流量。确保 SLI 衡量的是“有效请求”的质量。

4.2 SLO 过于宽松或苛刻

  • 过于宽松：错误预算永远用不完，失去约束意义，无法反映真实用户体验。
  • 过于苛刻：轻微波动就耗尽预算，导致频繁冻结，扼杀开发产出。 调整方法：每季度复审 SLO，结合事故回顾和用户投诉数据来修正目标。

4.3 多组件依赖的预算合并

单个服务可能依赖多个下游服务。此时 SLO 设计需考虑：

  • 客户端错误预算通常应比服务端更严格，因为下游故障会叠加。
  • 可以将端到端用户请求 SLI 直接作为最顶层 SLO，简化责任归属。

4.4 文化与组织障碍

错误预算的有效运作依赖于“不必追责”的文化。它不是用来考核团队绩效的工具，而是促进从错误中学习的工程控制机制。需要管理层明确传达：错误预算消耗是一种正常的工程现象，目的是驱动可靠性投资。

五、总结：从量化到决策的闭环

SLO 与错误预算共同构建了一个负反馈控制系统：

  1. 定义用户为中心的 SLI。
  2. 设定可度量的 SLO。
  3. 计算出基于时间的错误预算。
  4. 实时监控预算消耗。
  5. 根据剩余预算决策：可接受风险则继续发布；风险过高则转向稳固可靠性。

通过这一流程，可靠性不再是一个事后补救的状态，而是成为产品迭代中可预测、可管理的一等公民。对于任何希望实践 Site Reliability Engineering（SRE）思想的团队而言，掌握错误预算与 SLO 的制定正是从“救火”转向“工程”的第一步。