SLO

概述 2021 年我刚接手一个运维团队时，做了个简单统计：团队 12 个人，一周 40 小时工作时间里，平均 24 小时花在手动处理工单、重启服务、补磁盘空间这些事情上。琐事占比 60%。剩下 16 小时里，一半在开会同步信息，真正做工程优化的时间每周不到 8 小时。 团队里每个人都很忙，但系统还是不稳定。MTTR 40 分钟，可用性 99.5%，告警群每天 200 多条。老板问我：“我们团队到底行不行？“我答不上来。不是谦虚，是没有量化标准。 后来我花了 3 年时间，把可用性从 99.5% 推到 99.9%，MTTR 从 40 分钟压到 8 分钟，琐事占比从 60% 降到 20% 以内。回头复盘，最关键的一步不是引入了什么工具，而是建立了一套成熟度评估体系——先搞清楚团队在哪个段位，再决定下一步投什么。 这篇文章分享我实际用过的 SRE 团队成熟度 5 级模型。它借鉴了 CMMI 的分层思路，但完全针对 SRE 场景重新设计，每个级别都有可量化的判断标准。文末有一份 Python 自检脚本，你跑一下就知道自己的团队在哪一级。 为什么需要 SRE 成熟度模型 先说几个常见场景，看看你中了几条： 招人时 JD 写"精通 K8s 和 Prometheus”，面了一圈发现候选人技术栈差不多，但来了之后产出天差地别——因为你不知道团队缺的是"会写 PromQL 的人"还是"能设计 SLO 体系的人” 申报预算时跟老板说"我们需要买 Datadog 和搭建混沌工程平台"，老板问"现在是什么水平？投了能到什么水平？“你答不上来 跨团队协作时，开发觉得 SRE 只会卡上线，SRE 觉得开发只管发版不管稳定性——根源是双方对"SRE 该干什么"没有共识 团队里有人想推进自动化，有人觉得"手动操作挺好的为什么要改”，你作为负责人没法用数据说服 这些问题的共同根因是：没有一把可量量的尺子来衡量团队能力。...

概述 你公司用了某云厂商的服务，SLA 白纸黑字写着 99.95% 月度可用性。某天凌晨服务挂了 30 分钟，你跑去找云厂商索赔，拿回来的赔偿大概是这么算的：故障时间占月度总分钟数的比例，乘以你当月的服务费。假设你月付 1000 块，30 分钟除以 43200 分钟再乘 1000，赔你 0.7 元。 没看错，七毛钱。你线上炸了半小时，客服电话被打爆，用户退款申请堆了一屏，云厂商赔你七毛。 这不是段子，这是 2025 年某 CSDN 技术博客拆解云厂商 SLA 时用的真实计算逻辑。当然，实际云厂商的赔偿用的是阶梯制（后面会讲），但核心问题不变：SLA 的数字看着唬人，赔偿条款却藏着大量排除项和窄化定义，到了真出事的时候，赔的那点钱远远覆盖不了你的业务损失。 这篇文章不聊怎么"读懂"SLA——那种文章网上一搜一大把。我要聊的是：作为 SRE，你怎么设计自己服务的 SLA，怎么避免云厂商 SLA 的坑，怎么把一个合同条款变成可执行的工程约束。 SLA、SLO、SLI：别再混为一谈 很多团队把这三个词当同义词用。开会时"我们的 SLA 是 99.9%"，实际上说的是 SLO。这三个东西的区别不是文字游戏，搞混了会出真问题。 先上一张对比表，后面逐个展开： 维度 SLI（指标） SLO（目标） SLA（协议） 是什么 对服务质量的量化测量值 基于 SLI 设定的内部目标值 对外承诺的合同条款 面向谁 工程团队 工程团队 + 产品 客户 / 业务方 违约后果 无 冻结发布、投入稳定性修复 赔偿、合同违约 严格程度 客观事实，无严格/宽松之分 必须严于 SLA 比 SLO 宽松，留缓冲 典型例子 P99 延迟 = 120ms P99 延迟 < 200ms，成功率 > 99....

