1. SLO与误差预算基础:SLO定义、SLI指标、误差预算概念、为什么需要误差预算告警

1.1 从可靠性度量到服务等级目标

在站点可靠性工程(SRE)体系中,服务等级目标(SLO)是衡量系统可靠性的核心契约。它不是一个简单的“可用性百分比”,而是基于用户真实体验的量化承诺。要理解SLO,必须先厘清三个基础概念:SLI、SLO与误差预算。

术语 全称 核心定义 示例
SLI Service Level Indicator 服务等级指标,是系统某一维度(如延迟、错误率、吞吐量)的原始测量值 请求延迟 P99 = 200ms
SLO Service Level Objective 服务等级目标,是SLI的目标阈值或范围,代表“好事件”应达到的比例 99.9% 的请求延迟 ≤ 200ms
误差预算 Error Budget 误差预算 = 1 - SLO,代表在SLO周期内允许的不可用时间或失败次数 月度 99.9% SLO 允许 43.2 分钟不可用
关键认知:SLO 不是“系统能达到什么水平”,而是“用户能接受什么水平”。误差预算则是将可靠性从“追求”转化为“可管理资源”的关键桥梁。

1.2 SLI指标:定义“好事件”的测量标准

SLI是SLO的基石。一个有效的SLI必须满足可测量、可对比、与用户体验强相关三个条件。在Prometheus生态中,SLI通常通过Histogram、Counter或Gauge指标类型来采集。

常见的SLI分类与Prometheus采集方式:

  • 请求延迟(Latency):使用 histogram_quantile 计算 P50/P90/P99 延迟。例如:histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))
  • 错误率(Error Rate):使用 rate() 计算错误请求占总请求的比例。例如:rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m])
  • 吞吐量(Throughput):使用 rate() 或 irate() 计算每秒请求数。
  • 饱和度(Saturation):使用 Gauge 测量资源使用率,如 CPU 使用率、队列深度。
SLI 设计原则:优先选择“用户可见”的指标。例如,对于 Web 服务,请求延迟和错误率是比 CPU 使用率更直接的 SLI。CPU 使用率可以作为“饱和度”指标辅助判断,但不建议直接作为 SLO 的 SLI。

1.3 误差预算:可靠性的“预算管理”思维

误差预算将可靠性从“技术指标”转化为“业务资源”。其核心公式为:

Error Budget = 1 - SLO

例如:
SLO = 99.9%  →  Error Budget = 0.1%
月度总时间 = 30天 × 24小时 × 60分钟 = 43200 分钟
允许不可用时间 = 43200 × 0.1% = 43.2 分钟

误差预算的消耗与补充机制:

  • 消耗:每次 SLI 未达到 SLO 阈值(即“坏事件”),都会消耗误差预算。
  • 补充:在每个 SLO 周期(通常为 30 天)结束时,误差预算重置为满额。
  • 管理意义:当误差预算充足时,团队可以更积极地发布新功能;当预算紧张时,应优先投入稳定性工作。
误差预算生命周期与消耗补充机制 SLO 定义 99.9% 延迟 ≤ 200ms 误差预算计算 1 - SLO = 0.1% 预算消耗 坏事件消耗预算 预算检查 剩余预算 > 0? 决策 发布 / 冻结 说明:误差预算在周期结束时重置为满额。消耗速度决定团队发布节奏。

1.4 为什么需要误差预算告警?

传统的告警策略(如“CPU > 90%”或“错误率 > 5%”)存在两个根本问题:阈值静态化和缺乏业务语义。误差预算告警则从根本上改变了这一模式。

传统告警 vs 误差预算告警对比:

维度 传统告警 误差预算告警
阈值来源 运维经验或硬件极限 从 SLO 推导,与用户承诺绑定
告警频率 容易产生告警风暴,短时抖动即触发 基于消耗速率,容忍短时抖动
业务关联 低,只反映系统状态 高,直接反映用户满意度风险
降噪能力 弱,需要大量静默规则 强,通过预算窗口自然过滤噪音
行动指引 “修复指标” “保护剩余预算”或“暂停发布”
常见误区:不要将误差预算告警等同于“SLO 违约告警”。误差预算告警是在预算消耗速率过快时提前预警,而不是等到 SLO 已经违约才告警。后者往往为时已晚。

误差预算告警的核心价值在于:

  1. 将告警与业务风险对齐:告警不再是“系统有点问题”,而是“用户满意度正在被侵蚀”。
  2. 提供自然的告警降噪:只要误差预算充足,短时的指标毛刺不会触发告警,大幅减少无效告警。
  3. 支持发布决策:当误差预算消耗过快时,告警可以作为“停止发布”或“回滚”的自动化触发条件。
  4. 量化可靠性投资:通过跟踪误差预算消耗趋势,可以量化每次故障对用户的影响,指导稳定性投入优先级。
传统告警 vs 误差预算告警:告警触发逻辑对比 传统告警流程 静态阈值触发 CPU > 90% 持续 5 分钟 告警风暴 短时抖动即触发,噪音多 行动:修复指标 缺乏业务优先级 误差预算告警流程 预算消耗速率触发 剩余预算 < 30% 且消耗加速 自然降噪 容忍短时毛刺,关注趋势 行动:保护预算 / 暂停发布 直接关联业务决策

1.5 误差预算告警在Prometheus中的实现思路

在Prometheus中,误差预算告警通常基于SLI的燃烧速率(Burn Rate)来构建。燃烧速率表示误差预算消耗的速度,其计算公式为:

Burn Rate = (1 - 实际SLI) / (1 - SLO)

例如:
SLO = 99.9%(允许错误率 0.1%)
实际错误率 = 0.5%
Burn Rate = 0.5% / 0.1% = 5x

含义:误差预算消耗速度是预期的 5 倍。

基于燃烧速率的告警规则示例(PromQL):

# 计算过去 1 小时的燃烧速率
groups:
  - name: error_budget_alerts
    rules:
      - alert: HighErrorBudgetBurnRate
        expr: |
          (
            1 - (
              sum(rate(http_requests_total{status=~"5.."}[1h]))
              /
              sum(rate(http_requests_total[1h]))
            )
          ) / (1 - 0.999) > 2
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "误差预算消耗速率过高(当前 {{ $value }}x)"
          description: "过去 1 小时误差预算消耗速率为预期的 {{ $value }} 倍,请关注。"
核心要点:误差预算告警的阈值不是固定的百分比,而是燃烧速率。通过设置不同的燃烧速率阈值(如 2x、5x、10x)和不同的时间窗口(如 1h、6h、24h),可以实现多级告警,既保证及时性,又避免噪音。