文章

SLO SLI 错误预算与智能告警

#observability#slo#sli#error-budget#alerting#sre

SLO/SLI 错误预算与智能告警

一句话：SLO 把”监控指标”升级成”该不该发版/该不该告警”的决策依据。它的核心是：允许一定错误（错误预算），预算烧太快才告警，而不是”有任何异常就打电话”。

SLI / SLO / Error Budget 三件套

概念定义例子
SLI服务等级指标（可量化”好”的比例）请求成功率 = 成功数/总数
SLO服务等级目标（SLI 要达成的门槛）99.9% 请求成功，且 P99 < 300ms
Error Budget1 - SLO 允许的”错误配额”99.9% → 每月允许 0.1% = ~43 分钟错误
graph LR
    SLI[SLI 测量] --> SLO[SLO 目标]
    SLO --> EB[Error Budget = 1-SLO]
    EB --> BURN[燃烧率告警]
    EB --> RELEASE[预算耗尽→冻结发布]

怎么定义 SLI（关键在”好”的口径）

SLI 不是”系统有没有活着”，而是”对用户而言这次算成功吗”。

请求成功率 SLI = (总请求 - 5xx - 超时) / 总请求
时延 SLI = P99 < 300ms 的请求占比
  • 用 Prometheus 表达式 直接算：sum(rate(http_requests_total{code!~"5.."}[30d])) / sum(rate(http_requests_total[30d]))
  • 注意时间窗口：滚动 30 天 vs 日历月，结论不同，要固定口径

多窗口多燃烧率告警（MWMBR）

错误预算告警不能”一出错就叫”（误报），也不能”烧完了才叫”（太晚）。Google 的标准做法：用两个时间窗口 + 两个燃烧率。

窗口燃烧率阈值含义
1h14.4（=预算 1h 烧 1 天量）快速烧，立刻 page
6h6中速烧，page
1h + 6h 同时触发—确认是真实燃烧，才告警（降误报）
# 快速燃烧：1h 内烧掉 2% 预算（=14.4x 速率，2% budget / (1h/30d)）
- alert: HighBurnRateFast
  expr: |
    (sum(rate(errors[1h])) / sum(rate(requests[1h]))) > (0.02 / (1/720))
  for: 2m
  labels: {severity: page}

这个告警直接接 Prometheus Alertmanager（复杂路由/抑制），或 Grafana 告警。MWMBR 是”智能告警”的核心——它把”该不该打扰 on-call”量化了。

Error Budget 的政策含义（最有价值的部分）

错误预算不只是告警，更是发布纪律：

  • 预算充足 → 正常发版、做实验（混沌工程也敢做）
  • 预算快耗尽 → 冻结非关键发布、集中力量稳定性
  • 预算长期用不完 → SLO 定太松，可以收紧（逼自己提质量）

这套机制直接回应你 CI-CD 系列的”发布策略”——SLO 是发布闸门的上游决策。

告警疲劳治理

问题解法
天天误报MWMBR 多窗口确认、加 for 持续时间
告警太多看不过来分级（page vs ticket）、路由到不同群
没人认领明确 owner + 升级策略
重复告警Alertmanager 分组 + 抑制（inhibit）

与你的 vault 打通

  • LLM 推理服务化/生产部署与运维：推理服务的 SLO 应是”TTFT P99 < X，成功率 > Y”——直接套本篇
  • Grafana 可视化与告警：SLO 剩余预算做成 Stat 面板 + 燃烧率告警
  • CI-CD 最佳实践与安全：SLO 作为发布闸门

关联知识

参考资源

  • Google SRE Book: Service Level Objectives
  • “Alerting on SLOs” (Grafana/Linkert)

学习时间

内容日期状态
SLO/SLI 错误预算2026-07-24完成：三件套、SLI 口径、MWMBR、预算政策、告警疲劳

状态

  • SLI/SLO/Error Budget
  • SLI 定义口径
  • MWMBR 多窗口告警
  • 预算政策含义
  • 告警疲劳治理