Operations · XB 现场笔记

事故复盘应留下一份事实记录

Mon, 24 Aug 2026 00:00:00 +0000

一份复盘在它的说法能被重新检查时才赢得信任。这意味着每个阶段都要点名产生该事实的命令，而不是某人记忆的转述。下面的四个阶段让任何写下来的复盘在日后都可复核。

检测：症状，而且要带证据

从最小的可验证症状与展示它的命令开始。“截图"好过一段散文描述：

$ check-http-headers.sh https://www.xbcatm.com/
HTTP/2 200
content-security-policy: ... script-src 'none' ...
last-modified: Mon, 24 Aug 2026 11:20:54 GMT

如果症状是某个响应头变了，那么展示旧策略与新策略的输出应并排放在一起。如果是失败，请包含退出状态与错误行。

界定范围：影响多广，以及你如何知道

用证据而不是形容词陈述爆炸半径。修复一个你能检视的边界：

哪些主机或路径返回同样的症状？每个候选主机跑一次 check-http-headers.sh 就能回答。
缓存与源站是否不同？比较 Vary 与验证器。
适用哪个回滚窗口？使用变更前仍生效的 TTL。

修复：变更及其预期效果

写出可重放的正确动作。优先选择恢复契约的最小变更，并说明修复后运行应显示什么：

# 期望出现在响应里的新策略行：
script-src 'none'

验证：事后运行

变更后重复检测命令，并演示观察到的输出现在与预期契约一致。没有最后这一节的复盘只是一个故事；有了它，它就是一份允许自己未来被再检查的记录。

来源

RFC 9110 — HTTP Semantics，响应元数据与条件请求，已核验 2026-08-24。
制品 HTTP 响应头检查，贯穿本记录使用的只读检查。

用两条命令读取公共边缘

Mon, 24 Aug 2026 00:00:00 +0000

一次部署，是当公共边缘与你选择的文件一致时才完成，而不是因为最后一条上传命令退出码为零。操作套件里的两个只读小工具，能让任何能到达主机的机器看到这种一致性。

检查响应头

check-http-headers.sh 抓取一个 URL，并打印响应行、响应头与重定向后的最终 URL：

check-http-headers.sh https://www.xbcatm.com/

最近对本站一次运行的结果：

HTTP/2 200
server: nginx
content-type: text/html; charset=utf-8
content-security-policy: default-src 'self'; script-src 'none'; ...
strict-transport-security: max-age=31536000; includeSubDomains
x-content-type-options: nosniff

注意正文被丢弃，只显示响应线之外的状态行。要比较一次发布前后的变化，保存一份基线并把新的输出与之相减。

读取证书日期

check-tls-expiry.sh 从 TLS 握手读取服务器证书的过期日期，而不改变服务：

check-tls-expiry.sh www.xbcatm.com 30

它打印证书的 notAfter 以及到该日期剩余的天数。如果剩余天数低于阈值，它以非零状态退出——适合加进发布冒烟测试。

发布冒烟测试里它们配合使用

排定发布冒烟测试时，让一个命令确认法着陆状态，另一个确认即将过期的证书。剩下的剩余风险是活动报表之外、真正浏览无法发现的内容——例如重量级第三方脚本，或是仅在大流量出现的缓存问题。一条只读输出现场完成不了这些，仍需一次真实的浏览器会话。

来源

RFC 9110 — HTTP Semantics，响应语义与条件请求，已核验 2026-08-24。
OpenSSL s_client，TLS 连接与证书日期检查，已核验 2026-08-24。
制品 HTTP 响应头检查，贯穿本记录使用的只读检查。

维护定时器应让其最近结果可见

Sun, 23 Aug 2026 00:00:00 +0000

cron 式语法并不是维护任务契约的全部。命令需要一个清晰的服务身份、一个有界的运行时间，以及能区分"未调度"与"运行但失败"的证据。一个 systemd 定时器与 oneshot 服务能把这些关注点分开。

把工作定义成服务

使用显式用户与绝对命令路径：

# /etc/systemd/system/site-check.service
[Unit]
Description=Read-only public site check

[Service]
Type=oneshot
User=sitecheck
ExecStart=/usr/local/bin/check-public-site
TimeoutStartSec=2min

TimeoutStartSec 防止网络或子进程等待无限占用调度。当契约失败时，helper 应返回非零退出码，并且不得修改它所检查的服务。

