3. 业务数据迁移需求分析与评估

迁移项目失败，很少是因为存储设备性能不够，更多是因为需求没摸清：以为只有 20TB，实际扫描出 60TB；以为停机 4 小时够用，实际光是增量同步就跑了 6 小时；以为 NAS 里都是普通文件，结果混着数据库裸设备和合规审计数据。需求分析与评估这一节要解决的，就是把“模糊的迁移愿望”变成一份可签字、可验收、可排期的迁移需求说明书。

一、先梳理业务系统，而不是先看存储

正确的切入顺序是“业务 → 数据 → 存储”。先列出所有依赖待迁移存储的业务系统清单，每个系统标注：业务负责人、技术负责人、系统等级（核心/重要/一般）、上下游依赖、是否有数据库、是否有对外接口。系统等级直接决定后续的停机窗口和回退要求，不能由存储工程师单方面判定，必须由业务方确认。

梳理时最容易漏掉三类对象：一是“影子系统”，即业务部门自己搭的测试机、报表机，从未登记在 CMDB 中；二是“共享目录”，多个系统读写同一个 NFS 挂载点，迁移时若只迁其中一个系统会破坏依赖；三是“归档数据”，多年不访问但受合规约束不能删除。建议用一次全量扫描来兜底，例如在 NetApp ONTAP 上执行容量与文件统计：

# 查看各卷容量与快照占用
volume show -fields volume,size,used,percent-used,snapshot-reserve
# 统计卷内文件数量与目录深度（示例，实际按需调整）
volume file show-disk-usage -v vol_app01
# 查看导出策略，确认哪些客户端在访问
export-policy rule show -vserver svm_prod -policyname pol_app01

扫描结果要与业务清单交叉核对，凡是“有客户端在访问但清单里没有”的，一律先挂起，找业务方确认后再决定是否纳入迁移范围。

二、数据量评估：容量、文件数、增量速率

数据量不能只报一个“已用容量”。真正影响迁移方案的是四个参数：逻辑容量（业务看到的）、物理容量（含快照、含重复数据删除后的实际占用）、文件/对象数量（决定扫描和拷贝的元数据开销）、日增量速率（决定增量同步和最终切换的追赶时间）。

经验上，小文件（平均小于 64KB）占比高的卷，迁移耗时往往由文件数而非容量决定。例如一个 5TB 的卷若含 2000 万个文件，基于文件级拷贝的工具可能需要十几小时；而同样 5TB 的少量大文件卷可能 2 小时就能完成。因此评估时必须同时给出容量和文件数，并据此选择迁移方式（文件级、块级还是存储原生复制）。

日增量速率建议取最近 30 天的写入量均值，并额外考虑月末结账、季度报表等峰值。若日均增量 200GB、峰值 800GB，则增量同步窗口必须按峰值设计，否则切换当天会追不上。

三、性能要求：把“要快”翻译成可测指标

业务方说“迁移不能影响生产”，这句话无法验收。需要翻译成可测量的指标：迁移期间源端读 IOPS 上限、目标端写带宽上限、生产业务延迟允许上升比例、迁移任务可占用的时间窗。例如约定：迁移期间源存储 CPU 利用率不超过 70%，生产 NFS 读延迟 P95 不超过 5ms，迁移任务限速 400MB/s。

同时要区分“迁移期性能”和“迁移后性能”。迁移后新存储能否支撑业务，取决于业务真实的 IOPS、吞吐和延迟需求，而不是旧存储的当前值——旧存储可能本身就是瓶颈。若无法直接测得，可用业务峰值时段的性能采样作为基线，并预留 30% 余量。

四、停机窗口与合规约束

停机窗口要区分三种：计划停机（业务可接受的中断）、切换窗口（最后一次增量同步加应用切换）、回退窗口（出问题时退回旧存储的时间）。三者必须都写进需求说明书，且回退窗口通常应小于切换窗口，否则回退本身就会造成二次事故。

合规约束常见的有：数据不得出境或不得跨机房、特定数据必须加密存储、审计日志需保留若干年、迁移过程中不得使用第三方云中转。这些约束会直接否决某些迁移路径，必须在方案设计前确认，而不是实施中才发现。

五、形成迁移需求说明书

需求说明书的本质是一份“可验收的约定”，不是技术方案。它应包含：迁移范围与排除项、容量与文件数基线、增量速率、性能与限速约定、停机/切换/回退窗口、合规约束、验收标准、业务方签字。下面给出一份可直接填写的示例结构（参数为示例假设，需按实际扫描结果替换）：

完成上述梳理后，你会得到一份既有业务签字、又有技术基线的需求说明书。它将成为后续方案设计、工具选型、排期和验收的唯一依据。需求阶段多花两天，实施阶段可能省下两周。