典型切换日时间线
-
T-7 天
第二次演练复盘完成
所有演练发现的问题关闭，Runbook 定稿并冻结，参与人确认到位。
-
T-2 天
数据持续同步就绪
确认复制延迟稳定在秒级，目标端资源与配置全部就位，DNS TTL 提前降到 60 秒。
-
T-1 天
全员就位确认
确认值班人员、沟通群、回滚决策人与业务方联系人，准备公告文案。
-
T 00:00
开始停写
应用置为只读或停服，发布维护公告，记录停机开始时间。
-
T 00:15
最后一轮增量同步
等待复制追平，校验源端与目标端数据一致性（行数、校验和、关键业务表抽样）。
-
T 00:45
启动目标端服务
按依赖顺序启动服务，执行自动化冒烟测试，检查日志无异常。
-
T 01:15
切换流量
DNS 切换或负载均衡权重调整，先放 10% 流量观察，正常后全量切换。
-
T 01:45
业务验证
业务方按验证清单逐项确认核心流程，确认无误后正式恢复服务。
-
T +24 小时
观察期结束
监控指标对比切换前基线，确认稳定后释放源端资源（保留快照一个月）。
回滚决策标准（提前定好，别临场吵）
触发回滚
- 核心业务流程验证失败且 30 分钟内无法定位
- 数据一致性校验不通过
- 关键接口错误率超过 5% 且持续上升
- 超出预定停机窗口 50% 仍未完成切换
- 发现数据丢失或错乱风险
继续推进
- 非核心功能异常，有临时绕过方案
- 性能略低于预期但在可接受范围
- 个别监控告警但业务指标正常
- 问题已定位且修复时间可控在窗口内
- 数据校验通过，仅配置项需微调
把停机窗口压短的几个手段
- 用块级持续复制（MGN / DMS CDC），切换时只需追平最后几秒的增量
- 目标端提前完整启动过一次并做过冒烟，切换时不用现场调试
- DNS TTL 提前 48 小时降到 60 秒，避免解析缓存拖长切换
- 所有操作脚本化，切换步骤只需执行不需思考
- 数据校验脚本提前写好并在演练中验证过，不要临场写 SQL 对数
- 把非必须的操作（如清理源端、调整监控）挪到窗口外做