调度该服务

# /etc/systemd/system/site-check.timer
[Unit]
Description=每小时运行公共站点检查

[Timer]
OnCalendar=hourly
Persistent=true
RandomizedDelaySec=5min
Unit=site-check.service

[Install]
WantedBy=timers.target

Persistent=true 会在机器恢复后补跑错过的日历事件。RandomizedDelaySec 把一个窗口内的例行工作分散开；当任务必须在精确时刻运行时它并不合适。

启用前先验证

检视日历表达式，然后手动启动服务：

systemd-analyze calendar hourly
systemctl start site-check.service
systemctl status site-check.service
journalctl -u site-check.service -n 50 --no-pager

只有当服务在预期的用户、环境、路径与网络访问下成功时才启用定时器：

systemctl enable --now site-check.timer
systemctl list-timers site-check.timer

对服务结果告警

定时器触发并不等于成功。要监控 oneshot 服务的退出状态或日志结果。保持 stdout 简洁，调试需要的详细制品写入一个有界的路径。

来源

systemd.timer(5)，日历定时器、持久化与延迟行为，已核验 2026-08-23。
systemd.time(7)，日历表达式语法，已核验 2026-08-23。
systemd.service，oneshot 服务语义，已核验 2026-08-23。

DNS 变更需要一个感知缓存的回滚窗口

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

改一条地址记录很容易，预测每个解析器何时停止使用旧应答却很难。时间到活性（TTL）值随 DNS 响应传播，并控制缓存可复用的时长。在迁移那一刻降低 TTL，并不能改写更早被缓存下来的应答。

在事件前降低 TTL

如果既有记录是一天的 TTL，至少要在计划切换前一个旧 TTL 时就把它降低。这样在旧端点仍然权威时，缓存有时间去取较短的值。确切间隔应写进变更计划，而不是在迁移中即兴执行。

记录来自权威服务器与至少一个递归解析器的应答：

dig +noall +answer www.example.test A
dig @1.1.1.1 +noall +answer www.example.test A

递归解析器显示的剩余 TTL 是它当前缓存状态的证据。不同解析器合理地显示不同的剩余值。

让两侧都保持有效

切换期间，保持旧端点与新端点都能为预期主机名提供服务。TLS 名称、重定向与应用配置在两侧必须一致。权威记录改变后立刻移除旧端点，会给仍持有先前应答的客户端造成本可避免的停机。

否定应答也会被缓存。一个最近返回 NXDOMAIN 的名字，其出现可能很慢才可见，因为根据区域的权威数据，否定响应可能仍留在递归缓存里。

观察后恢复 TTL

一旦权威与具有代表性的递归应答都指向新端点，且旧缓存窗口已过，就恢复正常 TTL。在变更记录中保留旧值、新值、权威应答与回滚条件。

来源

RFC 1034 — Domain Names: Concepts and Facilities，缓存模型，已核验 2026-08-22。
RFC 1035 — Domain Names: Implementation and Specification，TTL 字段，已核验 2026-08-22。
RFC 2308 — Negative Caching of DNS Queries，否定缓存模型与保留的错误 TTL，已核验 2026-08-22。

robots.txt 与 sitemap 回答不同的问题

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

两个小文件常被当成安全边界使用，但它们不是。robots.txt 描述爬虫偏好，sitemap 则给搜索系统一份属于该站点的 URL 清单。

robots.txt 能做什么、不能做什么

规则发布于源站根路径 /robots.txt，由配合的爬虫读取。它不会保护私有目录、不会从网络上移除 URL，也不能替代认证。不应公开的路由需要服务器授权或网络边界。

让文件保持平实，并测试它的实际位置：

User-agent: *
Disallow:
Sitemap: https://www.example.test/sitemap.xml

文件应为 UTF-8。如果部署会重定向它，请核验你想要的爬虫行为，而不是假设每个客户端都遵循同一条链。

sitemap 增加了什么

sitemap 是一份清单，而不是权限列表。使用单一主机的绝对 URL、正确做 XML 转义，并且只列出你准备发布的规范页面。不要因为某个 URL 存在于构建目录就把它列出。

协议允许每个 sitemap 文件最多 50,000 个 URL 与 50 MB。小站不需要 index 文件；一份普通 sitemap 更容易检视。把它的 XML 校验通过，并像普通页面一样通过同一 HTTPS 边缘请求它。

