书接上回，我们继续聊聊数据迁移的策略，这个策略可能更加偏重于宏观层面的方法论，具体的迁移技术会有提及，但不是重点。
环境分离
在做数据库迁移之前，我建议将数据库环境做一下划分，分成三种环境，分别是开发环境(DEV），用户测试环境（UAT），生产环境（PROD）。
开发环境（DEV）
使用人员：开发人员、DBA
使用数据：虚拟业务数据
自由度：高
用途：针对新数据库的应用程序开发
无论是同构还是异构的数据库迁移，都需要对应用程序做代码级别的调整，以适配新的数据库版本。这时候需要一个可以随便折腾，反复毁掉重来的环境，对于权限的使用没有那么敏感的环境。通常我们称之为DEV环境。
DEV环境可以是在软件厂商自己的软硬件环境，也可以是应用程序使用者的软硬件环境，并没有严格的要求。DBA可以是软件厂商的DBA，也可以是使用方的DBA。
既然对于使用谁的环境没有严格要求，那么业务数据就一定不会使用真实的业务数据。通常都是由应用程序供应商来生成虚拟的业务数据，由开发人员和DBA对其进行维护。
用户测试环境（UAT）
使用人员：开发人员、DBA、业务人员
使用数据：脱敏的业务数据
自由度：中
用途：业务人员用来测试新应用程序版本
UAT环境是为了在完成软件开发之后，由业务人员来验证的环境。并且在成本允许的情况下，尽可能模拟与实际生产环境接近的软硬件，用以最大限度还原实际的业务场景。
在这一步，UAT环境一定要是软件使用者的环境，从网络到数据库服务器再到上层应用服务器。只有这样才能确保UAT环境与生产环境的尽可能接近。DBA与开发人员在这一阶段，去收集业务人员提出的各类问题，再回归到DEV环境调整。
而这一步为了尽可能模拟真实业务场景，常常使用的数据也是真实业务数据脱敏之后的数据。为了数据安全，一定不要使用真实的业务数据。
生产环境（PROD）
使用人员：业务人员、DBA
自由度：低
用途：在真实的环境中做最后的验证
到了PROD环境的时候，通常就不会再让软件供应商来触及了，一方面是业务数据的保密性，另一方面很多公司也有着各种安全以及制度上的顾虑。
迁移之前，在生产环境用真实的业务数据验证真实的业务场景，在迁移中，将数据从原有的生产环境迁移到新的生产环境。在迁移完成后，就是新的生产环境，接受业务请求。
这一步出现的各类问题，要重新回归到DEV，再从UAT验证，形成一个闭环。切除非万不得已，最好不要直接在生产环境做代码修改或直接更改数据库配置。
制定计划
环境分离之后，接下来就是整体的迁移计划的制定，整个迁移周期划分为多个阶段。根据迁移难度和系统的重要性，我经历过的最长的迁移周期有半年以上的，最短的也有不到一个月的。
开发测试计划
使用环境：DEV、UAT
开发测试阶段是数据库迁移的起始阶段，如果是很成熟的产品，可能这一阶段的实际时间相对较少，但是作为一个即将在生产环境使用的数据库与应用程序，还请仔细评估如下几个时间：
- 根据应用程序体量，评估DEV的开发测试的起止点
- 根据业务场景数量，评估UAT的用户测试的起止点
- 根据UAT的评估时间，评估PROD的验证与切换之前的起止点
- 为每个阶段留出一些buffer，3-5个工作日为佳
迁移计划
- 根据数据同步的方法与体量与系统运维人员与业务人员的详细验证计划，确定是否回退的最后时间点
- 在正式停机的时间点与回退时间点确定后，留给迁移的时间也就此确定，想起拆解迁移步骤，全部实现脚本化
- 确认所有关联系统的变更细节，例如防火墙端口、域名、上下游系统的账号密码验证等等
回退计划
- 认定迁移失败的标准，可能是时间不够用，可能是性能不达标，甚至可能是某个之前没有考虑到的点
- 切回原有生产环境时，每一步的详细操作以及时间点，全部脚本化
- 业务部门验证并确认回退成功的标准，便于做最后的确认
- 回退完成后，需要收集提交的材料清单，可能是每一步的用时列表，也可能是导致失败的现象等等
复盘总结
无论成功还是失败，其实都有很多需要我们去复盘总结的东西，这些都是以后数据库迁移所留下的宝贵经验：
- 迁移过程中，遇到哪些与演练过程中有差异的，这些差异哪些是人为因素，哪些是非人为因素
- 迁移过程中，哪些环节仍然可以优化，从而降低迁移的难度和风险
- 迁移成功后，是否仍然存在着回退的风险，如果必须回退，如何保证业务数据不丢失
- 迁移失败，究竟是哪些因素导致了迁移失败，这些因素在下一次迁移时如何规避
