演练的设定很朴素：模拟主编码器断电。主链路一旦中断，值班导播需要在 90 秒内完成判断、切换、确认与记录，并且不让听众听到超过 5 秒的空白。
一、90 秒里发生了什么
| 时间 | 动作 | 执行人 |
|---|---|---|
| T+00s | 主编码器断电，推流告警 | 技术组（模拟） |
| T+06s | 导播发现码率归零，按静音并播垫乐 | 值班导播 |
| T+18s | 确认非主播端问题，向技术组报障 | 值班导播 |
| T+34s | 技术组下令切换备播机房 | 技术值班 |
| T+58s | 备播源接管，节目声音恢复 | 技术值班 |
| T+86s | 确认信号与节目源一致，恢复主播口播 | 导播 + 主播 |
从听到告警到恢复声音，共 58 秒；到确认一切正常，86 秒。比目标快了 4 秒，但过程中暴露了一个问题，见第四节。
二、三个判定点
切换不是按一个按钮就完事。中间有三个必须确认的判定点，任何一个判断错，都会导致「切过去了但播的是错的」。
- 判定点一：是主播端还是链路端？先看调音台电平，再看待播状态，避免把主播喝水当成故障。
- 判定点二：备播源播的是哪一档节目？备播机房默认播放自动化曲库，切换后需要人工确认是否接回当前栏目。
- 判定点三：延时是否同步？备播源与主链路的延时不一致，会导致回切时出现重复或跳字。
三、演练中暴露的失误
问题出在 T+34s 到 T+58s 之间：技术值班在切换时先改了路由，后通知导播，导致导播有 12 秒不知道备播源已经接管，仍在播垫乐。听众听到的是「音乐 + 音乐」的叠音。
改进措施已经写进流程：切换前必须先口头报「准备切换，3 秒后接管」，导播确认后才动路由。这条规则看起来啰嗦，但能避免叠音。
四、记录与复训
演练结束后 30 分钟内，参与人员共同填写一张复盘表：时间点、动作、判断依据、偏差与改进。表格进技术档案，下一次演练前先看一遍。
- 演练每季度一次，时间随机，不提前通知主播
- 新人入职 30 天内必须参与一次完整演练
- 切换时间连续两次超过 90 秒，启动流程复核
- 所有演练记录保留 3 年
备播链路的价值，不在于它存在，而在于有人能在压力下正确使用它。
对合作方来说，这些细节可能不重要。但一档栏目能不能稳定播一年，靠的正是这些没人愿意看的表格。