摘要

  • Cloudflare 表示，2022 年 6 月 21 日一次网络配置变更导致使用其 Multi-Colo PoP 架构的 19 个数据中心出现中断。这些地点约占其网络的 4%，但承担了很大的流量份额。Cloudflare 将事件期间大约一半的总请求归因于受影响的流量，同时指出用户体验因地点而异。[1]
  • 原计划是在站点本地前缀上统一标准化的信息性 BGP community。在 MCP 脊柱路由器上，策略条目的重排把“禁用前缀”条目放在了应通告关键站点本地路由的条目之前。由此产生的路由策略撤回了这些前缀。[1]
  • 这次撤回影响的不仅是外部可达性。Cloudflare 表示，其服务器无法正常通信，也无法到达客户源站；Multimog 负载均衡层无法在受影响的 MCP 内把请求转移到各个计算集群之间。较小的集群随后接收到与较大集群相当的流量并出现过载。[1]
  • 工程师也难以到达受影响地点撤销变更，需要使用备用程序。恢复期间，工程师有时会互相覆盖对方的回滚，导致问题在最后一个地点恢复前不时复发。[1]
  • Cloudflare 的流程原本就包括变更工单、演练、同行评审和分阶段部署。控制失效更具体：早期发布阶段没有一个实际在 MCP 地点上运行。第一个有代表性的测试出现在最后阶段覆盖所有 MCP 脊柱时。[1]
  • BGP community 是路由策略使用的元数据。它们不能证明出口策略的顺序正确，也不能证明必需前缀仍被通告。RPKI 源验证解决的是源 AS 是否被授权通告某前缀的问题，它无法验证内部的词条顺序、金丝雀选择或回滚流程。[10][11][12][14][15][16]
  • 因此问责应当要求运营证据：变更前后的精确候选配置、机器可校验的必需前缀集合、路由策略模拟、MCP 专属金丝雀、commit-confirm 行为、独立管理可达性、唯一的回滚负责人、按地点记录的变更，以及与路由器日志核对过的外部路由观测。
  • 公开路由收集器有助于确立外部可见的通告与撤回，但无法揭示每一条私有站点本地路由或内部策略决策，运营商记录仍然必要。[17][18][19]
  • 公开记录无法证明恶意意图、过失、违规、每个受影响前缀、每位客户损失，或所有声明的补救措施是否仍在部署。这些边界应保持明确。

经审核的变更仍可能是未经测试的变更

基础设施组织常常用流程标签来代指控制。变更已开工单。演练已完成。多位工程师评审过。发布是分阶段的。每一个陈述都可能为真，而运行风险却仍未经过测试。

Cloudflare 对其 2022 年 6 月 21 日故障的说明让这一区别异常清晰。该变更经过了变更请求工单、包含演练、经过同行评审，并遵循分步骤部署流程。早期步骤没有造成中断。当发布到达使用 Cloudflare 称为 Multi-Colo PoP（简称 MCP）架构的 19 个地点时，故障出现了。此前没有一个阶段实际在 MCP 地点上运行。第一个能代表相关路由拓扑的阶段，也是把配置应用到所有 MCP 脊柱的阶段。[1]

这并不意味着工单、评审、演练或分阶段发布没有用。它说明每个控制措施都需要一个明确的命题。工单记录授权和意图。评审记录指名的若干人检查了变更的某种表示形式。演练记录工具针对特定模型或设备状态计算出了什么。分阶段发布只有当一个阶段能代表一个独立的故障域、并且范围小到足以在下一阶段开始前停下来时，才能限制范围。

因此问责问题不是“流程是否存在？”而是“每一步证明了什么？”在这次事件中，早期发布证明该变更不会干扰使用旧架构的地点。它没有证明该策略会在 MCP 脊柱上保留必需的通告。一个来自非代表性地点的绿色结果，无法回答这个决定性问题。

这个缺口之所以重要，是因为网络配置是可执行的运行权限。路由策略词条不只是描述流量应当流向哪里。它的顺序决定路由器通告或保留哪些路由。一旦提交，配置就改变了服务器、对等方、源站、运营商和恢复系统所使用的可达性图。无害元数据增加与重大故障之间，可能只差一个在另一个之前被评估的策略分支。

不应把 Cloudflare 的报告简化成“错误配置导致了故障”这句口号。更有用的教训更窄、也更严格：变更控制必须与架构、路由不变量、故障域和恢复访问绑定。跳过相关架构的分阶段流程，可能制造谨慎的表象，却不能提供关于真正会失效系统的证据。

预期变更是信息性的，实际变更是可达性

