1. SLO 基础概念：什么是 SLO、SLI、SLA
在开始构建可观测性与异常检测联动体系之前，必须首先理解三个核心概念：SLI（服务等级指标）、SLO（服务等级目标）和 SLA（服务等级协议）。它们是现代运维体系中衡量服务质量、驱动可靠性改进的基石。
1.1 核心定义
| 概念 | 英文全称 | 定义 | 典型示例 |
|---|---|---|---|
| SLI | Service Level Indicator | 对服务某个维度的量化测量指标，是原始数据 | 请求延迟 P99 = 200ms |
| SLO | Service Level Objective | 对 SLI 设定的目标阈值或范围，是内部承诺 | 99.9% 的请求延迟 ≤ 200ms |
| SLA | Service Level Agreement | 与客户签订的正式协议，包含未达标的惩罚条款 | 月度可用性 ≥ 99.99%，否则赔偿 10% 月费 |
关键区别速记： SLI 是“测什么”，SLO 是“目标值是多少”，SLA 是“做不到会怎样”。
1.2 三者的关系与层级
SLI、SLO、SLA 构成了一个从测量到承诺的递进关系。SLI 是底层数据，SLO 是内部可靠性目标，SLA 是面向客户的法律约束。通常一个 SLA 会包含多个 SLO，而每个 SLO 又由若干 SLI 支撑。
1.3 为什么 SLO 对现代运维至关重要
在微服务、云原生和 DevOps 环境下，SLO 已经从“可选”变为“必需”。以下是 SLO 带来的核心价值：
- 量化可靠性：将模糊的“系统稳定”转化为可测量的数字指标，避免主观判断。
- 指导运维优先级：当多个告警同时发生时，SLO 帮助团队判断哪个问题对用户影响最大。
- 驱动错误预算：SLO 定义了可接受的错误上限（即错误预算），团队可以在预算内进行发布和变更，超出则停止发布。
- 对齐业务与工程：SLO 将用户体验（如页面加载时间）与工程指标（如 API 延迟）直接关联。
- 异常检测的基准：SLO 为 OpenTelemetry 异常检测提供了明确的“正常”边界，超出即触发告警。
实践建议： 从最核心的用户旅程（如登录、下单、支付）开始定义 SLI，设置保守的 SLO（如 99.9%），再逐步收紧。不要一开始就追求 99.999%。
1.4 常见 SLI 类型与 SLO 示例
| SLI 类型 | 测量方式 | 典型 SLO 示例 |
|---|---|---|
| 可用性 | 成功请求数 / 总请求数 | 月度可用性 ≥ 99.99% |
| 延迟 | 请求响应时间的百分位值 | P99 延迟 ≤ 500ms（30 天滚动窗口） |
| 错误率 | HTTP 5xx / 总请求数 | 错误率 ≤ 0.1%（10 分钟窗口） |
| 吞吐量 | 每秒请求数（RPS） | 峰值吞吐量 ≥ 1000 RPS |
| 饱和度 | CPU / 内存 / 连接池使用率 | CPU 使用率 ≤ 80% |
1.5 SLO 与 OpenTelemetry 的天然联系
OpenTelemetry 提供了标准化的遥测数据采集（Traces、Metrics、Logs），这些数据正是计算 SLI 的原始来源。通过 OpenTelemetry 的 Metrics API 和 Exemplar 机制，可以精确计算延迟分布、错误计数等 SLI，进而实时评估 SLO 达成状态。
常见误区： 不要将 SLA 直接当作 SLO 使用。SLA 通常比 SLO 宽松（因为涉及赔偿），内部团队应该使用更严格的 SLO 来驱动改进。例如：SLA 承诺 99.9%，内部 SLO 应设为 99.95% 或更高。
1.6 本章小结
- SLI 是量化指标，SLO 是目标阈值，SLA 是客户协议。
- SLO 是连接可观测数据（OpenTelemetry）与运维决策（异常检测、告警、发布）的关键桥梁。
- 现代运维中，SLO 驱动错误预算、指导故障优先级、对齐业务目标，是可靠性工程的核心工具。
- 下一章将深入讲解如何基于 OpenTelemetry 的 Metrics 数据定义和采集 SLI。