OVH 2017 年光纤网络故障：冗余独立性成为问责检验

摘要

事件边界很窄：本文仅涵盖 2017 年 11 月 9 日鲁贝光纤网络故障。同一天斯特拉斯堡的电力中断是机制和控制链不同的独立事件。
可见故障范围广但并非普遍：当时记录描述了鲁贝与 OVH 六个网络接入点之间的连接丢失。这并不能证明所有 OVH 路由、客户或工作负载都以同样方式失败。
名义上的多样性并未带来运营独立性：OVH 描述了冗余光纤连接，但配置丢失后，鲁贝链路同时不可用，并且必须从已保存配置恢复。
公开的根本原因有两个层面：OVH 将直接事件归因于软件缺陷和光学设备配置丢失。相关链路同时丢失还暴露了物理路径多样性未能消除的共享配置或监控故障域。
已保存配置不是独立恢复系统：已保存配置使恢复成为可能，但其存在并未保持运行中的光纤系统可用。备份可用性、恢复权限和经过测试的可恢复性必须分别衡量。
责任跟随控制：OVH 控制架构、部署、配置保护、监测、恢复和客户沟通。设备制造商控制产品缺陷调查和软件修正。对等方、传输网络和客户控制其自身的外部多样性，但不控制 OVH 的内部光纤状态。
公布的修复正确区分了两种问题：OVH 计划与设备制造商一起进行软件升级，并将光复用系统分拆到两套系统。前者针对缺陷；后者旨在限制复发的影响范围。
修复不能仅凭公告证明：可信的收尾需要拓扑和配置证据、故障注入测试、独立可达性测量，以及证明一次控制故障不再能切断鲁贝所有外部路径。

在分配责任之前，先界定鲁贝事件

OVH 在同一天经历了两次严重故障。一次电力故障影响了其斯特拉斯堡站点，而一次光纤网络故障影响了鲁贝。OVH 后来的声明明确将两次事件描述为同时发生但互不相关。这一区分是问责的起点，而不是应被并入更大叙事的细节。[1]

将两次事件合并将产生不准确的因果链。斯特拉斯堡涉及电力供应、切换设备、发电机和服务重启。鲁贝涉及光传输、配置丢失和与外部网络位置的连接。负责的系统、运营商、供应商、检测信号、恢复行动和预防测试都不同。

因此，本文从鲁贝光纤故障开始，到相关链路和托管站点连接恢复结束，随后涵盖 OVH 公布的针对鲁贝的具体修复。本文排除斯特拉斯堡电力事件、2017 年 7 月的一次存储事件、2017 年 12 月晚些时候的一次网络事件、2021 年斯特拉斯堡火灾以及另一场 2021 年路由事件。这些事件或许有助于更全面地了解 OVH 的历史，但不能用作鲁贝光纤故障原因或修复的证据。

公开时间线有两个有用层面。OVH 的正式声明称，鲁贝站点在不到两个半小时内恢复运行。一家受影响服务提供商另行记录了同日上午客户可见的不可达，并描述了光纤配置恢复后的恢复情况。[1][4]

这些记录在不同层面描述了光纤恢复窗口。它们并未证明每项客户服务都在同一精确时刻恢复。托管站点是一个堆栈：传输链路恢复，路由会话重新建立，路径收敛，负载均衡器和应用依赖恢复，邮件队列排空，监控清除，客户重试。公开证据并未提供完整的逐服务恢复表。

同样的原则适用于事件开始。一家受影响服务提供商描述了上午中断期间部分网络可达而其他网络不可达，而 OVH 描述了提供方一侧的光纤故障及随后的恢复。这些视角并不一定矛盾。一方记录外部客户观察到的效果；另一方记录提供商光纤系统中的事件。不同的观察者、时钟和网络路径可能看到不同边界。[4]

问责要求保留这些区别，而不是强行制定一个完美时间。强有力的事件记录应把外部探测、光纤告警、接口切换、控制器日志、路由会话变化和客户报告与共同时钟对齐。公开材料并未提供这种完整对齐，因此本文不编造它。

运行中的网络暴露了什么

根据受影响服务提供商的记录，鲁贝站点依赖光传输连接至 OVH 的六个网络接入点。公开记录描述了多条光纤路径和广泛的外部连接丢失，但并未提供每条电路、客户路径或依赖的完整已验证拓扑。[4]

