网络设备升级最危险的假设，是“同型号设备可以一次性执行相同步骤”。实际环境中，同一名称下可能存在不同硬件修订、固件基线、服务器内核、线缆模块和拓扑角色。技术人员应先建立现状证据，再设计升级动作。
一、采集升级前基线。服务器侧可以使用 lspci、ethtool -i、devlink dev info、mstflint 或厂商工具记录网卡PCI地址、驱动和固件；再用 ip -br link、rdma link、ibdev2netdev 等核对接口与RDMA映射。交换机侧保存系统版本、硬件信息、启动项、配置、端口状态、邻居、路由、链路聚合和错误计数。命令会随系统版本而变化，最终以对应产品文档为准。
二、确认版本兼容链。目标清单不应只有“固件版本”，而应同时写明操作系统、内核、驱动或OFED、用户态库、交换机系统和必要的平台固件。查看官方支持列表、发布说明和已知问题，确认当前版本是否允许直接升级、是否需要中间版本、是否会改变配置语法或默认行为。若使用容器、SR-IOV、GPUDirect RDMA或网络自动化，还要把这些依赖加入测试矩阵。
三、准备可恢复条件。备份交换机配置和诊断包，保存当前安装包、目标安装包、校验值、执行脚本和带外管理信息。网卡升级前确认主机可通过其他路径管理；交换机升级前确认控制台、启动镜像和配置恢复方法。需要特别注意，部分版本或升级方式不支持直接降级，所以回退步骤必须来自对应版本文档，而不是凭经验反向执行。
四、建立灰度组。选择能代表不同服务器、端口速率、模块或线缆、交换机角色和业务类型的少量节点。先做连通性与功能检查，再做性能验证。网卡侧至少比较升级前后的吞吐、延迟、CPU占用、RDMA错误及端口计数；交换机侧检查端口协商、FEC、LACP/MLAG、VLAN、路由邻居、ECMP和遥测。AI集群还应使用固定消息规模与节点矩阵对比NCCL结果，避免只看设备“Up”。
五、按故障域分批。不要同时升级双归属链路的两端，也不要同时处理互为冗余的交换机。每批结束后设置观察期，并定义停止条件：链路抖动、错误或丢包增长、邻居异常、吞吐下降、尾延迟升高，都应暂停下一批并定位。
六、完成后审计。重新采集版本、配置和诊断信息，与升级前基线做差异比较；保留测试结果、异常处置和最终设备清单。对未升级、升级失败或版本例外的设备单独标记，避免下一次自动化把它们误当成同一基线。
一套合格的升级方案应回答四个问题：为何升级、哪些组合被支持、怎样证明业务正常、出现什么现象立即回退。这样才能把驱动和固件更新从高风险操作转化为可重复的工程流程。
