并行运行与回退方案
切换期间两套系统跑同一批数据、对比触发结果、按媒介逐个切。
看完这页，你手上会有一套「两套告警系统同时跑、每天能对账、任何一档都能一分钟退回去」的做法。 它对从 Alertmanager、Zabbix、Grafana Alerting 迁过来都适用。
并行期到底并行了什么
只有判定和通知是双份的，数据不是：
采集与存储（一份，两边共用）
│
├──> 老系统判定 ──> 老系统通知 ──> 真正的值班群 / 电话
│
└──> 夜莺判定 ──> 夜莺通知 ──> 影子渠道（先不发给人）
夜莺是在原地查你现有的时序库或日志库的，不需要复制数据，也不需要双写。 所以并行期的额外成本只有查询压力：两套系统按各自的周期查同一个后端。 规则多的时候先看一眼存储的负载。
唯一需要双写的场景是你同时在换存储（比如从 Prometheus 换到 VictoriaMetrics）。 那是另一件事，别和告警迁移放在同一个窗口里做。
第 1 步：让夜莺先不发给人
新系统第一天就往值班群里发，等于用生产事故来验证配置。先让它空转一段。
两种做法，按你要对比的东西选：
- 影子渠道（推荐）：建一条通知规则，媒介指向一个专用的群、邮箱， 或者一个只写日志的 Callback 地址，把这批新规则全挂上去。 好处是通知链路（媒介、模板、过滤条件）也一起被验证了。
- 只留事件不发通知：规则照常启用，用一条「只屏蔽通知」的屏蔽规则 盖住这个业务组。事件照常产生、照常留档，就是不发。 好处是不用建影子媒介，代价是通知侧完全没被验证。
两种都行，但不要用「屏蔽事件与通知」——那样事件根本不产生，你就没东西可对了。
验证：在「告警通知 → 告警事件」里能看到夜莺产生的事件， 而值班群里一条夜莺的消息都没有。
第 2 步：对比三个桶
每天（或每个班次）把两边的触发结果拉出来，分成三个桶。夜莺这边的数据源是 告警事件的历史列表，按业务组和时间段筛。
| 桶 | 含义 | 先查什么 |
|---|---|---|
| 只有老系统报了 | 规则漏搬，或者指标压根没查到 | 先去即时查询 / 日志检索确认数据存在，再看规则的判定记录 |
| 只有夜莺报了 | 阈值抄错，或者老系统那边有你没注意到的抑制、依赖、维护期 | 用试运行看这条规则每一段的实际取值 |
| 两边都报了但不一样 | 级别映射、持续时长、恢复条件的差异 | 逐项核对，级别档数不同的（比如 6 档压 3 档）必然有损失 |
判定记录是这一步最有用的东西：它把每一轮判定查了什么、怎么判的都落在告警引擎本地， 所以「为什么这轮没报」是能查的，不用靠猜。
第三个桶最容易被放过。 两边都报了就以为对了，但持续时长差 30 秒、 恢复条件不一样，会在真正的故障里表现成「一边早报十分钟」或「一边一直不恢复」。
跑够一个完整的业务周期再往下走——至少一周，要盖住一个周末和一次发布。
第 3 步：按媒介逐档切
切换的单位是媒介档次，不是规则。因为风险不在规则本身，在「半夜会不会响铃」。
| 档 | 夜莺发 | 老系统发 | 观察 |
|---|---|---|---|
| 0 | 影子渠道 | 全部真实渠道 | 对账，第 2 步 |
| 1 | 群机器人 / 聊天（低干扰） | 电话、短信、邮件 | 值班同学开始真的看夜莺的消息 |
| 2 | 群 + 邮件 | 只剩电话、短信 | 一周 |
| 3 | 全部 | 老系统只判定不通知 | 一周 |
| 4 | 全部 | 停判定 | 迁移完成 |
每档之间至少隔一周。档 1 到档 2 的切法是改通知规则，不是改告警规则： 用「规则管理 → 更多 → 更新告警规则」批量换这批规则挂的通知规则，一次操作切一整批。 见通知规则。
档 3 那一步在老系统上的做法各不相同：Alertmanager 把接收器指向黑洞、 Zabbix 停掉 Action、Grafana 暂停规则。共同点是保留判定，这样第 2 步的对账还能继续。
千万不要并行的两样东西
- 自动执行的动作。 告警自愈脚本、 事件 Pipeline 里的回调、工单系统的自动建单——这些只能有一边开着。 两边都开就会执行两次：重启两次服务、建两张重复工单。 并行期把夜莺侧的自愈和回调全部关掉，等切到档 4 再开。
- 同一个电话 / 短信通道。 电话和短信通常按条计费且会吵醒人， 两套系统同时打同一个号码，代价是真金白银加上值班同学的信任。 档 0 到档 2 期间，夜莺侧的通知规则里不要配电话和短信媒介。
每一档的回退动作
回退的粒度和切换的粒度一样，都是一档：
| 你在哪一档 | 出问题怎么退 | 需要多久 |
|---|---|---|
| 档 0–2 | 把这批告警规则挂回影子通知规则，或者直接批量禁用 | 一次批量操作 |
| 档 3 | 在老系统上把通知打开（Action / 接收器 / 规则恢复） | 一次配置改动 |
| 档 4 | 在老系统上把判定也打开 | 取决于老系统 |
三条纪律：
- 老系统的配置在档 4 之前一律不删。 停用、暂停、指向黑洞都行，就是不要删—— 删了回退就变成重建。
- 每一档切之前，先导出一份夜莺的规则 JSON 存档。 「规则管理 → 更多 → 导出规则 JSON」，进版本库。注意导出会丢生效时段， 见导入、导出与复用。
- 回退不是失败。 退回上一档、修掉差异、再切一次，比在档 3 上带着已知差异硬扛便宜得多。
什么时候算切完
四个条件同时成立才算：
- 连续两周，第 2 步的三个桶里没有需要处理的条目；
- 值班同学只根据夜莺的消息响应，没有人再去老系统的界面确认；
- 老系统已经在档 3 停了通知一周以上，期间没有人抱怨漏报；
- 夜莺侧的自愈和回调已经打开并验证过。
都成立了，就可以走档 4，然后按生产上线检查清单 把新系统本身的可靠性再过一遍。
下一步
- 上线前的完整检查项：生产上线检查清单
- 事件在夜莺里的处理顺序：降噪与路由模型
- 具体某一套系统怎么搬：从 Prometheus + Alertmanager 迁移、 从 Zabbix 迁移、从 Grafana Alerting 迁移