Linux服务器补丁、内核升级与重启编排

补丁管理不是在所有服务器上执行一次更新命令。真正的生产补丁流程要回答：哪些漏洞影响当前资产、哪些更新必须重启、业务能否逐台摘流、失败后如何恢复，以及如何证明所有目标主机已经达到要求。自动更新如果缺少分批、验证和回滚，可能把安全风险变成可用性事故。

本文适用于 Ubuntu LTS、Rocky Linux、AlmaLinux 等常见服务器发行版。包名、仓库和生命周期应以当前发行版官方公告为准。生产环境执行前应确认备份、控制台访问、启动项和业务回滚能力。

一、建立补丁管理边界

先区分四类动作：

常规月度补丁、紧急漏洞修复和发行版升级必须使用不同流程。不要把数据库大版本升级混在操作系统自动更新中，也不要把“软件包已经安装”当成“运行中的进程已经使用新版本”。

二、资产与责任是前提

每台服务器至少应记录：

• 资产编号、主机名、IP、环境和业务负责人；
• 操作系统、版本、内核、架构和虚拟化类型；
• 业务角色、集群成员关系和故障域；
• 维护窗口、允许中断时间和回滚要求；
• 软件源、代理、仓库凭据及例外包；
• 备份状态、快照能力和带外管理方式；
• 最近更新时间、待重启状态和补丁合规状态。

如果资产清单不完整，自动化只会更快地遗漏未知主机。补丁平台的目标清单应来自可信资产源，而不是某个人临时维护的文本文件。

三、补丁分级与时限

建议按“可利用性、暴露面、资产重要性、缓解措施和变更风险”综合分级，而不是只按 CVSS 分数：

紧急不等于跳过验证。可以缩短观察时间、扩大并行准备，但仍需最小范围测试、停止条件和回退路径。

四、更新前采集基线

Ubuntu/Debian：

cat /etc/os-release
uname -r
apt list --upgradable
df -hT
systemctl --failed

Rocky Linux/AlmaLinux：

cat /etc/os-release
uname -r
dnf check-update || test $? -eq 100
df -hT
systemctl --failed

还应检查：

• /boot 空间是否足够；
• 软件包管理器是否被其他进程占用；
• RAID、LVM、文件系统和磁盘是否健康；
• 集群是否已经有其他节点离线；
• 负载均衡摘除和健康检查是否可用；
• 备份是否真实可恢复，而不只是任务显示成功；
• 当前启动内核和默认启动项是否一致。

五、Ubuntu补丁策略

先刷新索引并预览变更：

sudo apt update
apt list --upgradable
sudo apt-get -s upgrade

执行安全更新前应核对组织的软件源策略。常规流程示例：

sudo apt-get upgrade
sudo systemctl --failed
test -f /var/run/reboot-required && cat /var/run/reboot-required.pkgs

unattended-upgrades 可自动应用更新，但生产环境仍应配置允许来源、更新窗口、重启策略、日志和失败告警。自动重启不能只按固定时间开启，否则可能在集群多节点同时重启。更稳妥的方式是自动安装、集中识别待重启状态，再由编排流程逐节点重启。

Livepatch 可以减少部分内核安全修复的立即重启需求，但它不能替代正常内核升级、用户态服务重启和计划性维护。仍需跟踪磁盘上已安装内核、当前运行内核和下一次重启计划。

六、Rocky与AlmaLinux补丁策略

查看安全公告和可用更新：

sudo dnf updateinfo list security
sudo dnf check-update
sudo dnf updateinfo summary

预览后执行组织批准的更新：

sudo dnf upgrade --refresh
sudo systemctl --failed

判断是否建议重启，可使用发行版提供的工具或比较运行内核与已安装内核。若安装了 dnf-utils，可检查：

sudo needs-restarting -r
sudo needs-restarting -s

dnf-automatic 适合受控自动下载或安装，但应明确：仅安全更新还是全部更新、是否自动重启、如何告警、仓库不可用时如何处理。数据库、容器运行时和内核通常需要更严格的维护窗口。

七、内核升级必须单独管理

内核升级前至少验证：

• 新内核包已经完整安装；
• /boot 和 EFI 分区空间充足；
• DKMS、存储、网卡、GPU和安全软件模块兼容；
• 默认启动项指向预期内核；
• 旧内核没有被全部清理，保留可回退版本；
• 有虚拟控制台、iDRAC、iLO或其他带外访问；
• 加密磁盘、根文件系统和网络启动流程已知。

重启后检查：

uname -r
systemctl --failed
journalctl -b -p warning
ip -br address
ip route
df -hT

还应验证业务端口、依赖连接、监控采集、日志上报和集群状态。只看到 SSH 能登录并不代表节点已经恢复服务。

八、服务是否需要重启

包更新后，运行进程可能仍映射旧库文件。可结合发行版工具检查，例如：

