Ubuntu 系统系列 | 第 14 天（重访·第二季）：系统更新与升级管理——生产环境升级策略

第 14/30 天（重访·第二季）

引言

在第一季的第 14 天，我们学会了 apt update && apt upgrade 的基础操作、do-release-upgrade 的大版本升级命令，以及用 unattended-upgrades 自动安装安全补丁。但真实的生产环境里，事情远没有「敲一条命令」那么简单——为什么有些服务器宁可带着已知漏洞运行几个月也不升级？为什么每次 do-release-upgrade 都像一场赌博？内核漏洞到底怎么在不重启的情况下修补？升级升挂了，怎么把系统拉回升级前的状态？

本篇文章是第二季的重访，我们把视角从「学会命令」切换到「构建生产环境的升级管理体系」：把更新分级分类、用 Ubuntu Pro / ESM 应对 EOL 后的安全补丁、把 do-release-upgrade 从「随缘操作」变成「有检查、有备份、有回滚预案的标准化流程」、用 Canonical Livepatch 实现内核热补丁、最后构建一套可回滚的升级方案。如果你已经在用 apt 和 do-release-upgrade，本文会告诉你如何让每次升级「有把握、可回滚、不停机」。

一、更新 ≠ 升级：先给变更分级

生产环境最大的误区是把所有 apt 变更混为一谈。不同变更的风险和操作窗口完全不同，先分级再动手：

# 只看安全更新（不升级功能），列出待处理的安全补丁
sudo apt update
sudo apt list --upgradable | grep -i security

# 模拟升级，先看会发生什么，绝不盲目 upgrade
sudo apt upgrade --simulate

# 输出示例（节选）
# Reading package lists... Done
# Building dependency tree... Done
# The following packages will be upgraded:
#   libssl3 openssl ca-certificates curl
# 4 upgraded, 0 newly installed, 0 to remove, 0 not upgraded

铁律：生产服务器上，apt upgrade 和 do-release-upgrade 之前必须先跑 --simulate / --dry-run 看清楚变更清单，并在变更窗口内执行，绝不在业务高峰期「顺手升级」。

二、apt 安全补丁策略：unattended-upgrades 与 Ubuntu Pro

2.1 unattended-upgrades：让安全补丁「自动且克制」

安全补丁应该在漏洞披露后尽快应用，但生产环境又不希望每次升级都人工介入。unattended-upgrades 的定位是：只自动装安全补丁，不自动做功能升级。

# 安装
sudo apt install -y unattended-upgrades apt-listchanges

# 配置：仅启用安全更新来源（默认已配置）
sudo dpkg-reconfigure --priority=low unattended-upgrades

# 查看实际生效的配置
cat /etc/apt/apt.conf.d/50unattended-upgrades | grep -E 'Allowed-Origins|Automatic-Reboot' | head -20

关键配置项（编辑 /etc/apt/apt.conf.d/50unattended-upgrades）：

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    // 不要放开 -updates / -proposed，避免功能更新混入自动安装
};

// 自动删除不再需要的依赖
Unattended-Upgrade::Remove-Unused-Dependencies "true";

// 内核安全更新后自动重启（可选，夜间维护窗口可开）
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";

验证与日志：

# 手动触发一次（模拟自动流程，输出所有动作）
sudo unattended-upgrades --dry-run --debug

# 日志位置
sudo tail -30 /var/log/unattended-upgrades/unattended-upgrades.log

2.2 Ubuntu Pro 与 ESM：EOL 后的「最后一道防线」

标准版 Ubuntu LTS 只提供 5 年免费安全更新。到第 6 年起，普通用户会收到「系统已结束标准支持」的提示。此时有两条路：

# 查看当前系统支持状态
sudo pro status

# 输出示例（节选）
# SERVICE       ENTITLED   STATUS    DESCRIPTION
# esm-infra     yes        enabled   Expanded Security Maintenance for Infrastructure
# livepatch     yes        enabled   Canonical Livepatch service
# ua-infra      yes        enabled   Common Criteria EAL2 provisioning

# 个人使用可免费订阅 Ubuntu Pro（最多 5 台机器）
sudo pro attach <free-token>

# ESM 让安全更新延长到 10 年（24.04 LTS 为 12 年）
# 启用后即可继续 apt upgrade 拿到安全补丁

实践要点：不要等到 EOL 才想办法。在标准支持期的最后一年就开始规划 ESM 订阅或计划迁移到新 LTS；pro status 应纳入季度巡检清单。

三、do-release-upgrade：从「随缘」到「标准化流程」

大版本升级（如 22.04 → 24.04）是风险最高的操作。标准流程应该是「检查 → 备份 → 升级 → 验证 → 回滚预案」五步，而不是直接 do-release-upgrade -d。

3.1 升级前检查（半小时内完成）

# 1. 确认当前版本与升级通道
lsb_release -a
do-release-upgrade -c   # 检查是否有可用的新版本

# 2. 确认没有未完成的 dpkg 操作
sudo dpkg --audit
sudo dpkg --configure -a

