1. 迁移工程总览

AMD EPYC 平台迁移不是一次简单的“换 CPU”，而是一项涉及业务连续性、性能模型、软件兼容性、运维体系与成本结构的系统性工程。理解迁移工程的第一步，是把它当作一个有明确输入、约束、阶段和验收标准的项目来管理，而不是把它当作硬件替换任务。本节从驱动因素、典型场景、工程阶段划分与成功标准四个维度建立整体框架，为后续各章的选型、验证、迁移与调优提供统一参照。

一、驱动因素：为什么要迁移

迁移决策通常由多股力量共同推动，可以归纳为四类。第一类是性能与密度驱动：EPYC 采用 Chiplet 架构，单路最高可达 128 核 256 线程，配合 12 通道 DDR5 与 PCIe 5.0，在虚拟化密度、内存带宽敏感型负载（如内存数据库、实时分析）上具有明显优势。第二类是总体拥有成本驱动：在同等机架功耗与空间下，更高的单机核数与能效比意味着更少的物理节点、更低的许可成本（部分按插槽计费的软件）与更低的电力支出。第三类是技术生命周期驱动：老旧平台面临备件停产、操作系统与虚拟化版本停止支持、安全补丁缺失等风险，迁移是规避“技术债”的必要手段。第四类是业务与合规驱动：新业务上线、数据主权要求、供应链多元化等，也会推动平台更替。

需要强调的是，驱动因素决定了迁移的优先级与验收口径。如果核心驱动是成本，那么验收必须包含单位算力成本与功耗对比；如果核心驱动是性能，则必须建立可复现的基准测试口径。忽略这一点，迁移很容易“完成了但说不清是否成功”。

二、典型场景：迁移的四种形态

实际工程中，迁移通常落在以下场景之一或组合：

• 同代替换（Refresh）：用 EPYC 新机型替换同角色旧服务器，操作系统与业务软件版本基本不变，重点是兼容性验证与数据搬迁。
• 跨代升级（Upgrade）：从更早的 x86 平台迁移到 EPYC，可能伴随操作系统大版本升级、虚拟化平台升级，需处理驱动、内核与指令集差异。
• 架构整合（Consolidation）：将多台低利用率旧服务器合并到少量高核数 EPYC 节点，重点是资源超分比、NUMA 拓扑与隔离策略。
• 云化/混合迁移（Cloud & Hybrid）：把本地负载迁移到基于 EPYC 的云实例，或构建混合云，重点是镜像兼容、网络时延与数据同步。

不同场景的验证深度差异很大：同代替换可以以功能回归为主，而跨代升级与架构整合必须增加性能基线与 NUMA 敏感性测试。

三、工程阶段划分

一个可落地的迁移工程通常划分为五个阶段，各阶段有明确的输入与出口条件：

1. 评估与盘点：采集现有服务器的 CPU 型号、核数、内存、存储、网络、操作系统、中间件与业务依赖，形成资产与依赖清单，识别“不能动”的硬约束。
2. 方案设计：确定目标机型（如 EPYC 9004/9005 系列）、虚拟化或容器平台版本、NUMA 与内存配置、网络与存储方案，并给出迁移批次与回退策略。
3. 验证与试点：在非生产环境完成兼容性测试、性能基线测试与故障演练，选取 1～2 个低风险业务做试点迁移。
4. 批量迁移：按批次执行数据同步、业务切换与验证，控制单批次影响面，保留回退窗口。
5. 优化与收尾：根据运行数据做 NUMA 绑定、电源策略、超分比调优，完成文档、监控与知识转移，关闭旧平台。

阶段之间不是严格串行：评估与设计可能迭代，试点结果会反向修正方案。但每个阶段都应有可检查的交付物，例如资产清单、目标架构图、测试报告、切换记录与回退预案。

四、成功标准：如何判断迁移是否成功

成功标准必须在项目启动时就定义，并尽量量化。建议从五个维度设定：

其中性能基线尤其关键。建议在迁移前对代表性业务做一次基准采集，记录 CPU 利用率、内存带宽、磁盘 IOPS、网络时延等指标，迁移后在相同负载模型下复测。若出现性能回退，应优先排查 NUMA 跨节点访问、电源策略、BIOS 配置与虚拟化调度，而不是简单归因于“新平台不兼容”。

五、整体关系图

下图把驱动因素、典型场景、工程阶段与成功标准放在同一张关系图中，帮助建立全局视角：驱动因素决定场景与优先级，场景决定阶段中的验证深度，阶段产出最终由成功标准验收。

把这张图作为项目沟通的“共同语言”：任何一次迁移讨论，都可以先确认当前处于哪个阶段、对应哪个场景、由哪条驱动因素主导、最终用哪些指标验收。这样，后续的选型、测试、切换与调优才有统一的判断依据，也才能在出现性能或稳定性问题时快速定位是方案问题、配置问题还是验收口径问题。