网站缓存：错误只在特定时段出现时怎样捕捉短暂证据
📱 CCBot/2.0 (https://commoncrawl.org/faq/)
🔗 /3350ca0f56a3.html
📄
网站缓存：错误只在特定时段出现时怎样捕捉短暂证据
先给结论：不要等错误再次出现才动手，而要在它出现之前把“可自动留痕的观察点”布置好。缓存类故障常表现为间歇性，是因为命中状态、回源路径和内容版本在时段之间发生了切换，而不是随机抖动。可用的办法是提前记录时间戳、响应头和缓存层级，让下一次复现自动留下可核对的证据。
先接受一个反直觉现象：错误越短，越难靠人工复现抓住
很多人遇到特定时段报错，第一反应是守在电脑前刷新页面，等它再次出现。问题在于，缓存错误往往只持续几分钟甚至几秒：某个节点上的旧副本被访问到，随后被新内容覆盖，人工刷新时已经恢复正常。你看到的“现在没问题”，并不能否定刚才确实出过错。
更麻烦的是，人工刷新本身会改变缓存状态。你反复请求同一个URL，可能触发回源、更新副本，把原本能作为证据的旧响应覆盖掉。所以捕捉短暂证据的核心不是“更快地看”，而是“让系统替你看”，并且保留原始记录。
矛盾结果通常指向两个解释：缓存层级切换，或内容版本切换
当同一URL在A时段正常、B时段异常，且两个时段的请求参数看起来一致，最常见的两种解释是：
- 解释一：请求落到了不同缓存层级。边缘节点、中间层缓存和源站可能保存着不同版本的响应。某个时段流量被调度到尚未更新的节点，就返回旧内容或错误状态。
- 解释二：源站在不同时段输出了不同版本。例如定时任务、发布流程或灰度开关在特定时间改变了源站响应，缓存只是把这个差异放大并延续了一段时间。
这两种解释的处置方向完全不同：前者要处理缓存刷新与节点一致性，后者要处理源站发布逻辑。如果只凭“清一次缓存就好了”下结论，很容易在下一个时段再次踩坑。
用三组证据区分是缓存层级问题还是源站版本问题
要区分上面两种解释，关键是拿到同一时刻、不同观察点的响应，而不是事后凭印象回忆。以下证据组合最有用：
- 带时间戳的响应头记录。重点看缓存命中标识、内容版本标识和生成时间。如果同一时刻不同节点返回的版本标识不同，偏向缓存层级问题；如果所有节点在同一时段都返回同一个异常版本，偏向源站问题。
- 绕过缓存后的对照请求。在异常时段，用带随机查询参数的请求或直连源站的方式取一份响应，与缓存响应对比。若绕过缓存后正常，说明异常版本存在于缓存层；若绕过缓存后同样异常，源头在源站。
- 错误发生与恢复的时间边界。记录第一次异常和最后一次异常的时间点，再对照发布记录、定时任务和缓存刷新记录。若边界与刷新动作吻合，偏向缓存；若与发布动作吻合，偏向源站。
这里有一个容易忽略的假设：错误时段内你没有改动任何配置。如果期间有人手动清过缓存或发过版，时间边界就失去对照价值，需要换一个未受干扰的时段重新观察。
布置自动留痕：让下一次复现自己交出证据
人工守候不可靠，可行的动作是加一层定时探测。例如假设每两分钟请求一次目标URL，把状态码、响应头中的缓存标识和响应体摘要写入日志，并保留原始响应。这样即使错误只出现三分钟，日志里也会留下至少一条异常记录。
这个动作的结果会直接决定下一步：如果日志显示异常只出现在某个节点或某个版本标识上，下一步应核查该节点的缓存刷新与回源配置；如果日志显示所有探测点在同一时间窗口同时异常，且绕过缓存也异常，下一步应转向源站发布流程和定时任务。反之，如果探测始终正常，说明触发条件比预期更窄，需要把探测频率、来源位置或请求特征调整到更接近真实用户的路径上。
需要提醒的是，探测正常不等于问题不存在。它可能只是没命中触发条件，例如探测来源与真实用户不在同一网络路径，或请求头差异导致走了不同缓存分支。因此探测日志要和真实用户侧的错误报告时间对齐看，而不是单独下结论。
捕捉证据时的几个取舍
保留完整响应体会占用较多存储，但只记录状态码又可能漏掉“状态码正常、内容却是旧版本”的情况。折中做法是记录响应体摘要或关键字段的哈希值，既能判断版本是否变化，又不必长期保存全部内容。
探测频率也不是越高越好。频率过高会增加回源压力，甚至改变缓存行为，让原本会出现的错误不再出现。可以先按与错误持续时间同一量级的间隔设置，例如错误通常持续数分钟，就按分钟级探测，再根据第一轮日志调整。
最后，所有记录都要带统一时区的时间戳。跨时区团队协作时，时间对不上会让本来清晰的证据链失效，这也是短暂故障排查中最常见的低级失误。
