迁移批次规划
先用低风险资产验证路径，再让核心业务进入割接窗口
迁移批次不是简单按服务器编号分组。每个批次都应形成一个可验证的业务或平台能力，并为下一批次提供经过真实环境验证的网络、权限、部署、数据同步、监控和回滚路径。
| 批次 | 典型范围 | 进入下一批的条件 |
|---|---|---|
批次 0：基础环境 | 账号、IAM、VPC、子网、安全组、日志、监控、域名与证书准备 | 目标环境基线通过安全、连通性和审计验证 |
批次 1：低风险试迁 | 测试环境、无状态应用、内部工具、可快速重建的任务 | 部署、监控、告警、验收和回滚路径完成真实验证 |
批次 2：数据与高风险服务 | 对象存储、数据库、缓存、中间件、有状态和高重要性服务 | 全量与增量收敛，数据校验、性能和恢复测试通过 |
批次 3：核心割接 | 核心数据库、生产入口、强一致链路和业务流量 | 割接审批、值守、回滚阈值和观察期全部确认 |
如果应用依赖尚未迁移的数据库、Bucket、队列、来源 IP 白名单或身份服务，即使应用本身无状态，也不能独立完成迁移。规划批次前应先画依赖图，再识别以下关系：
- 必须先创建：目标网络、权限、密钥引用、日志和监控。
- 可以提前复制：镜像、静态文件、对象存储和数据库全量数据。
- 必须持续追赶：数据库增量、对象变化和消息消费位点。
- 必须在窗口内切换：域名、负载均衡、写入口、定时任务和消费者。
- 必须在观察期保留：源端实例、备份、同步链路和回滚入口。
批次完成不能只看工具显示“任务成功”。至少验证资源数量和字节数、数据一致性、关键业务事务、性能基线、监控告警、备份恢复、费用变化和源端是否仍有写入。
如果某项退出条件失败，应停止后续批次，先按照风险登记表决定修复、接受、降级或回滚。不要让未关闭的问题被下一批次放大。
Built with