固件维护的流程要点
固件与微码决定存储设备在底层的行为，包括错误处理、重建策略、缓存管理与性能表现。升级的价值是修缺陷与对齐兼容性，风险则来自过程控制：升级中断电、版本与盘不兼容、批量升级期间工作负载过高，都会造成严重后果。因此升级的核心不是那几条命令，而是升级前、中、后每一步的确认动作与回滚预案。
基本信息
| 维护对象 | 存储控制器、盘、扩展柜、HBA 与驱动、承载网络与交换机 |
|---|---|
| 前置动作 | 配置导出、数据备份验证、健康检查、兼容矩阵核对、窗口授权 |
| 执行原则 | 同一时间只改一个变量，组内逐台执行，完成一台验证一台 |
| 过程观察 | 阵列事件日志、路径状态、业务错误率、性能基线是否异常 |
| 完成判据 | 版本已生效、卷与路径状态正常、告警清零、性能回到基线 |
| 回滚条件 | 不是所有版本都支持降级，需在升级前确认并写好回滚步骤 |
典型使用场景
- 厂商发布修复已知缺陷的固件，需要评估是否纳入维护窗口时
- 新增盘或扩展柜与既有版本不匹配，需要统一固件版本时
- 控制器硬件更换后，需要把固件与配置对齐到团队标准时
- 定期维护计划中把固件版本与驱动版本一起盘点与对齐时
- 故障复盘发现固件缺陷是根因，需要制定修复计划时
升级前后的核对动作
升级前后的核对动作
# 升级前记录版本基线，用于事后比对是否生效
storcli /c0 show all | grep -i version
smartctl -i /dev/sdb | grep -i firmware
cat /sys/class/fc_host/host0/firmware_version 2>/dev/null
# 记录主机侧驱动与多路径版本
multipath -ll | head
modinfo lpfc 2>/dev/null | head -3
# 导出配置，形成可回滚的配置基线（见阵列配置备份条目）
storcli /c0 show all > /var/log/array/before-upgrade.txt
# 升级期间持续观察路径与错误
journalctl -k -f | grep -Ei 'error|reset|path'阶段任务与完成判据
| 阶段 | 关键动作 | 完成判据 |
|---|---|---|
| 评估 | 核对兼容矩阵与已知问题 | 版本组合获得厂商支持 |
| 准备 | 备份配置与数据、确认回滚方案 | 备份已验证可读、方案书面可用 |
| 执行 | 逐台升级，单变量推进 | 单台成功并验证后再进行下一台 |
| 验证 | 版本、路径、性能、告警四项核对 | 四项全部回到正常区间 |
| 留档 | 更新版本清单与配置基线 | 台账与实际一致 |
升级过程中断电或强制中断是高危情形，可能导致控制器进入不可用状态。必须在供电与 UPS 状态明确、环境稳定的条件下执行，并确保窗口内没有其他变更在排队。
一次只改一个变量的另一层含义是：不要在同一次窗口里既升级固件又调整卷布局或换交换机配置。否则出现异常时无法判断是哪一步引入的。