2. 关键业务负载画像
迁移工程最容易犯的错误，是把“虚拟机清单”当成“业务清单”。一台运行 Oracle 的 VM 和一台运行文件共享的 VM，在 vMotion 眼里都是 VM，但在业务连续性视角下，它们的迁移窗口、可接受中断时长、数据丢失容忍度完全不同。负载画像的目的，就是把技术对象翻译成业务约束，让后续的迁移方式选择、批次编排、回退策略有据可依。
一、四类核心指标的定义与参照约定
在开始采集之前，必须先统一口径，否则不同团队填出来的数字无法比较。
- SLA（服务级别协议）：业务方对服务可用性的承诺，通常以“月度可用率”表达，例如 99.9% 对应月停机约 43 分钟，99.95% 对应约 21 分钟。它是外部承诺，不是内部目标。
- RTO（恢复时间目标）：从故障或中断发生，到业务恢复可用的最长可接受时长。它约束的是“停机多久”，直接决定迁移是停机窗口内完成，还是必须在线切换。
- RPO（恢复点目标）：可接受的最大数据丢失量，通常折算为时间，例如 RPO=15 分钟表示最多丢失最近 15 分钟的数据。它约束的是“数据能丢多少”，决定复制方式与同步频率。
- 性能基线：业务在正常运行时对 CPU、内存、磁盘 IOPS/时延、网络吞吐的典型与峰值需求。它约束的是“迁过去之后跑不跑得动”。
参照约定：本文所有时间指标均以“业务中断起点”为计时零点，RTO 为正向时长，RPO 为向过去回溯的时长；性能基线中的 IOPS 与吞吐均指业务侧观测值，而非存储阵列裸能力。
二、按负载类型建立画像模板
不同负载的指标敏感点差异很大，建议按类型分别采集，而不是用一张通用表。
| 负载类型 | 典型代表 | 关键敏感指标 | 迁移约束重点 |
|---|---|---|---|
| 关系型数据库 | Oracle、SQL Server、MySQL | RPO 极低（常为 0～5 分钟）、磁盘时延敏感 | 数据一致性、主备切换顺序、日志同步 |
| ERP 套件 | SAP、用友、金蝶 | RTO 中等（1～4 小时）、强事务完整性 | 应用与数据库联动、批处理窗口 |
| 中间件 | WebLogic、Tomcat、Kafka | 会话保持、连接池、消息堆积 | 集群成员同步迁移、消息不丢 |
| 文件/共享服务 | NFS、SMB、NAS | RTO 宽松、RPO 可放宽 | 挂载点切换、权限映射 |
以一台生产 Oracle 为例，画像结果可能是：SLA 99.95%、RTO 30 分钟、RPO 0（要求零丢失）、峰值 IOPS 12000、平均读时延需低于 2 ms。而一台内部 ERP 应用服务器可能是：SLA 99.9%、RTO 2 小时、RPO 15 分钟、峰值 CPU 利用率 65%。这两者的迁移方案必然不同。
三、性能基线的采集方法
性能基线不能靠“感觉”，要用数据说话。推荐在迁移前连续采集至少 2～4 周，覆盖月末结账、日终批处理等业务高峰。
# 示例：在 Linux 业务机上采集关键指标（示意命令）
# CPU 与内存
sar -u 5 12 # 每5秒采样，共12次，观察用户态/系统态占比
sar -r 5 12 # 内存与 swap 使用
# 磁盘 IOPS 与时延（以 sda 为例）
iostat -x 5 12 # 关注 %util、await、r/s+w/s
# 网络吞吐
sar -n DEV 5 12 # 关注业务网卡的 rxkB/s、txkB/s
# 数据库侧（Oracle 示例）
# 查询 AWR 报告中的 DB Time、物理读、TOP SQL
采集完成后，取 P95 值作为“典型峰值”，取最大值作为“极端峰值”。迁移目标平台的资源规格，应按极端峰值留出 20%～30% 余量，而不是按平均值配置。例如某数据库 P95 IOPS 为 9000、峰值为 12000，则目标存储应能稳定支撑 15000 IOPS 以上，并保证时延不劣化。
四、从画像到迁移决策
画像的最终价值，是驱动迁移方式与批次的选择。可以用下面这张关系图来理解各指标如何共同作用：
从图中可以看到，四个指标并非并列关系，而是分别回答不同问题：RTO 回答“能不能停”，RPO 回答“怎么复制”，性能基线回答“迁过去是否达标”，SLA 则决定整体风险等级与回退要求。实际项目中，建议把每个业务系统的画像结果整理成一行记录，形成“业务—指标—迁移方式—批次”的对应表，作为迁移方案评审的输入。
完成画像后，还应做一次交叉验证：把画像结果与现有监控数据、业务方访谈记录、历史故障记录三方比对。若某系统声称 RTO 为 1 小时，但过去一年实际恢复平均耗时 3 小时，则应以实测为准，并据此调整迁移批次和演练要求。画像不是一次性文档，而是迁移期间持续校准的基线。