3. 升级可行性评估与风险矩阵

在正式动手升级之前，最忌讳的就是“先升了再说”。RHEL 的升级（尤其是跨大版本，如 RHEL 7 到 RHEL 8/9）会同时牵动内核 ABI、glibc、systemd、OpenSSL、Python 运行时等一整套底层栈，任何一个环节不匹配，都可能在升级后表现为服务起不来、驱动加载失败或合规扫描不通过。因此本章要解决的核心问题是：用一张可量化、可复核的评估表，把“能不能升、风险多大、先处理谁”讲清楚。

一、四个评估维度及其判定依据

升级可行性评估建议固定四个维度，每个维度都给出可采集的客观证据，而不是凭印象打分。

• 内核版本维度：记录当前 uname -r 与目标版本内核基线，重点看内核模块 ABI、kABI 白名单、以及是否依赖已废弃的 syscall 或 /proc 接口。RHEL 7 的 3.10 内核与 RHEL 8 的 4.18、RHEL 9 的 5.14 之间差异显著，自编译模块几乎必然需要重编。
• 应用兼容性维度：梳理业务进程依赖的运行时（Python 2/3、Java 版本、PHP、Perl）、动态库（glibc、libssl、libcrypto）以及包管理来源（官方 RPM、EPEL、自编译、容器镜像）。
• 第三方驱动维度：识别存储 HBA、网卡、GPU、加密卡等厂商驱动，确认其是否有对应目标内核的 DKMS 或 kmod 包。
• 安全合规维度：对照等保、CIS、PCI-DSS 等基线，确认目标版本是否仍受支持、OpenSSL 版本是否满足 TLS 1.3 要求、SELinux 策略是否兼容。

二、评估表字段设计

评估表建议包含以下字段，便于逐项采集与复核：评估项、当前值、目标值、差异类型、影响范围、风险等级、处置建议、责任人。其中“差异类型”用于区分是“版本落后”“接口废弃”“依赖缺失”还是“策略冲突”，这决定了后续是升级、替换还是重写。

下面给出一个可直接套用的评估表样例（数据为教学示例，非实测结果）：

三、风险等级判定与矩阵

风险等级建议用“发生概率 × 影响程度”二维判定，而不是单看某一项。概率取决于该差异在同类环境中是否常见触发；影响程度取决于该组件失效后业务是否中断、是否影响数据一致性、是否触发合规红线。据此可把风险分为四级：

• 高：升级后极可能导致业务中断或数据风险，必须升级前解决。
• 中：可能引发局部功能异常或性能下降，需在灰度阶段重点验证。
• 低：影响面小、可回退，纳入常规验证即可。
• 可接受：无实质影响，仅记录备案。

把评估项按“概率—影响”落到矩阵中，就能直观看出哪些项必须优先处理。下图给出本节的风险矩阵与评估维度关系示意：

四、从评估到处置：实际怎么做

评估表填完后，处置顺序应遵循“高风险先闭环、中风险灰度验证、低风险随版本走”。以存储 HBA 驱动为例，实际动作是：先在测试机安装目标内核，执行 modinfo 确认厂商 kmod 是否匹配，再用 dmesg | grep -i hba 观察加载日志；若厂商未提供目标内核版本，则需评估是否更换 HBA 或改用内核自带驱动。这一步不能只停留在“确认驱动可用”，而要真正跑一次 multipath -ll 和一次小文件读写，确认路径聚合与 IO 正常。

对于 Python 2 到 Python 3 的迁移，建议先用 grep -r "print " /opt/app 和 python3 -m py_compile 做静态扫描，再在测试环境跑一遍核心业务用例。若业务依赖 python2-* RPM，需确认目标仓库是否仍提供，否则要提前准备虚拟环境或容器化封装。

五、评估结论的三种走向

完成评估后，结论通常落在三类：可直接升级（无高风险项，中低风险有明确处置方案）、需先改造再升级（存在高风险项，需先完成驱动替换或应用迁移）、暂缓升级（关键组件无目标版本支持，或合规要求不允许）。无论哪种结论，评估表都应作为升级方案的一部分归档，并在升级后复盘时对照实际发生的问题，反向修正风险等级的判定标准，让下一轮评估更准。

把四个维度、评估表字段和风险矩阵固定下来，升级就不再是一次“赌运气”的操作，而是一次有依据、有优先级、可回退的工程决策。