# 3. 检查磁盘空间（升级需要 5-10GB 可用）
df -h /

# 4. 检查第三方源兼容性（PPA 在升级后常失效）
grep -rh '^deb ' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

3.2 升级前备份：可回滚的底气

# 方案 A：LVM 快照（若根分区在 LVM 上，秒级完成）
sudo lvcreate -L 20G -s -n root-snap /dev/vg00/root

# 方案 B：etc 配置全量备份
sudo tar czf /root/etc-backup-$(date +%F).tar.gz /etc

# 方案 C：dpkg 包列表快照（用于升级后对比包版本）
dpkg --get-selections > /root/pkg-selections-$(date +%F).txt

3.3 执行升级

# 正式升级（不要加 -d，-d 是开发版通道）
sudo do-release-upgrade

升级过程会多次询问（是否重启服务、是否删除废弃包等），建议在 screen/tmux 会话中执行，避免 SSH 断开导致升级中断：

tmux new -s upgrade
sudo do-release-upgrade
# 中途断开可重新附着：tmux attach -t upgrade

3.4 升级后验证

# 版本确认
lsb_release -a

# 包一致性检查（对比升级前的清单）
diff <(dpkg --get-selections | sort) /root/pkg-selections-$(date +%F).txt | head -20

# 核心服务健康检查
systemctl --failed --no-pager
sudo apt-get check

四、内核 Livepatch：安全补丁「不重启」的黑科技

内核 CVE（尤其本地提权类）需要重启才能生效，但生产服务器重启窗口难求。Canonical Livepatch（基于 Kernel Live Patching）可以把内核补丁热加载进运行中的内核，零重启修复高危漏洞。

# 启用（Ubuntu Pro 免费订阅即可）
sudo pro enable livepatch
sudo canonical-livepatch status

# 输出示例
# last check: 5 minutes ago
# kernel: 6.8.0-51-generic
# livepatch: 6.8.0-51-generic.27
#     state: ✓ active
#     version: 117.1

# 查看当前已应用的热补丁
sudo canonical-livepatch status --verbose | grep -E 'state|version'

# 手动触发一次检查
sudo canonical-livepatch refresh

要点：Livepatch 只覆盖「已发布的内核安全修复」——日常 kernel 升级仍可通过 apt upgrade 安装，在下一个自然重启时生效；Livepatch 保证的是「在无法重启的窗口期，安全洞不是敞开的」。

五、升级回滚方案：让「升挂了」可逆

没有任何升级是 100% 安全的，所以回滚能力必须前置。按从轻到重排序：

5.1 回滚单个包（轻度异常）

# 查询包的历史版本（snapshots 源）
apt-cache madison nginx

# 降级到指定版本
sudo apt install nginx=1.18.0-0ubuntu1.4 --allow-downgrades

# 或者更保险：从 Ubuntu 官方快照仓库取历史版本
# https://snapshot.ubuntu.com/ubuntu/

5.2 LVM 快照回滚（重度异常，内核级回到过去）

# 若升级前做了 LVM 快照，升级后出问题可直接回滚
# 方法：挂载快照 → 替换根 → 重启
sudo umount /dev/vg00/root-snap 2>/dev/null || true
sudo mkdir /mnt/rollback
sudo mount /dev/vg00/root-snap /mnt/rollback
# 之后 rsync 回根分区并重启（细节依赖具体引导方式，务必在升级前写好回滚手册）

5.3 兜底：Live Server 重装 + 配置恢复

真到不可恢复的地步，配合 day-13 的备份体系（restic + etc 备份 + pkg-selections），可以「重装同版本系统 + 恢复配置 + 重建服务」在 2 小时内恢复业务。这就是为什么 day-13 的备份体系是 day-14 升级的底气。

# 重装后快速恢复软件清单
sudo apt update
sudo dpkg --set-selections < /root/pkg-selections-*.txt
sudo apt dselect-upgrade

总结与下期预告

生产环境的升级管理不是「敢不敢升级」，而是「变更可控、补丁及时、回滚有路」：先给变更分级（P0 安全补丁即时、P2 功能升级规划窗口），用 unattended-upgrades 让安全补丁自动且克制、用 Ubuntu Pro / ESM 覆盖 EOL 后的补丁缺口，把 do-release-upgrade 变成「检查 → 备份 → 升级 → 验证 → 回滚预案」的标准流程，用 Canonical Livepatch 在内核层做到「不重启修漏洞」，最后用 LVM 快照 + 包版本快照 + 备份体系撑起回滚的底气。记住三个立即可用的要点：升级前必跑 --simulate、升级必在 tmux 里做并先打快照、把回滚手册写进文档而不是临时抱佛脚。

下期预告：第 15 天（重访·第二季）将带来《SSH 远程管理——安全加固进阶》，深入 SSH 密钥认证最佳实践、基于主机的访问控制、MFA 二次认证、SSH CA 与堡垒机方案。敬请期待！

系列目录