摘要

  • 08:38 UTC 抓取的 APNIC WHOIS 与 RDAP 统计 JSON 覆盖 10 月 27 日 05:00–06:00 UTC；其 MD5 与下载文件吻合。小时发布当时已经恢复。
  • 10 月归档缺少从 10 月 23 日 04:00 到 26 日 23:00 UTC 的 92 个小时文件。APNIC 10 月 16 日通知的结束时间和持续时间仍空白，也没有逐小时修复清单。

统计钟走起来了，缺失的小时却没跟着回来

08:38 UTC 抓取的 APNIC 当前 JSON 覆盖 10 月 27 日 05:00–06:00 UTC。MD5 与下载文件吻合。那时，10 月归档已有当天 04:00–05:00 的报告。小时发布已经恢复。

再往前翻，故事就不同了。缺口前最后一份文件记录 10 月 23 日 03:00–04:00 UTC；下一份从 27 日 00:00 开始。中间 92 个小时起点没有归档文件。最新报告回来了，日历还缺四天。

这个数字不是估算。APNIC 的 README 规定每份报告覆盖一个左闭右开的 UTC 小时。文件名 20261023-0300 对应 23 日 03:00–04:00；下一份理应从 04:00 开始。目录随后跳到 20261027-0000。按照每小时一份的规则，空档正好 92 小时。

APNIC 10 月 16 日的服务通知把故障起点写在 UTC+10 10:00，也就是 UTC 00:00。受影响项目是“Whois and RDAP stats”。APNIC 将问题归因于日志处理，称从该时刻起统计不完整，生成程序暂时停用，并表示故障修复后会重发受影响文件。通知里的结束时间和持续时间都没有填写。

归档现在留下了一条修复线索：10 月 23 日 03:00–04:00 的文件于 27 日 03:12 UTC 重写，之后又出现新的小时报告。读者能看到当前数据，也能看到一份旧文件被重发；但公开记录没有说明哪些区间已经重建、哪些仍不完整、哪些将继续缺失。服务更新页仍列着那条原始通知，没有结案记录。

这会直接改变时间序列的计算。图表程序遇到空小时，可以删掉它、按前后值插值，或者填成零。平均值和告警阈值随之变化。APNIC 的报告列出查询总量、查询类型分布，以及按起源 ASN 统计的不同源 IP 数。时间戳和校验值可以核验单个文件；逐小时完整状态和修订历史才能说明整条序列发生了什么。

校验值能证明字节没变，不能替 APNIC 记修复账

APNIC 已经具备一份清楚修复清单所需的材料。每个更正区间可以列出 UTC 起止时间、状态、首次发布时间、修正时间、当前校验值和被替换文件的校验值。再用一份简短清单把缺失小时标记为已重发、暂不可用或无法提供，并链接对应文件。研究人员就能保留旧记录、识别新版本，并按同一规则重算数据，而不用猜目录背后发生了什么。

这里的分工很具体：当前文件的校验值证明下载字节与 APNIC 发布的文件一致；文件名标出报告对应的小时；服务通知说明统计从 10 月 16 日 00:00 UTC 起不完整。逐区间修正清单可以把三条记录接起来。

这次通知写的是统计生成环节，列出的也是统计文件。27 日的新报告证明发布已经恢复。下一条有用的更新应列出受影响小时、修正文件校验值，并为 10 月 16 日通知补上结案记录。钟已经重新挂上墙，归档还欠读者 92 行。

来源

APNIC 2026 年 10 月 16 日服务通知；APNIC 服务更新页；WHOIS 与 RDAP 统计 README；当前统计 JSON；当前 MD5 校验文件；2026 年 10 月小时归档；10 月 23 日 03:00 UTC 归档文件。