curl -fsS https://www.example.test/robots.txt
curl -fsS https://www.example.test/sitemap.xml | xmllint --noout -

如果未安装 xmllint，请在发布它的同一个 CI 环境里解析该 XML。重要的是检查要在文件被替换到边缘之前运行。

来源

RFC 9309 — Robots Exclusion Protocol，robots 规则、文件位置与 user-agent 匹配，已核验 2026-08-22。
Sitemaps Protocol，sitemap XML 结构与发现，已核验 2026-08-22。

SSH 主机密钥是部署记录的一部分

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

SSH 私钥认证客户端，但它并不告诉客户端到达的是哪台服务器。服务器的主机密钥与本地 known_hosts 数据库，提供身份检查的后一半。

把首次接触与轮换分开

在 StrictHostKeyChecking=yes 下，SSH 拒绝未知主机与变化的密钥。对于一个固定生产端点，只要期望密钥通过可信渠道安装，这就是最安全的默认值。accept-new 是面向预期会出现新主机的、更窄的方便选项：它接受一个从未见过的密钥，但仍拒绝被更改的密钥。

Host production-site
HostName www.example.test
User deploy
IdentityFile ~/.ssh/site_ed25519
StrictHostKeyChecking yes
UserKnownHostsFile ~/.ssh/known_hosts

不要通过给部署脚本加 StrictHostKeyChecking=no 来"修复"警告。那会把有用的信号变成静默接受。如果主机被重建，请记录替换后的指纹，并复核旧密钥为何不再有效。

让指纹可复核

在首次连接之前，从主机所有者或控制台获取指纹，再与客户端看到的值比较。密钥变更应有工单、维护说明或其他他人可检视的解释。

同一规则适用于自动化：known-hosts 文件是带有安全后果的配置，不是可丢弃的缓存数据。把它与部署记录一起备份，但不要把私钥或复制的凭据随站点制品一起公开。

来源

OpenBSD ssh_config，StrictHostKeyChecking 与 UserKnownHostsFile，已核验 2026-08-22。
OpenSSH ssh-keygen 手册，指纹检视，已核验 2026-08-22。

备份只有在演练过恢复之后才有用

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

“我们有备份"还不是一种恢复能力。一份有用的备份有已知范围、已知新鲜度、一个验证步骤，以及一份确有人实际跑过恢复流程。

定义恢复单元

对静态站点，源码仓库与生成制品用途不同。仓库是权威输入；制品是恢复最近发布版本的最快方式。请把两者的区别说清楚。

至少记录：

源码提交或归档标识；
生成器与主题版本；
制品包含的文件列表；
重要下载的校验和；
保留期限与存储位置。

不要把凭据、私钥、Cookie 或访问令牌放进网站备份。它们应属于独立的机密管理流程。

存储前先验证

打不开的归档不是备份。一个最小的验证循环如下：

tar -czf site-2026-08-22.tar.gz public/
tar -tzf site-2026-08-22.tar.gz >/dev/null
sha256sum site-2026-08-22.tar.gz > site-2026-08-22.tar.gz.sha256

校验和验证的是被存储的这个文件，并不能证明所有应用层面的假设都正确。这正是为什么仍需要一次恢复演练。

在某个可丢弃的地方恢复

把归档解包到临时目录或隔离主机，然后检查入口点与一个有代表性的资源。不要用覆盖唯一活动副本的方式测试恢复。

restore_dir=$(mktemp -d)
tar -xzf site-2026-08-22.tar.gz -C "$restore_dir"
test -s "$restore_dir/public/index.html"
test -s "$restore_dir/public/404.html"

这条命令刻意很平凡。演练应在事故到来之前，暴露出缺失文件、错误权限或未记录的依赖。

诚实地度量新鲜度

备份日程只有在相对可能丢失的工作量时才有意义。如果源码一个月才变一次，每日快照可能不必要；如果某个资源每小时更新，一次月度归档又不够。

写下目标恢复点与恢复时间，再选择能满足这些目标的存储与检查。当最后一次经过验证的恢复备份已经陈旧时，不要宣称"连续保护”。

来源

GNU tar manual，归档创建与验证行为，已核验 2026-08-22。
静态网站发布检查清单，本地配套资源。

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

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

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

