1. SLO 基础概念：服务等级目标
在 SRE 体系中，服务等级目标（Service Level Objective, SLO） 是衡量服务可靠性的核心量化指标。它不是一个简单的“可用性百分比”，而是定义了用户对服务可靠性的合理期望，并将这种期望转化为可度量、可追踪、可问责的工程目标。
1.1 SLI、SLO 与 SLA 的定义与关系
要理解 SLO，必须先厘清它与 SLI、SLA 之间的层次关系。下表总结了三个核心概念的定义与区别：
| 概念 | 英文全称 | 定义 | 典型示例 |
|---|---|---|---|
| SLI | Service Level Indicator | 服务等级指标，是服务质量的原始度量，反映服务的某个具体维度表现 | 请求延迟 P99 = 200ms；错误率 = 0.1% |
| SLO | Service Level Objective | 服务等级目标，是 SLI 的目标阈值，代表服务所有者承诺达到的可靠性水平 | 99.9% 的请求延迟 ≤ 200ms（月度） |
| SLA | Service Level Agreement | 服务等级协议，是对外承诺，通常包含未达标的惩罚条款 | 若月度可用性 < 99.9%，退还 10% 月费 |
关键认知： SLO 是内部工程目标，通常比 SLA 更严格（SLO 阈值 ≤ SLA 阈值）。SRE 团队通过管理 SLO 来确保 SLA 不被违反，从而避免业务损失。
1.2 SLI 与 SLO 的映射关系
SLI 是 SLO 的“原材料”。一个 SLO 必须绑定至少一个 SLI，并定义该 SLI 在特定时间窗口内的目标阈值。下图展示了从原始指标到 SLO 的完整映射链路：
1.3 SLO 在 SRE 体系中的核心地位
SLO 不是孤立的指标，而是整个 SRE 可靠性工程的中枢神经。它连接了用户期望、工程决策、运维响应和业务风险。以下从四个维度阐述 SLO 的核心地位：
- 决策锚点： SLO 决定了“多可靠才算足够”。它帮助团队在新功能开发与可靠性投入之间做出量化权衡，避免过度运维或可靠性不足。
- 错误预算引擎： SLO 直接衍生出错误预算（Error Budget）——即 SLO 允许的失败时间。错误预算的消耗速率驱动发布节奏、回滚决策和故障优先级。
- 故障响应触发器： 当 SLI 持续逼近或违反 SLO 阈值时，触发告警升级和复盘机制。SLO 违约是 MTTR 复盘的核心输入事件。
- 组织对齐工具： SLO 将抽象的“可靠性”转化为跨团队（开发、运维、产品）可理解的共同语言，统一考核标准。
课程关联： 本课程的核心机制——SLO 违约指标融入 MTTR 复盘口径——正是基于 SLO 的“触发-响应-复盘”链路。只有深刻理解 SLO 的定义与地位，才能设计出有效的自动复盘规则。
1.4 SLO 的常见类型与度量维度
根据服务类型和用户关注点，SLO 通常覆盖以下三个核心维度：
| 维度 | 典型 SLI | 常见 SLO 示例 | 适用场景 |
|---|---|---|---|
| 可用性 | 成功请求占比 | 月度可用性 ≥ 99.95% | API 网关、数据库、核心微服务 |
| 延迟 | 请求响应时间（P50/P95/P99） | 99% 的请求延迟 ≤ 500ms | 用户交互页面、搜索服务、实时推荐 |
| 吞吐量 | 每秒请求数（RPS）或每秒事务数（TPS） | 峰值吞吐量 ≥ 10000 RPS | 秒杀系统、流媒体服务、消息队列 |
1.5 SLO 违约与 MTTR 复盘的关联
在 SRE 实践中，SLO 违约事件是触发正式复盘的最强信号。下图展示了 SLO 违约如何驱动 MTTR 复盘流程：
常见误区： 不要将 SLO 等同于“可用性 99.9%”。SLO 是多维度的（延迟、错误率、吞吐量），且必须基于用户视角定义。一个服务可能可用性达标，但延迟 SLO 已严重违反，同样需要触发复盘。
1.6 小结：SLO 是自动复盘的“第一性原理”
本章建立了 SLO 的基础认知框架：
- SLI → SLO → SLA 构成可靠性度量的三层体系，SLO 是内部工程目标的核心。
- SLO 在 SRE 体系中扮演决策锚点、错误预算引擎、故障触发器、组织对齐工具四大角色。
- SLO 违约事件是 MTTR 复盘流程的量化触发点，违约指标将直接融入复盘口径，实现从“定性复盘”到“定量复盘”的升级。