摘要

  • RIPE NCC 在 2026 年 11 月 3 日欧洲中部时间 21:06:58 将专门的 RPKI 控制台维护单标记完成。这张单据 21:00:08 才进入进行中状态。另一张 Access、LIR 门户和数据库维护单在 21:08 后仍显示进行中，并把同一 RPKI 控制台加进了组件清单。
  • RIPE 的组件状态接口继续把 RPKI 控制台标为 under_maintenance，与此同时专门的控制台维护单已写着 completed。官方记录没有给出一次成功登录、打开控制台并提交 ROA 的端到端测试，无法替会员在两张状态卡之间做选择。

一张工单宣布收工，一块同名组件却还挂着“维护中”。这不是浏览器缓存中的两种颜色，而是 RIPE NCC 自己的两个 API 答案。11 月 3 日 21:06:58，专门的 RPKI System Maintenance 记录发布完成更新；它在 21:00:08 进入进行中，列出的组件是 RPKI Dashboard。六分多钟，动作利落。问题是会员的操作并不只经过这张工单。

并行的 Access、门户和数据库维护记录在执行期间也列出了 RPKI Dashboard。21:08:58 的更新说维护仍在进行，21:41 后保存的接口响应依然是 in_progress。预计结束时间先变成 21:40，随后又变成 21:59。组件状态接口显示，RPKI Dashboard 的 under_maintenance 标签在 21:08:58 更新，比专用工单宣告完成晚约两分钟。RIPE NCC Access 于 21:41:21 恢复 operational 时，控制台、门户和数据库仍标为维护中。单看控制台专用工单，控制台“完成”；看组件状态，控制台“维护中”。两种判断都来自同一个登记机构。

工单本身还改了内容。开工前保存的 Access 维护单只列数据库、LIR 门户和账户入口，计划 21:10 结束。执行期间保存的版本多出了 RPKI Dashboard，计划结束时间先后变为 21:40 和 21:59。该接口留下了开工和仍在进行的更新，却没有一条带时间的说明，解释何时、为何把控制台加进来，或为何把结束时间累计延后四十九分钟。要还原这个过程，读者只能把不同时间保存的原始响应并排放好。

最后的记录比 21:59 这次预计时间来得早。RPKI Dashboard 组件于 21:46:51 恢复 operational，第二张维护单于 21:47:19 完成。从专用工单 21:06:58 的完工标记，到组件恢复运行标签，官方状态相隔 39 分 52 秒；两张工单的完工通知相隔 40 分 21 秒。21:59 是修订后的计划，不是实际结束时间。一张工单收工后，同名组件的状态仍可持续近四十分钟指向另一边。

状态标签不是用户操作日志。completed 证明 RIPE 为一张维护单发布了完成记录；under_maintenance 证明其公共状态系统当时如何标记组件。它们都不能证明会员在 21:07、21:22 或 21:31 能否登录、打开控制台并提交一条 ROA。RIPE 的托管 RPKI 指南写得清楚：会员通过与 LIR 关联的 RIPE NCC 账户进入控制台管理路由源授权。Access 指南也把控制台列为该账户的服务目的地。一次更改横跨入口和应用；两张工单的界限挡不住会员的鼠标。

真正的问题不是“哪张工单先结束”，而是两张工单都指向同一组件时，谁决定它何时可用。专门的控制台工单关闭后，组件为何继续显示维护中？是第二张工单仍控制着它的状态，还是状态字段落后于实际服务？公开接口没有交代。即便底层服务始终能用，会员也无法从公开记录中得到一个可执行的答案。

RIPE 无需把每次内部变更写成事故小说。给每个组件一个权威状态，标明哪张仍开放的工单持有这个状态；增添组件或改动预计结束时间时保留变更时刻；完工更新写清是否测试过登录、打开控制台和提交 ROA。这样，“完成”才是会员可以使用的运维信息，而不只是工单系统中的一枚章。

RIPE NCC 原始记录