3. 企业现有IT资产盘点与迁移评估方法

迁移上云失败的项目，多数不是败在云平台能力不足，而是败在“不知道自己有什么”。本地数据中心经过多年演进，往往存在同一业务被拆成多个应用、同一数据库被多个系统直连、中间件版本混杂、定时任务与文件共享隐式耦合的情况。资产盘点的目标不是做一份漂亮的清单，而是建立一张可追溯的依赖地图，并在此基础上判断每个工作负载“能不能迁、怎么迁、先迁谁”。

一、盘点对象：四层资产与三类关系

建议把盘点对象固定为四个层次，避免遗漏也避免无限扩张：

• 应用层：Web 应用、批处理作业、定时任务、报表服务、接口服务。记录应用名、负责人、业务域、用户规模、SLA 等级、技术栈与版本。
• 中间件层：WebLogic、Tomcat、JBoss、MQ、ESB、文件传输与调度组件。重点记录版本、集群拓扑、端口、证书、连接池配置。
• 数据库层：Oracle 数据库实例、版本、字符集、数据量、归档模式、RAC/Data Guard 拓扑、Schema 归属。
• 基础设施层：物理机/虚拟机、CPU/内存/存储、操作系统版本、IP 与网段、负载均衡、防火墙策略。

层与层之间需要识别三类关系：调用关系（应用调应用、应用调数据库）、数据流向（谁写入、谁只读、是否有反向同步）、部署依赖（共享文件目录、共享库、同一台主机上的多实例）。这三类关系决定了迁移时的“最小可迁移单元”——一个应用如果与另一个应用共享数据库 Schema 或本地文件目录，就不能单独迁走。

二、采集手段：从自动发现到人工确认

纯人工填表效率低且容易失真，推荐“自动采集为主、访谈确认为辅”。在本地环境可用的采集方式包括：

• 主机侧：通过 CMDB、虚拟化平台 API、操作系统命令采集主机与进程清单。
• 网络侧：利用 NetFlow、防火墙日志、负载均衡访问日志还原真实调用关系，这比访谈更可靠。
• 数据库侧：查询 v$session、v$active_session_history、AWR 报告，识别实际连接来源与访问高峰。
• 应用侧：解析配置文件中的 JDBC URL、JNDI 名称、MQ 队列地址，得到显式依赖。

自动采集只能给出“技术连接”，业务重要性、合规要求、停机窗口必须通过访谈补齐。建议对每个应用指定一名业务负责人和一名技术负责人，双签确认。

三、迁移就绪度评估：六个维度打分

盘点完成后，用统一维度对每个工作负载打分，形成可比较的迁移就绪度。常用维度包括：技术兼容性（数据库版本、OS、中间件是否被目标云支持）、依赖复杂度（跨系统耦合数量）、数据规模与迁移窗口、性能与延迟敏感度、合规与数据驻留要求、改造工作量。每个维度按 1～5 分评估，加权后得到总分，用于排序迁移批次。

四、迁移策略判定：6R 与决策路径

对每个工作负载，依据就绪度与业务约束选择迁移策略：Rehost（直接搬迁，适合低耦合、无改造预算的系统）、Replatform（小幅改造，如从自建 Oracle 迁到 Autonomous Database）、Refactor（重构，适合核心系统长期演进）、Repurchase（换用 SaaS）、Retain（暂不迁移）、Retire（下线）。判定时优先看依赖复杂度与合规要求，再看改造成本。

五、实操示例：一个订单系统的评估过程

假设某企业本地有一套订单系统，结构为：Tomcat 8 部署订单 Web 应用，连接一台 Oracle 11g RAC 数据库，通过 MQ 向库存系统发送消息，同时与报表系统共享一个 NFS 目录存放对账文件。按上述方法评估：

加权总分约 3.4，属于“可迁移但需改造”。策略判定为 Replatform：数据库迁到 Autonomous Database，应用容器化部署到 OKE，NFS 目录改为 Object Storage 并通过预签名 URL 共享，MQ 迁移到 OCI Streaming。迁移批次排在库存系统之后，因为库存系统是消息上游，先迁上游可避免双写。

六、输出物与判断标准

盘点与评估的最终交付物应包含三份材料：资产清单（含四层字段与负责人）、依赖关系图（标注调用、数据流、部署依赖）、迁移就绪度评分表与批次计划。判断评估是否合格的标准是：任意一个应用，都能回答“它依赖谁、谁依赖它、迁走它会影响什么、用哪种策略迁、排在哪个批次”。如果某个问题答不上来，说明盘点还没做到位，不应进入实际迁移阶段。