新功能已经测试通过，并不意味着适合立即在业务高峰上线。如果发布后还需要现场调配置、补数据或临时找人确认，操作时间往往比预计更长。
无法避开高峰的发布，至少要在动手前回答三个问题：怎样判断新版本出现问题，谁可以决定停止，以及恢复到哪个状态。异常标准尽量对应实际业务，例如关键操作失败、错误明显增加或处理时间超过可接受范围，不宜只看服务器负载是否升高。
旧程序包、旧配置与对应的恢复步骤应提前准备。具备小范围发布条件的，可先观察少量业务；暂时不具备的，就缩小单次改动，避免把页面、接口、数据库结构一起大幅调整。
回退程序之前，还要确认发布期间产生的数据。新程序如果写入了旧程序无法识别的内容，仅换回旧文件可能仍然无法恢复业务。此类变更应事先安排兼容处理，或采用能分阶段完成的调整方式。
发现关键流程异常时，不要为了证明新版本能用而继续叠加多个修补。保存相关现象，按事先约定停止或恢复，再单独分析原因，会比现场不断尝试更容易控制影响。
恢复后也需要验收：用户能否继续完成关键操作，后台积压任务是否恢复处理，新旧记录是否对应。