摘要

  • Cloudflare计划从8月19日17:00 UTC至20日12:00 UTC维护HKG数据中心。05:54 UTC冻结证据时，事件仍为“计划中”，香港组件保持正常运行。
  • 官方说明称普通流量可能被改道，同时要求连接HKG的PNI/CNI客户预计流量会切换到其他位置，因为当地网络接口可能暂时不可用。两种改道并不由同一方独立完成。

一句“流量将改道”，很容易让人误以为平台已经包办了连续性。Cloudflare这次香港维护公告恰好说明，互联网边缘服务中至少存在两条不同的控制链。

官方事件页显示，HKG站点的计划维护窗口长达19小时，从8月19日17:00 UTC持续至20日12:00 UTC。Cloudflare称，流量可能离开该位置，受影响地区的最终用户可能看到轻微时延上升。对PNI和CNI客户，公告又单独提示：数据中心内的网络接口可能暂时不可用，因此要预计流量在其他位置完成故障切换。

截至05:54 UTC，计划维护数据源仍把事件my45g1324mkk标记为scheduled，HKG组件为operational。这个时间点只能证明风险已经公告，不能证明维护已开始，更不能证明出现丢包、路由撤回、时延上升或客户中断。

第一条控制链属于Cloudflare的共享边缘网络。其CDN架构说明指出，Anycast让多个站点发布相同IP地址，BGP把请求引向可接收流量的节点。一个站点不可用时，请求可以到达附近其他节点。因此公共服务可能保持可达，但路径变长，这也是公告保留时延上升可能性的原因。

第二条控制链跨越Cloudflare与客户。Network Interconnect文档把CNI定义为私有点对点IP连接；在对等互联场景中，连接在每个独立PoP建立。如果HKG接口不可用，客户需要另一个接入点或互联网备用路径，还必须让自己的路由策略真正把流量交给那条路径。

这里的控制边界很具体。Cloudflare控制维护、Cloudflare侧接口以及其网络内部的流量调度。客户控制或采购备用端口、BGP邻居、前缀接收、过滤、local preference、流量工程与容量。机房或电路提供商则可能控制两端之间的交叉连接或虚拟电路。任何一层没有准备好，都可能使“其他位置”只存在于设计图中。

Cloudflare自己的文档也没有把这部分责任藏起来。CNI能够提供的多样性因位置而异。在支持设备级多样性的站点，连接若终止于不同设备，可在维护期间保持连通；单设备部署在维护时可能完全中断。CNI实施必须保留替代互联网连接，客户还要负责规划可用链路之间的容量。

因此，BGP会话“已建立”不是连续性的最终证据。备用会话可能缺少关键前缀，过滤规则可能阻止路由，优先级可能没有切换，链路也可能在承接HKG流量后饱和。两条链路甚至可能共享设备、机房、承运商或物理路由，从而形成共同故障域。

这些风险分析不能反过来写成香港会发生事故。官方没有公布具体机房、设备、PNI/CNI客户、电路或备用站点，也没有给出预计流量、可用余量、收敛目标和回退门槛。公告使用“可能暂时不可用”和“可能改道”，而不是已发生或保证成功。

运营团队在17:00 UTC前可以核实自己掌握的证据：端口状态、BGP邻接、收到和发布的前缀、过滤与最大前缀设置、路由优先级、备用链路利用率，以及应用层时延和丢包基线。若备用路径由第三方提供，还应确认其是否与主路径共享同一设施或物理承载。

事件范围也必须保持准确。这是HKG单站维护，不是Cloudflare全球故障。Anycast正是为了降低共享服务对单一位置的依赖。更集中的风险属于那些把香港作为私有接入点、首选路径或源站邻近节点的客户，而公共状态灯无法描述每个客户的拓扑。

20日12:00 UTC之后，“已完成”可以证明Cloudflare结束了工作，却不能替客户证明服务路径的表现。更完整的记录应包括接口何时变化、路由迁移到哪里、收敛用了多久、备用链路是否逼近容量，以及时延和丢包相对基线如何变化。控制权分散，证据也必须来自多方。

来源