补丁管理怎么落地
补丁管理不是一句 dnf update -y 就能解决的事，它是一条流程：查可用更新与安全公告、在验证环境试装、在生产窗口期执行、留回滚点并复核。技术上依赖三个能力：dnf check-update 列可用更新、updateinfo 区分安全类更新、dnf history 提供操作级回滚依据。内网环境还要先搭离线仓库并同步补丁，否则根本看不到新版本。
基本信息
| 适用平台 | dnf 系：openEuler、银河麒麟服务器版、RHEL 8/9 |
|---|---|
| 查可用更新 | dnf check-update |
| 安全更新 | dnf updateinfo list security（需要仓库提供 updateinfo 数据） |
| 回滚依据 | dnf history / history info / history undo 事务号 |
| 内网前提 | 先建离线仓库并同步补丁，客户端才能看到新版本 |
典型使用场景
- 例行补丁窗口：按月或按季度统一更新，先安全类后功能类
- 高危漏洞响应：按厂商公告锁定受影响包，快速打补丁
- 内核更新：单独更新内核，保留旧内核以备回退
- 变更失败回滚：用 history undo 回退到上一个事务状态
- 离线内网：同步补丁到内网仓库后按批推进
查看与更新
查看与更新
dnf check-update # 列出所有可用更新
dnf updateinfo list security # 只列安全类更新
dnf list updates kernel # 看内核是否有新版本
dnf update -y --downloadonly # 只下载不安装，提前备好包
dnf update -y kernel # 单独更新内核，旧内核保留
dnf updateinfo info # 看更新内容的公告说明
rpm -q kernel | tail -3 # 确认已保留的内核版本数历史与回滚
历史与回滚
dnf history # 看操作历史与事务 ID
dnf history info <ID> # 看某次事务装了/卸了哪些包
dnf history undo <ID> # 回滚该事务（依赖旧版本包仍可获取）
dnf history rollback <ID> # 回滚到该事务之后的状态
cat /var/log/dnf.log | tail -30 # 复核本次操作的详细日志流程要素读法
| 环节 | 关键动作 | 风险点 |
|---|---|---|
| 评估 | 看 updateinfo 与厂商公告 | 只更新不评估，遗漏依赖影响 |
| 验证 | 测试环境先行试装 | 直接上生产是主要事故来源 |
| 窗口 | 定维护窗口与回滚点 | 业务高峰执行影响可用性 |
| 执行 | 分批推进并观察 | 一次性全网更新放大故障面 |
| 复核 | history 与日志核对 | 不做复核无法确认实际结果 |
| 回滚 | history undo 事务号 | 旧版本包不在仓库时回滚失败 |
内网环境要先搭离线仓库并同步补丁，客户端才能看到新版本；同步与发布的具体做法见内网软件源相关条目。
生产上直接执行 dnf update -y 而不设窗口期是常见事故来源；内核与关键库更新必须按变更流程走并保留回滚点。