Virgin Media 2023 年 AS5089 中断事件：路由撤销与边缘隔离成为问责考验

摘要

• 2023 年 4 月 4 日，英国 Virgin Media（技术观察者将其识别为 AS5089）遭遇两次重大中断，导致更广泛的互联网对其网络和服务的可达性受损。[1][2]
• Cloudflare 观测到约 00:30 UTC 流量跌至接近零，随后恢复并不稳定。ThousandEyes 描述了第一次事件（约 00:30 至 07:00 UTC）和第二次事件（约 15:20 至 17:30 UTC）。[1][2]
• ThousandEyes 将观测到的大部分流量损失归因于通往 Virgin Media 网络的有效 BGP 路由缺失。它还观察到另一种情况：部分提供商保留了通往 AS5089 的路由，但流量在 Virgin Media 边缘被丢弃。[2]
• 这些观测确立了路由与转发故障模式，但并未确立引发事件的命令、设备、供应商、人员、维护活动、网络攻击或其他根本原因。
• 当天晚些时候的再次发生，使恢复证据成为核心。路由重新出现不等于服务稳定恢复，内部绿色状态也不能证明多样化的外部网络能够到达并穿越边缘。
• 问责遵循实际控制。Virgin Media 控制着路由起源宣告、撤销、边缘策略、内部转发、恢复时序、事件披露和客户补偿；对等网络控制着各自的路径选择和证据；测量提供商提供了独立观测，但无法还原未公开的内部状态。
• 当前的 PeeringDB、RIPE 相关记录和路由记录可以识别 AS5089 及其互联背景，但它们并不是 2023 年 4 月 4 日网络的定格快照，不得当作事件遥测数据使用。[6][7][8][9][10][11]
• RFC 4271、RFC 7454、RFC 8212 和 MANRS 提供了协议与运营背景，但均不能证明 Virgin Media 当时部署了哪些控制措施，也不能证明某一项控制就能阻止该事件。[12][13][14][15]
• 一份可信的问责记录应当对齐三个时钟：路由可用性、数据包转发和客户可见的服务。它应保留精确的观测结果、标注推断、暴露未知项，并记录只有运营商才能产生的证据。

事件是两次中断，而非含糊的一天宕机

大型网络故障往往被概括为一个开始时间、一个结束时间和一个客户数量。这种格式很方便，但它可能抹去决定责任归属的机制。Virgin Media 中断事件更适合理解为两个被观测到的时段、若干不稳定的恢复阶段，以及至少两种外部可见的故障状态。

Cloudflare 的流量视图将第一次重大崩溃定在 4 月 4 日约 00:30 UTC。与 Virgin Media 相关的流量跌至接近零，服务并非通过一次干净利落的切换而恢复。其图表和随附说明描述了部分恢复、进一步下跌和随后另一次中断。这份记录的重要性不在于 Cloudflare 能看到每一位 Virgin Media 客户——它看不到；而在于一个大型外部网络观测到涉及 Virgin Media 自治系统的流量发生急剧变化。[1]

ThousandEyes 将第一次事件描述为大约从 00:30 持续到 07:00 UTC。它记录了 BGP 路由撤销、流量损失和间歇性的恢复。第二次事件于约 15:20 UTC 开始，约 17:30 UTC 结束，具有相似的外部特征。这一时间线支持“可达性两次失效”的判断，但不能证明两次事件由同一个内部组件或变更引发。[2]

当时的报道捕捉到了面向客户的一面。The Register 报道了大规模宽带中断，以及 Virgin Media 承认客户正遇到问题。这些证据有助于确认路由观测与服务影响相对应，但并不会把社交媒体消息或公司声明变成完整的技术复盘。[3]

区分两次中断之所以重要，是因为两次之间出现过恢复。运营方在第一次事件后宣布服务恢复，是在作出一个运营声明：网络再次可达、转发正常，且足够稳定以承载预期流量。随后的再次中断可能表明触发因素并未消除、恢复标准过于狭窄，或者存在另一个相关但独立的故障。公开记录并没有告诉我们哪种解释是正确的。

因此，本文不会把所有症状拼凑成一条虚构的时间线，而是把观测到的时段当作一个有边界的问责案例。第一个问题是外部世界能看到什么；第二个问题是只有 Virgin Media 才能知道什么；第三个问题是应当有哪些证据把这两种视角连接起来。

