3. 迁移升级需求与目标定义

迁移升级项目最容易失败的地方，不是技术选型，而是需求与目标没有量化。很多团队在启动会上说“尽量少停机”“性能要更好”“要满足合规”，这些表述无法验收，也无法指导方案设计。本节把业务连续性、停机窗口、性能目标、合规要求和回滚预期这五类需求，转化为可测量、可验证、可写入验收标准的工程指标。

一、业务连续性要求：先分级，再定 RTO/RPO

业务连续性描述的是“系统不可用时，业务能承受多大损失”。它由两个核心指标刻画：RTO（Recovery Time Objective，恢复时间目标）指从故障发生到业务恢复可用的最长时间；RPO（Recovery Point Objective，恢复点目标）指可容忍丢失的数据时间跨度。迁移场景下，这两个指标直接决定采用停机迁移、滚动迁移还是双写/日志同步迁移。

实操中不要对整个系统给一个笼统指标，而应按业务模块分级。例如某订单系统可划分为：交易下单（RTO≤5 分钟，RPO=0）、订单查询（RTO≤30 分钟，RPO≤5 分钟）、历史报表（RTO≤8 小时，RPO≤24 小时）。分级后，迁移方案可以差异化：交易库采用 Always On 可用性组或日志传送做近实时同步，报表库允许夜间批量迁移。

二、停机窗口约束：把“可停多久”算清楚

停机窗口不是拍脑袋决定的，而是由业务低峰期、上下游系统协同、运维值班能力共同约束。定义时要明确三件事：窗口起止时间、窗口内允许的最大中断时长、窗口外是否允许降级运行。

以某零售系统为例，业务低峰为每日 02:00–05:00，共 3 小时。但真正可用于数据库切换的时间要扣除：应用停止与排空（约 10 分钟）、最终增量同步与校验（约 20 分钟）、数据库切换与启动（约 10 分钟）、应用重连与冒烟验证（约 15 分钟）、回滚预留（约 20 分钟）。因此实际可用的“纯迁移操作时间”约为 105 分钟。若全量数据量 2 TB、备份还原速率约 400 MB/s，仅还原就需约 85 分钟，加上索引重建和统计信息更新，很可能超窗。这时就必须采用“预迁移 + 增量追平”的方式，把大部分数据搬运放到窗口之外。

三、性能目标：用基线对比，而不是绝对值

性能目标应基于迁移前的基线，而不是凭空设定。建议在源库采集至少一个完整业务周期的基线：关键语句平均/95 分位响应时间、每秒事务数（TPS）、批处理作业耗时、CPU 与 I/O 等待占比。迁移后按同一口径对比，设定可接受偏差，例如“核心查询 P95 响应时间不超过基线的 110%”“批处理总耗时不超过基线的 120%”。

同时要区分稳态性能与峰值性能。迁移后新库可能因统计信息未更新、执行计划变化、兼容性级别不同而出现计划回归。因此性能目标中应包含“计划回归检查”这一项，并预留调优时间。

四、合规要求：把约束前置为设计输入

合规要求常被当作验收阶段才检查的事项，实际上它应前置为设计输入。常见约束包括：数据驻留地（数据不得出境或必须存放在指定区域）、传输与静态加密（TLS、TDE）、审计日志保留期限、访问最小权限与职责分离、敏感字段脱敏。迁移过程中还要注意：备份文件、临时导出文件、日志文件同样受合规约束，不能只保护生产库。

例如金融行业要求审计日志保留不少于 6 个月，那么迁移方案必须保证新库的审计配置在切换前已启用，且历史审计数据完成归档，否则切换即产生合规缺口。

五、回滚预期：定义“什么情况下必须回退”

回滚预期要回答三个问题：回滚触发条件是什么、回滚需要多长时间、回滚后数据一致性如何保证。触发条件应量化，例如“切换后 30 分钟内核心交易错误率超过 1%”“关键查询 P95 超过基线 200% 且 15 分钟内无法定位”。回滚时间应纳入停机窗口预算，通常要求不超过窗口的 20%。

数据一致性是回滚的难点。若切换后新库已写入数据，回退到旧库时必须把这些增量回灌，否则会丢单。因此方案设计阶段就要确定回滚方向与增量回补机制，并在演练中验证。

六、把五类需求落成一份可执行的目标清单

需求定义的最后一步，是把上述内容整理成一份可评审、可验收的目标清单。清单应包含指标名称、目标值、测量方法、责任人和验收时点。下面给出一份示例（数值为教学示例，实际项目需按自身基线确定）：

需求与目标定义完成后，它将成为后续架构设计、迁移工具选择、切换演练和最终验收的统一依据。任何方案变更，都应回到这份清单上重新评估是否仍然满足目标。