摘要

  • AFRINIC于2026年2月19日表示，持续数月的网络流量已超过毛里求斯数据中心当时的连接容量，部分在线服务响应变慢，内部支持工作也受到影响。
  • 公告确认带宽升级已经获批、实施正在进行，却没有公布完整的受影响服务范围、原始性能基线、目标容量、启用时间、观测窗口或验收结果。
  • AFRINIC公开的服务承诺把可用率、首次响应和问题解决分别定义。服务器开机并联网，并不能单独证明服务速度已经恢复。
  • 无需公开拓扑、供应商合同或会员个案，也可以用一份有限的“容量—服务验收记录”把扩容启用与各类服务的性能结果连接起来。

衡量在线服务，最容易犯的错误之一，是把“还在运行”写成“已经正常”。前者回答电源和连接是否持续，后者还要回答用户操作需要多久、错误是否下降、支持人员能否顺利完成工作。

AFRINIC的临时服务延迟公告没有把两者混为一谈。公告称，在此前数月，持续的网络流量超过了毛里求斯数据中心现有的连接容量。因此，部分在线服务“可能比平时响应更慢”；内部支持效率也受到了约束，会员查询和服务请求的响应时间可能长于通常标准。

公告同时给出处理方向：带宽升级已获批准，并正与服务商共同实施，预期将显著提升容量、恢复正常服务性能。

这些表述足以确认压力、影响、决定和目标，却还没有构成一个完成记录。哪些在线服务被纳入恢复范围？升级前的容量和服务表现是什么？批准的目标是什么？新连接何时真正进入运行路径？应当在什么流量条件下观察多久？谁依据哪些结果宣布恢复？公告没有回答这些问题。

这不是“升级失败”的证据，也不能证明AFRINIC没有内部监控或变更记录。它只说明，从本次核查到的公开材料中，外部读者无法重建升级从实施走向验收的最后一段。

可用率没有测量“快不快”

AFRINIC的服务水平承诺是2015年11月发布的第1版。文件承诺每项服务达到99.8%的可用率，网络也达到99.8%的可用率。它对可用率的定义很具体：服务器在物理上处于开机状态，并通过互联网连接到正在运行的服务。计划维护、第三方服务不可用、终端用户连接问题和不可抗力不计入计算。

这项指标保护的是运行连续性的底线。服务器如果断电或断网，在线登记服务就无从谈起。但定义中没有延迟门槛，也没有交易完成时间。一个页面可以在十几秒后才出现，同时仍满足“服务器开机并联网”的字面条件；内部工具也可以持续可达，却让支持人员每次操作都等待更久。

同一份承诺还把另外两种时间分开。AFRINIC承诺在两个工作日内对所有查询作出有效响应；“响应时间”指对问题作出反应的速度，“解决时间”则从问题被记录开始，直到问题完全解决。

因此，收到第一次答复不等于问题已经解决；问题结案也不等于所有相关在线服务在同一时刻恢复；服务器可用更不能自动说明带宽压力消失。

指标 它能回答的问题 它不能单独证明的结果
服务或网络可用率 在扣除相应例外后，服务器是否开机并保持互联网连接 交易是否足够快，容量拥塞是否结束
首次响应 AFRINIC多快开始回应一项查询或问题 该问题何时得到完全解决
解决时间 从登记到完全解决经过多久 首次回应是否及时，底层服务是否同步恢复

扩容之后，这三条曲线可能不同步。链路容量增加，在线操作的延迟可以很快下降；但拥塞期间累积的请求还需要时间处理。工作人员也可能按时发送首次答复，案件却因为复杂性长期未结。反过来，某个应用自身的瓶颈可能继续存在，即使新的互联网连接已完全达到合同目标。

如果只发布其中一项，读者很容易把它解释成全部。正确的做法不是强迫指标同时转绿，而是保留每项指标实际证明的范围。

“正在实施”之后还有四道边界

