1. SLO 基础概念：服务等级目标
服务等级目标（Service Level Objective，SLO）是现代站点可靠性工程（SRE）与可观测性体系的核心度量。它不是一个简单的百分比数字，而是团队与业务之间关于“系统应该多可靠”的明确契约。理解 SLO 之前，必须先厘清它与 SLA、SLI 的三角关系。
1.1 定义：什么是 SLO？
SLO 是服务提供方为其内部或外部用户设定的、在一段评估窗口内必须达到的可靠性阈值。它通常由一个或多个服务等级指标（SLI）聚合而成，并以目标百分比的形式表达。
核心公式： SLO = 良好事件计数 ÷ 总事件计数 × 100% （在评估窗口内）
例如：
- API 延迟 SLO： 过去 30 天内，99.9% 的请求在 200ms 内完成。
- 可用性 SLO： 每月服务正常运行时间不低于 99.99%。
- 数据管道 SLO： 99.5% 的遥测数据在 60 秒内到达后端存储。
1.2 SLO 与 SLA、SLI 的关系
这三个概念构成一个金字塔结构：SLI 是底层指标，SLO 是目标阈值，SLA 是业务承诺。下表清晰展示了三者的区别与联系：
| 维度 | SLI（服务等级指标） | SLO（服务等级目标） | SLA（服务等级协议） |
|---|---|---|---|
| 定义 | 衡量服务质量的量化指标 | SLI 的目标阈值 | 与客户签订的正式合同 |
| 示例 | 请求延迟 P99 = 180ms | P99 延迟 ≤ 200ms（99.9%） | 若低于 99.9%，赔付 10% 月费 |
| 受众 | 工程师、可观测性平台 | 工程团队、产品经理 | 法务、客户、商业团队 |
| 严格程度 | 客观测量，无承诺 | 内部目标，可调整 | 法律约束，有罚则 |
| 典型窗口 | 实时/分钟级 | 30 天滚动 | 月度/季度 |
关键认知： SLO 通常比 SLA 更严格。团队内部设定 99.9% 的 SLO，对外 SLA 可能只承诺 99.5%，预留 0.4% 的“错误预算缓冲”用于发布和实验。
1.3 为什么 SLO 对现代系统至关重要？
在微服务、云原生和 OpenTelemetry 管道日益复杂的背景下，SLO 已经从“可选指标”演变为“生存必需品”。以下是五个核心原因：
- 量化用户体验： 将模糊的“系统很慢”转化为具体的“P99 延迟 200ms”，让团队有统一的判断标准。
- 指导容量规划： 当 SLO 逼近阈值时，自动触发扩容或管道优化，避免盲目过度配置。
- 平衡可靠性与创新： 通过错误预算（Error Budget = 100% - SLO），允许团队在预算内安全地发布新功能。
- 降低告警噪音： 基于 SLO 的告警（Burn Rate Alerting）比静态阈值告警更精准，减少 70% 以上的无效告警。
- 驱动可观测性投资： 明确哪些 SLI 需要高基数、低延迟的遥测数据，直接指导 OpenTelemetry 管道的采样策略和资源分配。
常见误区： 不要为每个指标都设置 SLO。选择 3-5 个与用户旅程直接相关的关键 SLI（如登录延迟、搜索成功率、支付可用性），否则 SLO 会变成管理负担而非工程工具。
1.4 SLO 与 OpenTelemetry 管道的关联
在《SLO目标与OpenTelemetry管道容量规划》课程中，SLO 是管道设计的第一性原理。下图展示了从用户请求到 SLO 评估的完整数据流：
上图揭示了课程的核心逻辑：用户请求经过微服务产生遥测数据 → OTel 管道负责采集、采样和导出 → 后端存储用于 SLO 评估 → 评估结果反馈调整管道容量。没有 SLO，管道容量规划就失去了量化依据；没有管道，SLO 评估就缺乏高质量的数据输入。
1.5 小结：SLO 是容量规划的锚点
在本课程中，SLO 将贯穿始终：
- 第 2-3 章： 学习如何定义高质量的 SLI 并设置合理的 SLO 阈值。
- 第 4-6 章： 基于 SLO 设计 OpenTelemetry 管道的采样策略和背压机制。
- 第 7-10 章： 通过 SLO 错误预算驱动管道的自动扩缩容和成本优化。
一句话总结： SLO 将“系统可靠性”从模糊的愿望转化为可测量、可预算、可规划的工程参数，是 OpenTelemetry 管道容量规划的唯一合理起点。