Cloudflare 表示，它正在统一附加在部分被通告前缀上的 BGP community，具体是向站点本地前缀添加信息性 community。BGP community 是运营商用来标记路由并影响路由策略的属性。标准 community 规范定义了一种把目的地分组的方式，使路由决策可以应用于一类路由，而不是逐个前缀。Large Communities 为现代运行需求扩展了这一格式。[1][11][12]

预期的添加并未被描述为撤回服务路由的尝试。Cloudflare 在其报告中将其描述为普通路由器上的无害信息。产生后果的差异出现在 MCP 脊柱路由器上。配置差异重排了汇总出口策略中的词条。一个与禁用前缀关联的词条被移到了应通告服务和内部功能所用站点本地路由的词条之前。由于策略词条按顺序评估，较早的匹配阻止了后面的通告逻辑继续生效。[1]

这就是语义意图与实际行为之间的区别。变更作者可能意在附加元数据。评审者可能看到的是 community 添加。工单标题可能写着“统一 community”。这些表示都不控制路由器。路由器按顺序评估最终生成的策略。如果生成或渲染出的配置改变了顺序，运行效果就是策略引擎实际执行的结果。

BGP 本身提供可达性机制。网络通告前缀，以告知对等方某些地址可通过某条路径到达。当可达性不再可用或不应继续通告时，它们撤回路由。被撤回的前缀可能从选定路径中消失，使相应地址无法通过该路由到达。BGP-4 规范定义了这些通告和撤回语义；它不了解运营商对某条策略词条的业务意图。[10]

这种区别产生了一项证据要求。变更审批应当绑定到路由器将实际评估的精确候选配置，而不只是高层请求或生成的模板。评审记录应显示：

  1. 变更前后的精确渲染策略。
  2. 每个受影响词条的评估顺序。
  3. 预期被接受、拒绝、通告和撤回的路由集合。
  4. 该集合中每个前缀的来源。
  5. 该策略将在哪些设备角色和架构上运行。
  6. 使用代表性路由输入的模拟或实验环境结果。
  7. 策略输出错误时仍保持可达的管理与回滚路径。

没有这些绑定，评审可能核实了请求，却漏掉了编译后的效果。基础设施问责跟随运行系统所消费的配置。

站点本地前缀属于服务路径的一部分

“站点本地”这个词听起来可能像是次要的，似乎受影响的路由只是与客户无关的内部维护项。Cloudflare 的报告显示并非如此。这些前缀支撑着其机器之间的通信，并使服务器能够到达客户源站。它们的撤回中断了这些路径。[1]

Cloudflare 还把这些前缀与 Multimog 联系起来，Multimog 是 MCP 地点使用的内部负载均衡系统。由于相关可达性消失，Multimog 无法再在 MCP 内的服务器之间转发请求。不同规模的计算集群随后接收到相近的流量负载。较小的集群出现过载。[1]

这一机制很重要，因为它解释了为什么一小部分路由撤回可能产生远超缺失前缀数量所暗示的服务影响。一个前缀可以支撑多个服务共享的依赖。如果它承担源站可达性、内部集群通信或负载均衡路径，它的撤回会改变工作在整个系统中的分配方式。服务可能仍然在边缘接收到流量，却失去了安全处理或转发这些流量所需的内部路由。

因此该事件测试的是运营商如何划分路由关键度。前缀登记不应止于归属或源授权。它应当记录运行角色：

  • 该前缀是面向互联网、仅管理、站点本地、面向客户源站还是集群间？
  • 哪些路由器和策略通告它？
  • 哪些服务依赖它？
  • 哪些监测检查能证明它可达？
  • 哪些地点共享同一策略模板？
  • 如果路由消失但入站流量继续，会发生什么？
  • 管理访问是否使用同一路由族或策略？
  • 预期由哪条替代路径承担该依赖？

这一记录并不凌驾于网络之上。它不能让路由存在。它创建的是关于预期状态的可测试台账。运营商可以把台账与路由信息库、转发表、外部收集器、主动探测和服务级结果进行比较。一份准确、唯一、受变更控制并与观测行为绑定的记录，能让撤回在客户成为监测系统之前就被发现。

Multimog 的影响还说明容量需要拓扑背景。Cloudflare 表示受影响的 MCP 地点包含不同规模的集群。当内部转发失效时，较小的集群接收到与较大集群相当的流量。因此仅显示站点总容量的容量仪表盘可能高估可用容量。路由故障移除了让聚合容量真正可用的均衡机制。

基于证据的评审会问：每个 MCP 是否有经过测试的降级模式？当 Multimog 失去站点本地可达性时，能否从外部排空流量？较小集群能否通过准入控制保护自己？路由策略金丝雀是否包含源站访问、集群间转发和管理访问探测，而不只是 BGP 会话健康？公开报告指出了这一依赖，但没有发布每项保护性控制。

