# 以 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 的示例（简化版）：

```yaml
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 把监控从技术细节拉回到业务目标上：我们要的是用户能下单、能看视频、能搜索到商品——把这些体验做成可以量化的目标，再围绕它来设计告警和流程，整个组织的反应会更快、更有方向感。别把告警当作噪音，把它当成团队决策的传感器。



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

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

后端

运维

架构设计

SLI/SLO驱动的可观测性实践指南：从业务目标到告警策略设计。详解如何将用户体验转化为可度量指标(SLI)，设定合理SLO目标，并基于误差预算(ErrorBudget)构建智能告警系统。提供电商下单服务示例及Prometheus告警规则代码，帮助团队实现从监控到决策的有效闭环。

数据库连接池

图像处理

数据库

AI驱动 智领未来

tencentdb-catalog

腾讯云BI新客户首次购买9.9元起！


imageprocess

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

以 SLI/SLO 为驱动的可观测性：从定义到告警策略 — 写给在值班室里泡过夜的你-腾讯云开发者社区-腾讯云

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

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