摘要

  • AFRINIC 2025 年年度报告称，其已启动缩减实体数据中心版图、增加云与混合模式使用的战略调整；同一报告还列出新版 Bacula、关键服务完整备份覆盖、AWS S3 异地备份、每季度恢复测试和 Ansible 自动化。
  • 这些措施首先应被视为真实改进，而不是故障证据。但“备份任务完成”“对象可以读取”“快照完成恢复”“应用启动”“成员完成关键操作”是相互衔接却不能互相替代的状态。
  • AFRINIC 可以发布一张不泄露安全细节的服务—恢复控制地图，披露目标、测试场景、完整性与业务验收、供应商控制环节、异常和最近一次独立环境演练，而无需公开账户、存储桶、密钥或应急命令。

一项合理的现代化计划

先把 AFRINIC 的方案按它最有利的方式理解。年度报告描述的不是把基础设施责任交出去，而是一次有具体工程内容的更新。2025 年，AFRINIC 淘汰了陈旧和达到生命周期终点的设备，更换故障网络和存储部件，部署 10G 对等互联基础设施，扩充备份存储，并准备冗余路由与上联设计。报告涉及毛里求斯、约翰内斯堡、Parklands、蒙巴萨和 Isando 的工作，也明确指出部分项目仍取决于供应商时间表和审批。

在这样的基础上，减少自有物理空间完全可能是一项稳健选择。旧服务器不会因为属于自己就自动带来自主性；它也可能只是一个越来越难维修的已知故障点。异地副本能够避开单一物理事件。云或混合资源可以在第二座自有机房尚未准备好时提供恢复算力。Bacula 和 Ansible 有机会把依靠少数工程师记忆的过程变成可重复步骤。每季度真正执行恢复，远比只汇报备份任务完成率更接近韧性本身。

正因为这些收益成立，控制问题才值得认真对待。实体机柜减少，不代表控制边界也随之减少。原先集中在设备和机房里的风险，可能被重新分配到账户、身份、权限、区域、加密密钥、恢复语义、合同以及审批队列。依赖某一环节本身不是失败，更不等于供应商违约；但测试若没有说明跨过了哪一道边界，就无法回答它真正覆盖了哪一类事故。

公开报告已经给出方向，却没有给出逐项恢复路径。它说关键服务实现完整备份覆盖，并把 AWS S3 用于异地备份；它没有披露哪些权威数据类别进入这一链路、所有服务是否走同一路径、各自的 RPO 与 RTO、测试的是哪一个快照、存储区域是什么、账户与密钥由谁控制、恢复了哪一版应用、测试目的地属于什么环境、具体检查结果如何，以及是否执行过离开日常供应商控制面的恢复演练。这里列出的都是未公开事实，不应被写成已经发现的缺陷。

“已经恢复”至少有九种含义

第一种状态，是备份任务顺利结束。第二种，是写入存储的对象后来仍能读取。第三种，是选定的快照能够在某一目的地完成还原。第四种，是还原后的数据通过模式、签名与引用完整性检查。第五种，是应用能够以这些数据启动。第六种，是公开端点对请求作出响应。第七种，是成员或依赖方能够完成真正重要的业务动作。第八种，是整个结果满足既定恢复点目标与恢复时间目标。第九种，是同一权威状态可以在不依赖日常控制环境的条件下被重建。

前一个状态不能自动证明后一个。数据库进程启动，可能仍然使用不兼容的版本。网页返回 200，不代表经过身份验证的资源操作能够完成。所有字节都存在，也不代表对象之间的引用和签名仍成立。业务最终恢复，可能已经超过 RTO；副本最终可用，也可能丢失超过 RPO 所容许的变更。一次在原账户、原区域、原密钥体系内完成的优秀测试，仍然不能说明失去这一控制面之后会发生什么。

对区域互联网注册管理机构而言，这种区分不是技术洁癖。WHOIS、MyAFRINIC、DNS 和 RPKI 不是一般内容网站。它们承载注册数据、授权动作以及其他网络和依赖方据此作出的判断。恢复数据库进程只是中间事件，恢复权威服务才是终点。测试的完成条件应从成员或依赖方的实际动作来定义，而不应由备份工具的绿色图标代替。

这并不要求公开攻击面。AFRINIC 无需透露账户 ID、存储桶名称、密钥材料、设施位置、网络拓扑或紧急命令。它可以只说明目的地类别、权限与密钥的控制类别、测试跨越的边界、检查类型和完成时间。公开“控制结果”与公开“操作秘密”不是一回事。

供应商边界早已出现在公开承诺里

AFRINIC 当前公开的服务等级承诺标注为 2015 年 11 月第 1 版。它覆盖注册与客户服务、数据库和公共在线服务、反向 DNS、计费以及服务基础设施，并点名 WHOIS、MyAFRINIC、服务网站、IRR、DNS、DNSSEC、邮件和 RPKI 等系统。该文件对每项服务及网络作出 99.8% 的可用性承诺，同时把第三方不可用时间排除在计算之外。

文件还说，AFRINIC 无法替第三方供应商提供服务等级承诺，但会努力在影响核心服务的商业关系中体现自身承诺。这段文字没有证明任何供应商曾经失职，也不能被当作合同违约记录。它的意义在于，公开承诺已经划出了一条测量边界。随着云与混合模式使用增加，这条边界会更加频繁地进入恢复过程。