AS5089 是运营边界，而非品牌细节

自治系统编号标识的是一个向其他网络呈现一致路由策略的网络。它并不描述每一台内部路由器、光缆、接入段或商业产品，但它确实为域间问责确立了一个有用的边界：其他网络与该自治系统交换可达性信息，并根据由此形成的路径转发流量。

技术来源将英国 Virgin Media 识别为 AS5089。当前 PeeringDB 数据在该 ASN 下描述 Virgin Media，并记录了互联足迹、AS-SET 和公共对等互联信息。当前的 BGP 工具和 RIPE 相关工具也将 AS5089 与 Virgin Media Limited 关联，并显示已宣告的网络资源。这些记录有助于把事件绑定到正确的网络身份上。[6][7][8][9][10][11]

这些记录必须谨慎使用。PeeringDB 页面在运营方更新记录后可能发生变化；当前的前缀可能不同于 2023 年 4 月宣告的前缀；当前的 RPKI 状态本身并不能说明中断期间某条路由的状态；注册对象记录的是管理和路由信息，它不能证明数据包在某一分钟穿越了某个边缘。

注册机构与网络目录是证据记录，有助于识别资源持有者、路由对象和联系途径，但它们并不是让运行中的网络保持健康的声明。运营真相体现在对等网络实际收到的路由，以及该网络实际接受并转发的数据包中。

AS 边界还能防止责任消解在“互联网”这个词里。互联网是众多独立运营网络的集合体。远端内容提供商可能有正常工作的服务器，转接提供商可能维护着通往 AS5089 的路径，客户设备在当地也可能正常工作。然而，如果通往接入网络的路由消失了，远端网络就无法投递流量；如果路由仍然存在但运营商边缘丢弃数据包，那么可见的路径仍然无法产生服务。

Virgin Media 并不能控制每一个远端对等网络、解析器、应用程序或客户设备。它控制的是自己的路由起源宣告、边缘行为、内部转发和恢复流程。这正是公允问责分析应当从之出发的实际控制边界。

路由撤销使可达性消失

BGP 允许自治系统交换关于它们可达哪些地址前缀、经由哪些路径的信息。RFC 4271 定义了该协议模型。路由并不保证应用程序一定可用，但没有可用路由时，流量通常无处可去。[12]

ThousandEyes 观察到，4 月 4 日事件中大部分流量损失与通往 Virgin Media 网络的有效 BGP 路由缺失有关。路由被撤销后，其他网络无法再选择这些路径。发往受影响前缀内地址的数据包会在上游被丢弃，或在反复连接尝试后失败。[2]

这不仅仅是附带的技术症状。路由起源宣告是接入服务商让全球互联网可达其网络的主要方式之一。撤销路由可能是刻意为之的安全动作、会话中断的后果、策略结果、自动化效应，或另一种故障的产物。公开来源并不能确定这里实际发生的是哪一种机制。

根本原因细节的缺失并不会让问责变得不可能，只是改变了问题：哪些前缀消失了？哪些对等网络先收到撤销？所有外部路径是一起消失还是分批消失？IPv4 和 IPv6 的表现是否相同？哪些监测系统检测到了变化？什么内部健康信号授权了重新宣告？在宣布面向客户的恢复之前，必须通过哪项验收测试？

这些问题是对证据的要求，而不是指控。它们把可观察的行为对应到运营方理应拥有的记录上。路由服务器、边缘路由器、自动化控制器或监测系统可以用时间戳记录变化；变更管理可以记录当时是否有部署在进行；外部路由采集器可以呈现部分外部视角。没有任何单一记录是完整的，但合在一起可以建立一条经得起推敲的时间线。

运营风险比单个协议会话更大。接入网络可能通过多个边缘宣告大量前缀。一次撤销大范围路由的故障可能同时隔离服务、客户地址空间、DNS 基础设施、管理系统和支持渠道。受影响的用户随后会体验到不同的应用错误，尽管共同的故障是可达性。

因此，问责既需要时间，也需要范围。运营方应当能够说明哪些地址资源受影响、哪些边缘改变了状态、哪些服务依赖这些资源、哪些路径仍然可用。一句笼统的“宽带中断”不足以区分区域接入故障与自治系统级隔离。

