以 SLI/SLO 为驱动的可观测性：从定义到告警策略 — 写给在值班室里泡过夜的你

作者 | Echo_Wish（运维那点儿事儿，接地气讲清楚）

最近跟不少公司聊架构和监控，发现一个常见误区：监控只是“报警器”，做得越多越好。但真正能稳定产线的，不是盲目堆指标，而是把业务目标用可度量的指标（SLI）表示出来，用SLO去约束期望，再把告警策略与这些目标绑定——这才是“可观测性成熟度”的核心。我把从概念到落地的思路拆成几步，顺手给代码示例，确保你回去就能撸一版出来。

先把概念说清楚（别糊弄自己）

• SLI（Service Level Indicator）：服务质量的度量指标。比如请求成功率、请求延迟 P95、图像处理错误率等。SLI 要聚焦用户感知的关键路径，不要把数据库连接池指标当作 SLI（除非连接池直接影响用户体验）。
• SLO（Service Level Objective）：对 SLI 的期望值，比如“请求 95th 延迟 < 300ms” 或者“可用性 ≥ 99.95%（30 天）”。SLO 是产品/业务与运维之间的契约。
• Error Budget（误差预算）：1 - SLO 的那部分允许的失败比例。比如 99.9% SLO → 0.1% error budget。它是“创新投入”和“稳定性”之间的货币——花完就要减速、修 Bug。

从 SLI 到 SLO：如何设定（实操派）

1. 拆业务场景：把产品按用户路径拆出来（登录、下单、支付、检索、流媒体播放）。每条路径定义 1-2 个 SLI。
2. 选择度量方式：对成功率用计数（requests_total / requests_successful），对延迟用分位数（p50/p95/p99）。
3. 设定 SLO：结合历史数据、业务可接受成本与法律合规设目标。初期可以用历史 90 天的表现做参考，不要盲目定 99.999%。
4. 定义评估窗口：SLO 一定要有窗口（如 30 天、7 天、1 天实时监测）。长期 SLO 和短期 SLO 可以并存（长期保证业务目标，短期指导运维响应）。

举个例子：电商下单服务

• SLI1（成功率） = 成功下单数 / 下单请求数
• SLO1 = 成功率 ≥ 99.95%（30 天）
• SLI2（延迟） = p95(order_submit_latency)
• SLO2 = p95 ≤ 500ms（7 天）

告警策略：别靠“阈值炸弹”吓醒同事

很多团队把 Prometheus/Datadog 里拉满阈值，一有波动就是 paging——结果大家对告警免疫了。SLO 驱动的告警策略应该区分紧急告警（Page）和运营告警（Ticket/Slack），并以 Error Budget 为核心。

关键告警类型：

1. SLO Burn Rate 警报（紧急）：如果短期内 error budget 被以很高的速率消耗，需要立即 paging。例如 1 小时内的 burn rate 超过 14x（即如果以当前速率持续会在 1 小时内耗尽 1 天的预算）就立刻通知值班工程师。
2. SLO Remaining Budget 警告（运营）：当剩余预算低于某阈值（比如剩余 ≤ 25%）发送团队通知，让 PM 决策是否触发缓减新功能发布。
3. 系统健康指标（辅助）：比如数据库连接数、队列积压，但这些只作为辅助线索，不直接 Paging，除非关联到 SLO 降低。

下面给个 Prometheus AlertRule 的示例（简化版）：

groups:
- name: slo.rules
  rules:
  - alert: OrderService_HighBurnRate
    expr: |
      (
        increase(order_failures_total[1h]) 
        / increase(order_requests_total[1h])
      ) / (0.001) > 14
    for: 5m
    labels:
      severity: page
    annotations:
      summary: "OrderService 高速消耗 error budget"
      description: "过去1小时失败率按当前速率会在24小时内耗尽预算，立即处理"

  - alert: OrderService_LowErrorBudget
    expr: |
      (sum_over_time(order_failures_total[30d]) / sum_over_time(order_requests_total[30d])) < 0.001 and
      (1 - (sum_over_time(order_failures_total[30d]) / sum_over_time(order_requests_total[30d]))) < 0.9975
    for: 30m
    labels:
      severity: ticket
    annotations:
      summary: "OrderService 剩余 error budget 低于25%"
      description: "请PM与SRE做是否降级发布/修复策略"

注：上面表达式只是示意，实际要用 SLO 计算库或者把 error budget 的计算预先做成 recording rule，避免在 alert 里做复杂计算。

实战建议与流程（别光写文档，要落地）

1. 把 SLO 写进团队协议：明确谁负责 SLO，SLO 达不到时的流程（谁 page？谁评估？是否冻结发布？）。
2. 把指标埋好：在应用端埋点确保 SLI 的原子性（能追溯到 request id、部署版本）。
3. 模拟演练：定期做 chaos 或故障演练，验证告警能把对的人叫醒、流程顺畅。
4. 可视化看板：把 SLO、burn rate、剩余预算放在看板上，业务方也能一目了然。
5. 数据质量门槛：ETL/metrics pipeline 也要做 SLO（指标可靠性本身就是 SLI），否则你看到的都是假象。

我的一点个人感受（接地气的结尾）

我见过太多团队把注意力放在“监控工具有多漂亮”，而忽略了“监控要服务于决策”。SLO 把监控从技术细节拉回到业务目标上：我们要的是用户能下单、能看视频、能搜索到商品——把这些体验做成可以量化的目标，再围绕它来设计告警和流程，整个组织的反应会更快、更有方向感。别把告警当作噪音，把它当成团队决策的传感器。