告警窗口与燃尽率：十分钟0.02%预算

```html

凌晨三点，手机在床头柜上震了一下。你摸黑抓起来看，屏幕上是一行指标名，没有别的。你不知道用户此刻遇到了什么，不知道有多少人受影响，也不知道下一步该点哪里。这条消息唯一确定的事情，是今晚的觉睡不成了。

告警的价值不在它响的那一刻，而在它让人在接下来十分钟里能做出什么决定。一条能回答"用户正在遭遇什么、影响范围多大、操作手册在哪"的通知，会变成工作；一条只报出指标名的通知，只会变成一次搜索。

Prometheus 的 Alertmanager 文档把这件事说得很清楚：这个组件负责对收到的告警做去重、分组，再路由到邮件、PagerDuty 或 OpsGenie 这类接收端。去重和路由都作用在已经存在的告警上，真正决定"系统什么时候该开口"的判断，发生在更上游的告警规则里。

一个假设场景：六个人的小团队

六个人维护一家网店，有结算页、支付服务商，还有一个每晚跑的库存同步任务。如果规则写成"支付服务商的错误计数一超过零就呼叫"，那么每一次信用卡拒付都会触发一次呼叫。如果规则写成"结算成功率跌破目标值就呼叫"，触发时才是顾客真的买不了东西。

前一条规则描述的是一个依赖项，后一条描述的是业务正在损失什么。同样一套监控，两种写法，夜里被叫醒的次数差出好几个量级。

窗口大小直接决定你会被叫醒几次

Google 的 SRE Workbook 把这个影响量化了。它的例子从 99.9% 目标上的一个十分钟窗口开始：0.1% 的错误率就会触发告警，而这次触发消耗的只是月度错误预算的 0.02%。窗口拉长，精度随之提高，因为告警需要更大的预算消耗才成立。作者推荐的起点是燃尽率框架——阈值描述的是服务相对目标消耗错误预算的速度。

几个数字值得记住：

• 30 天预算中的 2% 在一小时内烧完，燃尽率为 14.4，进呼叫通道
• 5% 在六小时内烧完，燃尽率为 6，同样进呼叫通道
• 10% 在三天内烧完，燃尽率为 1，进工单队列

最后那一档适合慢速渗漏，一个工作日足够消化。而几小时内就把预算烧穿的故障，才配得上一次主动打断。

还有一个细节能补上大部分缺口：多窗口告警。短窗口和长窗口一起检查，短窗口取长窗口时长的十二分之一作为经验值，错误一停，呼叫很快就停。Workbook 的例子是燃尽率在过去一小时和过去五分钟都超过 14.4 时才呼叫。同一节还提醒了一件事：重叠的窗口描述的是同一起故障，需要抑制机制，否则一次故障会发出三条通知。

分组和抑制把一百条压成一条

一个依赖坏掉，产生的告警数量和依赖它的东西成正比。Alertmanager 的分组概念就是把性质相近的告警收进一条通知。文档给出的正是这个场景：网络分区让一半服务实例连不上数据库，几百条告警涌出检测层，按集群和告警名分组后，变成一条仍然点名了受影响实例的紧凑消息。

抑制从另一个角度处理同一个问题。当一条告警声明整个集群不可达时，Alertmanager 可以在它持续触发期间，把这个集群的其他告警全部静音。抑制在配置里声明一次，响应者就不必去读一百条描述同一次故障的通知。

最难看的情况还有一个硬上限。Alertmanager 可以限制单个告警名下的活跃告警数量，达到上限后丢弃新来的，但仍然处理已知告警的心跳，并对外暴露一个被丢弃数量的计数器。文档把这个特性定位为对接收端的保护，点名的用例是同一告警的实例数量意外暴增。

静默和静音时段管的是计划内工作

静默在声明的时段内按告警自身的标签匹配并屏蔽告警，Alertmanager 通过网页界面配置。Grafana 的告警文档把同一族控制拆得更细：静音时段和活跃时间区间用于周期性窗口，静默用于一次性维护，抑制规则用于更大的告警已经覆盖了当前情况的时候。

设计问题在于谁有权创建它们。一个活得比变更窗口还长的静默，就是一个带时间戳的盲区。所以团队需要两个让它可以被审计的字段：原因和过期时间。Grafana 的文档把静默权限当作一项独立权限，和编辑规则的权限分开。

凌晨三点打开的那份手册

一条能自我解释的呼叫，开头有四个字段：用用户语言描述的 symptom、用数字描述的范围、测量覆盖的时间窗口、以及指向操作说明的链接。前三个来自告警负载，第四个来自纪律——指向空白页面的手册链接，比没有链接更糟。

第五个字段是负责人。一条告警对能处理它的团队有意义，对其他人都是噪音，所以路由决策应该属于创建它的那条规则。Alertmanager 的路由树把这份归属留在配置里，人员变动也不会丢。

有个不花钱的测试：把上个月触发最频繁的三条告警的手册打开，用那个当时正在睡觉的人的视角读一遍。如果正文从指标名开始，这条告警就没写完。

小团队的起步配置

四个决定能覆盖小团队遇到的大部分情况。为每个面向用户的旅程选一个目标，比如结算成功，或者任务在一小时内完成。针对它写两条规则，一条用 14.4 的燃尽率阈值走呼叫通道，一条用 1 的阈值走工单。把 14.4 那条路由到值班路径，1 那条路由到工单队列，两条都按服务分组，并设置单告警名上限，让一次故障淹不了值班频道。指定下一周的值班人，把手册链接放进告警注解。

这个初版有意推迟了 Workbook 的第二档呼叫阈值——六小时燃尽率 6，为的是让配置保持精简。等两条规则跑顺了，这一档再加入呼叫路径；在那之前，燃尽率低于 14.4 的情况不会叫醒任何人。

这些呼叫到底值不值

真正有用的数字在触发历史里。数一数上个月来了多少次呼叫，多少次导向了行动，多少次被当作噪音关掉。一次从不导向工作的呼叫，是降级为工单的候选；一条反复演变成故障的工单告警，是升级的候选。

复盘保持每周一次、时间很短。读触发最频繁的三条告警，对照燃尽率表检查它们的窗口，确认手册还在描述当前架构。少了这一步，静默列表会越来越长，对这个通道的信任会越来越少——那是同一个问题更贵的版本。