这些细节很重要，因为它们表明该事件并非被描述为一次普通的单纤中断。OVH 和当时的记录反而描述了影响光纤系统的软件和配置故障，随后与设备制造商一起恢复。现有来源并未揭示完整的诊断序列或内部管理平面状态。[1][4]

公开的根本原因描述认定光纤设备配置丢失。OVH 恢复了已保存配置并恢复了受影响的连接。该公司将直接事件归因于软件缺陷，而相关路径丢失则暴露了关于共享配置和监控依赖的更广泛问题。[1][4]

这是一个有意义的说明，但并不是完整的取证报告。它没有披露确切的软件版本、引发变更的状态、进程崩溃、存储序列、复制语义、控制平面选举、人工命令、告警时间线或内部事件记录。它也没有证明丢失的配置是唯一的初始原因，还是更深层控制故障的一个可见后果。

最有力的可辩护表述较窄：OVH 的光纤设备进入了一种鲁贝外部链路不可用的状态；OVH 将该状态归因于软件缺陷和配置缺失；恢复已保存配置使连接恢复；OVH 后来提出了软件修复和架构分离。

运行中的网络是首要证据。库存记录可以说光纤、路径、板卡和备份存在。设计文档可以说链路是冗余的。事件中重要的是，光纤系统停止了提供鲁贝可达所需的外部连接。运行状态压倒了名义上的图表。

这是网络基础设施问责的核心问题。冗余不应仅按组件计数。它应按能够移除服务的故障域来评估。

物理多样性不等于控制域独立

弹性传输的常见可视化模型是两个位置之间的两条线路。如果一条光纤被切断，流量使用另一条。这个模型对狭窄的物理危险有用。当两条路径共享软件、配置权限、监控硬件、时钟、电力、管理访问、激活逻辑或共同恢复流程时，它就不完整。

两条地理位置不同的光纤路径仍可能位于同一个运营故障域中。它们可能终止于由同一数据库管理的板卡。它们可能依赖同一控制器或监控对。它们可能收到同一份有缺陷的软件映像。它们可能继承一次配置事务。它们可能需要同一管理网络进行诊断。它们可能在进入共同安全状态时故障关闭。

OVH 的记录是这一区别的具体例子。提供商描述了冗余光纤连接，但当配置丢失时，鲁贝链路同时不可用。旨在保持连接的控件并未包含实际发生的共享配置状态故障。[1][4]

这并不意味着物理多样性毫无用处。这意味着它应对的是不同的危险。弹性声明应指明其所包含的危险类别：

单根光纤被切断；
管道或地理路由故障；
一个光放大器或节点丢失；
一个线路板卡或机箱丢失；
一个控制器或监控卡故障；
配置损坏或缺失；
共同的软件缺陷；
管理连接丢失；
操作员错误在冗余系统之间传播；
事件条件下恢复失败。

某项设计可能通过前三项，却在第六或第七项失败。若不在说明受保护故障类别的情况下称结果为“冗余”，会掩盖最重要的问题。

RFC 3439 在一般架构意义上警告称，复杂性有真实成本，系统常常在意想不到的交互中失败。它并非针对 OVH 事件而写，也不能证明提供商内部设计。它提供了一种有用的分析原则：添加组件、副本和自动化可能产生共享状态和额外的故障模式，除非这些行为有边界且可观测。[14]

NIST 的网络弹性系统指南同样将弹性视为一种经过工程化的预期、承受、恢复和适应能力。它是后来的框架，不是 OVH 2017 年部署了什么证据。谨慎运用时，它表明网络不应仅按预防声明判断，还应按退化边界、恢复权限、证据保存和故障后的适应能力判断。[17]

ITU 建议所描述的光传输架构提供了层、路径关系和保护的词汇。它无法从公开事实重建 OVH 的私有拓扑。其在此处的价值在于强化一个一般性观点：光传输是一个具有控制、监控和恢复功能的受管理网络，而不仅仅是被动光纤。[18]

因此，问责的检验是独立性，而不是重复。运营商应能识别哪些元素独立、哪些有意共享，以及每个共享元素发生故障时会发生什么。

已保存配置并不等于运营可用性

OVH 的事件记录称已保存配置被恢复。该细节说明基础设施保障中一个反复出现的问题：备份的存在常被等同于可恢复性。