概述 你大概率遇到过这个场景：SLO 定了 99.9%，错误预算也算了，Grafana 仪表盘画得漂漂亮亮。然后某个周五下午，错误预算已经消耗了 87%，产品经理拿着老板的旨意来说"这个功能周一必须上"。你说不行，预算快没了。产品说"那你说什么时候上"。吵了半小时，最后还是上了。周一晚上果然炸了。 这不是个例。我见过太多团队把错误预算做成了"运维的仪表盘"——指标定义了、告警配了、仪表盘画了，但一到决策环节就失效。问题的根源不是技术实现，而是错误预算从来就不是运维一个人的工具。 这篇文章要讲的是：怎么让错误预算从"运维墙上的一张图"变成"产品发版时绕不开的硬约束"。我会拆解三个层面的工作——把技术指标翻译成产品语言、设计三级响应机制让决策有规则可依、用燃烧速率做预测而非等预算花完才慌。每一步都附完整代码和配置，直接拿去用。 在展开之前，建议先回顾 SLO 的基础概念（相关文章：SRE核心理念：SLI、SLO与错误预算）。本文聚焦的不是"什么是错误预算"，而是"怎么让它真正管用"。 一、错误预算为什么在大多数团队形同虚设 1.1 一个典型失败案例 2024 年，我在某电商平台做 SRE 顾问。他们花了三个月搭建 SLO 体系：梳理了 47 个核心服务的 SLI，每个服务定了 99.9% 或 99.95% 的可用性目标，错误预算计算逻辑也写好了。Grafana 仪表盘很专业，每个服务一个面板，剩余预算一目了然。 然后呢？没有任何决策流程绑定到错误预算上。 产品该发版还是发版，发布评审会上没人看一眼预算仪表盘。直到某次大促前两天，订单服务的错误预算已经归零（实际可用性掉到了 99.82%），但促销活动的代码照常合入。结果大促当天流量翻三倍，订单服务 P99 从 200ms 飙到 3.5s，优惠券模块超时连锁崩溃，最终损失了大约 40 万订单。 事后复盘，所有人都在问：错误预算不是已经标红了吗？为什么没人拦住？ 答案很简单：仪表盘是给别人看的，决策是另一些人做的。两者之间没有桥梁。 1.2 三个根因 我复盘过至少 8 个团队的错误预算落地过程，失败模式高度集中： 失败模式 表现 根因 单方面制定 SLO 由运维独自定，产品不知道也不认 缺乏跨团队共识 只监控不执行 仪表盘有，但没有发布门禁代码 没有把预算消耗和发布流程绑定 当惩罚用 预算耗尽=运维要找开发的麻烦 定位错误，预算是共享决策工具不是武器 第三个最致命。错误预算的设计意图——Google SRE Workbook 里讲得很清楚——是给开发和运维一个共同的数据基础，让"要不要发版"从立场之争变成数据决策（来源：Google SRE Workbook）。如果运维把它当武器去卡开发，开发就会想办法绕过——比如把故障时间拆小到不触发阈值，或者在 SLO 计算窗口结束前一天重启计数器。 我的观点：错误预算落地的第一步不是配告警，而是开一次跨团队会议，让产品、开发、运维三方共同签署一份"错误预算策略文档"。这份文档要回答三个问题：预算耗尽时谁有权叫停发布？叫停后恢复条件是什么？预算充足时谁有权加速发布？没有这份共识，任何技术实现都是空中楼阁。 二、把错误预算翻译成产品语言 2.1 产品经理看不懂"剩余预算 13%" 你跟产品经理说"订单服务的错误预算还剩 13%"，他脑子里想的可能是"13% 听起来还有不少啊"。你得换一种语言。...

