每一条误报都在教你不要看告警。
一、他被自己的告警叫醒了二十二次
程野给自己配了告警：CPU、内存、磁盘、错误率、响应时间、队列长度，全发到手机。第一个月，他被叫醒二十二次。
第二个月，他把通知改成了静音，只在早上翻一眼。第三个月，支付回调连续失败四十分钟，他在睡觉，早上才发现。
以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。
告警疲劳不是意志问题，是设计问题。 当 92% 的通知都不需要行动时，忽略它们是理性选择。
降噪的目标不是变少，是变准。 条数下降但漏报增加，等于换了一种失败方式。
一个人没有值班表。 你没有第二个人可以轮换，所以唯一的注意力必须只花在真正的故障上。
二、四十条告警的构成
先把上个月的告警导出，逐条分类，再谈怎么改。
| 类型 | 条数 | 占比 | 典型例子 | 处置 |
|---|---|---|---|---|
| 抖动 | 22 | 55% | 单次请求超时、瞬时 CPU 尖峰 | 加持续时间条件 |
| 重复 | 9 | 22.5% | 同一故障从三个维度各响一次 | 抑制与聚合 |
| 非紧急 | 6 | 15% | 磁盘 71%、备份任务慢了 | 改看板，不通知 |
| 真实 | 3 | 7.5% | 登录失败率超阈值、队列停摆 | 保留并分级 |
抖动来自瞬时值。 一次 5xx、一次 800 毫秒延迟都会触发；加上「连续 3 次或持续 5 分钟」，22 条里通常只剩 1 到 2 条。
抖动与真实故障的差别在持续时间。 单次 5xx 多半是网络重试；连续十分钟的 5xx 才是故障。
重复来自多维度。 错误率、延迟、可用性三个告警说的是同一件事；按服务聚合，只发最靠近症状的那一条。
聚合要按服务，不按指标。 同一服务的错误率与延迟合成一条；跨服务的告警不要合并，否则会掩盖第二个故障。
非紧急要降到看板。 磁盘 71% 不该在凌晨通知你；改成 85% 才通知，71% 留在日检表里。
真实告警也要分级。 3 条真实里可能只有 1 条需要立刻处理，另外 2 条可以在工作时间处理。
三、三级分级与触发规则
分级的标准不是严重程度形容词，而是「多久之内必须有人动」。
| 级别 | 判定 | 通知方式 | 响应时间 | 例子 |
|---|---|---|---|---|
| P1 | 核心路径不可用或数据可能丢失 | 电话或强提醒，重复呼叫 | 15 分钟内 | 登录全挂、支付回调失败、数据库不可写 |
| P2 | 核心路径降级或成本异常 | 即时消息 | 4 小时内 | 错误率 1%、队列积压、账单翻倍 |
| P3 | 趋势问题，不影响当前使用 | 只看板，每周汇总 | 本周内 | 磁盘 71%、备份变慢、证书 30 天后到期 |
P1 只留三条。 登录、支付、数据写入；其他都进不了 P1，否则电话会变成噪音。
P1 的通知必须能穿透静音。 手机静音、专注模式、夜间免打扰都要单独放行，否则分级只是纸面。
用症状告警，不用原因告警。 「登录失败率超过 5%」比「数据库连接数超过 80%」更接近用户感受；原因类指标用于排查，不用于叫人。
持续时间是免费的降噪器。 把「立刻通知」改成「持续 5 分钟」，通常能去掉一半以上抖动。
持续时间要按路径定。 登录失败持续 2 分钟就够，报表任务失败持续 30 分钟才算问题；一刀切会误伤。
抑制窗口要写死。 同一服务 30 分钟内只发第一条，后续折叠成计数；恢复时只发一条恢复通知。
静默要有时限。 发布窗口静默 20 分钟，到点自动解除；手动静默容易忘记解除，最后变成永久静音。
四、把预算还给工作
告警处理时间是运维预算里最大的一块。
现状：40 条/月 × 平均 7 分钟 = 280 分钟 = 4.7 小时/月
运维预算：4 小时/月 → 已超 0.7 小时，缺口来自加班
调整后：3 条/月 × 7 分钟 = 21 分钟/月
释放：280 − 21 = 259 分钟 ≈ 4.3 小时/月 = 51.6 小时/年
误报率 = (22 + 9) ÷ 40 = 77.5%
把「单次触发」改成「持续 5 分钟」：22 条抖动预计剩 2 条
按服务聚合：9 条重复预计剩 3 条
4.3 小时可以换成一次恢复演练。 释放出来的时间不要拿去做新功能，先用它把 82 分钟那次数据库恢复压到 30 分钟。
释放的时间要记账。 把省下的 4.3 小时写进下月计划，否则它会被新功能悄悄吃掉。
误报率要按月追踪。 目标从 77.5% 降到 30% 以下；只看总条数会掩盖结构问题。
告警数量不是 KPI。 零告警可能意味着阈值太松；要同时看「漏报」：故障发生时告警有没有响。
每周花十分钟清一次。 把本周的告警过一遍，该加持续时间的加、该降级的降；不清，三个月后又会回到 40 条。
清理要有删除权。 留着不删的告警会占满注意力；删掉并记录原因，比调低阈值更彻底。
五、行动清单与复算验收
降噪是删减工作，不是增加工具。
- 导出上个月全部告警，逐条标注类型。
- 统计抖动、重复、非紧急与真实四类各多少条。
- 给所有告警加持续时间条件，先设 5 分钟。
- 按服务聚合，同源只保留最接近症状的一条。
- 把 P1 限定为登录、支付、数据写入三类。
- 非紧急告警移出通知，只进看板与周报。
- 发布窗口设 20 分钟自动解除的静默。
- 每周一花十分钟清理上周告警。
验收标准：你能说出上个月告警的条数、误报率与 P1 的判定条件；说不出，说明你还在用通知数量代替告警设计。
使用边界与实操验收
本文处理的是一人产品的告警策略，不涉及企业级值班体系。
轮班与升级链不归本文。 没有第二个人时，「升级」只能升级到暂停功能或公告用户。
告警平台选型不归本文。 本文的规则在邮件、即时消息与电话呼叫上都成立。
别把监控指标当告警指标。 CPU、内存适合看趋势，不适合叫人；叫人的应该是用户能感知的症状。
告警要能被验证。 每季度人为触发一次，确认通知真的到达；没验证过的告警等于没有。
静默不等于解决。 静默期内故障仍在发生；静默结束必须回看这段时间的错误数。
阈值要随版本调整。 新版本上线后基线会变，旧阈值可能连续误报一周。
通知渠道要有一条备用。 主渠道故障时，至少还有一个能到达你的方式。
关键参考与核验范围
核验日期：2026-10-25。以下链接用于核对症状告警与降噪的一般做法，本文未逐条引用其内容。
- Google SRE Workbook：基于 SLO 的告警 ：用于核对「按症状与预算消耗告警」的原则。
- PagerDuty：告警疲劳 ：用于核对告警疲劳的常见成因与缓解方式。
引用口径。 本文只借用「分级 + 症状告警 + 抑制」这一一般结构；40、22、9、6、3 与 7 分钟全部是教学假设，与上述材料无关。
口径一致。 40 条告警与《可用性是一份预算》的 4 小时预算、《最小监控》的五条探针共用同一套假设。
核验范围。 核验的是「三级分级能否让一个人守住三条主路径」，不是比对某家告警服务的功能。
如何自行复核。 取上周告警，按四类重新分类；若抖动占比超过一半，说明持续时间条件还没加上。
系列导航
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。