Linux系统维护无固定周期，取决于CVE通告、内核兼容性等信号；依赖三个触发点：升级日志、生效定时任务、漏洞状态轮询；须分检查与执行两阶段，避免直接cron执行升级。
系统维护周期不是固定时间表，而是响应变化的节奏
Linux系统没有“标准维护周期”这种东西。所谓“每月一次全量更新”或“每季度重启服务”在生产环境里往往适得其反——yum update 或 apt upgrade 是否执行，取决于 CVE 通告、内核模块兼容性、应用依赖锁定等具体信号，而不是日历提醒。
真正起作用的是三个可追踪的触发点：
-
/var/log/apt/history.log（Debian/Ubuntu）或/var/log/yum.log（RHEL/CentOS）里最近一次成功升级的时间与变更包列表 -
systemctl list-timers --all输出中实际生效的定时任务，而非/etc/cron.d/下静态文件的存在 -
curl -s "https://security-tracker.debian.org/tracker/source-package/linux" | grep -E "(pending|unfixed)"这类主动轮询渠道返回的关键漏洞状态
自动化维护脚本必须隔离“检查”和“执行”两个阶段
把 apt update && apt upgrade -y 直接塞进 cron 是最常见错误。一旦网络抖动或仓库临时不可用，后续依赖检查、服务验证、回滚判断就全失效了。
推荐用两阶段分离设计：
- 检查阶段（每日凌晨2点运行）：
apt list --upgradable 2>/dev/null | tail -n +2 | wc -l输出非零值时，写入标记文件/var/run/maintenance/pending-upgrade - 执行阶段（仅当标记存在且满足条件时触发）：要求人工确认、或检查
uptime -s距离上次重启 > 72 小时、且loadavgapt-get upgrade -y
#!/bin/bash
if [ -f /var/run/maintenance/pending-upgrade ]; then
if [ $(uptime | awk '{print $10}' | sed 's/,$//') -lt 1.5 ] && \
[ $(($(date +%s) - $(stat -c %Y /proc/1) )) -gt 259200 ]; then
apt-get upgrade -y && rm -f /var/run/maintenance/pending-upgrade
fi
fi内核更新必须跳过自动安装，除非你控制了 initramfs 生成逻辑
很多运维误以为 apt install linux-image-amd64 后 reboot 就完事。但实际问题常出在 initramfs —— 如果 /etc/initramfs-tools/conf.d/resume 指向已删除的 swap 分区，或 dracut --force 未被调用，新内核启动会卡在 “Loading initial ramdisk”。
关键动作只有两个：
- 禁用自动内核更新：
apt-mark hold linux-image-amd64 linux-headers-amd64（Debian系）或yum versionlock add kernel（RHEL系） - 每次手动升级后，强制重建 initramfs：
update-initramfs -u -k all（Debian）或dracut -f（RHEL）
维护日志本身需要轮转策略，否则 /var/log/syslog 会撑爆磁盘
logrotate 默认配置对高频率服务（如 Nginx 访问日志、rsyslog 的 /var/log/messages）往往不够用。一个 200GB 磁盘的服务器，可能三天就被 /var/log/journal 塞满。
必须调整三项：
- journal 日志大小限制：
sudo systemctl edit systemd-journald中添加[Journal] SystemMaxUse=500M - syslog 归档压缩：
/etc/logrotate.d/rsyslog里确保包含compress和maxsize 100M - 自定义维护脚本日志单独管理：
/var/log/maintenance.log应由脚本自身用logger -t maintenance写入，并在/etc/logrotate.d/maintenance中定义归档规则
没人会盯着 df -h / 等磁盘告警才行动。维护周期的真实终点，是让所有日志、缓存、临时文件的生命周期都可预测、可审计、可追溯。
