发布门禁

概述 你大概率遇到过这个场景：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% 听起来还有不少啊"。你得换一种语言。...