3. 迁移与升级项目前期评估
迁移与升级项目失败，绝大多数不是败在切换当晚，而是败在前期评估。前期评估的目标不是写一份漂亮的报告，而是把"我们以为的现状"变成"有数据支撑的现状"，并据此判断：哪些工作负载可以平滑迁移，哪些必须先改造，哪些必须延后甚至放弃。本节围绕四条主线展开：现状调研、容量与性能基线、兼容性矩阵、业务影响分析与风险登记。
一、现状调研：把资产和依赖关系摸清
现状调研要回答三个问题：有什么、怎么连、谁在用。建议从四个维度采集：
- 存储资产清单：阵列型号、控制器数量、固件版本、扩展柜与盘位分布、已用/可用容量、快照与克隆占用、复制关系（本地/远程）、卷与主机映射（LUN Masking）、协议类型（FC/iSCSI/NFS/SMB/NVMe-oF）。
- 主机与集群侧：操作系统与版本、多路径软件及版本、HBA/iSCSI Initiator 型号与固件、集群软件（如 Oracle RAC、SQL AlwaysOn、VMware vSphere 集群）、文件系统类型与挂载参数。
- 应用与业务归属：每个卷/共享对应哪个应用、业务负责人、SLA 等级、RTO/RPO 要求、是否有变更窗口限制。
- 依赖关系：应用之间的调用链、数据库与中间件的依赖、备份作业与复制链路，避免"迁了存储却断了备份"。
实操中，阵列侧可用 purearray list --connect、purevol list --space、purehost list --connect 等命令导出卷、主机与连接关系；主机侧用 multipath -ll、lsscsi、esxcli storage core device list 核对路径与设备。把两侧数据对齐，才能发现"阵列上有映射但主机已下线"或"主机在用但阵列无记录"的隐性风险。
二、容量与性能基线：用数据说话
容量评估不能只看"已用容量"。要区分逻辑已用、物理已用、精简回收后可用、快照/克隆占用、预留（Reserve），并预留迁移期间的临时双写空间。经验上，迁移窗口内目标端至少保留源端已用容量的 1.2～1.3 倍余量，用于临时副本、回滚快照和突发增长。
性能基线要在业务高峰采集，而不是空闲时段。关键指标包括：IOPS（读/写分开）、带宽（MB/s）、平均与 P99 时延、队列深度、读写比例、随机/顺序比例、块大小分布。采集周期建议覆盖至少一个完整业务周期（如月末结账、季度报表）。
下面这张图展示了前期评估中四条主线的输入、处理与输出关系，以及它们如何汇聚成迁移决策：
三、兼容性矩阵：逐项核对，不留"应该可以"
兼容性核对要落到具体版本号，而不是"支持"两个字。建议按以下顺序逐项确认：
| 核对项 | 源端现状（示例） | 目标端要求（示例） | 结论 |
|---|---|---|---|
| 操作系统 | RHEL 7.9 | RHEL 8.6+ 或 7.9 补丁级 | 需升级或打补丁 |
| 多路径软件 | DM-Multipath 0.4.9 | 0.4.9-135 及以上 | 需升级 |
| HBA 固件 | QLogic 8.07 | 8.08+ | 需升级 |
| 协议 | FC 16Gb | FC 32Gb / NVMe-oF | 可沿用或升级 |
| 复制 | ActiveCluster 旧版本 | Purity 6.x 对应版本 | 需确认互通 |
表中数据为教学示例，实际项目必须以厂商兼容性列表（如 Pure Storage 的 Interoperability Matrix）和现场采集结果为准。任何一项"待确认"都应登记为风险，而不是默认通过。
四、业务影响分析与风险登记
业务影响分析的核心是把技术动作翻译成业务语言：这次迁移会导致哪些应用中断、中断多久、能否降级运行、最坏情况损失是什么。建议按应用分级：
- A 级（核心交易）：RTO ≤ 15 分钟，RPO ≈ 0，必须双活或在线迁移，窗口需业务方书面确认。
- B 级（重要支撑）：RTO ≤ 2 小时，可接受短时停机，安排在业务低峰。
- C 级（一般系统）：RTO ≤ 24 小时，可批量迁移，允许较长窗口。
风险登记表应至少包含：风险描述、影响范围、发生概率、影响程度、风险等级、缓解措施、责任人、复查时间。例如"目标端固件与多路径版本不匹配导致路径抖动"属于高概率中影响，缓解措施是迁移前完成固件升级并做路径切换演练。
前期评估做得越扎实，切换当晚的意外就越少。现状调研解决"迁什么"，容量与性能基线解决"迁得动吗"，兼容性矩阵解决"能不能迁"，业务影响与风险登记解决"什么时候迁、出问题怎么办"。四者缺一，项目就会在某个环节被迫返工。