主机域名选择：错误只在特定时段出现时怎样捕捉短暂证据
📱 CCBot/2.0 (https://commoncrawl.org/faq/)
🔗 /e977cd95f584.html
📄
主机域名选择：错误只在特定时段出现时怎样捕捉短暂证据
捕捉短暂时段错误的核心不是盯着屏幕等它复现，而是让主机与域名两侧各自留下带时间戳的原始记录，再用同一时间轴比对。假设一个情境：某站在每天凌晨两点到三点之间偶发超时，白天一切正常，运维、开发和客服对原因各执一词。下面按这个假设走一遍可核对的决策过程。
先分清错误发生在域名侧还是主机侧
短暂时段错误最常见的分歧是：一方说 DNS 解析不稳，另一方说源站负载过高。两者都会表现为“那个时段打不开”，但留下的证据完全不同。域名侧的证据是解析结果和 TTL 到期时间，主机侧的证据是请求到达时间、响应码和处理耗时。若请求根本没到主机，主机日志里就是空白，这个空白本身就是信息，而不是“没查到”。
要做的第一个动作是：在疑似时段前后，用固定间隔从至少两个不同网络位置记录域名解析结果，并同时记录本机到源站的连接结果。如果解析结果在时段内发生跳变，而主机侧在这段时间没有收到对应请求，域名侧的可疑度上升；如果解析始终稳定、请求确实到达主机却超时，重心应移到主机资源与上游链路。这一步的结果直接决定下一步去查哪一侧，避免两边同时大改。
用带时间戳的原始记录代替事后回忆
短暂错误最怕的是事后凭印象描述。可核对的项目应当满足三个条件：有时间戳、有原始字段、可被他人复现查看。建议在疑似时段内固定采集以下几类记录，并统一使用同一时区：
- 主机侧访问日志中的请求时间、状态码、响应耗时字段；
- 主机资源在相同时段的采样，如 CPU、内存、连接数；
- 域名解析结果与对应 TTL；
- 外部拨测或监控在相同时段返回的状态与耗时。
这些记录要保留原始形态，不要先做汇总平均值。平均值会把“只有几分钟异常”的信号抹平。把四类记录放到同一时间轴上对齐后，异常窗口是否一致、谁先谁后，通常一眼可见。若某个来源在异常窗口内恰好没有数据，也要标注为缺失，而不是当作正常。
把分歧转成可核对的判断项
当多个角色对同一事实理解不同时，争论“到底是谁的问题”没有产出。更有效的做法是把分歧拆成几个只能回答“是/否”的判断项，并约定每项由哪份记录来回答。假设情境里可以这样拆：异常时段内请求是否到达主机；到达后是否在超时阈值内完成；域名解析结果在该时段是否变化；异常是否只出现在某个网络出口。四项各自对应一份记录，谁也不必先说服谁。
这里有一个容易误判的点：某段时间监控请求量或抓取量归零，不能单独证明服务正常或异常。它还可能来自监控自身在那个时段失败、采集任务被跳过、或者上游把请求挡在了到达之前。因此归零要与主机日志交叉确认，看是“没有请求”还是“请求没被记录”。
一个假设的排查顺序与动作结果
仍用凌晨两点到三点这个假设情境。第一步，对齐主机日志与域名解析记录：如果解析稳定、请求到达且耗时在两点十分到两点十五分集中升高，那么可排除域名侧，把范围收窄到主机资源或上游。第二步，查看同窗口的资源采样：若连接数在该时段接近上限，而 CPU 并不高，说明瓶颈可能在连接处理而非计算。第三步，针对这个判断做一次小范围调整，例如临时提高连接相关限制或错开该时段的批量任务，然后继续采集同一组记录。
调整后的结果决定下一步：若异常窗口消失或明显缩短，说明方向正确，可以把临时措施固化为配置并继续观察若干天；若窗口不变，说明判断有误，应回到第一步，检查是否还有未被记录的前置环节，例如上游代理或调度任务。整个过程中不要一次改动多个变量，否则无法判断是哪一项起了作用。
哪些证据不能单独作为结论
有些记录看起来像结论，其实只能作为线索。robots.txt 的抓取限制不等于可靠的索引移除；站点地图不保证收录；HTTPS 不保证安全无漏洞或排名。这些在排查短暂错误时同样适用：某份记录显示“正常”，只能说明该来源在该时刻没有捕捉到异常，不能反推问题不存在。不同来源的支持情况与行为须分别核查，不要用一处的结论覆盖另一处。
最后，把整条时间轴、原始记录、判断项和每次动作的结果整理成一份可复查的文档，交给下一个接手的人。判断标准很简单：对方能否只看这份文档，独立复现你对异常窗口的定位，并知道下一步该查什么。能，则分歧已经变成可核对的项目；不能，则还缺证据，而不是缺结论。
