2. SLO 基础概念：SLI、SLO、错误预算与 SLA 的区别
在平台工程团队中，SLO（Service Level Objective）是连接用户期望与系统可靠性的核心契约。要正确制定 SLO，必须先理解其底层组件：SLI（服务水平指标）、错误预算，以及它与传统 SLA（服务水平协议）的本质区别。本节将逐一拆解这些概念，并给出平台工程场景下的实战映射。
2.1 服务水平指标（SLI）—— 可靠性的可量化度量
SLI 是对服务某个特定维度的量化测量，通常是“好事件 / 总事件”的比率。平台工程团队需要为每个关键用户旅程定义 SLI。
SLI 通用公式： SLI = 符合预期标准的请求数 / 总请求数 × 100%
常见的 SLI 维度包括：
| 维度 | 典型指标 | 平台工程示例 |
|---|---|---|
| 可用性 | 请求成功率 | API Gateway 返回 2xx/3xx 的比率 |
| 延迟 | P95 / P99 响应时间 | 开发者自服务门户页面加载时间 ≤ 2s |
| 吞吐量 | 每秒请求数（RPS） | CI/CD Pipeline 每分钟构建触发次数 |
| 准确性 | 数据一致性比率 | 服务目录中资源状态与真实环境一致的比例 |
| 新鲜度 | 数据延迟时间 | 平台成本数据更新延迟 ≤ 15 分钟 |
平台工程实践建议： 每个平台服务至少定义 2-3 个 SLI，优先覆盖“可用性”和“延迟”两个维度。SLI 的测量窗口通常为滚动 30 天。
2.2 服务水平目标（SLO）—— 可靠性的目标阈值
SLO 是为 SLI 设定的目标值，表示“我们希望服务达到多可靠”。SLO 通常以百分比形式定义，并附带一个时间窗口。
SLO 标准格式： [SLI 名称] ≥ [目标值]% 在 [时间窗口] 内
平台工程团队典型 SLO 示例：
- API 可用性 SLO： 平台 API 请求成功率 ≥ 99.9% 在 30 天滚动窗口内
- 延迟 SLO： P95 响应时间 ≤ 500ms 在 7 天滚动窗口内
- 管道成功率 SLO： CI/CD 构建成功率 ≥ 95% 在 30 天滚动窗口内
常见陷阱： 不要将 SLO 设定为 100%。100% 的目标意味着零故障容忍，会导致过度工程化、成本失控，且无法指导错误预算决策。平台工程团队建议从 99.9% 开始，逐步调整。
2.3 错误预算 —— 可靠性的“风险预算”
错误预算 = 100% - SLO。它表示在 SLO 时间窗口内，服务可以“出错”的最大时间量或请求量。错误预算将可靠性从“目标”转化为“可消耗的资源”。
| SLO 目标 | 错误预算（30 天） | 错误预算（7 天） | 平台工程含义 |
|---|---|---|---|
| 99.9% | 43.2 分钟 | 10.1 分钟 | 每月可接受约 43 分钟的平台不可用 |
| 99.95% | 21.6 分钟 | 5.0 分钟 | 适合核心基础设施服务 |
| 99.99% | 4.3 分钟 | 1.0 分钟 | 仅用于关键控制平面 |
错误预算的核心价值： 当错误预算充足时，团队可以安全地部署新功能、进行实验；当错误预算耗尽时，团队应冻结发布，优先进行稳定性工作。这为平台工程团队提供了数据驱动的发布决策机制。
2.4 SLO 与 SLA 的区别
SLA（Service Level Agreement）是法律/商业契约，而 SLO 是技术/工程目标。两者经常被混淆，但用途和约束力完全不同。
| 对比维度 | SLO（服务水平目标） | SLA（服务水平协议） |
|---|---|---|
| 性质 | 内部技术目标 | 外部法律/商业契约 |
| 约束力 | 无惩罚，团队自律 | 有惩罚条款（如服务抵扣、罚款） |
| 受众 | 平台工程团队、SRE | 客户、业务方、法务 |
| 严格程度 | 通常比 SLA 更严格（内部目标 > 外部承诺） | 通常比 SLO 宽松（留有余地） |
| 变更频率 | 可随服务演进调整 | 合同期内固定，变更需双方同意 |
| 平台工程示例 | 内部 SLO：API 可用性 ≥ 99.95% | 对外 SLA：API 可用性 ≥ 99.9%（含赔偿条款） |
平台工程最佳实践： 始终将内部 SLO 设定得比对外 SLA 更严格（例如 SLO = 99.95%，SLA = 99.9%）。这为团队提供了缓冲空间，确保即使 SLO 偶尔未达标，SLA 仍可满足，避免触发赔偿。
2.5 概念关系总结
四个概念构成一个完整的可靠性管理闭环：
- SLI 告诉你“现在怎么样”（测量）
- SLO 告诉你“应该怎么样”（目标）
- 错误预算 告诉你“还剩多少犯错空间”（风险预算）
- SLA 告诉你“对外承诺了什么”（商业契约）
平台工程团队常见误区： 不要用 SLA 替代 SLO。SLA 是商业底线，SLO 是工程指南。只关注 SLA 会导致团队在 SLA 边缘试探，缺乏持续改进的动力。始终以 SLO 为内部驱动力。