概述 99.5% 的可用性听起来不错——直到你算一笔账。 一年 8760 小时，99.5% 意味着允许停机 43.8 小时。换算到每个月，差不多 3.65 小时的服务中断。如果是核心交易系统，这 3.65 小时可能就是几十万的订单损失。如果赶在大促期间，损失会翻几十倍。 99.9% 呢？年停机 8.77 小时，月均不到 44 分钟。停机时间砍掉 80%。 0.4 个百分点的提升，背后不是加几台服务器那么简单。我在某出行平台推动过一次这样的改造，从立项到稳定运行在 99.9% 以上，花了整整 14 个月。这期间踩的坑、做的权衡、推翻重来的方案，比写代码本身多得多。 这篇文章不讲理论框架，只拆解我们做过的 6 个关键工程决策，以及 3 个让我后背发凉的踩坑时刻。每个决策都附上我们当时的选型对比和最终方案，你拿去就能对照自己的系统查漏补缺。 可用性的数学本质：为什么 0.4% 这么难 先搞清楚一件事：可用性不是加法，是乘法。 假设你的系统由 3 个服务串联组成，每个服务可用性 99.5%。整个链路的可用性是多少？ 0.995 × 0.995 × 0.995 = 0.9851 ≈ 98.51% 三个"还不错"的服务串联起来，整体可用性直接跌破 99%。年停机从单服务的 43.8 小时暴涨到 128 小时——超过 5 天。 反过来想：如果链路有 10 个服务，每个要达到整体 99.9% 的可用性，单个服务的可用性得是多少？ 0.999^(1/10) ≈ 0.99990 → 99.99% 十个服务每个都得做到四个九。这就是为什么微服务架构下可用性提升的难度呈指数级增长。 关键认知：提升可用性不是给单个服务加机器，而是同时做三件事——减少串联依赖数量、提高单个服务可用性、在关键路径上做冗余和降级。 Google SRE 团队在 The Calculus of Service Availability 中提到一个观点：大多数服务的内部目标应该定在 99....

概述 凌晨三点，你被告警吵醒。爬起来一看：CPU 正常、内存正常、Pod 也在跑，但用户投诉说"系统卡得用不了"。你打开 Grafana 面板，画了一堆曲线，却说不清楚——这到底算不算故障？ 这个场景，我在多个企业客户的 SRE 咨询中反复遇到。核心问题不是监控不够多，而是度量体系设计错了方向：我们一直在监控"系统内部的指标"，而不是"用户感受到的服务质量"。 曾经在一次某出行平台的故障复盘中，团队发现一个讽刺的事实：告警系统在故障发生 12 分钟后才触发，而用户在故障发生后 30 秒就已经开始投诉了。原因很简单——告警基于 CPU 使用率超 80% 触发，但实际故障是数据库连接池耗尽，CPU 才 35%，根本没碰阈值。 可靠性度量的本质，是把"系统稳不稳"这个问题，从主观感觉变成可量化的数字。这篇文章不讲 SLI/SLO 的基础概念（这些在 相关文章：SRE核心理念：SLI、SLO与错误预算 中已经讲透了），而是聚焦于：如何从零设计一套完整、可落地、能驱动决策的可靠性度量体系。 为什么传统监控体系不能回答"系统稳不稳" 先说结论：传统监控体系回答不了"系统稳不稳"，因为它度量的对象错了。 传统监控的三个盲区 盲区一：监控的是资源，不是用户体验 大多数团队的监控面板长这样：CPU 折线图、内存折线图、磁盘 IO 折线图、网络流量折线图。这些指标反映的是"服务器忙不忙"，而不是"用户爽不爽"。 举个真实的例子：某电商平台的订单服务，CPU 使用率常年 70%，运维觉得"不太对劲"，计划扩容。但实际上 P99 延迟 120ms，请求成功率 99.97%，用户体验完全没问题。另一个缓存服务，CPU 才 20%，看起来"很健康"，但缓存命中率从 95% 掉到 60%，导致数据库被打爆，用户实际体验已经很差了。 盲区二：没有"好"和"坏"的量化边界 “CPU 80% 算好还是算坏？"——这个问题在传统监控体系里没有答案。80% 可能是正常的批处理负载，也可能是即将打满的前兆。没有 SLO 的情况下，80% 就只是一个数字，不是判断依据。 Google SRE Book 里有一段话说得很到位：“如果你不能度量它，你就不能管理它。” 但更准确的说法应该是：如果你度量错了对象，比不度量更危险——因为你会基于错误的信号做决策。 盲区三：告警基于静态阈值，不感知业务影响 传统告警的逻辑是"指标超过阈值就报”。问题是，同样的阈值在不同业务场景下含义完全不同： 场景 CPU 80% 含义 是否需要告警 凌晨 2 点批处理任务 正常负载 不需要 大促期间核心交易服务 即将打满 紧急告警 测试环境压测中 预期行为 不需要 生产环境空闲时段 异常进程 需要排查 静态阈值无法区分这些场景，导致的结果就是：要么告警太多（告警疲劳），要么告警太晚（用户已经投诉了才报）。...

