什么是"SLA、SLO、SLI"

三个概念

SLI（Service Level Indicator，服务水平指标）

你要测量什么？ 一个具体的、可量化的指标。

例如：

• 请求的成功率；
• 响应时间低于 200ms 的请求比例；
• 数据处理的延迟。

SLO（Service Level Objective，服务水平目标）

你要达到什么水平？ SLI 的目标值。

例如：

• "99.9% 的请求在 500ms 内返回"；
• "月度可用性 99.95%"。

SLA（Service Level Agreement，服务水平协议）

如果达不到，会有什么后果？ 一个有商业/法律后果的承诺。

通常是与客户签订的合同：达不到 SLO 就退款、赔偿。

关系

SLI 是测量，SLO 是内部目标，SLA 是对外承诺。

一个常见的实践：

SLA 的承诺应该比 SLO 更宽松。

例如：内部 SLO 是 99.95%，对客户的 SLA 是 99.9%。

这样 SLO 提供了一个缓冲——当指标开始下滑时，团队在违反 SLA（触发赔偿）之前就能收到告警并介入。

选择好的 SLI

原则：从用户视角出发。

用户不关心"CPU 使用率"或"数据库连接数"——他们关心：

• 请求是否成功；
• 是否够快；
• 功能是否可用。

常见的 SLI 类型：

• 可用性：成功请求数 / 总请求数；
• 延迟：低于阈值 X 的请求占比（注意：用分位数或占比，而不是平均值——前文提到过平均值的误导性）；
• 质量：如"返回完整结果而非降级结果"的比例；
• 吞吐量：系统能处理的 QPS；
• 新鲜度：数据的更新延迟（对数据管道重要）。

设定 SLO 的原则

一、不是越高越好

把可用性从 99.9% 提到 99.99%，成本可能增加数倍（需要更强的冗余、更严格的变更管理、更多的运维投入）。

"几个九"的商业价值，应该与其成本权衡。

几个常见的可用性等级对应的年停机时间：

二、应该是一个范围，而非单点

可以定义：

• 目标：99.95%（努力方向）；
• 底线：99.9%（超过就要采取行动）。

三、SLO 应该有所有者

谁负责达成？谁有权在可靠性和功能速度之间做权衡？

错误预算（Error Budget）

这是 SLO 最有价值的应用之一。

如果 SLO 是 99.9%，那么就允许 0.1% 的失败——这 0.1% 就是错误预算。

用途：

• 只要错误预算还有剩余，就可以加快发布（接受一定风险）；
• 当错误预算耗尽，冻结变更，把精力转向稳定性工作。

这把"可靠性 vs 速度"的争论，变成了一个数据驱动的机制——不再靠感觉争论，而是看预算还剩多少。

与告警的关系

SLO 应该驱动告警。

基于错误预算的告警（Google SRE 提倡的 多窗口、多消耗率告警）：

• 不是"错误率 > X% 就告警"，而是"错误预算的消耗速度过快就告警"；
• 例如：在过去 1 小时内消耗了 2% 的月度预算 → 按这个速度，预算会在 2 天内耗尽 → 告警。

为什么这样更好：

• 它关注的是"是否威胁到 SLO"，而不是任意设的阈值；
• 避免了短暂波动造成的误报；
• 也避免了长期缓慢劣化被忽略（用一个长窗口捕捉）。

一个常见错误

"我们的 SLO 是 100% 可用。"

这是不可能的，也是有害的——因为：

• 任何系统都会失败；
• 追求 100% 会让团队不敢做任何变更（因为任何变更都有风险）；
• 反而降低了交付速度和长期质量。

更好的表述："我们的目标是 99.9%，并且我们有明确的错误预算管理流程。"

一句话

SLO 把"系统要稳定"这个模糊的愿望，变成了一个可度量、可管理、可用于决策的工具。

说明：本文为 SRE 实践的知识整理。