若一次恢复必须等待外部权限或供应商审批，成员所经历的中断并不会因此暂停。合同可以分配责任，服务恢复时钟却不应把某段等待删除。更有价值的做法，是保留从事故开始到业务验收的完整时间，再区分其中哪些阶段由 AFRINIC 控制、哪些由供应商控制、哪些仍存在未解决的审批。

年度报告称，关键服务在 2025 年的可用性通常高于 99.7%。在本次证据截点，公开状态页把 WHOIS Database、MyAFRINIC Portal、AFRINIC Web Sites、Mailing Lists、New Member Registration Portal、DNS Services、RPKI Systems 和 Other Systems 均标为 Operational；被冻结页面的根组件没有指标摘要。这些信息并不互相否定，却回答三道不同的问题：年度百分比描述一段时期的结果，绿色状态描述当前时点，恢复演练描述从失败状态回到可用服务的能力。

把三者放在同一个表里并不会让证据更强，反而容易让读者误以为可用性等于可恢复性。真正需要的，是让每个数字保留自己的对象、时间区间和判定条件。

S3 的能力说明了为什么测试必须带条件

AWS 的灾难恢复文档提供了理解边界的工具，但不能用来猜测 AFRINIC 的实际配置。在共享责任模型下，AWS 负责 S3 等托管服务的基础设施层；客户仍对数据韧性负责，包括是否以及如何使用备份、版本控制和复制。

AWS 文档说明，S3 备份能力可以包括连续或周期性备份、时间点恢复以及对备份数据的直接访问。通过 AWS Backup 为 S3 建立备份，需要先启用 S3 Versioning。恢复结果还可能受权限和角色、访问控制列表、目的地版本控制状态、区域和加密密钥可用性的影响。若目的地已存在相同名称或版本 ID，对象可能被跳过；恢复到原存储桶是非破坏性的，并不是对全部现有对象进行统一覆盖；跨区域副本只能在包含原件或副本的区域中恢复。

这些是产品能力与限制，不是 AFRINIC 使用方式的证据。公开资料没有证明 AFRINIC 使用 AWS Backup、S3 Versioning、Replication、跨区域副本、某一指定区域、特定 IAM 设计或某种加密方案。恰恰因为不能推断这些事实，“S3 恢复成功”才需要说明场景。它可能只证明对象可读，也可能证明应用重建、成员操作成功或独立环境退出；四种结果都有价值，但含义完全不同。

进一步说，即便两个测试都在技术上成功，它们也可能产生不同的权威状态。一个测试可能因为同名对象而跳过部分版本，另一个可能在干净目的地完整重建。一个测试可能沿用原有密钥和身份，另一个则证明替代控制面有效。若报告只留下“通过”，后来的治理者无法判断哪一种风险曾经被覆盖。

一张不泄露蓝图的控制地图

AFRINIC 可以把现有工程成果压缩成一张安全的公开表格。每一行对应一个公开服务组件和适度抽象的权威数据类别，并列出恢复点目标、恢复时间目标、非敏感演练标识、数据时间点、完整性哈希和保留类别。

随后，表格把 AFRINIC 控制的功能阶段与供应商控制阶段分开。恢复场景和目的地类别说明测试是否跨过账户、区域或提供商边界。权限与密钥只以控制类别呈现，例如“机构独立控制”“共同控制”或“供应商路径”，不展示任何凭据。检查结果分别记录完整性、模式、签名、引用关系、应用启动、端点响应以及成员或依赖方验收。

时间至少需要三项：演练开始、技术上可用、功能上接受。这样，快速启动但迟迟不能办理业务的情况不会被一个平均数字掩盖。跳过对象、失败检查、未决供应商审批、修复负责人、截止日期和回滚或更正路径也应保留。测试出现问题并不可耻；问题在下一个报告中无声消失，才会削弱制度学习。

最后一列记录最近一次独立环境演练。这里的“独立”不一定要求长期维护完整的第二套平台。它意味着 AFRINIC 按适当周期证明：在日常账户、区域、身份面或供应商不可用的假设下，权威状态与最低可用服务仍可被重建。具体架构可以保密，是否真正演练则是可以公开的治理事实。

这样的地图不会自动保证下一次恢复成功。它可能过时，也可能需要独立抽查。但它提供了稳定语法：读者能够知道一次测试到底做了什么，下一季度的结果也能与上一季度比较。一次公开记录、随后修复的失败，往往比连续四次定义不明的“成功”更能说明控制成熟度。

证据没有告诉我们的事

现有材料没有显示 AFRINIC 发生过中断、恢复失败、备份缺失、安全事件或数据丢失。它没有说明全部关键服务或全部权威注册数据都存放在 S3，也没有证明某个供应商未履约。没有证据表明 AFRINIC 当前被 AWS 锁定、无法退出，或其 99.7% 年度数据有误。状态页不是历史可用性档案，但这不等于其当前 Operational 标签不真实。

同样，提出公开控制地图并不意味着现行内部测试薄弱。季度恢复、自动化、异地副本和部门级业务连续性规划，已经比只做备份不做验证更进一步。本文的主张是预防性的：当基础设施从自有物理边界转向云与混合边界时，证明也应随之移动。

因此，这不是一篇“云好还是坏”的文章。AFRINIC 已经给出缩减过时设备、降低维护负担、改善成本可预测性和灾难恢复的正面理由。真正的治理问题，是服务责任变得分布式以后，机构是否仍能完整说明谁把什么恢复到了何种状态、用了多长时间，以及测试跨过了哪一道控制边界。

来源