可见的路由并不总能带来正常转发

ThousandEyes 报告中最重要的细节是：路由撤销并不能解释所有观测到的故障。据其报告，部分提供商仍能把流量路由到 Virgin Media 网络方向。在这些情况下，流量在 Virgin Media 的边缘被丢弃。ThousandEyes 将这种模式描述为暗示系统性的压力，很可能涉及控制平面。[2]

“暗示”这个词很重要。外部观察者可以看到路径仍然存在、数据包在某个边界附近失败，但无法检查运营方的内部控制状态。边缘丢包可能源于多种情况：转发状态缺失、内部路由不可用、接口受损、策略拒绝流量、容量崩溃或依赖项故障。在没有证据的情况下选定某一种机制，就是把观测变成了虚构。

有边界的结论仍然有力：路由存在与数据包投递发生了背离。对某些路径而言，全球路由系统带着“AS5089 可达”的表面承诺，而运营商边缘并未提供相应的服务。

这种背离是反复出现的网络风险：控制平面状态看起来正常，而数据平面却在失效；BGP 会话仍然建立，下一跳却不可用；前缀仍留在路由表中，数据包却被丢弃；内部仪表盘因为进程存活而把边缘标为可用，端到端探测却失败。

问责的应对之道是要求成对的证据：路由健康要问预期前缀是否通过预期对等网络可见；转发健康要问代表性数据包是否穿越边缘并到达目的地；应用健康要问真实服务能否完成事务。运营方不应把这些层级压缩成一个绿色指示灯。

外部探测之所以有价值，是因为它们从被变更系统之外测试服务。探测应当足够多样化，避免把一个对等网络的视角误当成整个互联网；测量应当既包括收到撤销的提供商，也包括保留路由的提供商，并覆盖相关地区、地址族和服务类别。

结果应当是一张矩阵，而不是一个单纯的可用性数字。路由可以缺失或存在；数据包可以在边缘之前、边缘处或进入之后失败；应用也可以在传输成功的情况下失败。这张矩阵有助于响应者决定是恢复路由宣告、修复内部转发、减载、隔离故障边缘，还是沟通一个更窄的影响范围。

恢复必须在三个时钟上得到证明

4 月 4 日的再次中断让“已恢复”的含义成为核心。恢复不是一个时间戳，而是至少三个时钟之间的共识：路由、转发和客户可见的服务。

路由时钟记录前缀何时被撤销、重新宣告并被对等网络接受，可以包括 BGP 更新流、路由采集器观测和路由瞭望镜检查。由于 BGP 传播是分布式的，不同观察者可能在不同时间看到变化；路由第一次重新出现并不能证明全局收敛。

转发时钟记录流量是否真正穿越运营商边界并到达代表性目的地，包括丢包、时延、路径追踪和主动探测。如果转发状态不完整，它可能滞后于路由重新宣告；即使路由仍然可见，它也可能独立失效。

客户时钟记录用户何时失去服务、支持渠道何时确认问题、状态公告何时变化、客户何时能完成真实任务，以及补偿或投诉流程何时可用。它反映的是商业和社会后果，而不只是网络状态。

负责任的恢复应当对齐这些时钟。运营方应指定一个稳定期：在此期间路由可见性保持一致、来自多个网络的转发探测成功、客户影响指标回到预期范围。如果第一次恢复在稳定期结束前就被认定完成，记录应当解释原因。

公开来源没有透露 Virgin Media 的内部验收标准，但确实显示服务一度好转，随后又发生了一次类似的中断。这足以让我们追问：恢复是被定义为流量的短暂回归，还是稳定的端到端可达性。

答案不应靠猜测。事后记录可以通过公布一条有边界的时间线来提供：改了什么、哪些信号触发了恢复、哪些信号随后恶化、是否涉及相同组件、又增加了哪些额外验证。如果安全或商业考量不允许披露配置，仍然可以公布聚合后的路由与健康证据。

这种做法避免了表演式透明。一篇冗长但没有路由和转发时间戳的叙述可能听起来很坦诚，却让核心主张无法检验；而一份较短但对齐三个时钟的记录能提供更多问责价值。

第二次中断把回滚变成证据问题

部分恢复后的再次中断给响应者带来一个艰难的选择：他们可能相信自己已经消除了原因，也可能只是恢复了症状。这一区别决定了网络是应恢复正常运行，还是应保持在受控状态。

