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

Tue, 07 Jul 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

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

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

用证据而不是形容词陈述影响范围。先界定能够检视的边界：

哪些主机与路径出现症状？记录每次探测的 URL 与观察时间；一次成功请求不能代表所有边缘或访问者的状态。
缓存与源站是否不同？使用相同请求头，比较两条路径的实际响应、缓存元数据与验证器。Vary 描述选择输入，不能证明响应来自缓存。
什么因素拖延恢复？DNS 变更需记录旧 TTL 与解析器观察结果；HTTP 缓存需另记新鲜度与重新验证策略。DNS TTL 不是通用的回滚期限。

修复：变更及其预期效果

记录实际配置差异与部署标识，让修复动作可理解，并在安全时可重放。下面的响应头片段是预期观察结果，不是 shell 命令，也不是完整策略。优先选择恢复契约的最小变更，并说明修复后运行应显示什么：

Content-Security-Policy: script-src 'none'

验证：事后运行

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

最后记录促成事故的因素、仍不确定的事项，以及带负责人、到期日和验收检查的预防动作。一次探测成功只确认该时刻的采样路径；它本身不能确定原因，也不能防止复发。

来源

RFC 9110 — HTTP Semantics，响应元数据与条件请求，已核验 2026-07-07。
制品 HTTP 响应头检查，贯穿本记录使用的只读检查。
Google SRE: Postmortem Culture，影响、促成因素、证据复核与预防动作，已核验 2026-10-15。
RFC 9111 — HTTP Caching，缓存选择与新鲜度不同于 DNS 缓存寿命，已核验 2026-10-15。

Postmortem · XB 现场笔记

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

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

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

修复：变更及其预期效果

验证：事后运行

来源