维护与更新

一台 24 小时不间断运行、并且可以从外部访问的机器永远不会真正「完工」。它是活的，而正如一切有生命的事物一样，它需要一点点照料。好消息是：90% 的工作可以归结为两个习惯，一个自动完成，一个每月一次。我们来看看是哪两个，尤其是如何在更新时不弄坏任何东西。

操作系统：底层系统

您的 Ubuntu 是地基。维护分为两个层次：

# 日常动作：刷新软件包列表，然后安装更新
sudo apt update && sudo apt upgrade -y
# 清理掉那些已经没用的软件包
sudo apt autoremove --purge

至于安全，您已经在系统设置里用 unattended-upgrades 把一切都自动化好了：机器会自行应用关键修复。这就是我们刚才说的那个自动习惯。

每两年一次，Ubuntu 会发布一个新的 LTS 版本。最新的 Ubuntu 26.04 于 2026 年 4 月发布；从 24.04 升级的通道自它的首个修正版 26.04.1（8 月底发布）起开放：Canonical 总是等到这个「.1」之后，才提供 LTS 之间的升级。这并不紧急，24.04 的安全补丁会持续到 2029 年。等您决定动手时，先做好备份（参见 Git、GitHub 与备份），再浏览一遍版本说明（英文）。

# 先装完待处理的更新，如有提示就重启
sudo apt update && sudo apt full-upgrade -y
# 然后开始升级到下一个 LTS（如果是通过 SSH 操作，请在 tmux 里运行）
sudo do-release-upgrade

依赖：您的项目所依靠的东西

这正是意外藏身之处，因为一个升了大版本的依赖可能会弄坏一个项目。

• Node（通过 nvm）：nvm install --lts 安装最新的 LTS（截至 2026 年 10 月 1 日为 Node 24，Node 26 预计 10 月 28 日成为 LTS），nvm alias default 把它设为默认。先保留旧版本，等确认您的项目都能正常运行之后再说。
• 某个项目的软件包：npm outdated 会显示哪些落后了，npm update 会在您的 package.json 限定的范围内更新。对于大版本，请先读一读 changelog：破坏性变更正是发生在这里。
• 能救命的习惯：锁文件。 把您的 package-lock.json / requirements.txt 纳入版本管理。它们能保证您的项目在任何地方都重新安装完全相同的版本，不会在您背后悄悄变动。

工具与智能体

您技术栈里的其余部分都能干净地更新，各有各的方式：

• Docker：跟随系统的 apt 更新。记得清理那些堆积起来的东西（见下文）。
• Ollama：重新运行安装脚本即可升到最新版（curl -fsSL https://ollama.com/install.sh | sh）。至于模型，用 ollama pull <模型> 就能取到新的版本：本地版本会被替换。想知道哪些新模型值得更新，可以看每周更新的 Quelle IA 本地模型榜（法语网站）。
• 您的代码智能体：用安装脚本装的 Claude Code 会在后台自动更新，claude update 可以强制升到最新版。OpenCode 用 opencode upgrade 升级。如果您当初是用 npm 装的 Claude Code，请改用原生安装脚本（curl -fsSL https://claude.ai/install.sh | bash），再用 npm uninstall -g @anthropic-ai/claude-code 删掉旧的那份。一个最新的智能体，意味着免费到手的新能力。
• Tailscale 和 cloudflared：通过它们各自的软件源安装，会随系统一起更新。无需做任何特别的事。

磁盘空间：无声的陷阱

模型、Docker 镜像和旧软件包会在不知不觉中把磁盘填满，而一台塞满的机器会开始莫名其妙地崩溃。打扫只需三条命令：

df -h                      # 还剩多少空间
docker system prune -a     # 清除未使用的镜像和容器
ollama rm <模型>           # 删除一个您不再使用的模型
sudo apt autoremove --purge # 孤立的软件包

知道它什么时候坏了

一台整夜独自干活的机器，只有您事先安排过，它才会通知您。风险不在于故障本身，而在于消息传到您这儿要多久。下面这些全都来自这台机器上的真实事故。

1. 一个脚本调用另一个脚本，必须把退出码传下去

经典陷阱，而且非常常见：

#!/bin/bash
set -uo pipefail
python3 import.py >> import.log 2>&1        # 退出码被扔进了垃圾桶
systemctl --user restart my-site || true    # 最后一条命令：永远返回 0

这个脚本永远返回 0。导入可以崩掉，systemd 报告成功，而您的周报告诉您一切正常。这里就发生过：一个数据库空了一整天，而探针一直显示绿色。

修法只要两行：

python3 import.py >> import.log 2>&1
rc=$?
systemctl --user restart my-site || true
exit $rc

2. OnFailure：它倒下的那一秒就通知您

systemd 可以在一个单元失败时触发另一个单元。您写一个给自己发消息的小服务，然后把它挂到所有重要的单元上。

# ~/.config/systemd/user/my-service.service.d/onfailure.conf
[Unit]
OnFailure=alert@%n.service

请用 .d/ 目录里的覆盖文件，而不是直接改单元本身：这样即使单元是从代码仓库软链过来的也照样生效，而且要撤销只需删掉一个文件夹。

3. 一个系统级探针，因为任何单元告警都看不见机器正在下沉

内存被填满时，没有任何单元处于”失败”状态。下沉的是机器本身，OnFailure 什么都看不到。您需要一个独立的、跑在定时器上的探针，盯着可用内存、被内核杀掉的进程、swap 和负载，然后在状态发生变化时给您发消息，免得同一条告警每五分钟重复一遍。

让智能体来帮您

这正是您的智能体最喜欢的那种苦差事。「检查一下这台机器上有什么需要更新的，给我总结一下重要的变更，并提出一个方案」：它会列出落后的软件包，替您读完 changelog，然后建议您一步一步地行动。您的手指始终按在按钮上，调查的活儿由它来干。