2. 迁移评估与规划

迁移项目失败最常见的原因不是技术不可行，而是“不知道自己有什么”。在动任何一台服务器之前，必须先回答四个问题：现有资产有哪些、它们之间怎么连接、迁移要花多少钱、每个应用该用哪种迁移策略。AWS 为此提供了三件互补的工具：Application Discovery Service（ADS）负责资产发现与依赖采集，Migration Hub负责把发现结果、迁移状态和进度集中到一个控制台，Migration Evaluator负责把采集到的用量数据换算成 TCO 与业务案例。三者构成“发现 → 映射 → 算账 → 决策”的完整链路。

一、资产发现：Agentless 与 Agent 两条路径

ADS 提供两种采集方式，选择哪一种取决于你能拿到什么权限、以及需要多细的粒度。

Agentless（无代理）发现通过 VMware vCenter 连接器采集。在 AWS 控制台创建“发现连接器”后，把它部署为 vCenter 上的一个 OVA 虚拟设备，填入 vCenter 地址与只读账号，连接器就会周期性拉取虚拟机清单、CPU/内存配置、磁盘、网络接口和已安装的部分软件信息。它的优点是零侵入、部署快，适合先做一轮“摸底”；缺点是只能看到虚拟机层面，看不到进程级依赖和操作系统内部的连接关系。

Agent 发现则在每台服务器上安装 AWS Discovery Agent（Windows 与 Linux 均有）。Agent 会采集更细的数据：运行中的进程、TCP 连接对端、监听端口、性能计数器（CPU 利用率、内存使用、磁盘 IOPS、网络吞吐）。这些数据是后续做依赖映射和规格推荐的关键输入。实践中常见的组合是：先用 Agentless 快速盘点全量虚拟机，再对候选迁移的核心业务系统补装 Agent 获取依赖细节。

采集到的数据默认保留在 ADS 的数据存储中，可通过控制台查看，也可导出为 CSV 做离线分析。一个容易被忽略的细节是：Agent 采集的性能数据需要至少积累 2～4 周才能覆盖月末结算、批处理等周期性峰值，否则 TCO 估算会系统性偏低。

二、依赖关系映射：从连接数据到迁移分组

依赖映射的目标不是画一张漂亮的网络图，而是回答“哪些服务器必须一起搬”。判断依据主要来自 Agent 采集的 TCP 连接：如果服务器 A 持续向服务器 B 的 3306 端口建立连接，说明 A 依赖 B 的数据库服务，二者应放入同一迁移批次（wave），否则先迁 A 会导致业务中断。

在 Migration Hub 中，可以把 ADS 发现的主机按应用分组，形成“应用—服务器—依赖”的层级视图。分组时建议遵循三条经验规则：

• 强依赖同批：存在持续 TCP 连接、共享存储或同一 AD 域认证的服务器，划入同一 wave。
• 弱依赖可拆：仅通过 DNS 或 HTTP 偶尔调用的，可分批迁移，但需保证目标端网络连通与安全组放行。
• 无依赖优先：独立的应用（如内部工具、测试环境）作为第一批迁移对象，用来验证迁移流程和回滚机制。

依赖数据还能暴露“隐藏依赖”，例如某台看似独立的 Web 服务器其实在向一台老旧的授权服务器做心跳校验。这类依赖如果不在评估阶段发现，迁移后往往表现为“应用能启动但功能异常”，排查成本极高。

三、TCO 分析：把用量数据换算成钱

Migration Evaluator（前身是 TSO Logic）的输入是 ADS 采集的服务器配置与性能数据，输出是“现状成本 vs. AWS 目标成本”的对比。它的核心逻辑是基于实际用量而非配置规格做推荐：一台配置 16 vCPU、但 CPU 峰值利用率只有 8% 的服务器，不会被推荐为 16 vCPU 的 EC2 实例，而可能被推荐为 2 vCPU 的实例，甚至被建议改用 RDS 或容器。

做 TCO 时至少要覆盖四类成本项：

一个合理的示例假设：某企业有 200 台虚拟机，平均 CPU 利用率 12%，内存利用率 35%，年化本地成本约 480 万元（含折旧、维保、电费、运维人力）。Migration Evaluator 基于用量推荐的目标架构年化成本约 310 万元，其中约 60% 使用 1 年期预留实例、40% 按需。这个 35% 的降幅不是承诺值，而是基于采集数据的估算，实际结果取决于预留覆盖率、数据传出量和是否做架构优化（如把自建 MySQL 换成 Aurora）。

四、6R 策略选择与业务案例构建

6R 是迁移策略的分类框架，每个应用最终应落到其中一种：

• Retire（淘汰）：无人使用或功能重复的系统，直接下线，这是最快见效的“迁移”。
• Retain（保留）：因合规、延迟或近期要替换而暂不迁移，保留在本地。
• Rehost（重新托管）：即 lift and shift，用 MGN 等工具把服务器原样搬到 EC2，速度快、改造少，适合第一批验证。
• Replatform（平台重构）：做有限改造，如把自建 MySQL 迁到 RDS、把 Web 服务器换成容器，收益与工作量平衡。
• Repurchase（重新采购）：用 SaaS 替代自建，如把自建 CRM 换成 Salesforce。
• Refactor（重构）：按云原生方式重新设计，如拆微服务、无服务器化，收益最大但周期最长。

选择策略的判断顺序建议是：先问“还要不要”（Retire/Retain），再问“能不能少改”（Rehost/Replatform），最后问“值不值得大改”（Refactor/Repurchase）。业务案例则把每个应用的策略、迁移批次、预估成本、预期收益和风险汇总成一张决策表，作为后续执行和验收的基线。

把上述四步串起来，评估阶段的实际交付物通常包括：一份完整的服务器与应用清单、一张依赖关系与 wave 划分图、一份 TCO 对比报告、一张按应用标注 6R 策略的决策表。这四份材料共同构成迁移的业务案例，也是后续执行阶段判断“是否按计划推进”的基线。评估做得越扎实，执行阶段的返工和意外就越少。