19 个地点暴露了分布式网络内部的集中性

Cloudflare 表示，这 19 个 MCP 地点约占其网络的 4%，故障却影响了大约 50% 的总请求。它还强调影响因地点而异：一些用户无法访问使用 Cloudflare 的站点，而其他地点继续正常运行。[1]

这些数字应保留归属，不应转换为人数、客户数、网站数或财务损失。它们确实支持一条拓扑教训。一个网络可以在地理上分布，而流量仍集中在少数高容量地点。统计地点数量，不等于衡量它们承载的流量份额、客户依赖、对等容量或源站连通性。

MCP 项目旨在提升最繁忙地点的韧性。Cloudflare 描述了一种 Clos 风格架构，带有额外的路由层和脊柱连接网状结构。该架构允许在维护或故障处理时启用或禁用内部网络的某些部分。这些都是合理的韧性目标。该事件并不能证明这一架构本身不可靠。[1]

它确实表明，一条通用策略路径可以把物理上分开的地点连在一起。如果同一份渲染后的路由策略在一个最终发布步骤中到达每个 MCP 脊柱，那么策略模板就成了共享故障域。物理多样性并不会消除这种通用控制依赖。

这是网络问责中反复出现的模式。运营商可能有多个路由器、机房、运营商和路径，但单一自动化模板、凭据系统、路由策略、控制器或发布阶段仍可能造成共模故障。必须针对导致事件的控制面来衡量多样性。

对于 MCP 部署，一份有用的变更地图应包含：

维度所需证据
物理位置每个金丝雀和发布组的设施与城市标识
架构旧 PoP 与 MCP、脊柱角色、软件版本、硬件家族
策略每个角色精确渲染的策略和词条顺序
路由角色必需的站点本地、客户源站、管理和服务前缀
流量份额各发布组正常请求和带宽份额
管理主用和独立访问路径
回滚commit-confirm 状态、计时器、负责人和每台设备结果
观测路由、可达性、负载均衡、容量和客户检查

这张表可以防止低风险的第一阶段被误认为具有代表性。金丝雀应当很小，但必须真正运行被变更的功能和架构。如果唯一具有代表性的站点流量太大、无法作为金丝雀，这本身就是架构和运行风险，需要在生产前采用实验室孪生环境、影子评估、更小的代表性域或更强的静态不变量。

失去管理可达性改变了恢复问题

Cloudflare 表示，路由撤回使工程师更难到达受影响地点并回退配置。需要使用备用程序来取得控制。[1]

这一细节应当放在分析中心。仅仅因为存在回滚命令，网络变更并非就能安全回退。操作者还必须能够在网络劣化期间完成认证、到达设备、确定正确状态并协调回滚。如果管理流量依赖正在变更的路由，恢复路径就与故障域共享。

独立访问不一定要求为每台设备建立完全独立的全球网络。它需要一种能够承受所测试故障的合理设计。选项可以包括：位于单独路由管理网上的控制台服务器、带外运营商链路、可执行定时回滚的本地自动化、设备 commit-confirm 功能、受保护的终端访问，或者其可达性不依赖候选策略的控制通道。

每个选项都有局限。带外运营商可能共享机房或电源。控制台服务器可能依赖同一个身份提供者或 DNS 服务。commit-confirm 计时器可能被过早取消，或无法恢复所有依赖状态。本地自动化可能应用错误基线。问责需要通过演练证明所选路径在确切的丢失条件下仍能工作。

本次事件的相关测试很直接：在代表性 MCP 环境中撤回或抑制提供一般站点本地和管理可达性的路由集合，然后验证操作者仍能查看状态并恢复已批准的配置。演练应测量：取得访问的时间、识别失败不变量的时间、开始回滚的时间、恢复必需通告的时间，以及确认服务恢复的时间。

一张正常日子成功登录的截图远远不够。测试必须移除实际失败的依赖。运行系统证据优于一张把某路径标为“带外”的图。

公开报告没有列出 Cloudflare 使用的每项备用程序，出于安全和运行原因这是合理的。敏感拓扑和凭据不应公开。组织仍可在访问控制下保留可审计证据：演练时间戳、设备范围、独立见证、路由探测、成功标准和例外项。

回滚权限作为协调控制失效

Cloudflare 的时间线称，最终回退被推迟，因为网络工程师覆盖了彼此的操作。一些回退撤销了之前的回退，导致问题不时复发。[1]

这不仅仅是人为失误的脚注。它指出了事件响应中缺失的串行化属性。在重大故障期间，多位工程师可能都拥有有效访问权限和充分的行动理由。如果变更系统没有提供唯一的期望状态、可见的所有权、按设备锁定以及共享的进度记录，并行工作就可能产生振荡。

