3. 滚动升级与业务迁移的核心原则
滚动升级与业务迁移不是“把节点逐个重启”这么简单。它本质上是在一个持续对外提供服务的集群里，同时完成三件事：替换底层软硬件、迁移上层业务负载、并保证任何时刻都有足够的服务能力。要做到这一点，必须用一组明确的原则来约束每一步操作。本节围绕最小化停机、可回滚、灰度验证、依赖排序、变更窗口、风险控制与回退策略七个核心原则展开，说明它们各自解决什么问题、在实际操作中如何落地，以及它们之间如何相互配合。
一、最小化停机：把“不可用”压缩到可接受范围
最小化停机的目标不是“零停机”，而是让业务感知到的不可用时间不超过既定阈值。在 HPE ProLiant 集群中，停机通常来自三类动作：节点重启、固件/驱动更新、以及业务负载迁移。滚动升级的基本做法是同一时刻只处理一个故障域（例如一个节点或一对冗余节点），其余节点继续承载业务。
实际落地时，需要先确认冗余是否真实有效。例如某双机热备业务，若备机尚未完成数据同步，直接重启主机就会造成业务中断。因此操作前应检查：集群仲裁是否健康、副本是否同步、负载均衡是否已摘除待升级节点。以一台 ProLiant DL380 为例，升级 iLO 固件通常需要重启管理处理器，此时业务不受影响；但升级 BIOS 或阵列控制器固件需要重启主机，就必须先把该节点上的虚拟机迁移走或从负载均衡池中摘除。
二、可回滚：每一步都要有退路
可回滚原则要求：任何一次变更在实施前，都必须明确“如果失败，如何回到变更前的状态”。这包括固件版本回退、驱动回退、配置回退和业务回切。HPE 的 Smart Update Manager（SUM）和 iLO 都支持固件版本回退，但并非所有组件都支持任意版本回退，因此升级前必须记录当前版本基线。
一个可执行的做法是：在升级前导出当前节点的一键配置（如 iLO 的 One Button Backup）、记录固件清单、保存阵列配置和网络配置。对于业务迁移，回滚意味着业务能够从新节点切回旧节点。若旧节点在升级后已被改写，回切就不可行，因此滚动升级通常保留至少一个未升级节点作为回退目标，直到新版本验证通过。
三、灰度验证：先小范围，再全量
灰度验证的核心是“先在一小部分节点上验证新版本，确认无异常后再扩大范围”。在 ProLiant 集群中，灰度单元可以是一个节点、一个机箱或一个可用区。灰度阶段要观察的指标包括：业务响应时间、错误率、CPU/内存/存储 IO 是否异常、集群心跳是否稳定、驱动与固件是否匹配。
例如，先升级一台节点并让其承载 10% 的业务流量，观察 30 分钟。若错误率、延迟和资源使用均在基线范围内，再升级下一台。若出现异常，立即停止后续升级并回滚该节点。灰度验证的价值在于把故障影响面限制在最小范围，同时为后续全量升级提供真实数据支撑。
四、依赖排序：先底层，后上层
滚动升级涉及多个层次：固件、驱动、操作系统、集群软件、业务应用。它们之间存在明确的依赖关系。通常的顺序是：先升级 iLO 和 BIOS，再升级阵列控制器和网卡固件，然后升级驱动，最后升级操作系统补丁和业务应用。若顺序颠倒，可能出现驱动与固件不匹配、操作系统无法识别新硬件等问题。
业务迁移同样有依赖排序。例如，先迁移无状态服务，再迁移有状态服务；先迁移只读副本，再迁移主库；先迁移低依赖服务，再迁移核心服务。依赖排序的目的是避免“上游未就绪、下游已切换”造成的连锁故障。
五、变更窗口：在业务低峰期完成高风险动作
变更窗口是指允许执行高风险操作的时间段。它的选择依据是业务流量曲线，而不是“方便工程师操作的时间”。通常应选择业务低峰期，并预留足够的缓冲时间。例如，若业务低峰期为凌晨 1:00 至 5:00，而单节点升级加验证需要 40 分钟，那么一个 4 小时窗口最多可安全处理 4 至 5 个节点，剩余时间用于异常处理和回退。
变更窗口还需要明确“窗口内必须完成什么、窗口外不允许做什么”。例如，窗口内只允许执行已审批的升级步骤，不允许临时增加新变更；窗口结束前 30 分钟必须停止新节点升级，转入观察和收尾。这样做的目的是避免“做到一半窗口结束”导致集群处于中间状态。
六、风险控制：识别、量化、监控、熔断
风险控制不是一句口号，而是一组可执行的动作。首先识别风险：固件不兼容、驱动缺失、集群脑裂、业务迁移后性能下降、回退失败等。然后量化风险：每个风险的发生概率和影响范围。接着设置监控指标和熔断条件。例如，若升级后节点错误率超过基线 2 倍，或业务延迟超过 200ms，则自动暂停后续升级并触发回退。
在 ProLiant 环境中，可利用 iLO 的远程控制台和健康监控、OneView 的固件合规性检查、以及操作系统层的性能计数器来构建监控。熔断条件应提前写入操作手册，而不是在故障发生时临时决定。
七、回退策略：明确触发条件、执行步骤和验证方法
回退策略必须与升级策略成对出现。一个完整的回退策略包含三部分：触发条件、执行步骤、验证方法。触发条件例如“新版本节点在 15 分钟内出现两次心跳丢失”或“业务错误率持续 5 分钟高于阈值”。执行步骤例如“将该节点从集群中摘除，恢复旧固件版本，重新加入集群”。验证方法例如“确认节点重新同步完成，业务流量恢复，错误率回到基线”。
需要特别注意的是，回退本身也可能失败。因此回退策略中应包含“回退失败后的降级方案”，例如将业务集中到未升级节点、限制新功能、或进入只读模式，以保障核心业务可用。
核心原则的协同关系：最小化停机决定操作粒度，可回滚决定安全边界，灰度验证决定推进节奏，依赖排序决定操作顺序，变更窗口决定时间约束，风险控制决定监控与熔断，回退策略决定失败后的恢复路径。七者缺一不可，任何一项缺失都会让滚动升级从“可控变更”变成“高风险赌博”。
在实际项目中，建议把这七项原则转化为一份可执行的操作检查表：每个节点升级前确认冗余和回退路径，升级中监控关键指标，升级后验证业务和集群状态。只有把原则落到具体动作和判断依据上，滚动升级与业务迁移才能真正做到“升级不中断、故障可回退、风险可控制”。