一次容量变更至少经过授权、交付、启用、观测和验收。批准回答“可以做什么”；供应商交付回答外部依赖是否到位；启用表示运行路径实际改变；观测检查改变在有代表性的负载下怎样表现；验收才决定结果是否满足原先目标。此后还可能出现部分通过、继续监测、修正或回退。

2月公告把带宽升级放在“已批准、实施中”的位置。它没有给出启用日期，更没有声称验收完成。不能把“实施中”推成“尚未完成至今”，也不能反过来把批准公告当作性能已经恢复的记录。

由于原问题来自“过去几个月的持续流量”，观测窗口尤其重要。在低峰时刻做一次测试，不能代表造成拥塞的条件。验收至少应覆盖可比较的负载，或者解释替代测试为何足以代表原场景。

服务范围也不能被一个网络平均值抹平。共享链路扩大后，一类服务可能恢复，另一类服务却受制于不同依赖；整体延迟的改善也可能掩盖某个关键操作仍然缓慢。因此，验收对象应当是服务类别，而不必是公开的主机与拓扑。

一份对外记录可以比内部工程报告薄得多。精确链路容量、供应商参数、节点地址和会员数据都可以留在受保护材料中。公开部分只需使用服务类别、时间窗口、阈值区间和结果状态，留下足够的连接关系：

记录要素 要保留的连接关系
原公告与变更标识 确认验收对应2月所述问题，而不是后来另一项扩容
受影响服务类别与退化窗口 界定“恢复正常”所指的对象和时间
隐私安全的基线与批准目标 分开记录起点和授权结果
供应商交付与启用时间 不让采购批准冒充运行变更
代表性负载与验收窗口 不让一个安静时刻代表数月持续压力
各类服务的延迟、错误和可用率 让速度、失败和连接保持各自含义
首次响应与解决结果 让支持工作与系统性能相关但不混同
例外、结论、责任人与修订 支持部分通过、继续测量、回退和更正

这份记录无需创造新的服务承诺。它只检验公告已经说出的目标：新增容量是否使相关服务恢复到认可区间。公开状态可以是“已启用、测量中”“部分验收”“已验收”或“已回退并修正”，而不是只有成功与失败。

部分验收尤其重要。如果连接层已经达到目标，但某项应用仍受另一个系统约束，记录应保留这一分界。这样既不会把应用问题错误归咎于带宽采购，也不会用连接层的成功遮住会员实际面对的延迟。

状态页能发布结论，不能替结论提供依据

AFRINIC已经在另一件无因果关联的事件中展示过公开状态如何推进。4月的一则权威DNS服务退化通知从调查状态开始，经过后续更新，最终明确标为已解决。它不能说明2月扩容是否完成，也不能证明两个事件有关；它只证明现有公开界面能够承载阶段更新和关闭状态。

本次获取的状态历史页面展示了2026年1月、4月和6月的归档入口，所见响应中没有2月条目。这一观察只适用于取得的页面。它不能证明内部没有事故或变更记录，不能证明过去从未有其他公开入口，也不能证明升级未完成。

即使增加“已解决”标签，也仍需要回答解决了什么。DNS事件有DNS自身的验证方法；容量压力需要把启用时间、代表性流量和服务表现连接起来。状态页负责呈现，验收记录负责使呈现可核查。

现有证据停在哪里

公开材料没有给出原容量、新容量、供应商、启用日期或测量结果。它没有说明所有服务是否同步恢复，也没有说明是否存在阶段性验收、供应商延期或后续调整。它更没有证明2026年8月仍存在服务退化。

材料也不能证明违反服务承诺。公告说会员请求的响应可能比通常标准更长，却没有提供一个超过两个工作日的具体案件。服务变慢也不等于服务器断电或断网。缺少公开验收结果不等于升级失败。

可以确认的边界更窄，也更有用：AFRINIC用性能语言描述问题，用容量语言描述措施，用恢复正常性能描述目标；其服务承诺又把可用率、首次响应和完全解决拆成不同对象。完成记录应当沿用这些区分。

扩容启用是基础设施事实，服务恢复是运行结果。只有把两者放进同一个可验证的时间和指标框架，公告中的目标才真正获得一个公开终点。

来源