生产教训不是只能由一个人响应。调查、路由观测、客户沟通、服务测试和回滚准备可以并行展开。对同一路由状态的变更需要协调。系统应让一个响应者很难重新引入另一个响应者已移除的配置。

有用的控制包括：

  • 明确的事故指挥官和网络变更负责人。
  • 为恢复冻结一个期望状态提交。
  • 回滚期间对设备或策略域加锁。
  • 一个记录每次尝试和完成回退的单一编排器。
  • 在管理确认丢失时自动恢复先前状态的 commit-confirm 计时器。
  • 只读观察者，在不改变配置的情况下验证路由和服务恢复。
  • 规则：紧急手工变更在正常自动化恢复前必须与权威配置对齐。
  • 当所有权在团队或区域之间移交时进行明确交接。

这些控制应产生按地点记录的台账。对每个 MCP，记录应显示：错误配置标识、回滚命令或提交、执行者、开始和结束时间、设备确认、路由表结果、管理可达性、服务探测，以及之后触及同一策略的任何变更。台账使相互干扰可见，并支持对“最后一个站点已恢复”的可信宣告。

Cloudflare 的补救措施包括自动化 commit-confirm 回滚和更好的错峰执行。[1] commit-confirm 机制在路由变更可能移除管理访问时尤其重要。路由器可以自动恢复先前状态，除非操作员在可达性和不变量检查通过后确认新状态。

commit-confirm 并非魔法。超时必须长到足以完成验证，又短到足以限制影响。先前状态本身必须安全。确认不能仅凭弱信号自动完成。多设备变更需要协调语义，以免一台路由器回退而另一台仍停留在候选状态。该机制仍然需要演练和证据。

流程存在，但证明义务不完整

Cloudflare 的报告明确说，该变更拥有工单、演练、分步骤发布和多位同行评审者。[1] 这让该事件对已经拥有成熟变更管理词汇的组织很有价值。

弱化的事后响应会再加一道审批。更多签名可能拖慢交付，却不会测试缺失的条件。证据指向四个更强的问题。

第一，演练使用了什么输入？如果它只为旧架构渲染策略，就无法揭示 MCP 词条顺序效应。演练应包含生成逻辑影响到的每个策略角色，尤其是具有不同模板或继承关系的情况。

第二，演练评估了哪些断言？语法合法的配置仍可能撤回必需前缀。验证应比较路由输出，而不只是解析结果。如果任何必需的站点本地、管理、源站面向或服务前缀出现意外变化，工具应失败。

第三，发布组是如何定义的？如果早期每个地理位置都使用旧设计，仅按地理排序无法暴露特定架构故障。分组应反映硬件、软件、拓扑、策略角色、控制平面版本、流量份额和管理路径。

第四，什么阻止了继续推进？分阶段发布只有在具备明确的观察窗口和自动闸门时才有效。系统需要证据证明金丝雀保留了必需路由、源站可达性、内部负载均衡、管理访问和服务成功率，然后才开始下一组。

同行评审也有类似义务。评审者需要所有角色的渲染差异、预期路由输出、金丝雀矩阵、回滚计划，以及恢复路径独立的证据。要求评审者从高层工单中推断这些，会招致同样的缺口。

目标不是官僚式完美，而是把流程绑定到故障机制。对于 BGP 策略，运行命题是：指定前缀仍通告给指定对等方，而预期属性发生变化。这一命题可以机械地测试。

路由不变量把意图变成测试

路由不变量是在变更前、变更中和变更后都必须保持为真的陈述。例子包括：

  • 每个 MCP 脊柱通告经批准的站点本地前缀集合。
  • 管理前缀可从指定独立访问点保持可达。
  • 客户源站连通性探测在每个计算集群上成功。
  • 内部负载均衡能在不同规模集群之间转发请求。
  • 没有意外的公共前缀被通告。
  • 没有受保护的前缀被撤回。
  • 变更路由的数量和属性与批准的变更范围一致。

必需前缀集合应来自与服务归属关联的准确运行登记，而不是复制到一次性工单里的非正式列表。前缀身份、角色、来源、预期对等方、安全元数据和变更历史都需要持久的归属。

提交前，策略模拟可用代表性路由和对等方上下文评估候选配置。金丝雀提交后，系统可把路由器的路由信息库和已通告路由视图与不变量比较。主动探测可测试服务路径。外部收集器可为公共通告提供独立视图。[17][18][19]