回滚常常被当作一个二元事件：新状态被移除，所以旧状态必然是安全的。分布式网络并没有这么简单。旧配置可能已经恢复，但会话以不同速率重新收敛；缓存或生成的状态可能仍然存在；内部依赖可能不会一同恢复；原本的事件还可能暴露了另一个独立故障。

因此，回滚应当与可观察的不变量挂钩：预期前缀应当存在；意外的撤销或路径抖动应当停止；边缘转发应当能从多个外部网络正常工作；内部下一跳应当有效；容量应当能支撑回归的负载；客户可见的错误率应在规定时段内保持稳定。

RFC 7454 讨论了围绕 BGP 的运营与安全实践；RFC 8212 主张 eBGP 策略应明确采用默认拒绝姿态；MANRS 描述了过滤、协调、验证以及全球路由验证等实践。这些来源有助于界定控制措施类别，但它们并不能证明 Virgin Media 的某一项具体控制失效，也不能证明采用某一建议就能避免这次中断。[13][14][15]

教训更具体：路由策略与恢复需要明确、可检验的条件。运营方应当知道允许对等网络宣告哪些路由、自己将导出什么、在宣告聚合路由之前必须存在怎样的内部可达性，以及哪些独立测量可以阻止或撤回一次上线。

对于全国性接入服务商，金丝雀设计尤为重要。变更可以限制在一个边缘、一个地区、一个地址族或一组受控前缀，然后才扩大部署。金丝雀应在管理域之外进行观察；如果路由或转发不变量失败，自动化应当停止扩大范围并保留证据。

这些都不要求本文声称某项变更导致了 4 月 4 日事件。它为任何解释设定了一个标准：如果原因是一次部署，运营方应展示边界与回滚；如果是设备或依赖故障，应展示为什么冗余未能保住路由与转发服务；如果是多种条件叠加，应展示检测与恢复做了哪些改变。

互联把内部运营变成共同风险

AS5089 并非孤立运行，其可达性取决于与其他网络的会话和策略。PeeringDB 的当前记录标明了与 Virgin Media 相关的互联设施和交换中心参与情况。这些细节是当前背景，而不是对 2023 年拓扑的重建，但它们显示了到达一个大型接入网络涉及多少个运营边界。[7]

当网络撤销路由时，对等网络必须处理更新并在存在替代路径时选择替代路径。当边缘接收流量却无法转发时，对等网络可能继续把数据包送进一条失效路径，直到测量或运营方协调暴露问题。因此，这次事件在互联两侧都产生了证据义务。

Virgin Media 控制的是它起源宣告的路由的准确性、可用性以及边缘背后的转发行为；对等网络控制的是它们接受什么、如何监测路径以及能否联系运营方；测量提供商只能观察它们可用的观测点。

这种控制划分应当体现在事件协调中。对等网络的报告应说明收到了哪些路由、哪些会话仍然在线、数据包在哪里失败、行为何时发生变化；运营方应确认该视角是否与自己的遥测一致。相互冲突的观测应被保留，而不是过早地被归一化成一条时间线。

联系数据在这里很重要。注册机构和 PeeringDB 记录可以提供 NOC 或策略联系人。其价值是实际的：受影响的网络能否联系到有权行动的人？一个存在但无人监控的地址并不是运营控制。联系途径应当被测试和维护，而不要把注册记录变成对运营方的治理主张。

协调还影响客户恢复。拥有多个提供商的内容网络和企业客户可以把流量从失效路径上转移开，而住宅用户通常在事件期间无法选择备选的末梢自治系统。这种不对称让接入服务商承担了更多的连续性责任。

不应把客户无法绕开不可控的 AS 级接入中断归咎于他们。大型对等网络仍应测试自己的路由和升级流程，但它们的准备并不能抹掉运营方对准确路由与转发状态的责任。

监测必须独立于故障网络

影响路由的故障也可能隔离用于诊断和沟通的工具。状态系统、遥测采集器、认证服务和支持门户可能共享同一条网络路径。如果确实如此，运营方会同时失去服务和证据。

因此，独立监测应当位于生产故障域之外。外部路由采集器、主动探测和第三方测量可以检验其他网络看到了什么；内部遥测仍然是必要的，因为它能解释设备与策略状态。两种视角单独存在都不够。

