/tags/alerting/ Recent content in alerting on Hugo -- gohugo.io en Sun, 26 Apr 2026 00:45:00 +0800 /posts/slo-error-budget-multi-burnrate-2026/ Sun, 26 Apr 2026 00:45:00 +0800 /posts/slo-error-budget-multi-burnrate-2026/ 📦 本文基于的完整项目源码：meirongdev/shop 阈值告警（“5xx > 1% 持续 5 分钟”）的两个失败模式工程师都熟悉：阈值定低了一周告警一百条没人看，阈值定高了真出事告警来得太晚。Google SRE Workbook 第 5 章给出的思路是 error budget + multi-window multi-burn-rate——让告警的“敏感度”随事件严重程度变化。本文更像是一次整理：为什么、怎么做、以及落地时绕不开的取舍。 一、SLO 和 error budget 的底层逻辑 Q：SLO 不就是"99.9% 可用"这种数字吗？跟告警有什么关系？ 至少在工程落地里，SLO 一个很重要的用途是把 reliability 变成预算。 SLO 99.9% 意味着每个 30 天窗口允许 0.1% 的请求失败——这就是 error budget。 把整个 30 天窗口的 budget 按时间切片：1 分钟内允许失败的请求量很小（少量异常就把这分钟的 budget 烧光），但 30 天内的累计可以容忍。 如果短窗口内的烧速大于"按比例消耗"的速度，说明这次事件如果不止住，会提前烧完整个月的预算——这就是值得告警的事件。 阈值告警是"超过 X 报警"——只看一个时间点。Burn-rate 告警是"按当前的烧速会在多久烧完月度 budget"——看的是趋势对未来的投影。 Q：burn rate 怎么算？ 定义：burn rate = 观察窗口内的实际错误率 / SLO 允许的错误率。 SLO 99.9% → 允许错误率 0.