4. 升级与迁移前的资产与依赖梳理

滚动升级与业务迁移最怕的不是技术难度，而是“不知道有什么、不知道谁依赖谁”。在动第一台服务器之前，必须把资产、依赖、版本、兼容性和风险这五件事梳理清楚。本节围绕这五项交付物，说明实际怎么做、做到什么程度才算可用。

一、CMDB核对：从“台账”到“可执行清单”

CMDB（配置管理数据库）通常记录了服务器、存储、网络设备、虚拟化平台和业务系统的配置项（CI）及其关系。但直接拿CMDB当升级依据往往不可靠，常见问题包括：已下线设备未清理、IP与主机名不一致、固件版本字段长期未更新、业务归属缺失。因此第一步是核对，而不是照抄。

核对建议采用“三源比对”方法：以CMDB为基准，与带外管理平台（如iDRAC/OneView）的实机清单、监控系统（如Zabbix/Prometheus）的在管对象做交叉验证。对每台目标设备，至少确认以下字段：

• 唯一标识：服务标签（Service Tag）或序列号，避免仅靠主机名匹配；
• 硬件型号与关键部件：如PowerEdge R750、PERC H755阵列卡、网卡型号；
• 当前固件/BIOS/iDRAC版本；
• 操作系统与版本；
• 承载业务与负责人；
• 是否在维保期内、是否允许停机。

核对结果应形成一份“升级目标清单”，对差异项标注处理方式：以实机为准修正CMDB，或暂缓该设备。示例：某台R740在CMDB中记录BIOS为2.15.1，实机iDRAC显示为2.12.2，则该设备必须先纳入固件补齐批次，不能直接进入OS升级流程。

二、业务拓扑映射：把依赖关系画出来

资产清单只回答“有什么”，拓扑映射回答“谁连着谁、谁先谁后”。升级顺序一旦违反依赖关系，就会出现应用连不上数据库、负载均衡指向已停机节点等问题。拓扑映射应至少覆盖三层：

• 接入层：负载均衡、DNS、防火墙策略、VIP归属；
• 应用层：Web/中间件集群、会话保持方式、服务注册与发现；
• 数据层：数据库主从、共享存储、复制链路、备份任务。

映射时重点标注“强依赖”和“可并行”两类关系。强依赖决定升级的先后顺序，例如数据库从库必须先于主库切换验证；可并行关系决定能否批量操作，例如同集群内无状态Web节点可分批滚动。下图给出一个典型三层业务在滚动升级中的依赖与批次关系示意。

三、版本矩阵：明确“从哪到哪”

版本矩阵回答的是“每类设备当前是什么版本、目标是什么版本”。它不是简单罗列，而要区分“当前版本—目标版本—升级路径”。以PowerEdge为例，BIOS、iDRAC、PERC、网卡固件往往需要按特定顺序升级，某些版本之间不能跨版本直跳。示例矩阵如下：

版本矩阵的价值在于提前暴露“不能直跳”的路径，避免现场才发现需要多轮升级。矩阵中的每一行都应能对应到具体设备清单，做到“设备—部件—版本”三者可追溯。

四、兼容性矩阵：确认“能不能一起用”

兼容性矩阵关注的是升级后各组件之间是否仍能协同工作，重点包括：操作系统与固件版本、虚拟化平台与硬件、驱动与内核、备份软件与OS版本。例如，将ESXi从7.0 U3升级到8.0时，必须确认服务器型号在VMware兼容性列表（HCL）中、阵列卡驱动版本满足要求、备份代理支持新版本。

实际编制时，建议以“目标版本”为行、“依赖组件”为列，逐格标注“支持/不支持/需补丁”。对不支持的组合，要么调整目标版本，要么列入风险登记表并制定缓解措施。兼容性矩阵不需要覆盖所有组合，但必须覆盖本次升级涉及的全部关键组件。

五、风险登记表：把不确定性变成可跟踪项

风险登记表是前四项梳理的“收口”。每条风险应包含：风险描述、影响范围、发生可能性、影响程度、缓解措施、责任人、触发条件。示例：

五项交付物之间存在明确的先后与支撑关系：CMDB核对产出设备清单，拓扑映射产出依赖与批次，版本矩阵和兼容性矩阵产出升级路径与约束，风险登记表汇总所有不确定项并给出应对。只有这五项都达到“可执行”程度，滚动升级与业务迁移才具备开工条件。