1. 迁移工程导入

关键业务系统从物理服务器或旧虚拟化平台迁移到 vSphere，本质上不是一次“搬机器”的操作，而是一项需要同时管理业务连续性、数据一致性、性能基线和回退风险的工程活动。与普通测试系统不同，关键业务通常具备三个特征：停机窗口极短甚至不允许停机、数据持续写入且不允许丢失、上下游依赖复杂（数据库、中间件、接口、批处理任务相互耦合）。因此，迁移工程的第一原则是：先定义成功，再设计路径。如果一开始只关注“怎么把虚拟机迁过去”，往往会在切换窗口内才发现网络策略、存储性能或授权依赖没有对齐，导致回退甚至业务中断。

一、关键业务迁移的核心挑战

从工程视角看，挑战可以归纳为四类。第一类是停机窗口约束。例如一套核心交易库，业务方只允许在凌晨 00:30 至 02:00 之间停机，共 90 分钟。这 90 分钟要覆盖最后一次增量同步、应用停写、数据校验、DNS/负载均衡切换、应用启动和冒烟验证，实际留给数据同步的余量可能只有 20～30 分钟。第二类是数据一致性。对于数据库、消息队列、文件服务，迁移过程中若源端仍在写入，必须通过增量复制、日志截断点或应用停写来保证目标端数据与源端一致。第三类是性能与兼容性。物理机上的 CPU 主频、NUMA 拓扑、网卡多队列、存储 IOPS 与 vSphere 虚拟硬件之间存在差异，迁移后可能出现 CPU 就绪时间升高、磁盘延迟增大或授权绑定失效。第四类是回退与验证。迁移不是单向操作，必须预设回退触发条件和回退时限，否则一旦切换失败，业务恢复时间将不可控。

二、迁移目标与成功标准

迁移目标应当可度量，而不是“顺利完成迁移”这类模糊表述。建议从业务、技术、运维三个维度定义成功标准。业务维度关注 RTO（恢复时间目标）和 RPO（恢复点目标），例如 RTO ≤ 30 分钟、RPO = 0；技术维度关注数据一致性校验通过率、迁移后性能偏差不超过基线 10%、虚拟机硬件版本与 VMware Tools 状态正常；运维维度关注监控告警接入、备份策略生效、CMDB 信息更新。只有这些标准在迁移前被确认，迁移后的“成功”才有客观判断依据。

三、迁移工程的总体路线

本课程将迁移工程划分为六个阶段：评估与盘点、方案设计、环境准备、迁移实施、切换验证、复盘与优化。评估阶段要完成应用依赖梳理、性能基线采集和迁移风险分级；方案设计阶段要确定迁移方式（冷迁移、热迁移、存储复制、备份恢复或混合方式）、网络与存储映射、IP/DNS 变更策略；环境准备阶段要完成 vSphere 集群、分布式交换机、存储策略、权限与模板准备；实施阶段按批次执行迁移并记录每台虚拟机的同步状态；切换验证阶段执行停写、增量同步、数据校验、应用启动和业务冒烟；复盘阶段更新文档、监控和备份策略，并沉淀可复用的迁移模板。

四、课程路线图与学习方式

后续章节将沿着上述六个阶段展开。在评估与盘点部分，会介绍如何用性能基线工具采集 CPU、内存、磁盘、网络指标，如何梳理应用依赖和端口矩阵；在方案设计部分，会对比冷迁移、热迁移、存储复制和备份恢复的适用场景，并给出切换窗口倒排方法；在环境准备部分，会涉及 vSphere 集群、分布式交换机、存储策略和权限模型；在实施部分，会以数据库、文件服务和中间件为例，说明增量同步、批次控制和迁移记录；在切换验证部分，会给出停写、校验、冒烟和回退的具体判断条件；在复盘部分，会整理迁移文档模板和常见问题清单。

学习本课程时，建议始终带着三个问题：这台业务系统的 RTO/RPO 是多少？迁移过程中数据如何保持一致？如果切换失败，多久能回到源端？这三个问题贯穿全部章节，也是判断迁移方案是否合格的底线。只有把迁移当作一项有目标、有标准、有回退的工程来管理，关键业务虚拟化迁移才可能从“高风险操作”变成“可重复、可验证、可交付”的常规能力。