备份可以存在却仍无法保持服务。它可能存储在同一故障域内。其副本可能受到同一有缺陷软件的影响。它可能包含同样的损坏状态。系统可能无法自动选择或加载它。管理访问可能不可用。操作员可能需要到现场干预。恢复流程可能缓慢、含糊或在共同故障下未经过测试。

鲁贝的叙述表明，工程师最终恢复了已保存配置。这是一次成功的恢复行动。它也表明，运行中的系统并未仅仅因为存在可恢复配置而保持可用。[1][4]

因此，相关控制比“存在备份”更精确：

复制的确切对象是什么：完整数据库、生成配置、设备状态还是事务日志？
哪个进程写入每个副本，一个软件缺陷能否破坏所有副本？
副本是否不可变或独立版本化？
副本是否存储在物理和逻辑上分离的系统上？
哪种一致性规则决定副本是否可用？
能否在不依赖故障管理组件的情况下选择已知良好的版本？
恢复是自动的、经操作员批准，还是依赖本地访问？
最近一次测试中，完整恢复用了多长时间？
恢复是重建了预期状态，还是仅重建了最后一次复制状态？
哪些证据确认每个光纤节点和面向路由器的链路都已正确恢复？

公开材料只回答了列表的一部分。它表明配置恢复是可能的。它并未显示恢复是独立的、预先授权的、定期演练的，或对照服务目标进行衡量的。

这一区别应影响客户和董事会的报告。“配置已备份”是库存陈述。“已知良好的配置可以通过独立控制路径在经测试的时间内恢复，同时保留证据并防止重新引入坏状态”是运营控制陈述。

光传输是托管服务的一部分

托管问责通常在服务器或数据中心层面讨论。鲁贝故障表明这一边界为何过窄。服务器可以保持通电和健康，却因为将其站点连接至外部互联点的光传输故障而变得不可达。

OVH 的公开对等资料以及当前的 PeeringDB 和 RIPE 记录标识了 AS16276 和可观的互联足迹。这些记录对网络身份和运营商归属很有用。它们帮助客户或调查者区分 OVH 的网络与其他提供商，并识别可能发生互联的位置。它们不能证明 2017 年鲁贝某条电路的运行状态、某个特定数据包使用的路径或任意两项客户服务的独立性。[8][9][10][11]

这是现实层级的区别。注册机构或目录可以记录谁运营某个自治系统。对等页面可以描述政策。路由收集器可以保存选定的 BGP 观测。但都不能让故障的光纤系统承载流量。

反过来，光纤故障没有抹去网络身份。AS 号码、路由和外部关系仍是判断哪个网络被预期始发和承载流量的重要证据。记录和运行基础设施承担不同的问责功能：记录标识并保留权限；运行系统决定数据包是否移动。

购买“冗余”托管或从同一提供商购买多项服务的客户需要询问，他们的依赖是否在提供商内部汇聚。两个独立集群中的虚拟机可能共享同一站点传输。不同建筑中的两项服务可能共享一个城域光纤系统。两条宣告路径可能汇聚于一个控制器或配置数据库。产品名称和资源数量不会揭示这些依赖。

Actility 报告提供了一个有启发性的外部视角。它称部分服务不可达，而托管在另一个数据中心的一项 SaaS 产品未受影响。它还描述了从某些位置或网络可达，而从其他位置或网络不可达。[4]该模式与依赖和路径多样性一致，但公开数据不足以映射每条路由或服务。

客户教训不只是“使用两家提供商”。多提供商设计可以减少集中度，但会带来自身的 DNS、路由、数据一致性、安全和运营复杂性。更强的要求是记录依赖边界，并测试真正重要的失败。

影响必须与可观察证据绑定

OVH 承认对其他服务造成直接后果，并称接收客户邮件尤其困难。公司道歉并表示团队保持动员。[1]当时的报道描述了鲁贝环境中的重大客户影响。[5][6][7]

公开来源并未提供完整的受影响客户数量、丢包时间序列、逐路由分析、服务清单、收入影响或最终 SLA 表。它们也不能证明鲁贝的每个工作负载在整个光纤中断期间都不可达。它们同样不能证明某项服务仅因一次公开探测成功就是健康的。

不同网络可能观察到不同行为。路由策略、缓存的 DNS 答案、既有会话、备用服务位置和应用重试逻辑都可能影响可见影响。部分客户可能失去所有访问。其他客户可能通过剩余路径或另一个站点到达某服务。邮件可以排队且稍后送达，使传输故障表现为延迟而非永久丢失。

