错误预算

流量对齐的 burn rate 告警分级：凌晨 14x 与高峰 14x 的严重度差异怎么算？ «作者：许墨白-600｜技术文档工程师｜15 年经验 关键词：SLO、burn rate、告警分级、流量对齐、错误预算» 一、现象与背景：流量差异

【背景】 做了 10 年运维，去年带一个 20 人团队给核心交易链路上了 SLO 错误预算（error budget）机制，跑了 5 个月，踩的坑比写代码还多。先给几个具体数字： - 服务 P99 < 300ms，月度 SLO 99.9%，

背景 C 端电商主链路，对外承诺 P99 < 300ms，30 天 SLO 窗口，错误预算 0.05%。入口 QPS 有极强的日内周期：凌晨 0–6 点约 80 QPS，上午 10–14 点约 650 QPS，相差 8 倍。延迟分布也随流量

背景 5 年 SRE，最近负责一条核心查询链路：K8s 1.28，Java 17 / Spring Boot 3，JVM 堆 8G，4 副本（maxSurge=1 / maxUnavailable=0，滚动发布），入口稳态 1200 QPS

背景 我做了 10 年 SRE，最近给一条核心交易链路（P99 SLO 300ms、30 天窗口，对外承诺 99.95%）上了 Google SRE Book 那套「多窗口多 burn rate」告警： - 快窗口：1h / 2h，burn

背景 做了 3 年 SRE，接手过两套业务，SLO 都定过：订单服务 99.95%、支付链路 99.99%、对账批处理 99.5%。看着挺完整，但真到月底复盘，错误预算（Error Budget）基本没人用——它只是季度 OKR 里的一行字

«作者：沈望舒-936｜技术 PM 5 年｜习惯把原理拆成能算、能抄的步骤 关键词：SLO、错误预算（Error Budget）、burn rate、变更冻结» 一、现象与背景：目标喊得越狠，团队越不诚实 先给一组我经手的真实数字。我们一条

背景 我们团队给核心交易链路定了 SLO：月度成功率 99.95%、P99 延迟 < 300ms。前两周一切正常，第三周开始错误预算肉眼可见地往下掉——到第 18 天已经烧掉 60%。按 Google SRE 那套「错误预算耗尽 → 冻结变