摘要

  • 9 月 15 日，MyAPNIC 一个组件的配置变更对其他功能造成超出预期的影响；9 月 17 日，数据库问题延迟了发往工单系统的邮件，并使部分 MyAPNIC 功能不可用。
  • 两次事故时长相同、时间接近，并不能证明共同原因。真正缺少的是 APNIC 是否比较了依赖路径，以及结论为“发现关联”“排除关联”还是“仍未知”。

APNIC 的9 月 15 日服务公告记录，MyAPNIC 会员门户事故从 UTC+10 的 13:58 持续到 14:26，共 28 分钟。公告把直接机制限定为：一个 MyAPNIC 组件的配置变更，对其他 MyAPNIC 功能产生了比预期更广的影响。APNIC 表示正在修复，以免类似变更再次造成相同影响。

9 月 17 日公告记录了另一段 28 分钟窗口，从 14:50 到 15:18。这里的直接机制是数据库问题：发往工单系统的邮件被延迟，部分 MyAPNIC 功能不可用。APNIC 的后续方向是改进数据库监控，以便在问题再次影响服务前修复。

这两条因果边界不能混写。第一条谈的是配置变更的影响范围，第二条谈的是数据库问题。公告没有说前者导致后者，没有说两者共用同一个组件或数据库，也没有报告数据丢失、安全泄露、路由影响或号码资源登记错误。

两次事故的开始时间相隔 48 小时 52 分钟。相同的 28 分钟可能来自相同的检测、升级或恢复节奏，也可能只是巧合。它足以触发一次核查，却不足以支持共同根因结论。

公开记录没有回答一个更窄的问题：APNIC 是否比较过身份认证、消息队列、数据存储、配置系统、部署路径、监控盲区或人员交接？如果比较过，是否发现共同因素、排除了共同因素，还是证据仍不足？

回答这个问题不需要公开内部拓扑。一份隐私安全的关联回执，可以只列出两次事故编号、受影响的能力类别、证据时间窗和已经检查的依赖域，然后给出三态结论：发现、排除或未知。它还可以记录整改责任人、遏制状态和复核日期，而不披露主机名、凭据、会员数据、工单内容、员工身份或可被利用的技术细节。

两份公告提出的是不同的局部修复。限制配置变更的影响范围，不等于改进数据库故障检测；加强数据库监控，也不会自动缩小变更的影响面。如果核查后确认两次事故互相独立，公开这一结论会让两套修复更可信。如果存在共同运行表面，就应有跨团队措施。如果仍无法确定，明确写出“未知”也比两份彼此孤立的结案说明更有价值。

这不是要求 APNIC 公开取证材料，更不是预设共同原因。它只是要求在两条已有公开记录之间增加一个可审计的连接：事故说明回答各自发生了什么，关联回执回答组织是否检验过它们之间的边界。

来源