Cloudflare 的报告和 ThousandEyes 的分析说明了外部观测的价值：它们无需访问 Virgin Media 的内部系统就能检测到流量骤降、路由撤销和边缘故障；但它们的数据无法识别引发事件的内部原因。[1][2]

运营方应按时间、前缀、边缘和地址族关联外部与内部证据。时间源必须足够可靠，使响应者能够比较记录；五分钟的时钟偏差就可能扭曲路由撤销、转发故障和运营方行动的先后顺序。

监测还需要反向测试。确认路由存在并不够，还应在代表性前缀内探测目的地址；确认边缘有响应并不够，还应验证客户流量能够穿越它；确认门户从网络内部可以加载并不够，外部客户端也应能够访问它。

设计目标不是制造完美的全局视图——那是不现实的——而是让盲区显性化，并确保没有任何单一故障域提供宣布恢复所需的全部证据。

公开披露应保留未知项

网络事后复盘常常面临相互竞争的压力：客户想要解释，工程师需要时间验证，安全团队可能限制细节，法务团队可能避免可能带来责任的表述。结果往往是一套宽泛到没有任何运营证据价值的措辞。

负责任的披露可以保持有界而不空洞：它可以在适当粒度上说明受影响的服务和前缀、观测到的故障模式、路由撤销的时段、边缘转发失效的时段、恢复步骤、验证期，以及事后改变的控制措施。

它应当区分观测与推断：“通往这些前缀组的路由被撤销”是观测；“某个控制平面依赖处于压力之下”可能是推断；“某个特定供应商进程失败”则需要直接证据。

本文使用的公开来源保留了这种区分。ThousandEyes 表示，边缘行为暗示系统性压力，很可能影响控制平面；本文不会把这句话改写为已确认的控制平面根本原因。[2]

未知项应当保持可见：引发事件的原因、内部决策者、确切设备范围、完整客户范围、两次中断是否同源，以及持久整改措施，都无法由来源集确定。保留这些未知项是一种准确，而不是弱点。

接下来问责问题就变成：掌握缺失证据的一方是否提供了充分的记录。外部分析师不应以自信的猜测填补披露空白，运营方也不应以外部无法确认为由什么都不发布。

客户补偿是网络问责的一部分

路由与转发证据看起来可能与计费和客户支持相去甚远，但它们决定了客户能否证明符合条件的使用中断。接入服务商既控制技术记录，也控制初始补救流程的很大一部分。

Ofcom 的自动补偿框架旨在为特定宽带和固定电话服务故障提供退款，且无需客户提出传统索赔。Virgin Media 被列为参与方之一。Virgin Media 还发布了自己的补偿指引和计划内施工信息。[16][17][18]

这些页面是当前的。本文并不假定当前每项金额、规则或资格条件在 2023 年 4 月都原样适用。任何对该政策的引用都应注明日期，且不应断言受路由事件影响的每位客户都自动符合条件。

问责原则比一笔赔付更广。运营方应保存足够的服务状态证据，以确定完全中断的起止时间、哪些产品受影响、是否适用例外。客户不应为了证明自己的服务失效而去逆向工程 BGP。

沟通渠道也必须能在事件中存活。如果状态页、支持门户或电话服务依赖同一条故障网络，客户可能无法报障或查看更新。Virgin Media 当前的计划内施工页面会在计划性中断期间引导客户使用替代服务；非计划性事件同样需要独立的沟通路径。[17]

补偿数据可以改进工程问责。经核实的服务中断记录的数量与时长以客户语言展示了影响；投诉模式可以揭示聚合流量图掩盖的地区或产品差异。这些信息应进入事后复盘，但不应取代技术证据。

正确的标准是可追溯性：面向客户的中断时段应与路由和转发证据相互印证，例外情况应有书面理由。这能减少争议，并避免出现技术上勉强成立、商业上却过早宣布恢复的情况。

注册与路由安全证据应保持在恰当位置

ASN、前缀注册、路由对象或 RPKI 授权有助于确定谁有权起源宣告地址空间，以及其他网络如何验证这些声明。这些记录对接入问责界面很重要，但并不能保证可用性。

