2. 迁移评估与就绪度分析
迁移评估不是“把服务器清单导出来”这么简单。真正决定迁移成败的，是能否回答三个问题：我到底有什么资产、它们之间怎么互相依赖、哪些能直接搬、哪些必须先改造。AWS 为这三个问题提供了三件互补的工具：Application Discovery Service（ADS）负责采集，Migration Hub负责集中呈现与跟踪，Migration Evaluator负责成本与就绪度建模。理解它们各自的数据来源和边界，比记住产品名更重要。
一、三件工具的分工与数据来源
ADS 是数据采集层。它有两种采集方式：Agentless（无代理）通过 vCenter 只读账号拉取虚拟机清单、CPU/内存配置和性能计数器，部署快、覆盖广，但看不到操作系统内部的进程与网络连接；Agent（代理）安装在每台服务器上，能采集进程、TCP 连接、监听端口和出站依赖，是发现应用依赖关系的关键。实践中常见组合是：先用 Agentless 快速摸清全量资产，再对核心业务系统补装 Agent 做依赖深挖。
Migration Hub 是汇聚层。它本身不采集数据，而是把 ADS 发现的服务器、以及后续各迁移工具（如 DMS、MGN、SCT）的执行状态汇总到同一视图，按应用分组展示“已发现—已评估—迁移中—已完成”的进度。它的价值在于跨账号、跨区域的统一跟踪，避免用表格人工维护迁移台账。
Migration Evaluator 是决策层。它基于采集到的资源利用率和配置，结合目标机型价格、许可（如 Windows/SQL Server 的 BYOL 与 License Included 差异）、存储与网络成本，输出 TCO 对比和迁移就绪度建议。它回答的是“搬过去要花多少钱、怎么搬最省”。
二、资产盘点的实际操作
以 Agentless 采集为例，典型流程是：在 AWS 控制台创建 ADS 采集器，生成一个 OVA 模板并部署到 vCenter；在采集器配置中填入 vCenter 的只读账号（建议单独建一个 svc-ads-readonly 账号，仅授予“只读”角色，不要用管理员账号）；启动采集后，ADS 会按固定周期拉取数据。采集到的每台 VM 会带有唯一标识、主机名、IP、OS 类型、CPU 核数、内存、磁盘容量和最近一段时间的平均/峰值利用率。
这里有一个容易被忽略的细节：性能数据的采集窗口。默认采集周期通常覆盖数周，如果业务有明显波峰波谷（如电商大促、月末结算），采集窗口必须覆盖完整业务周期，否则利用率会被低估，导致目标机型选小、上线后性能不足。建议至少覆盖一个完整的月度周期，并在评估报告中标注采集起止时间。
三、依赖发现与分组
依赖发现的目标是形成“应用分组”。ADS Agent 会记录每台服务器上的进程、监听端口和出站连接，据此可以推断出调用关系。例如上图中 web-01/web-02 通过 HTTP 调用 app-01 的 8080 端口，app-01 再通过 JDBC 访问 db-mysql-01 的 3306、通过 Redis 协议访问 cache-redis-01 的 6379。这些连接关系汇总后，就能把原本散落的服务器归入同一个应用分组，迁移时整组一起搬，避免“搬了应用没搬数据库”导致中断。
需要提醒的是，Agent 采集到的是网络连接事实，不等于业务依赖的全部。定时任务、消息队列、文件共享、外部第三方接口等依赖，往往需要结合访谈和配置文件核对。因此依赖发现的结果应当作为“待确认清单”，由应用负责人逐条确认，而不是直接当作最终结论。
四、就绪度评估的判定维度
就绪度不是单一分数，而是多个维度的综合判断。常见的判定维度包括：
- 技术兼容性：OS 版本是否仍在支持期、是否依赖已废弃的中间件、是否有内核级定制。
- 依赖复杂度：应用分组内服务器数量、跨组调用数量、是否存在难以迁移的共享存储或硬件加密狗。
- 性能余量：峰值利用率与目标机型规格的匹配度，是否留有合理余量。
- 许可与合规：Windows/SQL Server 等许可能否 BYOL、数据驻留要求是否满足。
- 业务窗口：可接受的停机时间，决定采用停机迁移还是在线复制。
综合这些维度，通常把资产分为三类：可直接迁移（Rehost，如标准 LAMP 应用）、需小改造（Replatform，如把自建 MySQL 换成 RDS）、需重构或暂缓（Refactor/Retain，如强依赖特定硬件的系统）。这个分类直接决定后续迁移批次和工具选择。
五、成本建模与结果解读
Migration Evaluator 的输入是采集到的利用率和配置，输出是 TCO 对比。解读结果时要注意两点：一是利用率到机型的映射，例如某台 VM 平均 CPU 利用率 8%、峰值 35%、内存 16GB，评估器可能建议降到 2 vCPU/8GB 的机型，但若该应用对内存延迟敏感，就不能只看平均值；二是许可成本，Windows 和 SQL Server 的 License Included 与 BYOL 价差可能非常大，必须结合现有许可协议判断。
六、常见误区
第一，只做 Agentless 就下结论。无代理采集看不到进程和连接，依赖关系基本是空白，容易漏掉关键依赖。第二，把 Migration Hub 当成采集工具。它只做汇聚和跟踪，没有数据就没有视图。第三，忽略采集窗口，用一周的数据代表全年，导致机型选型和成本估算失真。第四，就绪度只看技术不看业务，忽略了停机窗口、合规和团队技能，结果评估通过但实际推不动。
把这三件工具用对顺序、用对范围，迁移评估才能从“一份清单”变成“一份可执行的迁移计划”。