场景与流程
安全补丁流程要回答三个问题：有哪些补丁、怎么安全地打下去、出错怎么退回来。盘点依赖发行版的公告与 updateinfo 元数据；动手前必须留回滚点，LVM 快照或云盘快照都行；执行时分批，先在一台非关键机器验证再全量。内核、glibc、systemd 这类基础组件的更新要重启才完全生效，所以要提前安排重启窗口，并在重启后核对内核版本与关键服务状态。全过程留痕，才能应对等级保护与审计要求。
基本信息
| 场景 | 月度或季度安全补丁窗口，以及高危漏洞的应急修补 |
|---|---|
| 盘点手段 | RHEL 系 dnf updateinfo；Debian 系 apt list --upgradable 配合安全源 |
| 回滚点 | LVM 快照、云实例快照、包版本锁定（versionlock 或 apt-mark hold） |
| 执行策略 | 先试点后全量，分批重启，避开业务高峰 |
| 验证要点 | uname -r 确认内核、systemctl --failed 看失败单元、关键服务功能回归 |
典型使用场景
- 定期补丁窗口：按月把安全更新打齐，兼顾变更管理与审计
- 应急修补：出现高危 CVE 时先修对外服务所在的主机
- 合规检查：等保要求提供补丁清单与执行记录
- 批量运维：上百台主机统一更新并逐台验证
- 升级失败处置：用事务回滚或快照还原到更新前状态
四步流程
四步流程
dnf updateinfo list security # 1. 盘点可用的安全更新
dnf updateinfo list sec --summary | tail # 看 CVE 数量与严重级别
lvcreate -s -L 5G -n snap_root /dev/vg0/root # 2. 留回滚点
dnf upgrade --security -y --refresh # 3. 只装安全更新
dnf history | head # 记录事务号，便于回退
systemctl reboot # 4. 内核类更新后择机重启
uname -r; systemctl --failed # 重启后验证版本与失败单元更新类型与重启必要性
| 更新内容 | 是否需重启 | 说明 |
|---|---|---|
| 内核包 | 需要 | 新内核在重启后才被加载，未重启等于修补未生效 |
| glibc 与 systemd | 通常需要 | 运行中的进程仍映射旧库，重启才彻底 |
| 用户态服务包 | 视服务而定 | 一般重启该服务即可生效 |
| 文档或字体类 | 不需要 | 没有运行时影响 |
apt 侧没有等价的一条「只装安全更新」命令，通常靠安全源配合 unattended-upgrades 的策略，或依据 DSA 公告按包名与版本精确升级。
补丁前必须留回滚点，否则批量升级出问题只能逐台抢救。快照之外，重要数据仍要有独立的逻辑备份，快照会随误删一起丢失。