摘要

  • RIPE NCC 于 11 月 3 日欧洲中部时间 15:55:39 公开开始调查 LIR Portal 资源信息访问时断时续的问题，16:50:45 标记解决。两条公告相距约 55 分钟，是公开报告区间。
  • 17:17 发布的复盘称，负载均衡器故障切换影响了使用数据库的应用；团队清理失效连接作为短期处置，下一步检查连接池配置并改善连接使用监测。

RIPE NCC 的事故记录写得短，却比一页“服务已恢复”的绿灯更有价值。负载均衡器完成切换，应用仍拿着失效的数据库连接。团队把这些连接清掉，会员门户的资源信息访问问题得到解决。机器有备用路径，软件却还惦记原来的门牌。这个细节决定了备用路径能不能成为真正的服务。

公告的时间顺序清楚。事故 API把调查更新记在 15:55:39.649，把解决更新记在 16:50:45.437。两次更新相隔 55 分 5.788 秒。RIPE NCC 没有公开逐笔失败请求的时间线，因此这 55 分钟是运营方的公开处置区间，不能拿来当每位会员的停机时长。真正确定的事实，是资源信息入口出现间歇性访问问题，受影响的组件列为 LIR Portal。

资源信息并非门户里的装饰。RIPE NCC 10 月介绍 My Resources 改版的文章从会员工作出发：在门户查看 IPv4、IPv6 和 ASN，辨认分配与再分配的层级，核对登记、使用和路由信息。文中树状视图、自动检查和侧栏仍处于设计与测试阶段，不能倒填成 11 月 3 日已经上线的功能。但会员要从这个入口辨认自己的资源，早已是现实工作。

因此，注册局的连续性不能只按数据库是否存在来算。地址记录留在后端，会员端却取不到，信息保管与信息可用就分了家。RIPE NCC 的复盘把这个分叉具体化：故障切换、旧连接、人工清理。它没有说故障切换由什么触发，也没有列出受影响会员和请求数量。缺的正是这些范围数据，以及下一次切换后从会员视角复测资源查询的结果。

复盘提出的两项长期动作也不能混成一句“加强稳定性”。检查连接池配置，是让应用在底层路径变化时主动舍弃旧连接；改善连接使用监测，是让团队看见哪些应用仍在向失效会话发问。前者改行为，后者改可见性。RIPE NCC 没给出完成日期或验收方式。若没有从门户完成一次真实资源查询的验收，负载均衡器的健康状态很容易先于会员体验变绿。

这起事故的可核对结果已经足够尖锐：RIPE NCC 清掉旧数据库连接后解决了门户问题，并承认连接池与监测还要补课。注册局的备用路径，最后要由查询成功来签收。

RIPE NCC 原始记录