sudo needrestart

如果没有该工具，可从包变更、服务类型和维护手册判断。重启服务前要注意：

• 配置文件是否被包管理器生成新版本；
• 服务重启是否会清空内存队列或中断长连接；
• 多实例是否允许滚动重启；
• 数据库、消息队列和存储集群是否满足仲裁；
• 重启后是否存在缓存预热和流量爬坡。

九、用Ansible做滚动编排

补丁剧本应控制批次，而不是对全部主机同时执行。简化结构如下：

- name: Rolling patch Linux servers
  hosts: app_servers
  serial: 1
  any_errors_fatal: true
  max_fail_percentage: 0
  tasks:
    - name: Precheck free space
      ansible.builtin.assert:
        that:
          - ansible_mounts | selectattr('mount', 'equalto', '/') | map(attribute='size_available') | first > 2147483648

    - name: Stop when host is not approved
      ansible.builtin.assert:
        that: patch_approved | default(false) | bool

    - name: Apply approved updates on Debian family
      ansible.builtin.apt:
        update_cache: true
        upgrade: safe
      when: ansible_os_family == 'Debian'

    - name: Apply approved updates on RedHat family
      ansible.builtin.dnf:
        name: '*'
        state: latest
      when: ansible_os_family == 'RedHat'

生产剧本还应包含：摘除负载、等待连接排空、备份或快照确认、更新、条件重启、等待 SSH、健康检查、重新加流量和观察窗口。不要把业务健康检查只写成 systemctl is-active。

十、推荐的分批方式

1. 实验环境：验证仓库、依赖、内核和自动化逻辑；
2. 预生产环境：使用接近生产的数据量和流量；
3. 金丝雀主机：选择可快速回退、非唯一角色的生产节点；
4. 小批次：按故障域、机房或可用区逐批推进；
5. 主体批次：每批完成后保留观察窗口；
6. 特殊资产：数据库主节点、仲裁节点和单点系统单独审批。

同一集群的多个副本不能在同一批次全部更新。跨可用区部署时，应确保每一批都保留满足业务峰值的剩余容量。

十一、停止条件与回滚

停止条件要在执行前定义，例如：

• 节点无法在10分钟内重新加入集群；
• 健康检查或关键交易失败；
• 错误率、P99或队列积压超过阈值；
• 新内核出现驱动、文件系统或网络异常；
• 同批次出现超过1台失败主机；
• 监控、日志或安全代理未恢复。

回滚手段按更新类型不同：

• 服务配置：恢复备份配置并重启服务；
• 用户态包：在仓库仍提供旧包且数据格式兼容时降级；
• 内核：从引导菜单启动保留的旧内核并修复默认项；
• 虚拟机：仅在一致性和数据回放风险可接受时恢复快照；
• 有状态服务：按产品级备份与恢复流程处理，不能只回退系统盘。

快照不是通用回滚。数据库和分布式系统恢复快照可能造成时间线、复制和仲裁问题。

十二、补丁后验证与证据

每台主机至少记录：

主机与业务：
变更单号：
补丁前版本：
补丁后版本：
运行内核：
是否重启：
系统健康检查：
业务健康检查：
监控恢复时间：
异常与处置：
执行人/复核人：

自动化结果应区分“成功”“失败”“跳过”“不可达”和“待重启”。不可达不能算合规，跳过也必须有原因和到期时间。

十三、常见事故

• /boot 已满，内核包安装不完整；
• 软件源或代理异常，部分主机拿到不同版本；
• 所有副本同时重启，健康检查来不及恢复；
• 更新了共享库但未重启服务，漏洞扫描仍提示旧进程；
• 新内核缺少第三方驱动，重启后网卡或存储不可用；
• 自动更新覆盖配置文件，服务使用默认配置启动；
• 在补丁期间同时进行发布或容量变更，无法判断故障来源；
• 快照回退导致数据库数据倒退或集群身份冲突。

十四、上线检查清单

• [ ] 目标主机来自可信资产清单并有业务负责人；
• [ ] 已区分安全更新、内核更新、功能升级和发行版升级；
• [ ] 更新包、依赖变化和重启需求已经预览；
• [ ] /boot、根分区、软件源和包管理器状态正常；
• [ ] 备份、控制台访问、旧内核和回滚方式已验证；
• [ ] 集群按故障域滚动更新，不会同时失去仲裁或全部容量；
• [ ] 已定义系统与业务级健康检查；
• [ ] 停止条件、观察窗口和异常升级路径明确；
• [ ] 补丁后版本、运行内核和待重启状态可查询；
• [ ] 例外主机有原因、负责人和补办日期。

十五、参考资料

• Ubuntu Security：Security updates
• Ubuntu：Automatic updates
• Red Hat Enterprise Linux：使用DNF管理软件
• Ansible：Package management modules