SRE运维：从 0 到 1 建设可落地的可靠性度量框架（SLO/SLI）

你是不是也遇到过这种情况凌晨三点被告警吵醒爬起来看了一圈发现 CPU 正常、内存正常、Pod 也在跑但用户就是说“卡”。或者反过来业务方问你“系统现在到底稳不稳”你掏出 Grafana 面板画了一堆曲线却说不清楚“到底算不算好”。读完本文你将能从 0 到 1 搭建一套完整的 SLO 体系——定义 SLI、设定 SLO、落地错误预算、配置基于燃烧速率的告警让“稳不稳”这件事变得可度量、可决策。1. 为什么需要 SLO——一个 SRE 的切身体会我刚做运维那几年团队最头疼的不是系统出问题而是“怎么判断系统出问题了”。我们监控 CPU、内存、磁盘、网络样样都有。CPU 飙到 85% 就报警结果值班的爬起来一看业务正常得不行纯粹是某个批处理任务在跑。反过来有一次数据库连接池满了CPU 才 30%没有任何告警但用户下单全挂了。那次事后复盘大家沉默了很久。后来我意识到一个问题我们一直在监控“系统内部的指标”而不是“用户感受到的服务质量”。SLOService Level Objective本质上是把“用户觉得好不好”翻译成可度量的数字。有了 SLOSRE 的决策就有了方向盘错误预算还剩多少能不能上线新功能要不要紧急介入——全部可以量化决策而不是靠“我感觉还行”或者“我感觉不行”。顺便说一句很多人一开始会纠结 SLO 和 SLA 的区别。简单说SLA 是对外承诺、要赔钱的那种SLO 是内部给自己定的目标。SLO 不达标不一定会赔钱但一定要让你重视起来。2. 三个核心概念SLI、SLO、Error BudgetSLIService 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 5xxAPI 响应的 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。4. 如何设定 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 SaaS99.5%~3.6 小时金融服务99.95%~22 分钟社交媒体99.9%~43 分钟SLO 必须有时间窗口。长期窗口如 30 天保证业务大盘目标短期窗口如 1 天指导日常运维响应。例子电商下单服务SLO1成功率 ≥ 99.95%30 天窗口SLO2P95 延迟 ≤ 500ms7 天窗口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% → P03变更控制预算充足时容忍小问题预算告急时暂停发布新功能。这种机制需要 CTO 级别背书。6. 基于 SLO 的告警——Burn Rate 才是正解传统按固定阈值告警的方式有个致命问题低谷期也报、高峰期不报久了大家就对告警免疫了。基于 SLO 的告警核心不是“错误率有多高”而是“错误预算被消耗的速度有多快”——这个速度叫 Burn Rate。什么是 Burn RateBurn Rate 1 表示按当前速率会恰好耗尽预算。Burn Rate 14 表示按当前速率 1 小时就能烧掉 1 天的预算。Google SRE 推荐的“多窗口多燃烧速率告警”框架用不同时间窗口如 1 小时和 5 小时分别计算 Burn Rate组合判断避免误报。告警配置建议紧急告警Page1 小时内 Burn Rate 14或 5 小时内 7立即叫醒值班工程师。预警Warning剩余预算 25% 时发 Slack 或工单通知不 Page。7. 自动化生成 SLO 配置用 Sloth 省掉 80% 的手工活手动写 Prometheus 的 SLO 记录规则和告警规则非常繁琐。Sloth 是一个开源工具基于 Google 的 SLO 实现能自动生成多窗口燃烧速率告警规则。安装我用的是 v0.15.0MacOS 和 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定义 SLOYAML 配置文件version: prometheus/v1 service: order-service labels: owner: sre-team tier: critical slos: # 可用性 SLO99.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 必须选“用户能感知到”的指标。用户不知道什么是数据库连接他们只知道“下单成功了没”。坑 2SLO 定得太高变成摆设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 了吗踩过什么坑欢迎来评论区交流说不定你的经验能帮到更多人。