3. SLO 基础：定义、设定方法与 SLI 关系
SLO（Service Level Objective，服务等级目标）是 SRE 实践中的核心决策锚点。它不是一个简单的“可用性数字”，而是将用户对系统可靠性的主观期望，转化为可量化、可追踪、可问责的客观阈值。理解 SLO 的本质、设定方法及其与 SLI 的关系，是后续量化 Error Budget 的前提。
3.1 什么是 SLO
SLO 是附着在 SLI（服务等级指标）上的目标值或目标范围。它回答了这样一个问题：“在给定的时间窗口内，我们的服务应该有多好？”
- 核心定义：SLO = SLI 的预期目标。例如，“99.9% 的请求在 200ms 内完成”。
- 业务视角：SLO 是产品经理、开发团队与 SRE 团队之间签订的“可靠性契约”。
- 技术视角：SLO 是触发告警、分配运维资源、决定发布节奏的量化依据。
- 关键特征：SLO 必须是一个时间窗口内的百分比（如过去 30 天内的 99.95%），而非瞬时值。
常见误区：不要将 SLO 设定为 100%。100% 意味着系统不允许任何故障，这会导致极高的成本、极慢的迭代速度，且通常无法被用户感知。SLO 的本质是“在可靠性与创新速度之间找到最佳平衡点”。
3.2 SLO 的设定方法
设定 SLO 是一个自上而下与自下而上相结合的迭代过程。以下是业界通用的四步法：
- 定义用户旅程：识别用户最核心、最频繁的操作路径（如登录、搜索、下单、支付）。SLO 应围绕这些关键旅程定义，而非所有后台接口。
- 确定 SLI 指标：为每个用户旅程选择 1-2 个最能反映其健康状况的 SLI（如可用性、延迟）。
- 设定目标阈值：基于历史数据、业务容忍度、技术成本，设定具体的百分比目标。
- 建立反馈循环：SLO 不是一成不变的。随着系统演进和用户期望变化，应定期（如每季度）复盘并调整 SLO。
下表对比了不同场景下 SLO 设定的典型差异：
| 场景 | 典型 SLI | 常见 SLO | 设定依据 |
|---|---|---|---|
| 核心支付链路 | 成功率 | 99.99% | 金融级合规、直接收入损失 |
| 用户信息查询 | 延迟 (P99) | 99.9% 请求 < 500ms | 用户体验敏感度 |
| 后台批量任务 | 完成率 | 99.5% | 非实时、可重试 |
| 内部开发工具 | 可用性 | 99.0% | 容忍度较高、成本敏感 |
设定原则：SLO 应比用户实际能感知的“底线”略高一点。例如，如果用户能容忍 1 秒的延迟，SLO 可以设定为 P99 500ms。这为 Error Budget 留出了缓冲空间，确保在 SLO 达标时，用户体验依然是良好的。
3.3 SLO 与 SLI 的关系
SLI 是“测量什么”，SLO 是“测量结果应该达到什么标准”。两者是度量与目标的关系，缺一不可。没有 SLI，SLO 就是空中楼阁；没有 SLO，SLI 就失去了决策意义。
下图清晰地展示了 SLI、SLO 与 Error Budget 之间的逻辑链条：
从图中可以提炼出三个关键关系：
- SLI 是 SLO 的输入：没有可靠的 SLI 数据，SLO 无法被度量，也就失去了存在的意义。
- SLO 是 Error Budget 的源头：Error Budget 的数学定义就是
1 - SLO。SLO 越严格（越接近 100%），Error Budget 越小，团队在发布新功能时就越谨慎。 - SLO 驱动决策：当 Error Budget 耗尽时，SLO 成为“停止发布、优先恢复”的触发条件。SLO 将抽象的可靠性转化为具体的运维行动。
常见陷阱：SLI 与 SLO 的错配
如果 SLI 定义得过于宽泛（例如，将整个数据中心的可用性作为一个 SLI），那么 SLO 将无法反映单个用户旅程的真实体验。正确的做法是：SLI 要细，SLO 要准。每个关键用户旅程都应有独立的 SLI 和对应的 SLO。
如果 SLI 定义得过于宽泛（例如，将整个数据中心的可用性作为一个 SLI），那么 SLO 将无法反映单个用户旅程的真实体验。正确的做法是：SLI 要细，SLO 要准。每个关键用户旅程都应有独立的 SLI 和对应的 SLO。