结论先行：告警分级回答的是"严不严重"，值守编排回答的是"谁来处理"。很多团队做了分级却仍然夜里乱成一团，原因是分级之后没有把告警路由到具体的人。可行的做法是：按业务域加职责边界把告警送到值班人，配套认领、升级、静默、交班四件事，考核只看两个数字——首次响应时长与认领后闭环率。
分级之后，缺的是"到人"这一环
分级表做出来之后，常见的结果是：紧急告警发到全员群，高优先级发到部门群，中低优先级静悄悄躺在系统里。表面上看每种级别都有去处，实际上没有哪一种绑定了确定的处置人。
后果有三个：紧急告警大家都以为别人在处理；高优先级告警被当成背景噪音；低优先级告警攒成一片，没人愿意清理。分级解决的是排序问题，排完序还要解决派发问题，两件事不能混为一谈。
路由规则怎么定
路由的目标是把一条告警映射到"某个人 + 某个时限"。建议按三个维度组合，而不是只按告警级别。
| 路由维度 | 取值来源 | 示例 |
|---|---|---|
| 业务域 | 服务所属业务线与归属团队 | 支付链路告警 → 支付组值班人 |
| 故障层次 | 应用、中间件、数据库、网络 | 数据库类告警 → 数据库责任人 |
| 时段 | 工作日、夜间、节假日、重保期 | 夜间仅核心链路告警唤醒值班人 |
三个维度组合出来的规则数量不需要多，十几条通常够用。关键在每条规则都要能落到一个具体的人，而不是"某某团队"这样的集体名词。集体名下无责任人，是值守体系失效最常见的原因。
四件事：认领、升级、静默、交班
认领
告警发出后要求接收人在约定时间内点击认领。认领动作的意义不在于"已读"，而在于把这条告警的状态从"待分配"改成"处理中"，让其他人知道有人在跟。未认领的告警自动走升级。
升级
升级条件要提前写死，不建议临场判断。常见写法是两条：按时效升级——超过约定响应时长未认领，自动通知上一级并抄送业务负责人；按影响升级——核心链路中断类告警直接触达最高优先级，跳过逐级等待。
静默
计划内变更、压测、已知缺陷修复期间，相关告警应能按对象与时间段整体静默，并注明静默原因与解除时间。静默必须带期限，长期静默等同于删除告警。
交班
轮值交接时，交班人需要给出三样东西：未闭环告警清单、已静默项清单、本班发生的异常但暂未定性事项。没有交班清单，值班质量会随班次剧烈波动。
两个考核数字
| 指标 | 口径 | 用途 |
|---|---|---|
| 首次响应时长 | 告警触发到首次认领的时间差 | 衡量路由是否有效、值班是否在岗 |
| 认领后闭环率 | 认领后按约定时限完成处置的比例 | 衡量处置能力，避免"认领即结束" |
不建议把告警数量本身当考核项。数量下降很容易通过调高阈值实现，代价是真实故障被漏掉。考核响应与闭环，团队才有动力把规则调得更准。
落地清单
- 先梳理业务域与归属团队，每一类告警都能找到一名默认责任人。
- 升级条件写成规则而不是原则，超时自动触发，不依赖值班人主动上报。
- 静默必须带原因、责任人与解除时间，到期自动恢复。
- 交班清单固定三样内容，与值班表一起存档，可回溯。
- 每季度回顾一次未认领告警与误派告警，回头修路由规则。
三个常见坑
- 路由只按告警级别，不按业务域——同一条数据库告警，白天和夜间应该到不同的人。
- 把所有告警都发给所有人，等于没有路由。
- 值班表没有备份人，值班人休假时告警自动落在空号上。
如果您正在规划相关建设，欢迎预约咨询，奇摩技术团队可结合现网情况给出可落地的清单与口径建议。