概述 告警是监控系统的"最后一公里"，也是最难做好的一环。一个常见的困境是：服务器上跑着几十个告警规则，每天产生上百条告警通知，值班工程师在微信/钉钉/邮件的轮番轰炸下逐渐麻木——真正紧急的告警被淹没在噪声中，直到客户投诉才发现系统早已出问题。 SRE 的黄金法则是：每一条告警都应该有明确的处理动作。如果一个告警收到后既不需要立即处理，也不需要记录跟踪，那它就不应该存在。从告警疲劳问题出发，详细梳理告警分级、SLO-based 告警设计、抑制与聚合策略、告警度量指标和治理方法，帮助你从"告警噪声"中提取出真正的"信号"。 参考来源：Google SRE Book《Monitoring Distributed Systems》、Prometheus 告警好的实践 一、告警疲劳：问题的根源 1.1 告警泛滥的典型表现 某团队告警统计（一周）： ┌──────────────────────────┬────────┬──────────┐ │ 告警类型 │ 数量 │ 实际处理 │ ├──────────────────────────┼────────┼──────────┤ │ CPU 使用率 > 80% │ 156 │ 3 │ │ 磁盘使用率 > 70% │ 89 │ 2 │ │ Pod 重启 │ 34 │ 5 │ │ HTTP 5xx 错误率 > 1% │ 12 │ 4 │ │ 数据库连接数 > 80% │ 8 │ 1 │ │ 证书即将过期 │ 3 │ 1 │ │ 服务不可达 │ 2 │ 2 │ ├──────────────────────────┼────────┼──────────┤ │ 总计 │ 304 │ 18 │ └──────────────────────────┴────────┴──────────┘ 有效告警率：18/304 = 5....

概述 错误预算（Error Budget）是 SRE 体系中最精妙的机制设计。它把"稳定性 vs 迭代速度"这个长期依赖口水战的矛盾，转化为一个可量化的工程决策框架：你的系统有一个"不可用额度"，花完了就得停下来修。 但实践中，很多团队定义了 SLO 和错误预算之后，就止步于仪表盘上展示一个百分比数字。预算耗尽时该怎么办？快耗尽时要采取什么行动？预算富裕时可以做什么？这些关键问题如果没有明确的策略，错误预算就只是一个好看的数字，而非真正驱动行为的工具。 详细梳理错误预算的消耗状态模型、每种状态对应的行动纲领、发布冻结的标准与流程、预算滚存与重置策略、跨团队协调机制，并配以实战案例。 本文假设读者已了解 SLI/SLO/错误预算的基本概念。如需补充，可参考 Google SRE Book - Embracing Risk 和本站 SRE核心理念：SLI、SLO与错误预算。 一、错误预算的工程本质 不只是"还剩多少额度" 很多人把错误预算理解为"这个月还能宕机多少分钟"。这只是表面理解。错误预算的工程本质是： 错误预算是创新速度与系统稳定性之间的自动调节阀。 它回答了一个在所有工程团队都存在但很难回答的问题：我们现在应该更激进地发布新功能，还是应该停下来提升稳定性？ 预算充裕 → 系统足够稳定，可以承担更多变更风险 → 加速发布 预告耗尽 → 系统已经接近可靠性边界 → 减速发布，专注稳定性 这个调节是自动的、基于数据的、不依赖个人判断和政治博弈的。 错误预算的计算 SLO = 99.9%（30天窗口） 错误预算 = (1 - SLO) × 时间窗口 = 0.1% × 43200 分钟 = 43.2 分钟/月 已消耗预算 = 实际不可用时间 剩余预算 = 43.2 - 已消耗时间 预算消耗率 = 已消耗预算 / 总预算 但"不可用"的判定不只是"服务完全宕机"。任何 SLI 违规都消耗预算：...