比较必须区分预期变更与意外变更。如果目的是添加 community，路由存在性应保持稳定，属性只在批准集合内变化。必需站点本地前缀的撤回就立即成为闸门失败，而不是等待全局 HTTP 错误的症状。

路由不变量还能改善事故沟通。运营商可以说“网络正在恢复”，也可以报告：必需通告已在确定数量的地点恢复、管理可达性已恢复、内部转发通过、客户请求成功率处于声明的区间内。每个表述都有证据和边界。

存在虚假信心的风险。不变量集合可能不完整。路由可能存在但转发错误。控制平面视图可能与数据平面不同。因此路由检查应与转发和服务探测配对。当事故暴露出未被表示的依赖时，测试套件应更新。

BGP community 本身并未导致故障

把该事件概括为“BGP community 搞垮了 Cloudflare”是不准确的。community 是附加在路由上的元数据。运营商使用它们进行策略控制、标记、流量工程和运行信号。RFC 1997 和 RFC 8092 定义了 community 格式，它们并未规定 Cloudflare 的策略顺序。[11][12]

预期的 community 添加是变更背景的一部分。故障机制是 MCP 脊柱上策略词条的实际顺序，以及由此导致的必需前缀撤回。[1] 这一区别很重要，因为补救应针对失效的控制，而不是污名化一个标准机制。

当 community 的含义被记录、唯一且一致应用时，它可以改善问责。它们可以标识路由类别、预期处理方式、维护状态、地理或客户关系。但标签只有在策略评估保留必需结果时才有用。一个写着“站点本地”的 community 并不能在更早的词条拒绝它时保持路由被通告。

同一原则适用于变更名称和注释。人类可读的标签有助于评审，但运行策略决定可达性。运营商应能从 community 定义追踪到路由集合、策略分支、预期通告和观测结果。如果追踪止步于文档，运行证据就是不完整的。

RPKI 重要，但不是直接修复

RPKI 提供了一种把 IP 地址资源绑定到授权源 AS 的方法。路由源验证允许路由器根据源和前缀长度是否与路由源授权一致来分类通告。RFC 6480 描述了该架构，RFC 6811 描述了源验证。[15][16]

这些控制回答的问题与 2022 年 6 月的故障不同。RPKI 有助于判断 Cloudflare 的 AS 是否被授权通告某个公共前缀。它不能判断内部出口策略词条是否应通告某个站点本地前缀、词条顺序是否正确、MCP 金丝雀是否具有代表性、或回滚访问是否独立。

一条被授权的路由可能被意外撤回。有效的源不等于可用性。反过来，内部站点本地路由可能永远不会出现在公共 RPKI 或外部收集器中。把 RPKI 说成万能修复，会掩盖实际的控制失效。

RPKI 仍属于证据模型，因为号码资源授权、路由策略和运行连续性会相互作用。运营商应维护准确的号码资源记录和安全元数据，同时单独验证策略行为和服务可达性。注册数据完整性与运行代码证据是互补的，而不是替代品。

这个边界对公共问责也有用。事后报告可以说明事件是否涉及源授权、路由泄漏、劫持、内部策略撤回或其他路由机制。精确分类可以避免把所有 BGP 相关事件都视为同一种故障，并支持正确的补救。

外部路由观测有价值但不完整

RIPE NCC 的 Routing Information Service 从对等方收集 BGP 数据，RIS Live 提供更新流。CAIDA 的 BGPStream 提供处理来自多个收集器的路由数据工具。这些系统可帮助研究人员和运营商观测参与观测点可见的通告、撤回、路径变化和恢复。[17][18][19]

对于公共前缀事件，外部观测可以回答重要问题：

  • 前缀何时从选定收集器消失？
  • 哪些对等方或地区观测到撤回？
  • 通告何时恢复？
  • 恢复后路径或属性是否发生变化？
  • 事件是否与运营商的公开时间线一致？

2022 年 6 月的事后报告涉及站点本地前缀和内部 MCP 行为，以及外部经历的服务故障。公共收集器可能看不到每条相关路由。它们不会暴露私有策略词条、路由器候选配置、内部管理可达性或 Multimog 状态。没有外部信号不能证明私有系统是健康的。

这一限制不应被用来否定外部证据。它定义了对账任务。运营商可以保留路由器日志、配置提交、已通告路由快照、主动探测结果和服务遥测。公共收集器提供独立层。可信的结案报告应说明两者在哪里一致、可见性在哪里不同，以及原因。

证据应使用一致的时钟加时间戳。否则路由更新、配置提交、事故宣告、回退、可达性探测和客户错误可能显得顺序错乱。时间同步和不可变日志是问责控制，因为它们保留评估响应所需的顺序。

影响数字需要自己的边界

