让告警直接支持故障判断与处置

告警是监控系统在某项测量值越过阈值时发出的消息。它的价值，体现在能否帮助接收者决定接下来十分钟该做什么。

Google 的《SRE Workbook》建议：当服务在一小时内消耗了 2% 的错误预算，也就是消耗速率（burn rate）达到 14.4 时，应触发呼叫告警；六小时内消耗 5% 时，也应触发呼叫告警。同一张表则将三天内消耗 10% 的情况交给工单队列处理。

选择多长的时间窗口，决定了会收到多少次呼叫告警。对于 99.9% 的目标，采用十分钟窗口时，一次仅消耗月度错误预算 0.02% 的事件就足以触发告警。

分组、抑制、静默和定时静音，是防止一个依赖故障演变成上百条通知的机制。

呼叫告警必须包含故障表现、影响范围、时间窗口和 runbook，还必须明确指出由谁值班。

小团队可以从一个呼叫级阈值、一个工单级阈值和每周一次复盘起步。要判断这些呼叫告警是否值得打扰人，就得查看实际触发过的告警。

一条告警必须包含什么

告警是一条会在不方便的时间送到手机上的消息。读到它的人有三个问题：用户此刻遇到了什么，服务有多大范围受到影响，以及处理说明在哪里。能回答这三个问题的通知，可以让人直接着手处理。只报出一个指标名称的通知，则会让人开始搜索。

Prometheus 的 Alertmanager 文档介绍了这个组件如何处理收到的告警：去重、分组，再路由到 email、PagerDuty 或 OpsGenie 等接收端。去重和路由处理的都是已经存在的告警，因此，真正的设计决策发生在更上游：告警规则负责判断，系统什么时候有值得说的事情。

Prometheus 官方 Alertmanager 文档截图（prometheus.io/docs/alerting/latest/alertmanager/，获取于 2026-10-14）：组件自身对分组、抑制和静默的说明。

来看一个明确虚构的例子。六个人运营一家网店，系统包含结账页面、支付服务商，以及每晚执行的库存同步任务。如果规则规定，只要支付服务商的错误计数器大于零就触发呼叫告警，那么每次银行卡支付被拒都会触发呼叫。如果规则规定，当结账成功率低于目标时才触发呼叫告警，那么客户无法购买商品时，团队才会收到呼叫。第一条规则描述的是一个依赖，第二条规则描述的是业务正在遭受什么损失。

消耗速率的时间窗口如何决定呼叫告警数量

窗口大小对呼叫告警数量影响很大，《SRE Workbook》对此给出了量化说明。书中的例子从 99.9% 目标下的十分钟窗口出发，展示了这种设置的代价：错误率达到 0.1% 就会触发告警，而此时仅消耗了月度错误预算的 0.02%。扩大窗口可以提高准确率，因为告警需要消耗更多预算才会触发。作者建议以消耗速率作为起点，用阈值描述服务相对于目标消耗错误预算的速度。

这些具体数字值得记住。一小时内花掉 30 天错误预算的 2%，对应的消耗速率是 14.4；六小时内花掉 5%，对应的消耗速率是 6。这两种情况都应该进入呼叫通知流程。三天内花掉 10%，对应的消耗速率是 1，书中将其放入工单队列，适合处理那些可以在工作时间内消化的缓慢损耗。如果问题会在数小时内耗尽预算，主动通知就值得打断人。

Netics 编辑部示意图：将《SRE Workbook》表 5-6 中的三组消耗速率阈值及时间窗口，对应到各自适合采用的通知方式。

再做一项改进，就能补上大部分剩余缺口。多窗口告警会在检查长窗口的同时，检查一个短窗口，通常可以将短窗口时长设为长窗口的十二分之一，让错误停止后，呼叫告警也能很快停止触发。书中的例子要求，过去一小时和过去五分钟的消耗速率都超过 14.4，才触发呼叫告警。同一节还给出了一条在真实事故发生后就会体现价值的提醒：相互重叠的窗口描述的是同一次事故，因此需要抑制机制，避免一个故障带来三条通知。

用分组和抑制，将依赖故障收敛成一条通知

一个依赖发生故障后，产生的告警数量会随着依赖它的组件数量增加。Alertmanager 的作用，就是把这种数量膨胀压下来。它通过分组，将性质相似的告警合并成一条通知。文档举的正是这种场景：网络分区导致一半服务实例无法访问数据库，检测层随即发出数百条告警。按集群和告警名称分组后，就能生成一条简洁的消息，同时保留受影响实例的名单。

抑制从另一个角度解决同样的问题。当一条告警指出整个集群都无法访问时，只要这条更大范围的告警仍在触发，Alertmanager 就可以将关于该集群的其他所有告警静音。只需在配置中声明一次抑制关系，就能让响应人员免于阅读上百条描述同一次故障的通知。

