错误预算

概述 某年双十一前 14 天，某电商平台启动了全量封板——所有非紧急变更一律冻结，CI/CD 流水线闸门关闭，只留一个安全补丁通道。运维团队松了口气，觉得这回稳了。 结果大促当天凌晨 2 点，支付链路 P0 告警炸了。 根因不是新代码，而是一个封板前 3 天上线的配置变更——某个限流规则的白名单写错了 IP 段，平时流量小没问题，双十一零点流量打到 8 倍，限流规则误杀了 30% 的正常请求。封板期间没人复查这个配置，因为"封板了，不动了嘛"。 这次故障给我最大的冲击是：封板 14 天，零代码变更，还是炸了 P0。问题不在变更多少，在于变更冻结制造了一种虚假的安全感——你以为关了闸门就安全了，实际上水位一直在涨。 行业数据也支持这个判断。SRE 实践白皮书指出，约 70% 的线上生产故障由变更直接引发。但"变更引发故障"不等于"减少变更就能减少故障"——封板期间积累的配置偏差、无人维护的监控规则、被延迟修复的隐患，都在暗处发酵。 这篇文章要拆解的就是：人工封板到底哪里出了问题，以及如何用错误预算驱动的动态变更窗口替代日历封板。我会给出 5 个工程决策，每个都来自实际项目中的踩坑和修正。 变更冻结的本质：你以为在防故障，其实在做"安全剧场" 先说清楚"变更冻结"到底是什么。 变更冻结（Change Freeze），行业里也叫封板、blackout period、code freeze，指的是在特定时间段内禁止或严格限制生产环境的任何变更操作。常见触发场景： 双十一/618 等大促前 1-2 周 春节/国庆等法定长假期间 核心系统迁移或基础设施切换期间 合规审计期间 IBM 在其云服务的维护策略中明确定义了 Change Freeze Period 的概念：在冻结期内系统正常运行，所有标准自动化流程（如数据库备份）照常执行，但协调性变更（如应用升级）不可用，SRE 团队不在此期间安排维护。 这个定义本身没问题。问题出在执行层面——大多数团队的封板实践，本质上是一种"安全剧场"（Security Theater）： 做法 看起来在做 实际效果 关闭 CI/CD 闸门 阻止新代码上线 配置变更、手动操作绕过流水线照样上 全量冻结所有变更 风险最小化 安全补丁被延迟，隐患变成定时炸弹 人工审批特例变更 精准放行 审批人不懂技术细节，变成橡皮图章 封板期间不巡检 “稳定"了不用看 配置漂移、监控失效无人发现 我不是反对变更冻结——在特定场景下，封板确实有必要。我反对的是"一刀切式"的静态封板：用日历决定什么时候能变更，而不是用数据决定风险有多大。...

概述 你大概率遇到过这个场景：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....

概述 凌晨 1 点 47 分，手机震了。告警群弹出 200 多条消息，订单成功率从 99.8% 掉到 92%。值班同学重启服务、回滚版本，折腾了 40 分钟才恢复。 第二天复盘，根因是下午发版时改了一行数据库连接池配置。这个变更走了完整的审批流程——开发提交、测试验证、主管签字、SRE 评审，审批花了 3 天。3 天审批，1 行配置，40 分钟故障。 这不是个案。Google SRE Book 里有个数据：大约 70% 的服务中断是由变更引起的。我在某电商平台做了 6 个月的统计，比例更夸张——82% 的 P1/P2 故障直接或间接跟变更有关。 问题出在哪？传统变更管理靠"人审"，而人审解决不了三个矛盾： 审批者不一定懂代码：签字的人大多是管理者，看不懂配置变更的技术影响 审批再严也挡不住低级错误：3 天审批审查的是流程合规性，不是技术正确性 审批拖慢迭代速度：开发为了过审拆小包、绕流程，反而增加变更频次 Google 的解法很直接：把变更管理从"人审"变成"机器门禁"，用错误预算做自动裁决，用渐进式发布做安全网。本文拆解我在某出行项目落地这套体系的完整过程——从审批流程改造到 Go 代码实现，包含真实踩坑和性能数据。 传统 CAB 模式的困境 CAB（Change Advisory Board，变更顾问委员会）是 ITIL 时代的标准做法。每次变更提交申请，CAB 成员（通常是运维主管、安全负责人、架构师）开会评审，投票决定是否放行。 听起来很合理，实际跑起来全是问题。 人工审批的三个死结 死结一：审批者看不懂变更内容 我见过一个 CAB，5 个审批人里 3 个是管理层。他们审查什么？表单填写是否完整、影响范围评估是否打钩、回滚方案是否写了。至于那行配置改了什么、对系统有什么实际影响——看不懂，也没法判断。 结果就是，审批变成了走过场。表单填得漂亮就过，填得丑就打回。技术风险？全靠开发自觉。 死结二：审批速度和变更质量无关 审批 3 天，不代表这 3 天里有人在做技术验证。实际情况是：变更提交后躺在 OA 系统里等 2 天，第 3 天 CAB 开会 10 分钟过一下就批了。3 天里有 2 天 22 小时是等待时间。...

概述 凌晨三点，你被告警吵醒。爬起来一看：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 点批处理任务 正常负载 不需要 大促期间核心交易服务 即将打满 紧急告警 测试环境压测中 预期行为 不需要 生产环境空闲时段 异常进程 需要排查 静态阈值无法区分这些场景，导致的结果就是：要么告警太多（告警疲劳），要么告警太晚（用户已经投诉了才报）。...

概述 错误预算（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 违规都消耗预算：...