4. 业务负载画像与迁移优先级

把业务从旧平台迁到 AMD EPYC 数据中心平台，最容易犯的错误是“按主机清单排队迁移”。主机清单只反映物理归属，不反映业务对资源的真实依赖。真正决定迁移顺序的，是业务负载画像：这台虚拟机或这个容器到底在消耗什么、对什么最敏感、迁移后最可能在哪一项上出问题。EPYC 平台的核心变化在于核心密度、内存通道数、NUMA 拓扑和 PCIe 通道数都与旧平台不同，因此同一类负载在新平台上的表现差异会被放大。先画像、再分批，才能把风险控制在可回退的范围内。

四类负载画像的判定依据

负载画像不靠业务名称猜测，而靠可采集的指标组合。建议在迁移前至少采集 7～14 天的稳态数据，避开月末结算、大促等峰值窗口，否则画像会被瞬时峰值带偏。判定时重点看四组指标：CPU 使用率与就绪时间、内存占用与内存带宽、磁盘 IOPS 与吞吐、以及延迟敏感度（P99 响应时间、超时率、跨 NUMA 访问比例）。

需要强调的是，一台业务可能同时具备两类特征，例如数据库既吃内存又对延迟敏感。此时应取“最敏感的那一类”作为画像主标签，其余作为约束条件。画像结论要落到具体对象上：虚拟机名、容器工作负载名、绑定的 NUMA 节点、依赖的存储卷，而不是只写“某业务系统”。

从画像到迁移批次

画像完成后，按“风险从低到高、依赖从少到多”的原则排批次。第一批放 CPU 密集型中无状态、可快速重建的负载，用来验证新平台的计算性能和调度策略；第二批放 IO 密集型，验证存储路径和 PCIe 带宽；第三批放内存密集型，重点验证 NUMA 绑定和内存带宽；最后一批放延迟敏感型，此时平台已经过多轮验证，抖动风险最低。每批之间保留观察窗口，确认无回退再进入下一批。

画像采集与判定的实际操作

在 Linux 虚拟机上，可以用一组命令快速拿到画像所需的核心数据。以下命令在业务稳态期执行，连续采集 7 天，每天取同一时段样本，避免峰值干扰。

# CPU 使用率与就绪时间（每秒采样，持续 60 秒）
vmstat 1 60 | awk 'NR>2 {cpu+=$13; r+=$1; n++} END {print "CPU使用率:",cpu/n"%","平均就绪:",r/n}'

# 内存占用与 NUMA 分布
numastat -p $(pgrep -f 业务进程名) | head -20

# 磁盘 IOPS 与吞吐（以 sdb 为例）
iostat -x 1 60 | awk '/sdb/ {print "r/s:",$4,"w/s:",$5,"rMB/s:",$6,"wMB/s:",$7}'

# 延迟敏感度：P99 响应时间（以应用日志为例）
grep "response_time" app.log | awk '{print $NF}' | sort -n | awk '{a[NR]=$1} END {print "P99:",a[int(NR*0.99)]"ms"}'

判定时给出明确阈值，避免主观。例如：CPU 使用率持续高于 60% 且内存占用低于 50%，判为 CPU 密集型；内存占用高于 70% 且 numastat 显示跨节点访问比例超过 20%，判为内存密集型；磁盘 IOPS 高于 5000 或吞吐高于 200MB/s 且 CPU 低于 50%，判为 IO 密集型；P99 超过业务 SLA 的 80% 且对抖动敏感，判为延迟敏感型。这些阈值是示例，实际应结合业务 SLA 调整。

批次迁移中的验证与回退

每批迁移完成后，不要只看“服务是否启动”，而要看画像中对应的关键指标是否落在预期区间。CPU 密集型批次重点看就绪时间和单核性能是否下降；IO 密集型批次重点看 IOPS 和队列深度是否因 PCIe 路径变化而劣化；内存密集型批次重点看跨 NUMA 访问比例是否上升；延迟敏感型批次重点看 P99 和超时率是否抖动。任何一项超出预设阈值，就应暂停下一批并回退当前批。

最后，迁移批次不是一次性的。业务负载会随版本迭代、流量增长而变化，原本的 CPU 密集型可能演变为内存密集型。建议每季度重新采集一次画像，更新批次归属，让迁移优先级始终与真实负载保持一致。