让常见路径变得无聊

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

构建自固定的工具链。
发布一个完整目录。
检查生成的 HTML 与资源。
保留上一个目录以便回滚。

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

只对可限定范围的操作重试

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

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

偏好单一权威状态

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

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

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

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

恢复应回到已知状态

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

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

来源

RFC 9110 — HTTP Semantics，9.2.2 节关于幂等方法与重试，已核验 2026-08-22。
静态网站发布检查清单，本地配套资源。

小系统的优势

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

小不等于未完成。它意味着每个组件职责清晰、依赖经过斟酌，并且从请求到结果之间始终可见。

可见性是一种特性

当运维人员能说出每个边界时，他们也能指出缺少哪份证据。日志变得更有用，告警更具体，例行维护风险更低。

对静态网站而言，重要的边界通常很容易列出：

DNS 把主机名指向预期的边缘。
TLS 在预期的代理处终结。
代理只服务一个已知的输出目录。
输出只包含站点需要的文件。
404 响应由站点本身处理，而不是意外的上游。

把这些写下来，比加上一块回答不了任何上述问题的仪表盘更有价值。

复杂性要用实力取得位置

当新的一层消除的不确定性多于它引入的，它才值得。缓存重要时，给资源加指纹的构建步骤会有用；内容需要事务时，数据库才有用。但对一个小而多为静态的站点，这两者都不必然是改进。

对客户端 JavaScript 也适用同一规则。如果页面需要搜索索引或交互编辑器，就加入满足该需求的最小实现，并有意识地更新内容。如果页面是一份文档，纯 HTML 往往更容易检视、更有韧性。

让所有权明确

每个文件都应有存在的理由与明确的更新方式。vendored 主题应记录其上游版本与许可。生成目录应标记为生成物。资源下载应说明它包含什么、何时更新、校验和如何产生。

这些简短声明能防止未来的运维者把偶然产生的制品当作受支持的接口。

为下一次变更留出空间

最好的小系统不是行数最少的那个，而是下一次变更看得见去处的那一个。笔记站可以从 Markdown、静态生成器与一个 Web 服务器起步；如果以后需要搜索或评论，可以独立评估这个新需求，而不是一开始就假设它存在。

来源

Hugo directory structure，内容与资源的目录约定，已核验 2026-08-22。
Caddy file_server 指令，设计中引用的静态文件服务默认值，已核验 2026-08-22。

重定向与错误码应保留故事的完整性

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

HTTP 状态码是接口的一部分。浏览器可能渲染出一个友好的页面，但监控、爬虫、缓存与 API 客户端也需要状态码与响应头来讲述同一个故事。

永久移动并不都等价

308 Permanent Redirect 在保留请求方法的同时，传达资源有了新的永久 URI。这对发送 POST、PUT 或其他非 GET 方法的客户端很重要。旧页面到新页面的重定向用 GET 很容易测试；端点的迁移则必须用真实调用方实际使用的方法来测试。

curl -sS -D - -o /dev/null --max-redirs 0 \
 https://old.example.test/api/item

检查 Location 是否为绝对地址或正确锚定、目标是否是预期主机，以及响应是否被静默降级为临时重定向。308 默认可缓存，因此只有在有意识的迁移计划时才改动它。

区分"缺失"与"被移除"

当服务器找不到当前表示且缺失可能是暂时或未知时，使用 404 Not Found。410 Gone 更强：它表示资源被有意移除且不太可能回归。两者都应有帮助人类的正文，但都不应因为自定义错误页成功渲染就返回 200。

这条检查应放在边缘：

curl -sS -o /tmp/missing.html -w '%{http_code} %{url_effective}\n' \
 https://www.example.com/a-route-that-does-not-exist

在错误路径上也应保留安全响应头。安全头、有用的内容类型与正确的状态码，比一个装饰性的错误动画更有价值。

来源

RFC 9110 — HTTP Semantics，第 15 与 13 节，已核验 2026-08-22。
RFC 7538 — 308 Permanent Redirect，第 3 节，已核验 2026-08-22。
curl manual，状态与重定向检查标志，已核验 2026-08-22。

重启策略需要一个速率限制

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

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

来源

systemd.service，服务类型、重启与启动速率限制器，已核验 2026-08-22。
systemd.unit，通用单元段与 drop-in 语义，已核验 2026-08-22。