为什么存储变更需要更严的流程
存储位于数据链路的底座，一次操作往往影响所有上层业务，而回退成本远高于普通应用：卷扩容可以扩不好，但数据布局变更、固件升级、控制器操作的错误常常无法用「重启回滚」解决。变更管理因此不是流程装饰，它逼着实施者提前回答清楚可回退性、恢复时间与观察责任，把风险摆在明面上再决定是否推进。
基本信息
| 变更要素 | 目的、影响面、回退步骤、执行窗口、验证方法、观察期、通知范围 |
|---|---|
| 风险分级 | 卷与策略调整属较低风险；重建、路径变更属中风险；固件与控制器操作属高风险 |
| 必备前置 | 配置备份已导出、冗余健康、业务方确认窗口、回滚步骤可执行 |
| 执行原则 | 同一窗口只改一个变量，完成一步验证一步 |
| 观察期 | 变更后一段时间不叠加新变更，便于把异常归因到本次动作 |
| 记录要求 | 变更前后的基线数据、实际执行步骤与偏差，全部留档 |
典型使用场景
- 扩容卷或新建卷，需要确认对既有业务的影响与验证方式时
- 调整缓存策略或预读参数，评估是否需要停业务以及如何回退时
- 更换控制器或升级固件，需要联合业务与厂商排期时
- 更换交换机或改造链路，需确认剩余路径能否独立支撑时
- 非计划变更后复盘，缺的是流程还是判断，为制度改进提供依据时
变更前后留基线
变更前后留基线
# 变更前：导出配置与状态基线
D=/var/log/change/$(date +%F-%H%M); mkdir -p $D
storcli /c0 show all > $D/array-before.txt
multipath -ll > $D/multipath-before.txt
iostat -x 1 5 > $D/iostat-before.txt
# 执行变更（单一变量，逐步验证）
# 变更后：重复采集并与基线对照
diff -u $D/array-before.txt $D/array-after.txt
# 观察窗口内持续跟踪延迟与错误，确认回到基线再关闭变更单
journalctl -k --since '30 min ago' | grep -Ei 'error|reset|path'变更类型与前置要求
| 变更类型 | 风险级别 | 前置要求 |
|---|---|---|
| 卷扩容与映射调整 | 较低 | 配置备份、业务确认、验证读写 |
| 缓存与策略调整 | 中 | 低峰窗口、性能基线、可回退原值 |
| 路径与交换机变更 | 中 | 冗余核对、逐条执行、观察期 |
| 固件与控制器操作 | 高 | 兼容核查、完整备份、厂商支持在场 |
同一窗口内叠加多项变更会让异常无法归因，也让回退变得不可能——退回去到底退哪一步都说不清。每次只改一个变量，是存储变更最便宜的风险控制手段。
变更单的完成标准不是操作执行完毕，而是验证通过并且观察期结束。把两者混为一谈，往往会让问题在下一个窗口才被当成新故障处理。