你是不是也遇到过这种情况：凌晨三点被告警吵醒，爬起来看了一圈发现 CPU 正常、内存正常、Pod 也在跑，但用户就是说"卡"。或者反过来，业务方问你"系统现在到底稳不稳"，你掏出 Grafana 面板，画了一堆曲线，却说不清楚"到底算不算好"。
读完本文，你将能：从 0 到 1 搭建一套完整的 SLO 体系------定义 SLI、设定 SLO、落地错误预算、配置基于燃烧速率的告警，让"稳不稳"这件事变得可度量、可决策。
1. 为什么需要 SLO？------一个 SRE 的切身体会
我刚做 运维那几年，团队最头疼的不是系统出问题，而是"怎么判断系统出问题了"。
我们监控 CPU、内存、磁盘、网络，样样都有。CPU 飙到 85% 就报警，结果值班的爬起来一看，业务正常得不行，纯粹是某个批处理任务在跑。反过来有一次，数据库连接池满了，CPU 才 30%，没有任何告警，但用户下单全挂了。那次事后复盘，大家沉默了很久。
后来我意识到一个问题：我们一直在监控"系统内部的指标"，而不是"用户感受到的服务质量"。
SLO（Service Level Objective）本质上是把"用户觉得好不好"翻译成可度量的数字。有了 SLO，SRE 的决策就有了方向盘：错误预算还剩多少，能不能上线新功能，要不要紧急介入------全部可以量化决策，而不是靠"我感觉还行"或者"我感觉不行"。
（顺便说一句，很多人一开始会纠结 SLO 和 SLA 的区别。简单说：SLA 是对外承诺、要赔钱的那种，SLO 是内部给自己定的目标。SLO 不达标不一定会赔钱，但一定要让你重视起来。）
2. 三个核心概念：SLI、SLO、Error Budget
SLI（Service Level Indicator） ：服务质量的度量指标。比如"过去 5 分钟请求成功率"、"P95 延迟 200ms"。SLI 必须是可观测、可量化的。
SLO：对 SLI 的期望值，比如"可用性 ≥ 99.95%（30 天）"或者"P95 延迟 ≤ 300ms"。SLO 是运维与业务之间的契约。
Error Budget：错误预算 = 1 − SLO。SLO 是 99.9%，那错误预算就是 0.1%。它定义了在 SLO 考核周期内可以承受的"失败额度"。
小心：错误预算不是让你去主动犯错。它是一个容忍度，让你在"快速迭代"和"保持稳定"之间做理性权衡。
3. 如何定义 SLI------别把监控指标当 SLI
这是最容易被搞错的环节。SLI 必须聚焦用户感知的关键路径。
好的 SLI 长这样：
- HTTP 请求成功率（200 vs 5xx）
- API 响应的 P99 延迟
- 消息推送成功率
坏的 SLI（不推荐当 SLI 用） ：
- CPU 使用率
- 内存使用率
- 磁盘 I/O
- 数据库连接池大小
不是说这些指标没用------它们在排查问题时很有价值。但它们不是 SLI，因为用户根本感知不到 CPU 跑到了 85%。用户只知道"页面打不开"或"下单卡住了"。把内部资源指标当 SLI，等于用发动机温度去判断车子跑得快不快，不准确。
实操步骤：
第一步：拆出关键用户旅程（CUJ）。比如电商系统：登录 → 浏览商品 → 加购物车 → 下单 → 支付。
第二步：为每个 CUJ 选 1-2 个 SLI。不要贪多，每个业务路径 2 个足够。
第三步：确认可观测性。你选的 SLI 必须能从现有监控数据（Prometheus/Datadog/Splunk 等）里采集到。
一个真实的例子：LINE 的 OBS 媒体平台被 160 多个服务共用，他们直接把主要 API 本身当作 CUJ，对 DOWNLOAD/UPLOAD/OBJECT_INFO 三个 API 分别设了可用性 SLI。
- 如何设定 SLO------99.9% 还是 99.99%？
新手上路最容易犯的错：拍脑袋定 SLO。99.999% 听起来很牛，但你先算算成本------五个 9 意味着一年只能宕机 5 分钟。5 分钟！一次计划内重启可能都不够。
我的建议：先看历史数据，再加一点 aspiration。
用过去 90 天的实际表现做基准，把目标设在"当前水平的略高处"。例如过去 90 天可用性稳定在 99.85%，那 SLO 可以定 99.9%，而不是直接跳到 99.99%。
行业参考（2024 年数据） ：
|----------|------------|----------|
| 服务类型 | 典型 SLO/SLA | 月不可用时间 |
| 电商平台 | 99.9% | ~43 分钟 |
| B2B SaaS | 99.5% | ~3.6 小时 |
| 金融服务 | 99.95% | ~22 分钟 |
| 社交媒体 | 99.9% | ~43 分钟 |
SLO 必须有时间窗口。长期窗口（如 30 天）保证业务大盘目标，短期窗口（如 1 天）指导日常运维响应。
例子：电商下单服务
- SLO1：成功率 ≥ 99.95%（30 天窗口）
- SLO2：P95 延迟 ≤ 500ms（7 天窗口）
5. 错误预算：让 SLO 落地
SLO 是目标，但它本身不直接指导行为。错误预算是把 SLO 转化为可操作决策的工具。
错误预算的计算公式：
错误预算 = 允许的失败次数 = 总请求量 × (1 − SLO)
例子：trade_cart 服务，SLO = 99.95%，4 周总请求 4,653,680，允许失败 ≈ 2,326 次。用"还剩 2,326 次失败额度"来沟通，比"成功率 99.95%"直观得多。
错误预算的应用场景：
1）稳定性燃尽图：实时展示预算消耗，建议以 4 周为周期。
2）故障定级：根据预算消耗比例量化故障等级，减少争议。
- 消耗 >20% → P2
- 消耗 >30% → P1
- 消耗 >50% → P0
3）变更控制：预算充足时容忍小问题，预算告急时暂停发布新功能。这种机制需要 CTO 级别背书。
6. 基于 SLO 的告警------Burn Rate 才是正解
传统按固定阈值告警的方式有个致命问题：低谷期也报、高峰期不报，久了大家就对告警免疫了。
基于 SLO 的告警核心不是"错误率有多高"，而是 "错误预算被消耗的速度有多快" ------这个速度叫 Burn Rate。
什么是 Burn Rate？
Burn Rate = 1 表示按当前速率会恰好耗尽预算。Burn Rate = 14 表示按当前速率 1 小时就能烧掉 1 天的预算。
Google SRE 推荐的"多窗口多燃烧速率告警"框架：用不同时间窗口（如 1 小时和 5 小时）分别计算 Burn Rate，组合判断，避免误报。
告警配置建议：
- 紧急告警（Page） ：1 小时内 Burn Rate > 14，或 5 小时内 > 7，立即叫醒值班工程师。
- 预警（Warning） ：剩余预算 < 25% 时发 Slack 或工单通知，不 Page。
7. 自动化生成 SLO 配置（用 Sloth 省掉 80% 的手工活）
手动写 Prometheus 的 SLO 记录规则和告警规则非常繁琐。Sloth 是一个开源工具，基于 Google 的 SLO 实现，能自动生成多窗口燃烧速率告警规则。
安装（我用的是 v0.15.0，MacOS 和 Linux 都行）：
# 下载二进制
wget https://github.com/slok/sloth/releases/download/v0.15.0/sloth-linux-amd64
chmod +x sloth-linux-amd64
sudo mv sloth-linux-amd64 /usr/local/bin/sloth定义 SLO（YAML 配置文件） ：
version: "prometheus/v1"
service: "order-service"
labels:
owner: "sre-team"
tier: "critical"
slos:
# 可用性 SLO：99.9%
- name: "requests-availability"
objective: 99.9
description: "HTTP 请求可用性"
labels:
category: "availability"
sli:
events:
# 总请求量
error_query: sum(rate(order_requests_total{status=~"5.."}[{{.window}}]))
total_query: sum(rate(order_requests_total[{{.window}}]))
alerting:
page_alert:
# 多窗口燃烧速率告警
disabled: false
ticket_alert:
disabled: false生成 Prometheus 规则：
sloth generate -i ./order-slo.yml > ./prometheus-slo-rules.yml输出是完整的 Prometheus 记录规则和告警规则，直接应用到 Prometheus 就能用。官方还提供了配套的 Grafana Dashboard 可以直接导入。
8. 我踩过的 5 个坑
坑 1：把内部指标当 SLI 用
上面说过了，但还是值得重复一遍------我见过有人把"数据库连接数"当作 SLO，结果连接池抖动就触发告警，业务完全没受影响。SLI 必须选"用户能感知到"的指标。用户不知道什么是数据库连接，他们只知道"下单成功了没"。
坑 2：SLO 定得太高，变成摆设
99.999% 在纸面上很漂亮，但问问你的基础设施能不能撑住。如果总是达不成，大家就会彻底无视 SLO。务实的 SLO 比完美的 SLO 有用得多。
坑 3：错误预算没有跨团队共识
SRE 知道错误预算还剩 10%，但产品经理还在催着上线新功能。结果线上崩了，复盘时才发现两边根本没对齐。错误预算机制必须从上层推动，至少在 VP/CTO 层面获得背书。
坑 4：告警配置过于复杂，没人能维护
我有段时间把 Burn Rate 调得太敏感，结果告警太多，值班的干脆把手机静音了。后来收敛到每个 SLO 只保留 1-2 个关键告警规则。告警少而准，比多而杂有用。
坑 5：以为 SLO 只是 SRE 的事
这可能是最大的误区。SLO 需要产品、业务、开发、运维一起参与：业务方定义"什么叫好的用户体验"，产品方定义核心用户路径，SRE 和开发负责度量。如果 SRE 自己在会议室里闭门造车定 SLO，大概率用不起来。
9. 一个简单的 SLO 实施检查清单
启动 SLO 之前，先过一遍这个清单，可以帮你省掉不少返工时间：
- 是否识别了关键用户旅程（CUJ），而不是只看 API 层面的指标？
- 每个 SLI 是否都能从现有监控系统中直接采集？
- SLO 目标是否基于历史数据设定，而不是拍脑袋？
- 是否同时设定了长期窗口（30 天）和短期窗口（1 天）？
- 错误预算是否在团队间（SRE、开发、产品）达成书面共识？
- 告警策略是否基于 Burn Rate，而不是固定阈值？
- 是否留了"调优期"（建议 1-2 个月），允许根据实际运行情况调整 SLO？
题外话：我见过有人追求 SLO 数量越多越好，其实不是这样。一个服务 3-5 个 SLO 足够了，每个 CUJ 配 1-2 个 SLI 即可。SLO 是导航仪，不是驾驶舱的全部仪表盘。
如果你的系统还处在"告警一堆但不知从何入手"的阶段，别急着一步到位做复杂的多窗口燃烧速率。先把可用性和延迟这两个最基础的 SLO 跑起来，错误预算画出来，两周后你会惊讶地发现：值班时的判断力提升了不止一个档次。
你开始给自己的服务设 SLO 了吗？踩过什么坑？欢迎来评论区交流，说不定你的经验能帮到更多人。