更新历史为什么值得看
补丁是否装过、什么时候装的、装的哪个版本，这几个问题只能靠历史记录回答。它既是合规审计的证据，也是「某天变更之后开始出问题」这类故障的定位线索：把现象出现时间与更新历史对齐，多数情况下能直接锁定可疑变更。
基本信息
| 适用平台 | Linux（RHEL 系 yum/dnf history，Debian 系 dpkg 日志） |
|---|---|
| 记录位置 | /var/log/dpkg.log、dnf 历史数据库 |
| 典型用途 | 补丁审计、变更定位、回滚依据 |
| 基线 | 更新有记录且可查询 |
典型使用场景
- 月度补丁报告：统计安全更新安装次数与时间，形成可举证记录
- 故障定位：把问题出现时间与更新历史对齐，缩小排查范围
- 变更复盘：确认某次升级是否真的执行成功
- 合规检查：说明补丁管理处于受控状态，有记录可追溯
RHEL 系查法
RHEL 系查法
# 查看最近的更新事务列表
yum history list | head -20
# 查看某次事务的详细内容
yum history info <ID>
# 注意：history undo 会连带依赖变更，非必要不使用
yum history undo <ID>Debian 系查法
Debian 系查法
# 查看安装与升级记录
grep -E ' (install|upgrade) ' /var/log/dpkg.log | tail -20
# 压缩归档中的记录
tar -tf /var/log/dpkg.log.1.gz >/dev/null 2>&1 || ls -l /var/log/dpkg.log*
zgrep -h 'install ' /var/log/dpkg.log.*.gz 2>/dev/null | tail -5记录对象读法
| 记录来源 | 内容 | 局限 |
|---|---|---|
| yum/dnf history | 事务 ID、操作人、包与版本 | 本地库被重建或迁移后可能丢失 |
| dpkg.log | 安装、升级、删除动作 | 按日轮转压缩，久远记录需解压查看 |
| 日志轮转策略 | 决定可回溯时长 | 轮转过快会导致记录不足半年 |
| 集中日志平台 | 跨主机的统一记录 | 需提前配置采集，事后无法补录 |
其他常见记录位置
其他常见记录位置
# Debian/Ubuntu 的事务历史，比 dpkg.log 更易读
less /var/log/apt/history.log
# 自动更新任务的执行结果
ls /var/log/unattended-upgrades/ 2>/dev/null | tail -3
# 从包视角看最近安装或升级时间（RHEL 系）
rpm -qa --last | head -15
# dnf 环境用 dnf history，子命令与 yum history 一致
dnf history list | head -10月度报告可直接从历史里统计安全更新的安装次数与时间：比口头说明「已经修复了」有说服力得多，也方便抽查遗漏机器。
history undo 不是万能后悔药：跨内核或涉及依赖变更时可能失败或造成环境不一致，回滚前先评估并准备好备份。
把历史记录纳入月度报告：统计安全更新的安装次数、涉及主机与时间，顺带对比未覆盖的主机清单，比逐台口头确认更省人力。
同一台机器上往往并存多份记录：包管理事务历史说明装了什么，自动更新日志说明有没有自动执行，两者对不上通常意味着某条更新通道没在正常工作。