3. 企业迁移评估与业务案例分析
在正式把工作负载搬上 Azure 之前，最容易被跳过、却最影响成败的一步是“评估”。评估不是填一张问卷，而是用数据回答三个问题：我到底有哪些机器和依赖？它们能不能迁、迁到哪种目标最合适？迁过去之后成本是升还是降？本节围绕 Azure Migrate、依赖关系分析和 TCO 计算器这三件工具，把发现、评估、就绪判断串成一条可执行的工作链。
一、发现：先把资产和依赖摸清楚
Azure Migrate 的发现分两条路径。物理机或 VMware/Hyper-V 虚拟机，通过部署一个轻量的设备（Appliance）到本地环境，由它扫描 vCenter、Hyper-V 主机或直接扫描服务器清单，采集 CPU、内存、磁盘、网络吞吐等性能计数器。默认采集周期为每 15 分钟一次，通常建议至少收集 24 小时到 1 个月的数据，才能覆盖业务高峰，避免用闲时数据得出偏小的规格建议。
对于无法安装采集代理的机器，可以用“无代理依赖分析”，通过读取网络连接日志推断机器之间的调用关系；对关键业务系统，则建议启用基于代理的依赖分析，在目标机器上安装 Mobility Service 代理，采集进程级连接，精度更高。
依赖关系分析的价值在于：它把“一台台孤立的机器”还原成“一组组业务系统”。例如某订单系统由 3 台 Web 前端、2 台应用服务器、1 台 SQL Server 和 1 台 Redis 缓存组成，它们之间存在 443、1433、6379 端口的调用。如果只按单机迁移，很可能漏掉缓存或数据库，导致上线后应用报错。依赖图能直接暴露这些隐藏耦合，帮助划分迁移批次。
二、评估：把清单变成规格建议
发现完成后，在 Azure Migrate 中创建评估。评估前要选两个关键参数：一是“目标区域”，不同区域价格和可用服务不同；二是“评估依据”，可选“按性能数据”或“按本地现状”。按性能数据会取采集周期内的百分位值（默认第 95 百分位）作为规格依据，更贴近真实负载；按本地现状则直接沿用当前分配的 vCPU 和内存，适合无法采集性能数据的场景。
Azure Migrate 还会引入“舒适因子”，默认 1.3，用于在性能数据基础上留出余量。例如某应用服务器 95 百分位 CPU 使用为 4 核、内存 12 GB，乘以 1.3 后约为 5.2 核、15.6 GB，评估结果会推荐 8 vCPU、16 GB 的 Azure VM 规格。这个因子可按业务波动调整，但不宜随意调低，否则容易在高峰期出现资源不足。
评估结果中每台机器会给出“就绪状态”。常见状态包括：Ready（可直接迁移）、Ready with conditions（有条件就绪，如需要调整磁盘类型或启用加速网络）、Not ready（如操作系统版本过旧、缺少驱动、磁盘超过单盘上限）、Unknown（数据不足）。对 Not ready 的机器，评估会给出具体原因和整改建议，例如升级 OS 版本、拆分超大磁盘、改用托管磁盘等。
三、TCO 计算器：算清五年账
Azure Migrate 中的 TCO 计算器用于对比本地与 Azure 的总拥有成本。本地侧需要输入服务器数量、CPU/内存配置、存储容量、网络带宽，以及硬件折旧、软件许可（如 Windows Server、SQL Server）、电力和运维人力成本。Azure 侧则根据评估出的目标规格，叠加计算、存储、网络出口费用，并可勾选 Azure Hybrid Benefit（复用已有 Windows/SQL 许可）和预留实例（1 年或 3 年）来降低费用。
一个合理的示例：某企业 20 台本地 VM，年硬件折旧与软件许可合计约 48 万元，电力与运维约 12 万元，五年本地总成本约 300 万元。迁移到 Azure 后，按评估规格选用 3 年预留实例并启用混合权益，五年计算与存储费用约 210 万元，加上网络与备份约 25 万元，合计约 235 万元，五年可节省约 65 万元，回收期约 2.5 年。这些数字属于教学示例，实际结果必须以企业真实清单和当前区域价格为准。
四、迁移就绪判断：从评估到行动
把评估结果落到行动上，可以按下面的判断顺序推进：先看依赖分组，把强耦合的机器划为同一迁移批次；再看每台机器的就绪状态，Ready 的直接进入迁移计划，Ready with conditions 的先完成整改项，Not ready 的单独列出并评估是否改为重构或重建；最后用 TCO 结果确认该批次迁移的经济性，若某组机器迁移后成本反而上升，可考虑保留本地或改用 PaaS 服务替代。
| 就绪状态 | 典型原因 | 处理动作 |
|---|---|---|
| Ready | 规格、OS、磁盘均满足 | 纳入迁移批次，安排复制与测试切换 |
| Ready with conditions | 需启用加速网络、调整磁盘类型 | 先完成条件整改，再进入迁移 |
| Not ready | OS 版本过旧、磁盘超限、缺少驱动 | 升级/拆分/重建，或改为 PaaS 重构 |
| Unknown | 性能数据不足或采集失败 | 延长采集周期，补齐数据后重新评估 |
需要强调的是，评估不是一次性动作。业务在变，依赖在变，价格也在变。建议在迁移启动前完成一轮完整评估，迁移过程中按批次复核，迁移后再用 Azure 成本管理持续比对实际支出与 TCO 预测，把偏差反馈到下一批次的评估参数中。这样，Azure Migrate、依赖分析和 TCO 计算器才真正形成闭环，而不是三份互不相干的报告。