Cloudflare 表示，这 19 个 MCP 地点约占其网络的 4%，但故障影响了 50% 的总请求。它还发布了请求量图和出口带宽视图。[1]

这些数字显示流量集中于高容量站点。它们并不能证明全球一半互联网用户、一半 Cloudflare 客户或一半网站完全不可用。请求流量不是人口统计。一些地点继续正常运行，客户影响因地理位置和服务路径而异。

负责任的影响说明应区分：

  • 失败的请求。
  • 被延迟或重试的请求。
  • 失去必需路由的地点。
  • 过载的集群。
  • 从受影响站点变得不可达的客户源站。
  • 从未受影响地点继续提供的服务。
  • 首次恢复与最终回退的时间。
  • 路由恢复后的剩余错误。

公开报告对其中几个维度提供了有力信息，但没有一份完整的逐客户清单。本文不应制造精确性。

对于未来事件，运营商可以通过公布分母和不确定性来改进披露。如果 50% 的请求受到影响，应定义测量区间、成功标准、重试处理、地理范围，以及该数字是否包含转移到其他站点的流量。清晰指标让客户能把该陈述与自己的日志比对。

问责跟随控制，而非品牌曝光

Cloudflare 控制着路由策略、发布流程、MCP 分组、演练范围、同行评审材料、管理访问、自动化和回滚协调。其事后报告承认该故障是其自身错误，而非攻击。[1] 这些事实使 Cloudflare 成为问责分析的核心运营商。

这并不意味着每个后果在法律上都可归因，或每位工程师承担相同责任。公开记录无法确定个人过错或过失。治理应把控制映射到团队和系统：

  • 网络架构负责人定义 MCP 角色和故障域。
  • 策略负责人定义出口词条和 community 处理。
  • 自动化负责人渲染并分发配置。
  • 变更负责人选择阶段和观察窗口。
  • 评审者评估提供的证据。
  • 事故指挥官协调恢复。
  • 设备和平台团队提供回滚与 commit-confirm 机制。
  • 服务团队监测源站可达性、Multimog、集群负载和客户请求。
  • 领导层设定可接受的流量集中度和变更风险。

路由器和软件厂商影响可用的安全机制，但 Cloudflare 的公开报告并未把词条重排归因于厂商缺陷。标准机构定义协议行为，但不运营 Cloudflare 的策略。客户依赖该服务，但不控制内部站点本地路由配置。

客户仍对其依赖架构负有责任。一个公共服务依赖单一 CDN 或权威 DNS 路径的组织，应理解这种依赖，在可行时测试替代访问，并在供应商不可达时定义沟通方式。这种责任不会把 Cloudflare 路由器的控制权转移给客户，也不会让每种依赖都可避免。

监管机构和大型采购方可要求证据，而不必规定私有拓扑。他们可以询问供应商是否使用架构代表性金丝雀、路由不变量、独立管理访问、串行化回滚和演练。合同可以定义披露和恢复证据。他们应避免在公开渠道要求敏感配置，而受保护的评审可以达成目的。

一套实用的证据包

最强的事后结案，不是保证完全相同的错误不会重演，而是一个有边界的证据包，说明改变了什么以及新控制的实际表现。

控制留存的证据运行测试重要局限
变更授权工单、审批人、范围、风险分类工单绑定到精确渲染的候选配置审批不能证明路由行为
策略评审每个路由器角色变更前后的词条顺序评审工具识别变化的匹配与动作评审者可能漏掉不完整的路由模型
必需前缀不变量带版本、角色和归属的前缀列表候选配置和金丝雀保留每条受保护通告路由存在不能证明转发
架构金丝雀MCP 角色、硬件、软件、流量和管理路径记录金丝雀与后续组运行相同的策略路径一个金丝雀可能无法代表每个 MCP
路由模拟代表性输入路由和预期输出没有意外的撤回或通告模拟可能与设备行为不同
commit-confirm计时器、先前状态、确认标准管理丢失或不变量失败触发回滚多设备一致性仍然困难
独立访问拓扑、依赖和演练记录在普通路由丢失后操作者仍能到达并恢复设备隐藏的共享电源、身份或 DNS 仍可能存在
回滚所有权事件负责人、锁定状态、按设备台账并行调查者无法覆盖恢复状态紧急手工操作可能绕过自动化
外部观测RIPE RIS、BGPStream 或其他收集器证据公共路由变化与运营商时间线一致私有路由和全部对等方不可见
服务验证源站、内部转发、集群负载和请求探测路由恢复产生完成的服务合成探测可能漏掉客户特定路径
补救持久性部署证据和定期演练结果MCP 专属分阶段和回滚持续通过一次性测试不能证明永久合规

