📚 课程目录第3章迁移评估方法论与工具链

3. 迁移评估方法论与工具链

迁移评估不是“看一眼服务器清单就报价”，而是一条从发现到量化再到决策的证据链。Oracle 官方与开源生态提供了互补的工具组合：Oracle Cloud Migration Advisor（OCMA）负责把本地资产与 Oracle Cloud 目标形态做匹配并给出就绪度评分，Terraform负责把目标环境固化为可复现的基础设施代码，Ansible负责主机内配置、依赖与运行时的自动化采集和改造。三者串起来，才能把“能不能迁、迁成什么样、要改多少”讲清楚。

一、工具链的分工与数据流

先明确每个工具在评估阶段的位置，避免把评估工具当成交付工具用：

OCMA / Migration Advisor：输入是资产清单（主机、数据库、中间件、应用）、版本、资源用量、依赖关系；输出是目标云形态建议（IaaS/PaaS/Exadata/自治数据库等）、兼容性风险、迁移就绪度评分与改造建议。
Terraform：把评估结论落成目标架构代码，例如 VCN、子网、安全列表、计算实例、DB 系统、负载均衡。评估阶段用它做“目标环境预演”，验证网络与规格是否满足依赖。
Ansible：在源端主机执行只读采集（进程、端口、服务、包、配置文件、cron、JDBC 连接串），在目标端执行配置基线。评估阶段重点是依赖发现与性能基线。

三者的数据流可以概括为：Ansible 采集源端事实 → OCMA 做匹配与评分 → Terraform 生成目标环境骨架 → 回填评分与差距。下图给出这一关系：

二、应用依赖发现：从端口到调用链

依赖发现的目标是回答三个问题：谁在调用谁、通过什么协议、有没有硬编码地址。Ansible 适合做无代理的只读采集，下面是一段可直接参考的 playbook 片段，用于采集监听端口、进程与 JDBC 连接串：

- name: 采集应用依赖事实
  hosts: app_servers
  gather_facts: true
  tasks:
    - name: 监听端口与进程
      shell: ss -tulnp | awk 'NR>1 {print $1,$5,$7}'
      register: listen_ports
      changed_when: false

    - name: 扫描 JDBC/ODBC 连接串
      shell: grep -rEho 'jdbc:[a-z]+://[^"'"'"' ]+' /opt/app/conf 2>/dev/null | sort -u
      register: jdbc_urls
      changed_when: false

    - name: 输出依赖摘要
      debug:
        msg:
          ports: "{{ listen_ports.stdout_lines }}"
          jdbc: "{{ jdbc_urls.stdout_lines }}"

采集结果需要归一化成依赖矩阵。例如某订单系统采集到：10.20.1.15:1521（Oracle DB）、10.20.1.22:6379（Redis）、10.20.1.30:8080（内部支付服务）。若连接串中出现 IP 而非域名，就标记为“硬编码依赖”，迁移到云上 VCN 后网段变化会导致连接失败，必须在改造清单中列为高优先级。依赖矩阵建议至少包含：源主机、目标主机、端口、协议、调用方向、是否硬编码、是否跨安全域。

三、性能基线采集：用数据说话

性能基线不是“看一眼 top”，而是要在业务高峰与低谷分别采样，形成可对比的统计量。评估阶段常用指标包括：CPU 使用率（用户态/系统态）、内存与 swap、磁盘 IOPS 与 await、网络吞吐、数据库 AWR 中的 DB Time 与 Top SQL。采样周期建议覆盖至少一个完整业务周期（如 7 天），采样间隔 1 分钟，取 P95 而非平均值，避免被瞬时峰值误导。

一个可操作的基线采集命令示例（在源端主机执行，输出 CSV 供后续分析）：

# 每 60 秒采样一次，持续 7 天，输出到 baseline.csv
nohup bash -c 'while true; do
  ts=$(date +%F_%T)
  cpu=$(top -bn1 | awk "/Cpu\(s\)/ {print 100-\$8}")
  mem=$(free | awk "/Mem:/ {print \$3/\$2*100}")
  io=$(iostat -x 1 2 | awk "/^sd|^nvme/ {print \$1,\$14,\$10}" | tail -n +2 | tr "\n" ";")
  echo "$ts,$cpu,$mem,$io" >> baseline.csv
  sleep 60
done' &

得到基线后，用 P95 值对照目标规格。例如源端 8 vCPU 主机 P95 CPU 为 62%、内存 P95 为 78%，则目标实例建议不低于 8 OCPU 且内存不低于 1.5 倍，以留出云上虚拟化与安全代理的开销。若数据库 AWR 显示 DB Time 中 40% 消耗在一条全表扫描 SQL 上，则迁移前应先优化该 SQL，否则云上规格再高也无法解决根因。

四、迁移就绪度评分与决策

就绪度评分是把上述事实压缩成一个可比较的数字，便于在多个应用之间排优先级。评分不是目的，评分背后的差距项才是。建议按五个维度加权：兼容性 30%、依赖复杂度 25%、性能余量 20%、改造工作量 15%、风险 10%。每个维度按 0–5 分打分，再乘以权重求和，得到 0–100 的总分。参考判读：

总分区间	就绪等级	建议动作
85–100	就绪	可直接进入迁移波次，优先安排
70–84	基本就绪	完成少量配置改造后迁移
50–69	需改造	列入改造迭代，明确责任人与验收标准
<50	暂缓	重新设计架构或保留本地，避免高风险迁移

以一个示例应用“订单服务”为例：兼容性 4 分（OS 与 DB 版本受支持）、依赖复杂度 2 分（存在 3 处硬编码 IP 与共享 NFS）、性能余量 4 分（P95 CPU 62%）、改造工作量 3 分（需改连接串与挂载）、风险 3 分（停机窗口 2 小时）。加权计算：4×0.30 + 2×0.25 + 4×0.20 + 3×0.15 + 3×0.10 = 1.20 + 0.50 + 0.80 + 0.45 + 0.30 = 3.25，换算为百分制约 65 分，属于“需改造”。差距项集中在依赖复杂度与改造工作量，下一步应先用 Terraform 预演目标 VCN 与子网，确认新网段后统一替换硬编码地址，再用 Ansible 推送新配置并回归验证。

评估阶段的所有采集脚本都应保持只读，避免在源端生产环境引入变更。Ansible 使用 changed_when: false 与只读命令，Terraform 使用 plan 而非 apply 做预演，OCMA 的报告应保留原始数据以便复核。

就绪度评分中的权重与阈值是示例约定，实际项目应根据行业合规要求、停机容忍度和团队自动化能力调整，并在评估启动前与业务方确认，避免事后争议。

把工具链跑通后，评估交付物应至少包含：依赖矩阵、性能基线报告、就绪度评分表、目标架构 Terraform 骨架、改造清单与迁移波次建议。这五份材料共同构成迁移决策的证据基础，也是后续工程交付的输入。