正确的影响陈述有三个层面：

提供商报告的基础设施影响：鲁贝站点失去了 OVH 记录中描述的外部光纤链路。
外部观察到的服务影响：客户和至少一家托管提供商报告了部分或广泛的不可达和特定的服务中断。
未知的完整影响：公开记录未逐一列出所有受影响客户、流量、路由、服务或财务后果。

保留这些层面可以同时防止轻描淡写和夸大。说完整影响未知并不是淡化事件。失去一个站点的主要光纤链路本身就是严重的。同样，在证据不支持全面中断的情况下主张全面中断也没有必要。

一份可问责的影响报告会公布来自独立网络的限时可达性、BGP 会话状态、链路可用性、聚合流量、邮件积压、主要服务健康、客户工单量和恢复分布。它会描述采样限制和时钟。它会把传输恢复与应用恢复分开。

控制分配：分布式责任不等于无责任

网络基础设施跨越组织边界。这可能导致“责任共享”的模糊结论。更好的方法按控制分配责任。

OVH

OVH 控制其鲁贝光纤网络的架构、物理路径与控制系统之间的关系、其范围内的软件部署、配置保护、监测、事件升级、本地干预、恢复顺序、客户沟通和变更设计的决定。

这种控制产生了具体义务。OVH 需要识别共同故障域、安全地分阶段部署软件、保留已知良好的配置、维护独立诊断路径、测试恢复、设定客户预期，并拿出证据证明修正后的设计能防止复发。

OVH 并不一定制造了设备软件缺陷。这并不解除其架构责任。运营商选择某个供应商缺陷如何影响自己的服务。他们决定缺陷是否会波及所有冗余路径、回滚是否可能，以及故障控制器能否被绕过。

设备制造商

设备制造商控制产品工程、缺陷分析、修正后的软件、供应商诊断以及向 OVH 提供的披露。公开记录称 OVH 正在与制造商调查，并计划升级受影响的软件。[1][4]

在没有公开供应商报告的情况下，本文无法定位确切的软件错误，也无法断言该缺陷是否为已知。制造商仍拥有产品侧任务：识别配置为何消失或变得不可用，并证明修正后的代码防止了故障。

对等方与传输提供商

外部网络运营商控制自身的链路、BGP 会话、路由偏好、监测和升级。他们可以观察到 OVH 可达性的丢失，并在存在替代互联的地方进行适应。他们无法恢复 OVH 的内部光纤配置。

BGP 运营实践（如明确的导入和导出策略）在域间边界至关重要。RFC 7454 和 RFC 8212 提供了后来或通用的路由防护，不是本次光纤事件的诊断。它们重要，因为光的恢复本身不能证明正确的路由交换。接口恢复后，明确的路由策略有助于使路径恢复受到约束。[15][16]

客户

客户控制提供商选择、服务放置、外部监测、DNS 和应用故障切换、数据复制及其自身的事件沟通。从 OVH 购买多项产品的客户可以要求证据，证明这些产品不共享鲁贝光纤故障域。

客户不控制 OVH 的内部光纤设备状态、配置系统或光纤拓扑。把提供商内部传输故障归咎于客户可以购买更多冗余，是错误的。客户弹性和提供商问责是互补的，不是替代关系。

监管机构、目录和观察者

注册机构、ASN 和对等记录支持归属和历史分析。测量平台可以保存选定的路由观测。标准机构定义了有用的设计和运营原则。它们都没有运营鲁贝系统，也无法恢复它。

这种分配避免了两种错误。第一种是把供应商缺陷当作提供商故障的完整借口。第二种是在不承认其边界之外客户和互联控制的情况下，把每个后果都归给 OVH。问责跟随预防、检测、控制、恢复和证明的能力。

检测和诊断是控制面的一部分

公开记录没有披露第一个内部告警、其时间戳、严重性、责任人或诊断质量。我们知道客户看到了不可达，OVH 动员了团队。我们不知道监测是否首先识别出光传输丢失、管理故障、路由会话丢失、流量崩溃或客户症状。

这一缺失的证据很重要，因为检测设计影响中断持续时间。一条“主机不可达”的告警不如显示光纤控制器状态、数据库健康、板卡模式、管理可达性、路由器接口状态和外部路径丢失的相关记录有用。

