4. 迁移前期调研与评估实战

迁移项目最容易出问题的地方，往往不是切换当晚的操作，而是前期调研做得不够扎实。业务方说“随便迁，越快越好”，运维说“存储还有空间”，但真正开始规划时才发现：关键业务有严格的停机窗口、某些卷的IOPS已经接近阵列上限、容量增长曲线在三个月后会撞到阈值。本章围绕四件事展开：业务需求收集、现有存储环境盘点、性能基线采集、容量与增长趋势分析。这四项不是并列的文档工作，而是一条从“业务约束”到“技术事实”再到“量化判断”的评估链。

一、业务需求收集：先确定约束，再谈技术方案

业务需求收集的目标不是罗列应用清单，而是提取会直接影响迁移策略的硬约束。建议按应用或业务系统逐项确认以下信息：业务名称与负责人、关联主机与存储卷、允许的停机窗口（RTO/RPO）、是否有计划内的业务低峰期、迁移期间能否接受性能下降、是否存在合规或数据驻留要求、依赖关系（例如数据库与文件服务、中间件与后端存储的先后顺序）。

其中停机窗口是最关键的输入。若某业务只允许每周日02:00–04:00停机，那么在线迁移、双写或快照同步等方案的选择空间会被大幅压缩。依赖关系则决定迁移批次：被依赖的系统应先迁或同步迁，避免出现“应用已切换、后端存储仍在旧阵列”的悬空状态。

一个可直接使用的收集表可以这样设计：

二、现有存储环境盘点：把“有什么”变成“在哪里、连给谁”

环境盘点的核心是建立“阵列—卷—主机—应用”的映射关系。对HPE Alletra或同类阵列，至少应记录：阵列型号与微码版本、控制器数量与状态、端口与SAN拓扑（FC或iSCSI）、卷（LUN）清单、卷容量与已用容量、卷所属存储池/CPG、主机与卷的映射（masking/igroups）、快照与克隆策略、复制关系（Remote Copy/Peer Persistence等）。

盘点时不要只看管理界面的汇总数字，要逐卷核对。常见问题是：某些卷长期未使用但仍占用容量、某些卷映射给了已下线主机、某些卷的快照保留了数月未清理。这些“隐性占用”会直接影响迁移窗口和容量规划。

建议在盘点阶段同步输出一份卷级清单，字段包括：卷名、容量、已用、所属池、映射主机、应用、是否含快照、是否参与复制、迁移优先级。这份清单是后续性能采集和容量分析的索引。

三、性能基线采集：用数据说话，而不是凭感觉

性能基线的作用是回答两个问题：当前系统在正常业务下的性能水平是多少？迁移后如何判断“没有变差”？基线采集应覆盖至少一个完整的业务周期（通常7天，包含工作日高峰与周末低峰），采集粒度建议5分钟或更细。

关键指标包括：

• 前端IOPS与吞吐量（按卷、按主机）
• 读/写比例与随机/顺序比例
• 平均延迟与尾延迟（P95/P99）
• 队列深度与端口利用率
• 存储池利用率与控制器CPU/缓存命中率

采集方式可以组合使用：阵列自带性能监控、主机侧iostat/ESXTOP、SAN交换机端口统计。三者交叉验证，避免单一数据源偏差。例如主机侧看到延迟升高，但阵列侧延迟正常，问题可能在HBA、交换机或主机队列。

基线不是一组静态数字，而是一条随时间变化的曲线。应标注业务高峰时段、批处理窗口、备份窗口，这些时段的性能特征对迁移窗口选择至关重要。若备份窗口与迁移窗口重叠，迁移期间的性能风险会显著上升。

四、容量与增长趋势分析：预测何时会“撞墙”

容量分析不能只看“还剩多少TB”，而要看“按当前增长速度，还能撑多久”。基本方法是：取过去3–6个月的已用容量数据，计算月均增长量，再结合业务规划（如新上线系统、数据保留策略变化）做修正。

示例：某存储池当前已用80TB，总容量100TB，过去6个月从68TB增长到80TB，月均增长2TB。若不做任何干预，10个月后达到100TB。若迁移项目预计3个月后完成，且迁移期间需要额外10%的临时空间用于快照或复制，则实际可用余量更紧张。此时应优先清理无用快照、归档冷数据，或提前扩容。

增长趋势分析还要区分“线性增长”与“阶梯式增长”。数据库归档、日志滚动、新业务上线都可能造成阶梯跳变。对阶梯式增长，应结合业务排期单独评估，而不是简单套用月均值。

五、把四项调研串成一张评估图

下面这张图把业务需求、环境盘点、性能基线、容量趋势四类输入，汇聚到迁移策略与批次决策上。它强调的不是流程顺序，而是“哪些事实决定了哪些决策”。

这张图的价值在于提醒：迁移策略不是拍脑袋定的，而是由业务约束、环境事实、性能数据和容量趋势共同推导出来的。任何一项调研缺失，都会让后续的迁移方案缺少依据。

六、调研成果的落地形式

调研结束后，建议至少产出三份可直接使用的成果：第一，业务需求收集表（含停机窗口与依赖关系）；第二，卷级环境盘点清单（含映射、快照、复制状态）；第三，性能与容量基线报告（含高峰时段、增长曲线、风险提示）。这三份成果将直接支撑迁移方案设计、窗口排期和验收标准制定。

最后需要强调：调研不是一次性动作。在迁移实施前一周，应重新采集一次性能与容量数据，确认基线没有发生显著漂移。若发现某卷的IOPS或延迟在近期明显上升，应重新评估该卷的迁移窗口和方式，避免用旧数据指导新操作。