1. SLO 基础概念：服务等级目标
服务等级目标（Service Level Objective, SLO）是现代站点可靠性工程（SRE）与可观测性体系的核心度量。它不是一个简单的百分比数字，而是服务健康状态的量化契约，直接决定了告警的触发时机、故障的响应优先级以及团队的稳定性投入方向。
1.1 SLO 定义与核心公式
SLO 是服务提供方为其内部或外部用户承诺的特定指标在给定时间窗口内达到的目标值。通常以“好事件”占总事件的百分比表示：
SLO = (好事件计数 / 总事件计数) × 100%
例如：过去 30 天内，99.9% 的 HTTP 请求在 200ms 内完成。
例如：过去 30 天内，99.9% 的 HTTP 请求在 200ms 内完成。
一个完整的 SLO 声明包含三个要素：
| 要素 | 说明 | 示例 |
|---|---|---|
| 指标（SLI） | 衡量服务质量的量化指标 | 请求延迟 P99、错误率、可用性 |
| 目标值 | 好事件占比的阈值 | ≥ 99.9% |
| 时间窗口 | 统计周期（滚动窗口或日历窗口） | 过去 28 天滚动窗口 |
1.2 SLO 与 SLA / SLI 的关系
这三者构成了服务等级管理体系中的度量-目标-承诺三层结构。理解它们的区别是设计有效 SLO 的前提。
1.3 为什么需要 SLO
在传统运维模式中，团队往往依赖“所有指标都正常”或“没有告警”来判断服务健康度。这种模式存在三个致命缺陷：
- 告警疲劳：阈值设得太紧导致频繁误报，设得太松又漏报真实故障。
- 缺乏量化标准：无法回答“服务到底有多好”或“这次发布是否降低了稳定性”。
- 资源分配盲目：团队不知道应该优先优化延迟还是提升可用性。
SLO 从三个维度解决了这些问题：
| 维度 | 没有 SLO 的痛点 | 有 SLO 后的收益 |
|---|---|---|
| 告警管理 | 基于固定阈值的告警风暴 | 基于错误预算消耗率的智能告警 |
| 决策依据 | 凭感觉判断服务健康度 | 用 SLO 达成率做数据驱动决策 |
| 团队协作 | 开发与运维目标冲突 | 统一用 SLO 对齐稳定性目标 |
| 风险控制 | 无法量化故障影响范围 | 错误预算量化可承受的风险 |
1.4 错误预算：SLO 的衍生概念
错误预算（Error Budget）是 SLO 最直接的应用产物，定义为 100% - SLO。它量化了服务在给定时间窗口内允许失败的总量。
实战案例： 某 API 服务 SLO 为 99.9%（30 天窗口），则错误预算为 0.1%。30 天总请求数约 4.32×10⁶ 次，允许失败约 4,320 次。当错误消耗超过预算的 70% 时，触发 P1 告警；消耗超过 100% 时，冻结所有非紧急发布。
错误预算的消耗速率是 Prometheus 告警规则中最核心的输入指标，后续章节将详细展开如何用 PromQL 计算实时消耗率。
1.5 常见 SLO 类型与选择建议
不同服务类型适合不同的 SLO 指标组合。以下是生产环境中常见的 SLO 分类：
- 可用性 SLO：服务正常响应请求的时间占比。适用于负载均衡器、网关、数据库。
- 延迟 SLO：请求在指定时间内完成的占比。适用于 API 服务、搜索服务、实时处理管道。
- 吞吐量 SLO：单位时间内成功处理请求的数量。适用于批处理系统、消息队列。
- 数据新鲜度 SLO：数据从产生到可查询的最大延迟。适用于数据仓库、流计算平台。
- 错误率 SLO：返回错误响应的请求占比。适用于所有 HTTP/gRPC 服务。
避坑提示： 不要为每个指标都设置 SLO。选择最能直接反映用户体验的 2~3 个指标即可。过多的 SLO 会导致告警规则复杂化，反而降低团队响应效率。