归属为什么要显式声明
每条告警都应该有明确 owner，并与服务目录对齐：谁负责这个服务、哪个值班组接收、看板与 runbook 在哪里。归属不清的典型后果是告警在群里飘着没人认领，大家都以为别人管。做法是把 owner 变成标签与路由的输入，而不是靠人肉转发。
按 team 标签路由
按 team 标签路由
routes:
- matchers: [ 'team="trade"' ]
receiver: trade-oncall
- matchers: [ 'team="platform"' ]
receiver: platform-oncall
# 未匹配 team 的告警落到默认路由，定期清理默认路由的常客服务目录字段
| 字段 | 用途 | 维护时机 |
|---|---|---|
| 服务名 | 作为标签与看板命名的基准 | 新建服务时登记 |
| 负责人与值班组 | 决定路由与升级链 | 人员变动时更新 |
| 看板地址 | 写进告警注释便于直达 | 看板迁移时同步 |
| runbook 地址 | 处置步骤与联系路径 | 流程变化时修订 |
落地流程
- 新告警上线前先确认 owner 与 team 标签，缺归属的不予上线
- 服务改名或转手时，同步更新标签、路由与看板标题
- 定期审计落在默认路由的告警，要么补归属要么删除
- 把归属信息与告警规则放在同一个仓库，评审时一起检查
常见落地缺口
| 标签缺失 | 告警没有 team 标签，只能落默认路由 |
|---|---|
| 路由陈旧 | 接收器指向已解散的值班组 |
| 目录过期 | 服务已下线，目录仍挂着旧负责人 |
归属清晰后，路由与升级链都能按 team 自动分流，值班不再靠人肉转发，复盘时也能快速定位责任人。
审计要点
- 按周统计落在默认路由的告警，逐条确认是临时还是缺归属
- 检查接收器指向的值班组是否仍存在，成员是否包含在岗人员
- 新服务上线清单里加入告警归属检查，从源头避免无主告警
- 服务下线流程里加入告警与目录清理，避免僵尸告警长期存在
- 把归属标签纳入告警规则评审清单，新增规则时必须填写 team
- 跨团队共用的服务明确主责方与协助方，路由只指向主责值班组