📚 课程目录第3章 SLO目标设定

3. SLO 目标设定：如何根据业务重要性设定 SLO 阈值

SLO（Service Level Objective）是服务等级目标，它定义了服务在特定时间窗口内应达到的可靠性水平。设定合理的 SLO 阈值是 SRE 实践的核心环节——阈值过高会导致成本失控，过低则无法保障用户体验。本章将系统讲解如何根据业务重要性分级设定 SLO，并深入解析错误预算的计算与消耗机制。

3.1 业务重要性分级与 SLO 阈值映射

不同业务模块对可靠性的敏感度差异巨大。核心交易链路与后台报表系统显然不应使用相同的 SLO 标准。我们采用“业务重要性-服务等级”四象限模型进行分级：

业务重要性等级	典型场景	推荐 SLO 阈值	年度最大不可用时间
L1 核心交易	支付、下单、登录鉴权	99.99% (四个9)	52.56 分钟
L2 关键业务	商品详情、购物车、搜索	99.95%	4.38 小时
L3 一般业务	用户评论、历史订单查询	99.9% (三个9)	8.76 小时
L4 辅助服务	推荐、广告、后台报表	99.5%	43.8 小时

实践建议： 不要对所有服务一刀切使用 99.99%。SLO 每增加一个 9，基础设施成本通常上升 2-3 倍。将非核心服务的 SLO 从 99.99% 降至 99.9%，每年可节省数百万的冗余资源投入。

设定 SLO 阈值时，还需考虑以下三个约束条件：

用户期望基线： 通过客户端埋点数据，统计用户可感知的延迟与错误容忍度。
技术实现成本： 多 AZ 部署、跨区域容灾、实时监控等投入是否在预算范围内。
合规与合同要求： 金融、医疗等行业有明确的监管 SLA 底线，SLO 必须高于 SLA。

3.2 错误预算的概念与计算

错误预算（Error Budget）是 SRE 方法论中最重要的管理工具之一。它将“可靠性”从抽象目标转化为可量化的、可消耗的预算额度，从而平衡稳定性与创新速度。

核心公式：

错误预算 = 总时间窗口 × (1 - SLO 目标)

例如：
- 30 天窗口，SLO = 99.9%
- 总时间 = 30 × 24 × 60 × 60 = 2,592,000 秒
- 允许错误时间 = 2,592,000 × (1 - 0.999) = 2,592 秒 ≈ 43.2 分钟
- 错误预算 = 43.2 分钟

错误预算的消耗与剩余状态，直接决定了团队是否可以发布新功能：

预算充足（剩余 > 50%）： 正常发布，鼓励创新。
预算紧张（剩余 20%-50%）： 限制高风险发布，优先修复稳定性问题。
预算耗尽（剩余 ≤ 0%）： 冻结所有发布，进入“错误预算燃烧”应急模式，全力恢复可靠性。

常见误区： 错误预算不是“允许故障的额度”，而是“可接受的不可用时间上限”。一旦预算耗尽，意味着服务已经违反了 SLO，必须立即启动复盘与改进流程，而不是继续消耗。

3.3 错误预算消耗速率与告警触发

仅监控剩余预算是不够的，我们需要关注消耗速率。如果预算在窗口初期就快速消耗，即使总量未超限，也预示着严重问题。我们引入“错误预算消耗率”指标：

消耗率 = 当前已消耗错误预算 / 窗口已过时间比例

示例：
- 30 天窗口，SLO = 99.9%，总预算 = 43.2 分钟
- 第 5 天结束时（窗口已过 16.7%），已消耗 15 分钟预算
- 消耗率 = 15 / (43.2 × 16.7%) = 15 / 7.21 ≈ 2.08
- 消耗率 > 1.0，说明预算消耗速度是预期的 2 倍，需触发告警

我们设定三级告警阈值：

