2. 迁移评估与就绪度分析

迁移评估不是“把服务器列个清单”，而是回答四个彼此约束的问题：为什么迁（业务用例）、迁什么（应用组合）、划不划算（TCO/ROI）、谁来迁、能不能迁（组织与技能）。这四者构成一个闭环：业务用例决定评估范围与优先级，应用组合发现提供成本与依赖的输入，TCO/ROI 反过来校验业务用例是否成立，组织与技能差距则决定迁移节奏能否落地。任何一环缺失，都会导致后期返工或预算失控。

一、业务用例梳理：把“上云”翻译成可度量的业务目标

业务用例梳理的核心是把模糊的“降本增效”拆成可验证的驱动因素。常见驱动分为五类：数据中心退出（合同到期、租赁成本）、弹性与可用性（应对流量峰值、缩短故障恢复）、创新速度（缩短新功能上线周期）、合规与安全（满足等保、数据驻留要求）、并购整合（统一 IT 平台）。每个用例都应绑定一个可量化指标，例如“2025 年 Q2 前关闭 A 机房，年节省租赁与运维 320 万元”“大促期间扩容时间从 3 天缩短到 30 分钟”。

实操中建议用一张“业务用例登记表”逐条记录：用例编号、业务负责人、驱动类型、当前痛点、目标指标、目标时间、受影响应用范围、约束条件（如数据不能出境）。这张表是后续优先级排序和 ROI 建模的输入。示例：用例 BU-03，驱动为“弹性”，痛点为“促销日订单系统 CPU 峰值 92%，扩容需提前 3 天申请物理机”，目标指标为“峰值自动扩容至 3 倍，扩容触发时间 ≤ 5 分钟”，受影响应用为订单服务、支付网关、库存服务。

二、应用组合发现：从“资产清单”到“依赖关系图”

应用组合发现要产出三类信息：应用清单（名称、负责人、业务关键度、用户量、SLA）、技术栈与运行形态（语言、框架、中间件、数据库、OS、部署方式）、依赖关系（应用间调用、共享数据库、文件共享、消息队列、定时任务）。依赖关系是迁移分批的关键——如果订单服务依赖本地 Oracle 且与库存服务共享表，就不能单独迁移订单服务。

发现手段通常组合使用：CMDB 与资产系统导出、APM/网络流量分析（如 VPC Flow Logs、应用调用链）、数据库连接审计、代码仓库扫描、以及与应用负责人访谈。建议为每个应用打上“6R 初步倾向”标签：Retire（下线）、Retain（保留）、Rehost（平移）、Replatform（小改造）、Refactor（重构）、Repurchase（换 SaaS）。例如：内部报表系统用户少、功能被 BI 替代 → Retire；核心交易系统依赖 Oracle RAC 且合规要求高 → 先 Rehost 到 EC2 + RDS，后续再评估 Replatform。

三、TCO/ROI 建模：把“感觉便宜”变成可审计的数字

TCO 建模要覆盖现状成本与目标成本两侧，且必须包含一次性迁移成本与持续运营成本。现状侧常被低估的项包括：机房租赁与电费、硬件折旧、软件许可（Oracle、Windows、中间件）、运维人力、备份与灾备、网络专线。目标侧则包括：AWS 计算/存储/网络/数据库费用、支持计划、迁移工具与人力、培训、双跑期并行成本、以及可能的许可变更（如 Oracle 自带许可 BYOL 规则）。

以一个简化示例说明计算过程（以下为教学假设数据，非实测）：某应用现状年成本 = 机房分摊 18 万 + 硬件折旧 12 万 + 软件许可 25 万 + 运维人力 30 万 + 灾备 8 万 = 93 万元/年。迁移后 AWS 年成本 = EC2 24 万 + RDS 18 万 + 存储与网络 6 万 + 支持计划 5 万 = 53 万元/年。一次性迁移成本 = 工具与人力 20 万 + 双跑 3 个月 12 万 + 培训 5 万 = 37 万元。则年节省 40 万元，静态回收期 = 37 ÷ 40 ≈ 0.93 年（约 11 个月）。若考虑三年周期，三年净收益 = 40×3 − 37 = 83 万元。ROI 建模还应做敏感性分析：若实际用量比预估高 30%，AWS 年成本升至约 69 万，年节省降至 24 万，回收期延长至约 1.5 年——这提示必须用真实监控数据校准用量假设，而不是拍脑袋。

四、组织与技能差距评估：决定迁移节奏的隐形约束

组织与技能评估要回答：现有团队是否具备云平台、IaC、容器、CI/CD、安全合规、成本治理等能力？通常用“技能矩阵”按角色（云架构师、平台工程师、应用开发、DBA、安全、运维）对关键技能打分（0 无、1 了解、2 可独立操作、3 可指导他人）。差距 = 目标等级 − 当前等级。例如：平台工程师在 Terraform 上当前 1、目标 3，差距 2，需要安排 2 周实操训练 + 1 个试点项目；DBA 在 RDS 上当前 0、目标 2，需要外部顾问带教。同时要评估组织阻力：是否有团队担心岗位变化、是否有集中式云平台团队、预算与决策权归属。技能差距直接决定迁移批次大小——差距大时应先做 1～2 个试点应用，用真实项目培养能力，再扩大批次。

五、把四要素合成一份可执行的评估结论

评估收尾时，建议输出一份“就绪度结论表”，字段包括：应用/批次、业务用例编号、6R 倾向、迁移前依赖解耦动作、TCO 年节省与回收期、所需技能与缺口、风险等级、建议迁移窗口。示例行：订单域批次 1，用例 BU-03，Rehost + 数据库 Replatform 到 RDS，需先解耦共享表，年节省约 40 万、回收期约 11 个月，技能缺口为 Terraform 与 RDS 运维，风险中，建议在 Q3 非促销期执行。这样，评估结果才能直接驱动迁移计划、预算申请与人员安排，而不是停留在 PPT 里。