Grafana Alerting 官方文档截图（grafana.com/docs/grafana/latest/alerting/，获取于 2026-10-14）：将联系点、通知策略、定时静音、静默和抑制规则作为独立的控制项。

对于情况恶化时的告警洪峰，还有一道硬上限。Alertmanager 可以限制单个告警名称下处于活跃状态的告警数量。达到上限后，它会丢弃新告警，但仍会处理已知告警的心跳，并通过计数器暴露丢弃的告警数量。文档将这项功能定位为对接收端的保护，明确提到的使用场景，就是同一种告警的实例突然大量涌入。

用静默和定时静音覆盖计划内工作

静默会根据告警自身的标签进行匹配，在指定时间段内将其静音。Alertmanager 可以通过 Web 界面配置静默。Grafana 的告警文档则将这类控制进一步区分：定时静音和活跃时间区间用于周期性窗口，静默用于一次性维护，而抑制规则用于更大范围的告警已经覆盖当前情况的场景。

设计时需要考虑的是：谁有权创建这些设置。静默如果超过变更窗口仍未结束，就成了一个带时间戳的监控盲区。因此，团队需要两个字段来保证它可审计：原因和到期时间。Grafana 文档将静默访问权限视为一项独立权限，与编辑规则的权限分开。

Google《SRE Workbook》中“基于 SLO 告警”章节的截图（sre.google/workbook/alerting-on-slos/，获取于 2026-10-14）：上文的消耗速率阈值就出自这一章。

响应人员在凌晨 03:00 打开的 runbook

一条能把情况解释清楚的呼叫告警，首先要有四个字段：用用户能理解的语言描述故障表现，用数字说明影响范围，注明测量覆盖的时间窗口，以及提供处理说明的链接。前三项来自告警载荷。第四项靠日常维护，因为一个指向空白页面的 runbook 链接，比没有链接还糟。

负责人是第五个字段。一条告警对能够处理它的团队来说有意义，对其他人来说就是噪声。因此，路由决策应该在创建告警的规则中明确。Alertmanager 的路由树将这种归属关系保存在配置里，即使人员变动也能保留下来。

有一个实用的测试，不需要任何成本：打开上个月触发最频繁的三条告警所对应的 runbook，设想自己就是那个刚从睡梦中被叫醒的人，再读一遍。如果文字开头还是一个指标名称，这条告警就还没有设计完。

小团队的起步配置

四项决策就能覆盖小团队遇到的大多数情况。为每条面向用户的流程选定一个目标，例如结账成功率，或任务在一小时内完成。围绕这个目标编写两条告警规则：一条采用 14.4 的消耗速率阈值，进入呼叫通知流程；另一条采用 1 的阈值，生成工单。将 14.4 的规则路由到值班通知渠道，将 1 的规则路由到工单队列，两者都按服务分组，并设置每个告警名称的数量上限，避免单个故障淹没值班渠道。明确接下来一周的值班人员，并将 runbook 链接放进告警注解。

Netics 编辑部示意图：按照团队实际处理的顺序，展示告警设计的四个步骤，从用户遇到的故障表现，到附在告警中的 runbook。

为了保持配置精简，这个初始版本有意暂缓加入书中的第二档呼叫告警，也就是六小时内消耗速率达到 6 的情况。等两条规则落实后，再将这一档加入呼叫通知流程。在此之前，消耗速率低于 14.4 时，不会呼叫任何人。

如何衡量呼叫告警是否值得打扰人

真正重要的数字，都在告警触发历史里。统计上个月收到了多少次呼叫告警，其中多少次带来了实际操作，又有多少次被当作噪声关闭。从不带来实际工作的呼叫告警，可以考虑降级为工单；反复演变成故障的工单告警，则可以考虑升级。

每周做一次简短复盘。阅读出现最频繁的三条告警，对照消耗速率表检查它们的窗口，并确认 runbook 描述的仍是当前架构。缺少这一步，静默列表就会越来越长，大家对告警渠道的信任也会越来越少，最终付出的代价更高，根源却还是同一个问题。

Netics 的基础设施监控方案采用通俗语言告警，为每条告警概括可能的原因和最先该做的几步，过滤噪声，并且只在你批准后，才执行预先准备好的 runbook 操作。

如果你希望有人帮你再评估一下，这些阈值在你的服务中应该设在哪里，可以预约一次免费的 30 分钟审查，并带上上个月的告警触发历史。审查会从这份清单入手，决定哪些呼叫告警应该保留。

本文最初发表于 Netics 博客。

如需采取进一步措施，可以考虑屏蔽此人和／或举报滥用行为。