摘要

  • 10 月 28 日 CET 20:04，RIPE NCC 为 WHOIS 间歇性更新失败开启事故调查；20:23 将 RIPE Database 组件恢复为正常并继续监控，20:32 宣布结案。
  • 状态页记录了修复时钟，却没有列出失败提交或逐个对象的写入结果；提交者还需核对自己的回执与权威记录。

20:23，RIPE Database 的状态灯重新变绿。准备下一次更新的人可以松口气；刚才按过提交键的人，还得等另一种答案。

RIPE NCC 的事故页将问题命名为“WHOIS 间歇性更新失败”。公开 JSON 记录精确列出 10 月 28 日三个节点：CET 20:04:48 开始调查，20:23:24 应用修复并监控，20:32:00 结案。RIPE Database 组件在调查时被标为部分中断，在监控时恢复正常；整起事故另带“重大”影响标签。页面没有说明故障原因、影响了哪种更新入口、多少提交失败。这些是机构发布事故状态的时刻，不是每个用户请求失败的起止时刻。

为什么绿灯不能替代回执？RIPE 数据库的回执说明写明，每次提交得到一份回执，内含该次提交中各对象操作的结果。Syncupdates 返回 HTTP 200，只能说明消息已处理；个别对象仍可能失败，要看回执汇总。REST API 的回复格式又不同。这是日常写入规则，事故页并未交代 28 日具体波及哪一种入口。

对象处理说明还指出，同一次提交内的对象分别处理；同步 HTTP 连接关闭后，数据库的工作仍可能完成，而调用方拿不到那条连接上的回执。如果只凭超时就重试，可能把尚未核实的写入再发一次。提交者该先保存请求和收到的回复，再读取当前权威对象，最后决定是否补写。

RIPE NCC 让所有人看见服务何时恢复，却没有让某个持有者从状态页得知自己的哪条记录已经改变。一次事故需要两本时钟：服务恢复时钟，以及写入结果的对账时钟。