当前工具显示 AS5089 的网络身份和已宣告资源；PeeringDB 标明运营方和互联背景；RIPE 相关服务公开注册与前缀信息；BGP 工具展示当前的路由观测。[6][7][8][9][10][11]

本文不会用这些当前页面来断言 2023 年每一时刻存在哪些路由。历史事件分析应依赖 Cloudflare 和 ThousandEyes 的有日期观测；当前记录仅用于绑定实体和说明控制面。

RPKI 同样有有限的作用。路由来源验证可以帮助网络评估某个起源 ASN 是否有权宣告某前缀，但它不能证明被授权的起源能转发数据包、其内部路由健康，或它的边缘会接受流量。一条路由可能起源有效，却仍然通向黑洞。

这种区分与现实层面一致：安全元数据能提高路由决策的质量，但不能替代运行中的代码证据。问责既需要准确的记录，也需要被观测到的服务。

同样的谨慎也适用于 RFC 8212 的默认拒绝方法和 MANRS 实践：它们能减少某些意外路由传播并改善协调，但它们并不是可达性崩溃的普适解释，一般性的控制措施也不能建立回溯性诊断。

接入网络恢复的实用证据标准

Virgin Media 事件提示了一种其他接入网络可以采用的、具体的恢复记录。这种记录应在中断之前设计好，因为事后拼凑的证据很容易不完整。

第一，保存路由状态。对每个受影响的前缀组，记录宣告、撤销、对等会话、策略版本和时间戳；包含足够的信息以显示哪些外部路径消失、哪些仍然存在。不要公布涉及客户敏感信息的配置，但应保留以备内部与监管审查。

第二，保存转发状态。从多样化的外部网络向代表性目的地发起探测；记录流量在哪里停止、边缘是否接受、内部目的地是否响应。分开记录 IPv4 和 IPv6；在路径不同的地方，分开记录住宅、企业、DNS 和管理依赖。

第三，保存变更状态。记录事件时间窗口内的部署、维护、自动化决策和回滚动作。如果没有变更导致事件，只有在核查记录之后才能这么说；如果原因仍然未知，应保留该状态和调查边界。

第四，定义恢复标准。要求路由稳定、转发成功、应用健康和客户影响改善持续一个指定时段；避免根据第一次探测成功或第一次路由重新宣告就宣布完全恢复。

第五，检验复发风险。把恢复后的状态与事件前状态进行对比，识别仍然退化的依赖项；至少在一个正常负载周期内保持加强监测。如果第二次中断发生，保留差异，而不是覆盖第一条时间线。

第六，与对等网络协调。提供经过测试的 NOC 联系途径，以及供其他网络报告路由与转发观测的结构化方式；承认相互冲突的证据。外部报告可能暴露从运营方内部看不到的故障。

第七，分层沟通。向客户提供简明服务声明和补救路径；向技术相关方提供有边界的路由与转发时间线；向监管机构提供足以评估时长、范围和响应的证据。

第八，对账补救。把经核实的中断时段关联到补偿和投诉系统，而无需客户理解网络机制；注明政策日期和资格限制。

第九，审查集中度。找出与受影响网络共享同一路径的支持、状态、认证和遥测系统；在可行的情况下，把关键证据和沟通路径移到故障域之外。

第十，公布持久的整改。仅仅承诺改进监测是不够的；应说明增加了什么信号、改变了什么阈值、引入了什么上线边界、什么恢复测试成为强制要求，以及这项控制将如何被审计。

这一框架并不假定每次中断都可以预防。它要求运营方能够识别故障边界、安全恢复服务并证明发生了什么变化。

问责应跟随能力，而非后见之明

大型接入网络的中断影响着客户、服务和其他网络之间数以百万计的关系。这种规模诱使人把无限责任归于某一个运营方，或者反过来把事件称为不可避免的互联网故障。两种做法都不精确。

Virgin Media 应对它掌握的控制负责：路由起源宣告、边缘转发、内部恢复、运营沟通和客户补救。它不应对公开证据无法确定的事实负责，例如具名的供应商故障或恶意行为。

对等网络应对自己的路由接受、监测和升级负责；内容提供商应对切合实际的依赖与沟通设计负责；监管机构应对能够使用技术证据、又不把不可能的证据负担加给客户的补救框架负责。

测量提供商应说明其观测点的局限。它们的观测之所以有价值，是因为独立，而不是因为全知。分析师和记者应保留这些局限。