告警级别	消耗率阈值	剩余预算	响应动作
Info	> 0.8	> 30%	通知 SRE 团队关注
Warning	> 1.2	10%-30%	启动应急响应，限制发布
Critical	> 1.5	< 10%	全团队介入，冻结发布，启动复盘

  关键洞察： 消耗率告警比剩余预算告警更灵敏。它能在预算耗尽前 3-5 天发出预警，为团队争取宝贵的响应时间。

3.4 多窗口滑动计算与 SLO 违约判定

单一时间窗口的 SLO 计算容易受短期波动影响。我们采用多窗口滑动计算机制，同时追踪 1 小时、7 天、30 天三个窗口的 SLO 状态：

窗口类型	用途	违约判定条件	告警灵敏度
1 小时滑动窗口	实时异常检测	当前小时错误率 > (1 - SLO) × 3	高（分钟级）
7 天滑动窗口	短期趋势评估	7 天累计错误预算消耗 > 80%	中（小时级）
30 天滑动窗口	SLO 合规判定	30 天累计错误预算耗尽	低（天级）

SLO 违约判定逻辑：

IF (30 天窗口错误预算剩余 ≤ 0) THEN
    触发 SLO 违约事件
    自动生成复盘工单
    计算 MTTR 并关联违约时间线
ELSE IF (7 天窗口消耗率 > 1.2) THEN
    触发 Warning 告警
    通知 SRE 值班团队
ELSE IF (1 小时窗口错误率 > 阈值) THEN
    触发 Info 告警
    记录异常事件
END IF

  实战要点： 30 天窗口的 SLO 违约是“硬性违约”，通常对应业务合同中的 SLA 处罚条款。7 天窗口的消耗率告警是“软性预警”，用于提前干预。1 小时窗口用于快速发现突发故障。

3.5 错误预算的自动化告警配置

在 Prometheus 中，我们可以通过以下 Recording Rules 实现错误预算的自动化计算与告警：

# 计算 30 天窗口的错误预算消耗率
- record: job:slo_error_budget_consumption_rate:ratio_30d
  expr: |
    (
      1 - (
        sum(rate(http_requests_total{status=~"5.."}[30d]))
        /
        sum(rate(http_requests_total[30d]))
      )
    ) / (1 - 0.999)  # SLO = 99.9%

# 告警规则：消耗率超过 1.2 触发 Warning
- alert: ErrorBudgetConsumptionRateHigh
  expr: job:slo_error_budget_consumption_rate:ratio_30d > 1.2
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "错误预算消耗率过高 ({{ $value | humanize }})"
    description: "服务 {{ $labels.job }} 的错误预算消耗率已达 {{ $value | humanize }}，请及时排查。"

# 告警规则：错误预算耗尽触发 Critical
- alert: ErrorBudgetExhausted
  expr: |
    (
      sum(rate(http_requests_total{status=~"5.."}[30d]))
      /
      sum(rate(http_requests_total[30d]))
    ) > (1 - 0.999)
  for: 10m
  labels:
    severity: critical
  annotations:
    summary: "错误预算已耗尽"
    description: "服务 {{ $labels.job }} 的 30 天错误预算已耗尽，SLO 违约事件已触发。"

自动化集成： 上述告警触发后，可通过 Webhook 自动创建 Jira 工单、发送 PagerDuty 通知、并触发 MTTR 复盘流程的初始化。我们将在第 4 章详细讲解告警到复盘的完整链路。

3.6 本章小结

SLO 阈值设定 必须基于业务重要性分级，L1-L4 对应 99.99% 到 99.5%，避免一刀切。
错误预算 是 SLO 的量化表达，公式为：总时间 × (1 - SLO)，用于平衡可靠性与创新。
消耗率告警 比剩余预算告警更灵敏，三级阈值（0.8/1.2/1.5）实现分级响应。
多窗口滑动计算 结合 1h/7d/30d 窗口，兼顾实时性与合规性。
自动化告警配置 通过 Prometheus Recording Rules 实现，为后续 MTTR 复盘提供数据基础。