4. 业务迁移需求调研与评估

业务迁移项目失败，往往不是败在存储阵列的复制带宽或主机多路径配置上，而是败在调研阶段：没人说得清到底有多少套应用、每套应用的真实数据量是多少、业务方给的 RTO/RPO 是拍脑袋还是经过验证、停机窗口是"周末两小时"还是"凌晨 0:00–4:00 且不能跨月结"。本章的目标是把这些模糊的口头承诺，转化为可量化、可排序、可写入迁移方案的工程输入。

一、应用清单：从"业务系统"落到"可迁移单元"

调研的第一步不是问数据量，而是建立应用清单。清单的粒度不能停留在"财务系统""OA 系统"这种业务名称上，因为一个业务系统往往由多台主机、多个数据库实例、若干中间件和共享文件目录组成，而迁移的最小单元是"能一起切换、一起回退的一组卷和主机"。建议按下面的层级拆解：

• 业务系统：如 ERP、MES、影像归档 PACS。
• 应用组件：Web 层、应用层、数据库层、缓存层、文件共享层。
• 主机与实例：主机名、IP、操作系统、数据库实例名/SID。
• 存储资源：卷名、容量、文件系统类型、挂载点、是否共享（集群卷/ASM 磁盘组/NFS 导出）。
• 依赖关系：调用关系、共享存储关系、DNS/VIP、证书、定时任务、外部接口。

依赖关系是清单里最容易被忽略、却最容易导致切换失败的部分。例如应用服务器迁移后仍指向旧数据库的 VIP，或者两台主机共享同一个 NFS 导出，只迁了一台就会造成数据不一致。建议在清单中增加"迁移时必须同批处理的对象"一列，把强耦合的组件绑定成一个迁移批次。

二、数据量与增长：区分"已用容量"和"迁移传输量"

数据量调研要同时记录三个数字：卷的配置容量、文件系统已用容量、以及实际需要传输的增量。配置容量决定目标端 LUN 的规划，已用容量决定首次全量同步的时间，而增量决定切换窗口内的最后一次同步耗时。以某示例环境为例：一个 Oracle 数据库使用 3 个 2 TB 的 ASM 磁盘，已用 4.2 TB，日增量约 60 GB；一台文件服务器配置 10 TB，已用 7.8 TB，日增量约 120 GB。这些数字必须标注为示例假设，实际项目需通过 df -h、du、存储管理界面或备份系统报表核实。

同时要关注"小文件海量"场景：同样是 1 TB，一个大文件卷和包含 2000 万个 4 KB 小文件的卷，在同步和校验阶段的耗时可能相差数倍。调研时应记录文件数量级，必要时用 find /data -type f | wc -l 抽样统计。

三、IO 特征：决定迁移通道与目标端选型

IO 特征调研的目的是判断迁移方式是否可行、目标存储池是否扛得住。需要采集的指标包括：读写比例、IOPS、平均 IO 大小、随机/顺序比例、峰值时段、是否对时延敏感。数据库 OLTP 通常是小块随机写为主，对时延敏感；备份归档、视频监控则是大块顺序写，对带宽敏感。若源端在业务高峰时 IOPS 已达 3 万、时延 2 ms，而迁移复制链路只能提供 800 MB/s 且会增加额外读写，就必须评估是否采用"存储底层复制 + 短暂停机"而非"主机层在线迁移"。

采集方式可以借助操作系统工具（如 iostat -x 1、Windows 性能监视器）、数据库 AWR/statspack 报告，或存储阵列的性能历史数据。建议至少采集连续 7 天、覆盖月结或日结高峰的数据，避免用闲时数据做容量规划。

四、RTO/RPO 与停机窗口：把业务语言翻译成技术指标

RTO（恢复时间目标）指业务中断后必须恢复的最长时间，RPO（恢复点目标）指允许丢失的数据时间跨度。业务方常说"越快越好"，工程上必须逼出具体数字。RPO=0 意味着必须同步复制或数据库级一致性保障；RPO=15 分钟意味着可以接受异步复制加一次增量同步；RTO=4 小时意味着切换脚本、DNS 变更、应用启停都要在 4 小时内完成并验证。

停机窗口则要问清三件事：允许停机的起止时间、是否可跨天、是否有不可触碰的时段（如财务月结、生产排程下发）。把 RTO 与停机窗口对比，就能判断迁移策略：若停机窗口 ≥ 全量同步时间 + 切换验证时间，可采用停机迁移；若窗口远小于全量时间，则必须先做在线预同步，窗口内只做增量追平和切换。

五、合规约束与优先级排序

合规约束包括数据出境限制、行业监管留存要求、审计日志完整性、加密要求等。例如某些行业要求迁移过程中数据不得离开本地机房，这会直接排除公有云中转方案；要求传输加密则需确认复制链路是否支持 IPsec 或阵列级加密。

优先级排序建议采用加权评分法，而不是简单按"业务重要性"排序。可选取业务影响度、RTO 紧迫度、数据量、依赖复杂度、合规风险五个维度，各赋权重后打分。下面给出一个可直接使用的评估表模板（数值为示例）：

排序原则是：高影响、高 RTO 紧迫、低依赖复杂度的先迁，作为验证迁移流程的"探路批次"；数据量大、依赖复杂、合规要求高的放在后面，留足预同步和演练时间。每批迁移后都要复盘实际停机时长与 RTO 的偏差，用于修正后续批次的窗口估算。

调研成果最终要落到一份可评审的《迁移需求评估表》上，字段至少包含：应用名称、组件清单、主机与实例、卷与容量、已用与增量、IO 特征、RTO、RPO、停机窗口、合规约束、依赖对象、加权得分、迁移批次、迁移方式建议。这份表既是方案设计的输入，也是迁移后验收的对照基准。调研阶段多花一天把数字问清楚，实施阶段就可能少熬一个通宵。