客户对自治系统边界的控制力最弱。住宅用户通常无法绕开自己的服务提供商重新路由。他们的主要责任是报告影响和使用可用的补救措施，而不是去建设第二条接入网络。

基于能力的问责避免了后见之明。它追问每一方当时能观察到什么、决定什么、改变什么、证明什么；它也会暴露缺失的证据，而不去虚构原因。

结论

2023 年 4 月 4 日的 Virgin Media 中断是网络基础设施事件，因为路由与转发状态决定了 AS5089 是否作为来自更广泛互联网的可用路径存在。观测到的大部分流量损失伴随着有效 BGP 路由的缺失；部分路由仍然存在，但流量仍在运营商边缘失败；随后服务恢复，当天晚些时候又再次失败。[1][2]

尽管根本原因仍未公开，这些事实足以定义一个问责标准：恢复必须在路由可用性、数据包转发和客户可见服务三个层面得到证明；注册数据必须用于识别网络，而不能被误当作运营真相；外部测量必须检验运营方的说法，而不假装揭示内部状态；客户补救必须与同一条证据时间线相连。

最有力的事后记录不会宣称来源无法支持的确定性。它会展示哪些路由发生了变化、数据包做了什么、客户经历了什么、运营方改变了什么，以及稳定恢复是如何被验证的。这就是“网络短暂回归”与“运营方证明服务已恢复”之间的区别。

对于未来的事件，这种证据应在运营进行过程中同步收集，而不是在公众关注升温后再重建。路由更新、转发探测、客户影响信号、变更记录和状态公告应共享一条对账一致的时间线。运营方应公布该记录中足够的部分，以展示故障模式、恢复测试和持久控制变更，同时保护客户与安全敏感细节。能够产出这种证据的网络，更有能力从失败中学习、与对等网络协调并提供公平的补救；不能产出这种证据的网络或许能恢复数据包，却无法证明同样的状况为何不会再次出现。

来源

1. Cloudflare：《Cloudflare 对英国 Virgin Media 中断事件的观察》：https://blog.cloudflare.com/virgin-media-outage-april-4-2023/
2. ThousandEyes：《Virgin Media UK 中断分析：2023 年 4 月 4 日》：https://www.thousandeyes.com/blog/virgin-media-uk-outage-analysis-april-4-2023
3. The Register：《英国 Virgin Media 遭遇大规模宽带中断》：https://www.theregister.com/on-prem/2023/04/04/uks-virgin-media-suffers-massive-broadband-outage/1495714
4. ThousandEyes：《2023 年互联网重大中断盘点》：https://www.thousandeyes.com/blog/top-internet-outages-2023
5. Cloudflare：《2023 年第二季度互联网中断摘要》：https://blog.cloudflare.com/q2-2023-internet-disruption-summary/
6. Cloudflare Radar：AS5089 流量：https://radar.cloudflare.com/traffic/as5089
7. PeeringDB：AS5089 Virgin Media：https://www.peeringdb.com/net?asn=5089
8. bgp.tools：AS5089 Virgin Media Limited：https://bgp.tools/as/5089
9. RIPEstat：AS5089 网络信息：https://stat.ripe.net/data/network-info/data.json?resource=AS5089
10. RIPEstat：AS5089 宣告的前缀：https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS5089
11. RIPE 数据库：AS5089 查询：https://apps.db.ripe.net/db-web-ui/query?searchtext=AS5089
12. RFC 4271：《边界网关协议 4（BGP-4）》：https://www.rfc-editor.org/rfc/rfc4271
13. RFC 7454：《BGP 运营与安全》：https://www.rfc-editor.org/rfc/rfc7454
14. RFC 8212：《无策略时外部 BGP（EBGP）路由传播的默认行为》：https://www.rfc-editor.org/rfc/rfc8212
15. MANRS：网络运营商计划：https://manrs.org/netops/
16. Ofcom：《自动补偿：你需要了解的内容》：https://www.ofcom.org.uk/phones-and-broadband/service-quality/automatic-compensation-need-know
17. Virgin Media：《我们正在改善你所在地区的网络》：https://www.virginmedia.com/help/planned-work
18. Virgin Media：《自动补偿》：https://www.virginmedia.com/help/billing-and-payments/automatic-compensation