可靠的默认行为胜过聪明的恢复

Sat, 22 Aug 2026 00:00:00 +0000

小服务往往在正常路径被充分理解之前，就先累积了恢复逻辑。每一次重试、备用端点与兼容分支，都增加了必须被观察和测试的一个状态。

让常见路径变得无聊

一个有用的默认行为是明确的、易于检视的、且可安全重复的。对静态站点，可以简单到：

这段序列不如多阶段部署系统炫目，但它的状态可见。当某处失败时，运维者能回答：问题在源码、构建、复制还是 Web 服务器。

当操作已知是瞬时的、且重复不会产生第二个副作用时，重试才有用。从源站下载可能可安全重试；数据库迁移则未必。把每个错误都看作可重试的，会掩盖需要关注的边界。

当重试适当时，记录尝试次数与最终原因。类似"发布失败：校验和不匹配"的日志条目，比一串静默重试后跟一个笼统超时更有可操作性。

配置、运行时状态与文档应一致地说明哪个目录是活动的、哪条命令产生它。如果一个发布可以被不同的人复制到三条不同路径，恢复就变成了猜谜。

对静态部署，一份简短的发布记录就够了：

release: 2026-08-22
source: git commit <commit-id>
builder: Hugo 0.165.0
output: public/
verification: links + headers + checksums

占位符 commit ID 应按设计在发布时解析，而不是在文档里杜撰。

当恢复把服务带回最后一个已知良好目录，而不是在几个半成品替代品之间选择时，恢复最容易。保留上一次输出直到新输出通过检查，再按保留策略移除旧副本。

目标不是消除失败，而是把失败缩小到能解释、把恢复缩小到能信任。

Sat, 22 Aug 2026 00:00:00 +0000

对长驻服务来说，自动重启很有用，但无界的循环会把一个清晰的失败变成一个嘈杂的失败。单元文件应同时描述正常进程生命周期与可接受的恢复量。

对长驻进程，Type=exec 能在启动时暴露配置程序执行失败，而不是把一次 fork 当成功。把它与显式的 ExecStart 以及能完成工作所需最小权限的 User 搭配使用。

[Service]
Type=exec
User=site
ExecStart=/srv/site/bin/server
Restart=on-failure
RestartSec=5s

Restart=on-failure 是一种恢复策略，不是健康检查。如果进程在提供错误响应的同时保持存活，systemd 不会知道站点坏了；外部冒烟测试仍有其职责。

Systemd 通过 StartLimitIntervalSec= 与 StartLimitBurst= 应用启动速率限制。选择允许短暂瞬时停机、但不会让崩溃循环耗尽主机资源的值。当达到限制时，日志里应包含区分"重启成功"与"重复失败后放弃"所需的证据。

修改单元后，核验已加载配置并检查最近日志：

systemctl daemon-reload
systemctl restart example.service
systemctl status --no-pager example.service
journalctl -u example.service -n 80 --no-pager

不要用重启策略掩盖缺失文件、无效权限或糟糕的环境。先修复第一次失败，再测试恢复路径。