告警分档是什么
按可行动性把告警分成三档：需要立刻人工介入的走页面通道，当天可处理的走工单，只需留痕的进日志或日报。分档的价值在于保护「立刻响应」这个稀缺资源——当页面通道里混进不需要立刻处理的告警，值班的紧迫感会被稀释，真正重要的告警反而被忽略。分档标准应写入团队文档并定期复核。
基本信息
| 分档依据 | 用户是否已受影响、是否需要立即动作 |
|---|---|
| 通道对应 | 页面（电话与推送）、工单、日志与日报 |
| 判定方法 | 三问判定法，全部为是才进页面 |
| 复核机制 | 定期审视页面级告警的实际可行动性 |
典型使用场景
- 核心业务告警：用户已受影响且需立即处置，走页面通道
- 容量预警：按趋势预判，可排到当天处理，走工单
- 趋势观察：慢查询、缓存命中率变化，进日报
- 值班体检：统计页面级告警中真正需要动作的比例
- 新告警上线：明确归属档位后再接入通知通道
分档落地方式
分档落地方式
# 在告警规则里用统一标签表达档位
labels:
severity: page # 页面级：需立即动作
# severity: ticket # 工单级：当天处理
# severity: info # 日志级：仅留痕
# 路由端按标签分发
# severity=page -> 电话与推送通道
# severity=ticket -> 工单系统
# severity=info -> 日报或看板
# 复核口径：统计页面级告警里「收到后没有任何动作」的比例三档分流
| 档位 | 条件 | 通道 | 失败后果 |
|---|---|---|---|
| 页面 | 用户已受影响且需立即动作 | 电话与推送 | 响应延迟直接扩大影响 |
| 工单 | 数小时窗口内处理即可 | 工单系统与群通知 | 延误但不至于失控 |
| 日志 | 观察趋势、无需打扰 | 日报与看板 | 信息保留，无打扰成本 |
| （降档） | 当前不动也不会恶化 | 仅留痕 | 需写明降档理由以便追溯 |
三问判定法：用户受影响吗、现在不做会恶化吗、有明确动作吗；三问全为是才进页面通道，否则降档处理。
好告警的判据是「值班收到后知道下一步做什么」，不满足这条的告警应该降档或直接删除，而不是留在页面通道里。