常见SEO服务器定时更新脚本如何写得更稳当

很多团队第一次写服务器定时更新脚本，思路都很直接：cron 里加一行，到点跑 apt upgrade 或者 yum update，完事。真跑上一两个月，问题就慢慢冒出来了。有时候更新撞上业务高峰，CPU 突然被拉满；有时候依赖包升级把某个服务搞挂，第二天才发现；还有时候脚本卡在交互确认那一步，进程一直挂着，后面所有定时任务都被堵住。定时更新这件事，难点不在“定时”，在“更新出问题时你怎么知道、怎么退”。

先说脚本本身的结构。一个能长期用的服务器定时更新脚本，至少要把几件事分开：检查有没有别的更新进程在跑、记录这次更新了什么、失败时留下可回看的日志、结束后给个明确的退出状态。很多人把所有命令串成一行，中间某一步失败了也继续往下走，最后看日志根本分不清是下载失败还是安装失败。比较稳妥的做法是脚本开头先加锁，用 flock 或者 pid 文件都行，避免上一轮还没结束下一轮又起来。更新前把当前关键包的版本号写进日志，更新后再写一次，前后一对比，这次动了哪些东西就清楚了。

更新范围也要提前想好。安全补丁和内核升级不是一回事，数据库和 Web 服务的更新节奏也不该一样。有的机器只跑静态资源，随便更；有的机器上跑着对版本敏感的业务，就不能跟着安全源无脑升。我见过一个内部工具站，管理员图省事，把自动更新设成每天凌晨全量升级，结果某次 PHP 小版本跳变，一个老扩展加载失败，页面白屏到第二天上班才有人发现。后来他们把更新拆成两类：安全补丁每周跑一次，普通包更新只做下载和通知，人工确认后再装。服务器定时更新脚本本身没变复杂，变的是更新策略。

日志和通知是另一个容易被省掉的部分。脚本跑在后台，没人盯着屏幕，出问题只能靠事后查。日志至少要包含时间、主机名、更新前后的包列表、命令退出码。通知不用做得很花哨，邮件或者 webhook 推一条摘要就够，重点是把“成功”和“失败”分开。有些脚本失败也返回 0，定时任务面板上一片绿，实际什么都没干成。退出码要写对，失败就非零退出，这样上层的监控才能接住。日志文件也要考虑轮转，不然半年后一个几百兆的文本文件躺在 /var/log 里，查起来反而费劲。

回滚这件事，写脚本的时候就得留后路。不是所有更新都能干净回退，但至少要做到更新前知道哪些包会变、更新后能快速定位到出问题的那个。Debian 系可以保留 apt 的 history 日志，RHEL 系可以借助 dnf history 回看事务。内核更新尤其要留意，新内核装完没重启之前，旧内核还在，真出问题还能从引导菜单选回去。把这些检查点写进脚本的注释里，比写在文档里更容易被下一个接手的人看到。

还有个小细节：时区和业务低峰。cron 用的是系统时区，容器里经常是 UTC，写 2 点实际跑在上午 10 点，这种事不罕见。更新窗口最好避开备份任务和批处理任务，别让几个重活挤在一起。脚本里可以加一个简单的时间判断，或者干脆用 systemd timer 配 RandomizedDelaySec，把多台机器的更新错开，避免同时打满软件源或者同时重启服务。

最后说验证。脚本写完不等于结束，先在测试机上手动跑几遍，模拟网络中断、模拟锁被占用、模拟某个包安装失败，看看日志和退出码是不是符合预期。上线后头两周盯一下通知，确认成功和失败都能收到。服务器定时更新脚本的价值不在于省掉几次手动操作，而在于每次更新都有记录、有边界、有人知道结果。做到这几点，自动更新才敢长期开着。