1. 课程导入与迁移全景

在企业的数据中心里，RHEL（Red Hat Enterprise Linux）旧系统往往承载着最核心的业务：数据库、中间件、文件服务、批处理调度、监控代理，甚至一些已经无人敢动的“祖传脚本”。这些系统可能仍运行在 RHEL 5、RHEL 6 或 RHEL 7 上，而 Red Hat 早已结束或即将结束其标准支持周期。升级与迁移不是一次简单的 yum update，而是一项涉及操作系统、应用依赖、数据一致性、停机窗口和回滚预案的系统工程。

本课程围绕“RHEL旧系统升级与业务迁移”展开，共 30 章。第 1 章不急于敲命令，而是先建立一张全景图：你要面对什么、有哪些典型场景、应该按什么路径学习、手头有哪些工具可用。只有先看清全局，后续的每一步操作才不会变成盲人摸象。

一、核心挑战：为什么旧系统升级比新装更复杂

新装一台 RHEL 9 服务器，你只需要一张 ISO、一个 Kickstart 文件和半小时。但升级一台跑了八年的旧系统，挑战来自多个层面。

第一，软件包依赖的“暗礁”。RHEL 6 到 RHEL 7 之间，Python 从 2.6 升到 2.7，systemd 取代了 SysVinit，网络接口命名从 eth0 变为 ens192。一个依赖 /etc/init.d/ 启动脚本的旧应用，在 systemd 环境下可能根本无法拉起。更隐蔽的是，某些第三方 RPM 包在旧版本中依赖特定版本的 openssl，而新系统的 openssl 已经升级到 3.x，ABI 不兼容会导致程序启动即崩溃。

第二，内核与硬件的兼容性。旧系统可能运行在物理机上，使用老旧的 RAID 卡驱动或网卡驱动。RHEL 8/9 默认移除了大量旧驱动，升级后可能直接找不到根分区。这类问题必须在升级前通过 lspci、lsmod 和 Red Hat 硬件兼容性列表逐一核对。

第三，业务连续性的压力。生产环境不允许“先升了再说”。你需要评估停机窗口：数据库能否接受 30 分钟不可用？文件服务能否切换到备用节点？如果升级失败，回滚需要多长时间？这些问题的答案决定了你选择原地升级（in-place upgrade）还是迁移到新主机（migration）。

第四，配置漂移与文档缺失。旧系统经过多年手工调整，/etc/fstab、/etc/sysctl.conf、防火墙规则、SELinux 布尔值、cron 任务、SSH 密钥、证书文件，很多都没有记录。升级前必须做一次完整的配置盘点，否则新系统上线后会出现“功能都正常，就是某个业务跑不起来”的尴尬。

二、典型场景：你大概率会遇到哪一种

根据业务形态和停机容忍度，RHEL 旧系统升级与迁移通常落在以下四类场景中。

场景 A：原地升级（In-Place Upgrade）。使用 leapp 工具在现有主机上将 RHEL 7 升级到 RHEL 8，或 RHEL 8 升级到 RHEL 9。优点是保留原有主机名、IP、磁盘布局和大部分配置；缺点是升级过程中系统不可用，且一旦失败回滚复杂。适合停机窗口充足、应用与系统耦合较深的场景。

场景 B：迁移到新主机（Rehost）。在新硬件或虚拟机上安装 RHEL 9，然后迁移应用和数据。优点是干净、可控、可并行运行；缺点是需要重新配置环境，且数据同步需要额外工具。适合有备用硬件、应用可分离部署的场景。

场景 C：容器化改造。将旧应用打包为容器镜像，运行在 RHEL 9 的 Podman 或 OpenShift 上。这不仅是系统升级，更是架构转型。适合微服务化程度较高、团队具备容器能力的场景。

场景 D：混合迁移。部分组件原地升级，部分组件迁移到新主机，部分组件容器化。这是大型企业最常见的现实选择，也是最考验规划能力的场景。

三、学习路径：从评估到切换的六个阶段

本课程后续章节将按照一条可落地的路径展开，你可以把它理解为一次迁移项目的生命周期。

阶段一：资产盘点与评估。收集所有旧系统的硬件配置、OS 版本、内核参数、已安装 RPM 列表、运行服务、开放端口、定时任务、用户与权限、磁盘布局、网络配置。使用 rpm -qa、systemctl list-units、ss -tlnp、crontab -l 等命令生成基线报告。同时用 leapp preupgrade 做一次预升级检查，它会明确告诉你哪些包会阻止升级、哪些配置需要人工干预。

阶段二：目标环境设计。确定新系统的版本（RHEL 8 还是 RHEL 9）、分区方案、文件系统（XFS 还是 ext4）、网络模式（NetworkManager 还是 network-scripts）、SELinux 策略、防火墙后端（firewalld 还是 nftables）。如果选择迁移到新主机，还要规划新主机的资源规格和存储映射。

阶段三：迁移方案制定。根据业务优先级和停机容忍度，为每个业务系统选择原地升级、迁移新主机或容器化。制定详细的切换步骤、验证清单和回滚预案。回滚预案必须包含：回滚触发条件、回滚操作步骤、回滚所需时间、数据回滚策略。

阶段四：测试环境验证。在测试环境中完整执行一遍迁移流程。重点验证：应用能否正常启动、数据库连接是否正常、文件权限是否正确、SELinux 是否阻止了合法访问、防火墙规则是否放行必要端口、监控代理是否上报数据。记录所有异常和解决方式。

阶段五：生产切换。在停机窗口内执行迁移。对于原地升级，先做系统快照或备份，然后运行 leapp upgrade，重启后验证。对于迁移新主机，先同步数据，再切换 DNS 或负载均衡，最后停旧系统。切换过程中保持与业务方的实时沟通。

阶段六：上线后观察与优化。切换完成后，持续观察系统日志、应用日志、性能指标和业务指标。确认无异常后，清理旧系统资源，更新文档，并将本次迁移的经验固化到 Ansible Playbook 或内部知识库中。

四、工具链概览：你手头有哪些武器

RHEL 升级与迁移不是靠一个工具打天下，而是一组工具协同。以下是最常用的几类。

本章没有要求你立刻动手升级任何系统。它的价值在于帮你建立判断力：当你面对一台 RHEL 6 数据库服务器时，你能快速判断它适合原地升级还是迁移新主机；当你看到 leapp preupgrade 报告时，你能理解每一类抑制项背后的风险；当你制定迁移计划时，你知道哪些工具可以组合使用，哪些环节必须人工确认。接下来的章节将逐一深入这些主题，从资产盘点开始，逐步走到生产切换和上线观察。