证据包把记录与运行证明分开。前缀登记之所以有用，是因为它保留唯一性、归属、角色、预期对等方、安全元数据和变更历史。它不是让数据包流动的权威。策略模拟之所以有用，是因为它预测行为；金丝雀和实时路由状态仍然需要观测。公开事后报告之所以有用，是因为它描述事件；它不能证明之后每一项承诺仍然有效。

敏感细节可以保护。精确管理地址、凭据、拓扑和路由器配置若公开可能带来安全风险。独立审计方、监管者或保密客户可以审查。公开披露可以概括控制结果、时间戳、范围和未解决的局限。

比较边界很重要

Cloudflare 也经历过其他路由和配置事件。把它们当作一次泛泛的故障会削弱分析。

2019 年 6 月的事件涉及外部路由泄漏。这不是 2022 年的 MCP 分级发布失败。

2020 年 7 月的 Cloudflare 故障是一次路由器规则故障。其直接机制与 2022 年的站点本地前缀撤回不同。

2025 年 3 月的事件涉及错误的 ROA。2022 年的路由是由内部策略撤回的；公开记录并未把错误的 ROA 描述为原因。

Cloudflare 2025 年的功能文件失败不是 BGP 出口策略事件。

这些案例共享一条抽象教训：小的控制输入可能获得全局影响。具体证据和修复各不相同。网络问责要求明确指出实际失效的协议、层级、权限、传播路径和恢复边界。

公开记录不能证明什么

Cloudflare 的事后报告很详细，但它是一份第一方说明。它为机制和时间线提供了最强公开来源，同时把重要材料留在了私有范围。

公开记录没有披露每一个被撤回的前缀、完整路由器配置、完整变更工单、评审者意见、自动化代码、私有拓扑、管理访问设计或全部服务依赖。它没有显示每台设备完整的路由信息库或转发状态。

公开流量图没有识别每一位受影响客户、用户、请求类型、源站或财务后果。本文不推断服务抵扣、收入损失、监管处罚、合同违约或客户过失。

事后报告称该事件是 Cloudflare 的错误，而非攻击。它并不能证明恶意意图、隐瞒、犯罪行为或个人责任。它本身也不确立法律上的注意义务标准。

补救部分记录了计划中和即时的工作。它不能证明每一个 MCP 专属金丝雀、策略重新设计、错峰自动化或 commit-confirm 机制至今仍在部署并有效。当前文档可以解释架构和控制，但不应被追溯当作确证 2022 年当时状态的证据。

RIPE RIS 和 BGPStream 可以提供独立路由观测，但现有公开证据并不构成对每次站点本地撤回的完整收集器重建。外部可见性有局限。

这些未知并不妨碍问责分析。它们定义了证据持有者应回答的问题，并防止本文把技术事后报告变成没有依据的指控。

给运营商、董事会、客户和评审者的问题

网络运营商应问：

  • 哪些路由策略因架构或路由器角色而异？
  • 演练是否渲染了每个受影响角色？
  • 哪些前缀必须在变更期间保持通告？
  • 必需前缀列表是否带版本、有归属并链接到服务依赖？
  • 策略模拟器是否评估代表性路由输入和词条顺序？
  • 首个金丝雀是否足够小且具有架构代表性？
  • 哪个观察窗口和自动闸门会阻止继续推进？
  • 当候选策略移除普通管理路由后，操作者还能到达设备吗？
  • commit-confirm 是否恢复一致的多设备状态？
  • 事件回滚期间谁拥有变更权？
  • 只读团队能否在不改变配置的情况下观测路由和服务？

董事会和风险委员会应问：

  • 多少流量份额依赖最繁忙的通用控制域？
  • 地理分布是否掩盖了共享策略或自动化依赖？
  • 主路径和恢复路径共享哪些管理、身份、DNS、电力和运营商依赖？
  • 有什么证据表明修复是在反复演练，而非一次性补救？
  • 客户影响指标如何定义并与路由和服务证据对账？

客户应问：

  • 哪些服务依赖 Cloudflare 的可达性、DNS、CDN、安全、访问或源站路径？
  • 如果供应商及其状态路径受损，关键通信能否继续？
  • 替代供应商或直接源站路径是否经过技术和运行测试？
  • 绕过或故障转移会带来哪些安全权衡？
  • 哪些日志能证明客户自身的影响，而不假设发生全球性故障？

评审者和审计方应问：

  • 他们是否检查了精确渲染策略，而不只是请求？
  • 金丝雀是否匹配 MCP 拓扑和脊柱策略？
  • 站点本地和管理路由是否包含在不变量中？
  • 独立测量与路由器日志是否一致？
  • 两位工程师能否互相覆盖对方的回退？
  • 每项补救声明是否绑定当前测试结果和例外记录？

