本节摘要:一条告警如果不说清楚"多严重、该谁处理、得多快处理",就只是一句无用的打扰。本节给出先按"影响范围 × 严重度"定级别、再按"级别 + 值班排班"定优先级的两步法,并拆解告警触达渠道(电话、IM、邮件、Webhook)与沉默期的设计。一个「同一事件 vs 共同调度」的编排点会帮你理顺不同级别该用哪种触达。
有个真实对照:团队 A 的告警不分级,不管磁盘剩 10% 还是磁盘满 100%,全都往同一个 IM 群轰炸;团队 B 分级,只有 P0/P1 才打电话 P2 才进群。一个月下来,团队 A 的告警群被全体静音,真出事反而没人看见;团队 B 的关键告警,每个人都第一时间回应。差别就在"级别是否把噪音隔开"。
所以告警分级的本质是给每条告警配上一个明确动作:我该被吵醒吗、紧急到哪种程度、谁负责、去哪个门户处理。而不是一句"提醒你一下"。
分级的依据是两个独立维度,合起来判断:
把两者交叉,告警落进以"Priority"标号的级别。给一套常见口径(各团队可改名但思路通用):
| 级别 | 典型语义 | 处置时限 | 例 |
|---|---|---|---|
| P0 | 严重影响用户,需要立即介入 | 立即 | 全站不可用、核心交易中断、数据损坏 |
| P1 | 大范围降级或部分不可用 | 15 分钟 | 主打接口错误率大幅上升、缓存雪崩 |
| P2 | 局部受影响但可控 | 工作日当天 | 单个节点异常、个别租户慢 |
| P3 | 已知隐患、可选处置 | 排期 | 磁盘 80%、证书将过期 |
级别不是工作量的标签,而是"该多快响应"的共识。P0 意味着值班人必须被叫醒;P3 意味着你可以在正常工作时间排期,不用为它子夜爬起。
级别定的是"多严重",优先级再叠一个"谁、在什么时间处理"的维度,合起来才是真正落地的动作:
把定级和响应动作画在同一张图上,这条"升阶梯"一眼就能明白——级别越高,响应越急、触达越强、升级越快。

从底层走到顶层,响应动作从"排期"一路升到"立即打断值班人"。真正的纪律在于:级别越高,升级链越要自动接住,第一棒没人接,下一棒自动顶上——这才叫把级别落实成动作,而不是标签。
值班排班决定了"谁"来处理——所以各负责人的联系电话、IM、交接规则都必须完整。轮转交接的断裂,是 P1 级告警没人应的最常见原因。交接尤其要留一个"当前谁 on-call"的实时清单,并且和排班表联动,否则人换了班、告警还是找旧人,等级再清晰也落不了地。
升级链是分级里最后一道保险。它解决的是"第一责任人正好没看见/没接"的真空:给每级告警设好一级、二级、三级响应人,第一棒在限定时间内没确认,系统自动升级到下一棒,一直升到有人接手。这条链不是可有可无的排班表,而是把"一定有人会应"变成制度。我见过一次 P0,值班人恰好在电梯里没信号,靠升级链自动打给了技术负责人,才算没让故障等了三小时没人看。没有升级链,分级再细也只是一张没人执行的表。
触达渠道的选择和前面级别强相关。常见渠道:
现代编排更倾向"一个事件一条龙":让告警先落到事件追踪系统(生成事件单),再按级别触发对应渠道的通知,所有处置动作都附着在事件单上形成记录。这样既能叫醒人,又把整场处置串成一个可复盘的事件。
还有一个常被忽略但很关键的设计——沉默期(MUTE)。当你已知某个时刻在做维护,或者已知某指标会因正常操作而波动,就该让相关告警提前静默,免得维护本身也把值班人吵起来。
实现上分两类:
我的建议:把"P0 必须叫醒、P1 走值班、P2 进工作队列、P3 排期"这四条铁律钉进团队协作规范,配合一个事件单系统。级别是共识,共识在事里才有效。维护静默务必带自动恢复,别开着静默忘了关。
级别和触达定了,下一个难题是告警太多——风暴、刷屏、狼来了。下一节讲噪声治理,把"叫得太密"的毛病治干净。