1. SLO 基础概念：什么是 SLO、SLI、SLA
在可靠性工程体系中，SLO（Service Level Objective，服务等级目标）、SLI（Service Level Indicator，服务等级指标）和SLA（Service Level Agreement，服务等级协议）是三个最基础、最核心的概念。理解三者的定义、区别与联系，是构建可靠性运营体系的起点。
1.1 核心定义
| 术语 | 英文全称 | 核心定义 | 典型示例 |
|---|---|---|---|
| SLI | Service Level Indicator | 服务质量的可量化度量指标，直接反映用户体验的某个维度 | 请求延迟 P99 ≤ 200ms；请求成功率 ≥ 99.9% |
| SLO | Service Level Objective | 团队为 SLI 设定的目标阈值，是内部可靠性承诺 | 过去 30 天内，P99 延迟 ≤ 200ms 的时间占比 ≥ 99.5% |
| SLA | Service Level Agreement | 服务提供商与客户之间的正式合同承诺，通常附带惩罚条款 | 月度可用性 ≥ 99.9%，否则退还 10% 月费 |
记忆口诀：SLI 是“测什么”，SLO 是“目标值是多少”，SLA 是“对外承诺了什么”。
1.2 三者的区别与联系
三者的关系可以用“度量 → 目标 → 承诺”的递进链条来理解。SLI 是原始数据，SLO 是基于 SLI 设定的内部目标，SLA 则是基于 SLO 对外签署的正式协议。
1.3 为什么 SLO 是可靠性运营的核心
在可靠性工程实践中，SLO 之所以成为运营核心，是因为它解决了传统运维中“没有量化标准”和“过度追求 100% 可用性”两个根本问题。
- 量化决策依据：SLO 将“系统是否可靠”从主观判断转化为客观数据，让团队可以基于指标做决策。
- 错误预算机制：SLO 定义了可接受的故障时间窗口（错误预算），团队可以在预算内放心发布新功能，而不必因恐惧故障而停滞创新。
- 优先级对齐：当多个项目争夺资源时，SLO 帮助团队判断哪些故障对用户体验影响最大，从而合理分配修复优先级。
- 客户期望管理：SLO 是内部目标，比 SLA 更严格，确保团队在对外承诺之前有足够的可靠性余量。
核心观点：SLO 不是“追求完美”，而是“定义足够好”。它让团队在可靠性与创新速度之间找到最佳平衡点。
1.4 SLO 在可靠性运营中的位置
下图展示了 SLO 在可靠性运营闭环中的核心位置，它连接了用户感知、指标采集、告警响应和持续改进四个环节。
1.5 常见误区与避坑
常见误区 1：将 SLA 直接当作 SLO 使用。SLA 是法律合同，修改成本高；SLO 是内部目标，应比 SLA 更严格，为故障留出缓冲空间。
常见误区 2：SLI 定义过于复杂。建议每个服务只定义 3~5 个核心 SLI，过多指标会导致运维成本激增且难以聚焦。
常见误区 3：SLO 设定为 100%。100% 的目标意味着零故障容忍，会导致团队过度保守、不敢发布新功能，反而降低整体交付效率。
1.6 本章小结
| 概念 | 一句话总结 | 运营作用 |
|---|---|---|
| SLI | 服务质量的量化指标 | 提供数据基础 |
| SLO | 内部可靠性目标阈值 | 驱动运营决策 |
| SLA | 对外合同承诺 | 法律约束与客户保障 |