📚 课程目录第2章迁移评估与发现

2. 迁移评估与发现

迁移项目失败最常见的原因不是技术选型错误，而是“不知道自己有什么”。在动手搬迁任何一台虚拟机之前，必须先回答三个问题：现有资产到底有多少、它们之间怎么互相依赖、搬到云上要花多少钱。Google Cloud 的 Migration Center 正是为这三个问题设计的统一评估平台，它把资产清单（Asset Inventory）、依赖关系映射（Dependency Mapping）和 TCO 分析（Total Cost of Ownership）整合到同一个数据模型中，让摸底工作从“人工填表”变成“数据驱动”。

一、Migration Center 的定位与数据来源

Migration Center 是一个托管式评估服务，它本身不运行业务负载，而是作为“资产与成本的中央账本”。它的数据来自三类采集通道：

无代理采集（Agentless）：通过 vCenter、AWS、Azure 等平台的 API 批量拉取虚拟机清单、CPU/内存配置、磁盘容量与利用率。适合快速建立全量台账。
代理采集（Agent-based）：在目标主机上安装 mcdc 采集器，获取进程级信息、网络连接、文件系统使用率等细粒度数据。依赖关系映射必须依赖这一层。
手工导入：通过 CSV 模板导入物理机、数据库、中间件等无法自动发现的资产，保证台账完整。

采集完成后，所有资产进入统一的资产库，每条记录包含主机名、IP、操作系统、CPU 核数、内存、磁盘、所属应用、运行状态等字段。这一步的产出物就是资产清单——它是后续所有分析的唯一事实来源。

二、依赖关系映射：从“孤岛清单”到“拓扑图”

仅有清单是不够的。一台应用服务器如果不知道它连接了哪个数据库、调用了哪个中间件，迁移时就会漏掉关键依赖，导致上线后连接失败。Migration Center 的依赖映射通过分析采集到的网络连接数据（源 IP、目的 IP、端口、协议、连接频次），自动推断出资产之间的调用关系，并生成可视化的拓扑图。

在实际操作中，建议按以下顺序推进：先运行 7～14 天的采集窗口，覆盖月末结算、批量作业等周期性流量；然后在 Migration Center 中查看“依赖关系”视图，重点识别三类关系：强依赖（高频、固定端口）、弱依赖（低频、偶发）、外部依赖（指向公网或第三方系统）。强依赖组必须作为一个迁移批次整体搬迁，弱依赖可以后续处理，外部依赖则需要单独评估网络出口策略。

三、TCO 分析：把“配置清单”翻译成“账单预测”

有了资产清单和依赖分组，下一步是回答“搬到云上要花多少钱”。Migration Center 的 TCO 分析不是简单地把本地 CPU 核数乘以云主机单价，而是基于实际利用率做规格推荐。它的核心逻辑是：读取采集到的 CPU、内存、磁盘 IOPS 的 P95 使用率，匹配 Google Cloud 的机器类型（如 E2、N2、C3 系列），再叠加存储、网络出口、许可证等成本项。

下面是一个简化的 TCO 计算示例，假设某应用服务器采集到的 P95 利用率为 CPU 18%、内存 42%，配置为 8 vCPU / 32 GB：

资产：app-server-01
本地配置：8 vCPU / 32 GB / 500 GB SSD
P95 利用率：CPU 18% → 有效需求约 1.5 vCPU
             内存 42% → 有效需求约 13.5 GB

Migration Center 推荐规格：e2-standard-2（2 vCPU / 8 GB）
说明：按 P95 利用率向上取整并保留 30% 余量，
      2 vCPU 可覆盖 1.5 vCPU 需求，8 GB 覆盖 13.5 GB 偏紧，
      实际推荐 e2-standard-4（4 vCPU / 16 GB）。

月度成本估算（示例，us-central1 区域）：
  计算：e2-standard-4 按需约 $97/月
  存储：500 GB 平衡持久盘约 $50/月
  网络出口：预估 200 GB 约 $24/月
  合计：约 $171/月（不含承诺使用折扣）

这个示例说明了一个关键点：TCO 分析的价值不在于精确到小数点，而在于暴露“过度配置”和“配置不足”两类风险。如果本地 8 vCPU 实际只用 18%，直接按 8 vCPU 搬上云就是浪费；如果内存利用率长期在 85% 以上，则不能简单降配，否则迁移后会出现 OOM。Migration Center 会在推荐规格旁标注“利用率偏高/偏低”的提示，帮助架构师做最终判断。

四、从评估到决策：摸底成果如何落地

完成上述三步后，Migration Center 会输出一份可导出的评估报告，通常包含以下可直接用于决策的内容：

资产总览：按操作系统、应用、环境（生产/测试/开发）分类的资产数量与资源汇总。
迁移批次建议：基于依赖关系自动分组的迁移波次，每个波次内的资产可以整体搬迁。
规格映射表：本地配置 → 推荐云规格 → 利用率依据 → 风险提示。
TCO 对比：本地 3 年 TCO 与云上 3 年 TCO 的对比，含按需与承诺使用折扣两种口径。

在实际项目中，建议把 Migration Center 的评估结果与业务方的应用台账做一次交叉核对。自动采集能发现“机器”，但发现不了“这台机器属于哪个业务系统、谁是负责人、有没有合规要求”。把技术数据与业务上下文合并，才能形成真正可执行的迁移路线图。

依赖关系映射需要至少 7 天的采集窗口。如果只采集 1～2 天，月末结算、批量对账等周期性流量会被漏掉，导致迁移后才发现关键依赖。对于核心交易系统，建议采集 14 天以上，并覆盖一次完整的业务周期。

总结来说，Migration Center 的评估与发现流程可以概括为“采集 → 建库 → 映射 → 分组 → 算账”五个环节。它的产出不是一份静态报告，而是一个持续更新的数据底座：随着迁移推进，资产状态会从“待评估”变为“已迁移”，TCO 也会从“预测”变为“实际账单”。把这个底座维护好，后续的迁移执行和现代化改造才有可靠的依据。