1. 课程导入与全景认知
在企业数据中心里，服务器硬件的生命周期管理从来不是“买来用到坏”这么简单。固件漏洞需要修补、性能瓶颈需要突破、老旧机型需要退场、新业务需要上线——这些诉求最终都会落到同一个动作上：在业务不中断的前提下，把运行中的ThinkSystem服务器升级到新的固件、驱动或操作系统版本，并把承载的业务平滑迁移到新的硬件平台。这就是本课程要系统讲解的“滚动升级与业务迁移”。
所谓滚动升级（Rolling Upgrade），指的是在集群或业务池中，以“分批、逐台或逐组”的方式对节点进行升级，任何时刻都只让一部分节点处于维护状态，其余节点继续对外提供服务。与之相对的是“停机升级”——一次性关闭全部节点统一升级，简单但会造成业务中断。而业务迁移（Workload Migration）则更进一步：不仅升级软件，还要把工作负载从旧平台搬到新平台，例如从SR650迁移到SR650 V3，或从VMware集群迁移到新的虚拟化平台。两者常常组合出现：先迁移业务腾空节点，再对节点做滚动升级，最后把业务迁回或迁到新硬件。
为什么这件事值得单独开一门30章的课程？因为滚动升级与业务迁移是典型的“跨层协作”任务，它同时牵涉硬件层（BMC/XCC、固件、RAID卡、网卡）、系统层（操作系统、驱动、内核）、虚拟化层（Hypervisor、vMotion、集群HA）、应用层（数据库、中间件、负载均衡）以及运维流程层（变更窗口、回滚预案、验证清单）。任何一层考虑不周，都可能导致升级卡死、业务抖动甚至数据丢失。下面这张全景图，把本课程涉及的关键对象、层次与数据/控制流关系做了整体呈现。
从全景图可以看到，滚动升级与业务迁移不是单一操作，而是一条从“评估—设计—迁移—升级—验证”的完整链路，并且始终有“保障要素”贯穿其中。理解这条链路，是后续29章展开具体技术细节的基础。
典型场景：什么时候需要滚动升级与业务迁移
在实际项目中，触发这类任务的原因通常有以下几类，它们对方案设计的要求各不相同：
- 安全与合规驱动：XCC、BIOS 或网卡固件曝出高危漏洞，必须在限定时间内完成修补，但业务不能停。此时升级范围明确、时间紧迫，方案重点在于“快速分批 + 充分验证”。
- 硬件更新换代：老旧的 SR650 逐步被 SR650 V3 替换，需要把虚拟机或裸机业务从旧机迁到新机。此时重点是迁移路径、驱动兼容性和性能基线对比。
- 平台版本升级：操作系统从 RHEL 8 升到 RHEL 9，或虚拟化平台大版本升级，需要逐节点滚动，避免集群整体不可用。
- 容量与性能优化：业务增长导致现有节点资源紧张，需要边扩容边迁移，把负载重新均衡到新老混合的节点池中。
这些场景的共同点是：业务连续性优先级高于升级速度。因此，方案设计时宁可多分几批、每批少动几台，也不要为了赶时间一次性操作过多节点。
课程目标与学习路径
本课程的目标不是让你记住某个按钮在哪，而是让你具备独立设计并执行一次滚动升级与业务迁移的能力。具体来说，学完课程后你应该能够：
- 准确描述 ThinkSystem 服务器固件、驱动、操作系统与虚拟化平台之间的版本依赖关系；
- 根据业务SLA和变更窗口，设计合理的分批滚动策略与迁移路径；
- 使用 XCC、Lenovo XClarity Administrator、厂商工具链完成固件与驱动的批量升级；
- 在 VMware、KVM 等虚拟化环境中执行虚拟机迁移与集群滚动维护；
- 制定回滚预案，并在升级异常时快速判断是继续、暂停还是回退；
- 通过监控指标、日志和基线对比，验证升级与迁移后的系统健康状态。
课程的学习路径遵循“先认知、再工具、后实战”的节奏：前几章建立全景认知与版本管理基础；中间章节深入 XCC、XClarity、固件升级、驱动兼容性等具体工具与操作；随后进入虚拟化迁移、数据库迁移、存储迁移等业务场景；最后通过综合案例与排障复盘，把零散知识串成可复用的方法论。
需要特别提醒的是，滚动升级与业务迁移的成败，往往不取决于最复杂的那个技术点，而取决于最容易被忽略的细节：比如固件升级前是否确认了电源冗余、迁移前是否检查了目标节点的 CPU 兼容性、升级后是否验证了多路径链路状态。本课程会在每个关键环节给出可执行的检查项和判断依据，帮助你把“知道”变成“做到”。
接下来，我们将从 ThinkSystem 的硬件与固件体系开始，逐步建立完整的知识框架。请先记住全景图中的五个环节和贯穿全程的保障要素——它们会在后续每一章中反复出现，成为你设计和执行升级迁移任务时的基本坐标。