共同控制故障也可能损害监测。如果监控卡、管理网络或配置服务共享同一故障域，系统可能同时失去服务和解释性遥测。工程师随后面对的是黑暗故障：症状广泛、远程访问不完整，以及在不稳定证据被保存前重启设备的压力。

独立诊断路径不应仅意味着同一控制平面上的第二个接口。它应具有独立供电和管理的访问、最少依赖、已知安全边界，以及在主系统受损时捕获状态的能力。

设计还需要运营权限。谁可以重置配置？必须首先捕获哪些证据？可以加载哪个已知良好的版本？何时需要本地干预？如何权衡重启的风险与持续中断？存在却无法快速授权的恢复计划不是有效控制。

鲁贝的叙述显示，恢复光纤系统所需的不仅仅是观察到备份存在。[4]这把恢复时间变成了架构参数。如果恢复依赖多个组件的重启和顺序化，这些依赖应出现在弹性测试和服务目标中。

公布的修复将缺陷修正与影响范围控制分离

OVH 针对鲁贝的正式行动计划有两部分。它计划与设备制造商一起通过升级调查并修复软件缺陷。它还加速了一个项目，将光复用系统分布到两个独立系统，以限制故障范围。[1]

这种分离在技术上很重要。软件修正应对已知缺陷。架构分离应对不确定性，包括另一个缺陷或另一种共同控制故障的可能性。

软件补丁不能证明整个故障类别已消失。它可能修复代码中的一条路径，却让共享配置、监控或管理依赖保持不变。反过来，在未修正已知缺陷的情况下拆分系统，如果相同的软件和状态被完全相同地部署，可能产生两个独立故障的系统。

因此，强有力的修复计划应测试两个维度。

缺陷修正

将供应商公告或缺陷记录绑定到受影响的软件版本。
确定确切的故障条件、受影响组件和修正后的行为。
在代表性系统上分阶段部署修正映像。
验证配置迁移、回滚和状态保存。
复现先前导致配置丢失的条件。
保留日志，证明故障不再发生。

故障域分离

记录每个系统上终止了哪些光纤路径。
在需要处分离控制、监测、配置存储和管理访问。
防止一次配置事务同时禁用两套系统。
确保软件发布可以小规模试点并在到达每条路径前停止。
证明一套系统的丢失仍能为既定服务目标留下足够的外部容量和可达性。
测试缩减拓扑下的流量移动和路由收敛。

恢复证据

在不依赖故障控制组件的情况下恢复已知良好的配置。
测量检测、决策、恢复、链路恢复和路由收敛时间。
保存恢复前后的校验和与拓扑状态。
将内部链路状态与独立外部探测对比。
记录残余错误，而不是在第一次 ping 成功时就宣告全部恢复。

OVH 的公开声明记录了进行拆分的意图。本文冻结的来源没有提供完成日期、实施图、独立测试或后来的复发演练。负责任的结论是，所公布的方向应对了正确的控制区分，而其有效性在此记录中仍未得到证明。

如何测试冗余独立性

运营商可以通过构建故障域矩阵，将事件转化为可重复审计。每条客户相关路径都按物理路由、光纤节点、线路板卡、机箱、监控系统、配置存储、软件版本、管理网络、电力、时钟、操作员组和恢复权限进行映射。

矩阵应回答一个简单问题，适用于每对“冗余”路径：哪些组件仍能同时移除两者？

这种分析常揭示被拓扑图隐藏的依赖。分离的光纤可能进入同一建筑。分离的机箱可能共用一个控制器。分离的控制器可能共享一个数据库集群。分离的软件实例可能从共同自动化流水线收到一份错误配置。分离的数据中心可能依赖同一个 DNS、身份或网络控制服务。

矩阵只是在测试之前的一个假说。有用的测试包括：

移除一根物理光纤，验证自动光保护；
移除一个机箱，验证容量仍在既定目标内；
隔离一个控制器，验证另一系统继续运行且不出现不安全状态收敛；
损坏或保留一个配置副本，验证安全选择；
拒绝主管理路径，通过独立路径进行诊断；
向金丝雀部署一个故意被拒绝的软件映像，验证发布控制；
在时间压力下恢复已知良好配置；
从独立网络测量 BGP 和数据平面收敛；
验证面向客户的状态反映实际服务，而不仅仅是设备健康；
保留足以让外部审查者复现结论的证据。

