3. SLO 基础概念：定义、目标值设定方法与常见误区
SLO（Service Level Objective，服务等级目标）是 SLI 与 Error Budget 之间的桥梁。它不是一个简单的“可用性百分比”，而是一套带有时间窗口、统计方法和业务语义的量化承诺。理解 SLO 的定义、设定方法和常见陷阱，是构建有效质量门禁的前提。
3.1 SLO 的定义与核心要素
SLO 是对一个或多个 SLI 的目标值的正式声明，通常表述为：“在 [时间窗口] 内，[SLI 指标] 的 [统计方法] 应达到 [阈值]”。
| 要素 | 说明 | 示例 |
|---|---|---|
| SLI 指标 | 被测量的具体服务质量维度 | 请求延迟、错误率、吞吐量 |
| 统计方法 | 聚合与评估数据的方式 | 百分位数（p99）、平均值、最小值 |
| 目标阈值 | 期望达到的数值边界 | ≤ 200ms、≥ 99.9% |
| 时间窗口 | 评估目标是否达成的周期 | 30 天滚动窗口、28 天日历月 |
| 合规条件 | 如何判定目标达成 | 窗口内 99% 的时间满足阈值 |
关键认知：SLO 不是“必须 100% 达标”的承诺，而是“在统计意义上，大部分时间应达到”的可靠性目标。这为 Error Budget 提供了计算基础。
3.2 目标值设定方法
3.2.1 百分位数（Percentile）
百分位数是 SLO 最常用的统计方法，它关注“最差的那部分请求”的表现，而非平均值。常见的百分位包括 p50（中位数）、p95、p99、p99.9。
- p50（中位数）：反映典型用户体验，适合作为内部优化参考，不适合作为 SLO 目标。
- p95：排除 5% 的极端异常，常用于 API 网关或微服务间调用的 SLO。
- p99：排除 1% 的最差请求，是大多数在线服务（如搜索、推荐）的标准选择。
- p99.9：排除 0.1% 的极端值，适用于对延迟极度敏感的金融交易或实时通信系统。
实践建议：不要同时使用多个百分位作为同一 SLO 的目标。例如，同时要求 p50 ≤ 50ms 且 p99 ≤ 200ms 会导致 Error Budget 计算复杂化。通常选择 p99 作为主要目标，p95 作为预警参考。
3.2.2 时间窗口（Time Window）
时间窗口决定了 SLO 的评估周期和 Error Budget 的消耗速率。常见窗口类型：
| 窗口类型 | 定义 | 优点 | 缺点 |
|---|---|---|---|
| 固定日历窗口 | 按自然月/季度重置 | 与业务周期对齐，便于汇报 | 月初/月末边界效应明显 |
| 滚动时间窗口 | 持续向前滑动（如 30 天） | 平滑异常波动，无边界效应 | 历史故障影响持续时间长 |
| 复合窗口 | 同时使用多个窗口（如 7 天 + 28 天） | 兼顾短期敏感与长期稳定 | 管理复杂度高 |
常见陷阱：使用固定日历窗口时，如果在月末发生大规模故障，Error Budget 可能在最后一天耗尽，导致团队在月初“归零”后放松警惕。滚动窗口能更真实地反映服务近期健康状况。
3.3 常见误区与避坑指南
SLO 设定过程中，团队容易陷入以下误区，导致 Error Budget 失去实际指导意义：
| 误区 | 错误表现 | 正确做法 |
|---|---|---|
| 追求 100% 完美 | 设定 SLO = 100%，导致 Error Budget 永远为 0，无法容忍任何变更 | 设定 99.9% 或 99.99%，保留 Error Budget 用于创新 |
| 使用平均值 | 用平均延迟作为 SLO，掩盖了长尾请求的糟糕体验 | 使用 p95 或 p99 百分位数 |
| 窗口过短 | 使用 1 小时或 1 天窗口，频繁触发告警，团队疲劳 | 使用 28 天或 30 天滚动窗口 |
| 忽略业务分层 | 所有服务使用相同的 SLO 模板 | 核心支付服务 SLO 高于日志收集服务 |
| SLO 与 SLI 脱节 | SLO 定义清晰，但 SLI 采集口径不一致 | 先定义 SLI 口径，再设定 SLO 目标 |
| 静态不变 | SLO 设定后永不调整 | 每季度复盘，根据系统演进调整目标 |
核心原则：SLO 是“可容忍的失败边界”，不是“理想状态”。一个好的 SLO 应该让团队在 99% 的时间里感到安全，在 1% 的时间里感到紧迫。
3.4 SLO 与 Error Budget 的协同关系
SLO 直接决定了 Error Budget 的初始预算和消耗速率。理解以下关系有助于设定合理目标：
- Error Budget = 1 - SLO：例如 SLO = 99.9%，则 Error Budget = 0.1%（即 30 天内允许约 43 分钟的不可用时间）。
- 消耗速率：每次故障消耗的 Error Budget 取决于故障持续时间和影响范围。
- 门禁触发：当 Error Budget 消耗超过 50% 或 75% 时，应触发质量门禁，限制低风险变更。
实践案例：某电商平台将核心交易链路的 SLO 设定为 p99 ≤ 200ms（30 天滚动窗口）。当一次数据库故障导致延迟飙升到 500ms 持续 10 分钟时，Error Budget 消耗了 0.02%（约 20% 的月度预算）。团队立即触发质量门禁，暂停了所有非关键变更，优先修复数据库性能。
通过以上定义、方法和误区分析，团队可以建立一套科学、可执行的 SLO 体系，为后续的 Error Budget 管理和质量门禁协同打下坚实基础。