确定异常开始时间,核心是找到“最后一个正常状态”和“第一个异常状态”之间的分界点,再用可交叉验证的证据把这个区间压缩到一个可交付的时间点。多人协作时,不要凭印象说“大概上周开始的”,而要把每个证据的时间戳、时区、统计口径和采集方式写清楚,让接手的人能复现你的判断。
同一件事在不同系统里显示的时间可能不一致,这本身就是返工的常见来源。开始诊断前,先确认三件事:
把这三项写成一句话放在交付文档开头,例如“本文所有时间均为北京时间,流量数据来自站内日志按小时聚合”。这一步能避免大量“你说的和我看的不一样”的争论。
先明确“异常”指什么。是抓取频次下降、索引量减少、点击量下滑,还是页面返回错误增多?不同异常对应不同数据源。常见的可核查来源包括:
每一项都标注数据保留周期。如果某个来源只保留30天,就要先导出,否则后续无法回查。
假设你怀疑索引量从某天开始下降。不要从最早的数据一天天往后看,而是取一个已知正常的时间点A和一个已知异常的时间点B,检查中点M:
这是本题最关键的一步。二分法把线性排查变成对数级排查,30天的区间最多5次检查就能定位到天。多人协作时,每次检查都记录“检查时间点、数据来源、结论、检查人”,交接时直接看记录即可。
如果指标是连续渐变而非突变,二分法仍然可用,但要先定义阈值。例如“索引量低于基线的90%”算异常,那么先算出基线,再按这个阈值判断每个中点。阈值定义要写进交付文档,否则不同人用不同标准,结论无法对齐。
找到候选起点后,不要直接下结论。用至少两个独立来源验证同一时间点:
还要检查该时间点附近是否有已知变更:发布、迁移、规则调整、证书更新。变更记录是解释异常起点最直接的证据,但要注意“时间接近”不等于“因果成立”,只能作为假设,仍需其他证据支持。
如果多个来源指向不同时间,保留全部结果并注明差异原因,例如“日志按UTC记录,换算后比统计后台晚8小时”。不要为了结论整齐而丢弃矛盾证据。
异常处理完后,把这次的时间线整理成固定格式存档:异常描述、候选起点、验证来源、最终认定起点、排除的假设及理由。下次出现类似问题时,可以直接对比历史记录,判断是复发还是新问题。
维护还包括定期检查数据保留策略。如果日志只留7天,很多异常在发现时已经无法回溯起点。根据业务需要调整保留周期,是降低未来诊断成本的实际动作。
假设某页面点击量下降,你手头有站内日志和搜索引擎点击报告。操作如下:
判断结果:如果两份数据在同一天下降且有对应变更记录,可以把该变更作为重点排查对象;如果只有一份数据下降,先确认这份数据的采集是否正常,再决定是否继续追查。
任何起点结论都有适用范围。写明“本结论基于站内日志和搜索引擎点击报告,适用于该域名下所有被抓取页面;不适用于付费广告落地页,因为广告流量不经过同一采集路径”。这样接手的人知道结论能用在哪里、不能用在哪里,减少返工。
下一步:挑一个当前正在关注的异常指标,按上面的准备清单列出数据源和保留周期,然后对最近30天做一次二分法排查,把过程记录成文档。