通过条件应在测试前定义。“流量恢复”过于模糊。有用的条件应说明最低容量、最大可达性损失、允许的丢包、收敛时间、服务类别、外部观测点和证据保留要求。

测试还应考虑维护。许多常见故障发生在升级或配置变更期间，此时冗余系统被有意对齐。一项能承受随机板卡丢失的设计，可能在共同自动化作业将同一坏状态推送到两侧时失败。

独立运营并不要求每个组件都不同。完全异构可能增加复杂性和错误。它要求共享依赖明确、有边界，并与经过测试的恢复相匹配。目标不是多样性表演。目标是证明一个合理故障无法无声地击败所有被宣称为冗余的路径。

反事实控制澄清最初错失的机会

反事实分析不应假装某项控制一定会阻止事件。它询问可观察控制在哪里可能改变序列。

如果软件缺陷在部署前被发现

代表性预发布环境、金丝雀发布或供应商缺陷测试本可能在缺陷到达生产系统前暴露失败状态。公开证据并未告诉我们该缺陷是否需要一个在预发布中难以复现的罕见序列。因此这一反事实是可能的，但未证明。

如果光纤系统有独立的控制状态

如果两组路径有独立的配置权限和监控系统，一个配置数据库的丢失可能让另一组继续运行。OVH 公布的拆分计划表明公司看到了缩小共同故障范围的价值。事件前的确切拓扑不公开，因此无法计算该反事实的幅度。

如果配置恢复有独立路径

已知良好、不可变的配置和带外恢复机制本可能缩短诊断和恢复时间。事件记录称已保存配置最终被恢复。它并未显示是否存在独立恢复路径、它如何被测试，或恢复在多大程度上依赖受影响的控制环境。

如果客户有独立的托管路径

使用另一个数据中心或提供商的客户本可以避免部分服务影响。Actility 报告称位于另一个数据中心的一项 SaaS 产品未受影响。[4]这一观察支持依赖多样化，但并不证明每个多站点设计都会成功。

如果外部可达性证据被整合

独立探测和路由观测本可以帮助区分本地设备恢复与客户可达性。它们不会恢复光纤链路。其价值在于更快的诊断、范围化的沟通和更强的收尾证明。

最初错失的机会无法仅凭公开证据定论。它可能是软件保证、架构、配置状态保护、监测、恢复设计或组合。内部事件记录应确定最早拥有权限且合理能够行动的控制。

可能改变结论的证据

结论刻意可证伪。如果出现更强证据，它应当改变。

设备和控制器日志可能显示配置丢失是结果而非原因。供应商报告可能识别出特定的硬件或软件条件。拓扑记录可能显示光纤路径比公开记录暗示的更加独立，或另一个共享组件切断了它们。配置历史可能显示一次人工变更、自动化作业或状态转换触发了事件。

客户和测量数据可能修订影响边界。完整的可达性分析可能显示鲁贝几乎完全隔离，或大量残留连接。BGP 收集器数据可以确定哪些外部会话和路径发生了变化，但仍需要数据平面测量来支持转发结论。

修复证据可能加强或削弱问责认定。已完成并经控制器和配置故障独立测试的系统拆分将表明 OVH 把教训转化为了控制。后来的测试若显示两套系统仍共享一个故障域，则表明重复并未带来独立。

本文并不要求这些记录来陈述发生了严重网络故障。它需要它们来使修复主张完整。

结论

OVH 鲁贝中断的教训不是冗余无用。教训是冗余必须按其能控制的故障来描述。

提供商有冗余光纤连接和已保存配置。这些控制应对了真实风险。它们没有阻止共享光纤控制故障切断鲁贝连接，恢复仍依赖恢复配置。

OVH 后来的行动计划承认了问题的两个层面：修复软件缺陷，拆分光复用系统，让一次故障的影响范围更小。这是正确的概念分离。此来源集中的公开证据并未证明完成或抗复发能力。

对托管和网络运营商而言，问责标准是具体的。指明受保护的故障类别。映射共享控制域。保留独立诊断和已知良好恢复。在一套系统承载流量时测试另一套系统的丢失。从提供商之外测量可达性。发布足够证据以区分组件重复与运营独立。

网络身份记录和拓扑清单可以展示谁在运营基础设施，以及应该存在什么。只有运行代码证据、观察到的可达性和经过测试的恢复能证明基础设施是否继续工作。