这些问题并不假设零故障可能。它们测试的是，已知的路由错误类别是否被限制、可观测且可恢复。

结论：一个阶段的好坏取决于它所代表的系统

Cloudflare 2022 年 6 月的故障始于一次受控变更。该变更有工单、演练、同行评审和多个发布阶段。但当它到达此前任何早期阶段都未运行过的架构时，仍然撤回了关键站点本地前缀。撤回中断了服务器和源站可达性，停用了内部负载再分配，使较小的集群过载，并削弱了恢复所需的管理路径。并发的回退随后导致偶发复发。[1]

该事件让 BGP 变更分级成为问责测试。一个阶段不会仅仅因为排在另一个阶段之前就成为证据。它必须代表相关拓扑、策略角色、软件、路由输入、流量集中度和管理依赖。其成功标准必须包括必须保持可用的路由和服务。

修复模型是具体的。把审批绑定到渲染后的配置。维护准确且记录必需前缀及其运行角色的台账。模拟策略输出。使用 MCP 专属金丝雀。观测通告、转发、源站连通性、内部负载均衡和管理访问。用 commit-confirm 和唯一的变更负责人保护回滚。在可见性允许处，把私有路由器记录与独立公共测量对账。

BGP community、RPKI、路由收集器、工单和图表都贡献证据。它们都不能替代运行结果。community 标记路由；策略顺序控制决策。RPKI 验证源授权；它不能证明可用性或内部策略正确。收集器观测选定的外部视图；它们不揭示每个私有依赖。工单记录意图；它们不能保持前缀被通告。

这个现实层才是持久的教训。一个分布式网络之所以具有韧性，是因为其运行路径、控制策略、管理访问和回滚机制能在代表性故障下保持服务。证明不是流程的名称，而是仍然保持可达的路由、阻止发布的金丝雀，以及一个团队能够完成而不被另一个团队撤销的恢复。

资料来源

  1. Cloudflare，《Cloudflare outage on June 21, 2022》：https://blog.cloudflare.com/cloudflare-outage-on-june-21-2022/
  2. Cloudflare，2022 Impact Report：https://cf-assets.www.cloudflare.com/slt3lc6tev37/fBTOgkechN3IcaoT3kbA3/c9b74ee483d28c795d3c7891d8d36034/2022_Cloudflare_Impact_Report.pdf
  3. Cloudflare，《Cloudflare Backbone: A Fast Lane on the Busy Internet Highway》：https://blog.cloudflare.com/cloudflare-backbone-internet-fast-lane/
  4. Cloudflare，《The backbone behind Cloudflare's Connectivity Cloud》：https://blog.cloudflare.com/backbone2024/
  5. Cloudflare，《Load Balancing without Load Balancers》：https://blog.cloudflare.com/cloudflares-architecture-eliminating-single-p/
  6. Cloudflare，CDN Reference Architecture：https://developers.cloudflare.com/reference-architecture/architectures/cdn/
  7. Cloudflare，IP addresses and anycast network：https://developers.cloudflare.com/fundamentals/concepts/cloudflare-ip-addresses/
  8. Cloudflare，Peering Policy：https://www.cloudflare.com/peering-policy/
  9. PeeringDB，Cloudflare network record：https://www.peeringdb.com/net/4224
  10. IETF / RFC Editor，RFC 4271，Border Gateway Protocol 4：https://www.rfc-editor.org/rfc/rfc4271
  11. IETF / RFC Editor，RFC 1997，BGP Communities Attribute：https://www.rfc-editor.org/rfc/rfc1997
  12. IETF / RFC Editor，RFC 8092，BGP Large Communities Attribute：https://www.rfc-editor.org/rfc/rfc8092
  13. IETF / RFC Editor，RFC 8326，Graceful BGP Session Shutdown：https://www.rfc-editor.org/rfc/rfc8326
  14. IETF / RFC Editor，RFC 7454，BGP Operations and Security：https://www.rfc-editor.org/rfc/rfc7454
  15. IETF / RFC Editor，RFC 6811，BGP Prefix Origin Validation：https://www.rfc-editor.org/rfc/rfc6811
  16. IETF / RFC Editor，RFC 6480，RPKI Architecture：https://www.rfc-editor.org/rfc/rfc6480
  17. RIPE NCC，RIS Live Manual：https://ris-live.ripe.net/manual/
  18. RIPE NCC，Routing Information Service：https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/
  19. CAIDA，BGPStream：https://bgpstream.caida.org/
  20. Cloudflare，《What is BGP?》：https://www.cloudflare.com/learning/security/glossary/what-is-bgp/