错误预算不是限制告警，而是用SLO给告警装上频率调节阀：预算充足时告警可以安静，预算燃烧异常时才拉响，从而把无意义的打扰挡在门外。
错误预算怎么设置才合理？先给SLO定一个真实底线
错误预算的计算公式很简单：错误预算 = 1 - SLO，比如可用性SLO定在99.9%，错误预算就是0.1%，一个月大约43分钟不可用，这个数字不是拍脑袋出来的，它背后只有一个问题：用户能容忍你的服务坏多久。
设置错误预算时,多数团队会踩三个坑。
- 把SLO定得过高,99.99%的可用性意味着一个月只允许约4.3分钟不可用，任何一次常规发布或网络抖动都可能把预算烧光，告警会频繁到让人直接静音。
- 把所有服务都套同一个SLO,核心支付服务定99.95%也许合理，但内部报表服务也这样定，只会逼着运维半夜处理根本不紧急的故障。
- 把错误预算当成性能目标,业内专家指出，错误预算最大的误区是把它理解为“要尽量少用”，而不是“用户可接受失败的数字化表达”，预算不是省下来的钱，是允许你犯错的额度。
正确的设置路径应该从业务容忍度反推。
- 先问业务方：这个服务中断多久，用户会开始投诉或流失。
- 再把业务容忍度转换成SLO,比如用户能接受一个月最多20分钟不可用，SLO就定99.95%左右。
- 初期可以稍微宽松,比如99.9%，运行一两个月后再收紧。
- 每个服务单独设置SLO,不要搞一刀切。
SLO一旦确定,错误预算就有了总量，但光有总量还不够，告警频率的真正控制，要看你有没有把预算的消耗速度纳入监控。
SLO和SLA的区别是什么？告警策略从这里分岔
很多团队直接把SLA当告警阈值,这是告警频率失控的根源之一，SLA是对外合同承诺，比如跟客户签99.9%，违约就要赔钱，SLO是内部健康目标，通常比SLA更严格，比如99.95%，两者对告警的作用完全不同。
- SLA是底线,触达时用户已经受到影响，告警来得太晚。
- SLO是提前量,在接近违约前就发出信号，给处理留出缓冲。
- 错误预算基于SLO计算,不是基于SLA，用SLA算错误预算，等于用户已经疼了你才按铃。
用一张表看会更清楚。
| 维度 | SLA | SLO |
|---|---|---|
| 定义 | 对客户的合同承诺 | 内部服务健康目标 |
| 违约后果 | 赔偿、扣款、信用损失 | 内部复盘、改进 |
| 告警角色 | 事后通知，往往已造成用户影响 | 事前预警，提前介入 |
| 数值高低 | 通常较低，如99.9% | 通常更高，如99.95% |
| 错误预算来源 | 不应使用 | 正确来源 |
为什么SLO和SLA的区别会直接决定告警频率？因为SLO更严格，错误预算更小，消耗速度更敏感，一旦你开始用SLO计算预算，告警就不再是“某个指标超了”，而是“用户可接受的失败额度正在以多快的速度消失”。
错误预算燃尽率怎么计算？Burn Rate决定告警急不急
错误预算燃尽率,也叫Burn Rate，是SRE领域用来约束告警频率的核心工具，它回答的是：你消耗预算的速度，是不是比时间流逝更快。
计算公式可以这样理解：
- 先算总预算,30天周期，SLO 99.9%，错误预算约43分钟。
- 再看时间窗口,比如过去1小时，系统错误率导致不可用时长折合2分钟。
- 2分钟占总预算43分钟的比例,约4.65%，换句话说，你在1小时里烧掉了整个月预算的4.65%。
- 如果按线性消耗,1小时只应该用掉总预算的约0.139%，现在实际消耗是这个速度的几十倍，说明故障正在指数级放大。
多窗口、多阈值是控制告警频率的关键，实际操作中通常会设置短窗口和长窗口两条规则。
- 短窗口规则：过去1小时消耗超过总预算的2%，触发页级告警，这意味着故障发展极快，必须立刻响应。
- 长窗口规则：过去6小时消耗超过总预算的5%，触发电话告警，故障没有瞬间爆炸，但已经持续损耗。
- 极长窗口规则：过去3天消耗超过总预算的10%，触发邮件或工单，说明存在慢性问题，可以排期处理。
在监控系统里落地时,可以这样拆步骤。
- 定义SLI指标,比如请求成功率。
- 用监控查询统计错误请求量与总请求量。
- 把错误量换算成错误预算消耗量。
- 在告警规则中同时判断两个窗口的Burn Rate。
- 为不同Burn Rate级别绑定不同通知渠道。
这样配置后,告警频率会天然降下来，因为大多数瞬时毛刺不会让短窗口Burn Rate超过2%，只有真正的持续性故障才会触发页级通知。
告警疲劳怎么解决？让错误预算当裁判
传统监控为什么容易产生告警疲劳？因为它只看单指标阈值，CPU超过90%响一次，内存超过85%响一次，磁盘IO等待超过阈值再响一次，这些指标在业务上可能毫无影响，但告警已经铺天盖地。
错误预算的思路恰恰相反：它不关心某个资源指标是否超过阈值，只关心用户可接受的失败额度还剩多少。
- 一个CPU尖峰持续20秒就回落,错误预算几乎不动，就不该告警。
- 一个慢查询导致错误率小幅上升,但预算消耗速度正常，也不用告警。
- 只有当错误预算在短时间内大量消失,才说明用户正在受伤，才值得打断值班人员。
用错误预算当裁判,具体能解决三类告警疲劳。
- 关联性告警太多,数据库连接池满、缓存穿透、队列堆积，背后可能是同一个上游故障，错误预算只看用户可见的失败结果，多个关联指标最终会收敛到一个预算告警。
- 夜间低优先级告警太多,以前半夜收到磁盘空间低于20%的告警，值班人员还得爬起来处理，现在只要错误预算没有快速燃烧，这类告警可以降级为次日处理。
- 发布期间告警爆炸,发布经常导致短暂的错误率上升，传统阈值会连续触发，错误预算允许自然消耗，只有发布使预算燃烧过快时才升级告警。
落地时,可以把原来的资源类阈值告警和错误预算告警做分工。
- 错误预算告警：决定要不要叫醒人，属于主开关。
- 资源类阈值告警：辅助定位问题，默认静默或低优先级。
- 错误预算燃烧过快时,再临时启用具体资源指标的细粒度告警。
一张对比表能更直观看出差别。
| 对比项 | 传统阈值告警 | 错误预算告警 |
|---|---|---|
| 触发条件 | 任意指标超过固定值 | 预算消耗速度超过允许值 |
| 关注点 | 资源或性能指标 | 用户可见失败 |
| 误报率 | 较高 | 较低 |
| 对值班干扰 | 频繁，易疲劳 | 只在故障真正升级时通知 |
| 告警数量 | 大量碎片化 | 少量聚合化 |
一个中大型电商的告警降噪实例
假设某中型电商的支付服务团队,之前给支付系统配了几十个阈值告警：GC时间、线程池使用率、数据库连接数、磁盘IO、网络重传率，每天告警量经常达到几十条，值班人员基本麻木，真正严重的故障反而被淹没在噪声里。
团队后来按错误预算重新设计告警。
- 先确定支付成功率SLI,SLO定为99.95%。
- 月错误预算约21分钟,即用户每月可接受的支付失败时间。
- 设置短窗口规则：过去30分钟错误预算消耗超过1%，触发页级告警。
- 设置长窗口规则：过去6小时消耗超过5%，触发电话告警。
- 设置极长窗口规则：过去3天消耗超过10%，只发邮件。
- 原来那些资源类阈值告警全部降为低优先级,默认不发通知。
结果告警量从每天几十条降到个位数,GC时间、线程池这些指标还在监控，但它们不再直接叫醒人，只有支付成功率持续下降、错误预算快速燃烧时，值班手机才会响，这个场景里，错误预算扮演的就是告警调度员：平时安静，出事时精准唤醒。
把告警频率还给用户痛感
错误预算用SLO约束告警频率的原理并不复杂：先把用户容忍度翻译成数字化的错误预算，再用Burn Rate衡量预算消耗速度，最后只让异常消耗触发告警，预算烧得慢，系统可以保持安静；预算烧得快，再小的指标波动也不能忽略。
Q&A
错误预算怎么设置才合理？
从业务可接受的不可用时长反推,比如用户能接受一个月不超过20分钟不可用，就把SLO定在99.95%，错误预算就是0.05%，先宽后严，运行一段时间再逐步收紧，比一开始定极端高值更现实。
SLO和SLA的区别是什么？对告警频率有什么影响？
SLA是合同承诺,违约要赔偿；SLO是内部健康目标，通常比SLA更严格，用SLO计算错误预算，可以提前告警，减少用户实际受损的时间，用SLA直接做告警阈值，告警会来得太晚，而且一旦违约，内部警告已经失去意义。
告警疲劳怎么解决？错误预算能完全替代阈值告警吗？
错误预算通过聚合用户可见失败,减少碎片化告警，解决“该不该响”的问题，但资源类阈值告警在定位问题时仍然有用，不能完全替代，事实是两者定位不同：错误预算告警做主开关，资源阈值告警做排查辅助。