摘要
- Cloudflare 在 2025 年 6 月 12 日的故障后报告中表示，一次服务中断影响了 Workers KV 及相关产品，这与第三方云服务提供商的中断有关。受影响的产品列表和依赖解释应归因于 Cloudflare 自身的故障后报告。
- 上游提供商的状态记录很重要，但它不能消除 Cloudflare 对内部依赖设计、客户沟通、降级运营以及证明计划中的依赖缩减工作已完成的责任。
- 问责问题是隐藏的故障域重新连接。客户选择 Cloudflare 部分是为了分散对另一家提供商的依赖，但 Cloudflare 的产品仍可能依赖第三方云组件，除非该依赖被披露、隔离或设计为优雅降级。
- Workers KV 是面向开发者的存储原语。当其受损时，下游应用程序、访问工作流、安全工具和小型企业服务可能会以客户未曾预料的方式失败。
- 可信的修复记录应显示依赖映射、受影响产品的清晰度、客户通知质量、故障转移重新设计、降级模式行为、恢复顺序、韧性测试，以及后来证明故障后报告中承诺已完成的证据。
隐藏依赖重新连接故障域
Cloudflare 自身的故障后报告Cloudflare 2025 年 6 月 12 日服务中断是受影响的 Cloudflare 服务、Workers KV 依赖解释和修复承诺的主要来源。Cloudflare 的状态页面和状态历史提供了公开的事件状态背景。公开的教训不仅仅是服务宕机了。它在于，客户可能视为独立韧性层的提供商本身可能依赖另一家提供商，从而重新连接故障域。
这种重新连接就是问责问题。客户使用 Cloudflare 可能出于性能、安全、边缘计算、访问控制或开发者服务。客户可能也在其他地方使用超大规模云提供商。如果 Cloudflare 产品在内部依赖同一家提供商，客户的架构可能不如其认为的那样多样化。客户看到两家供应商；而故障路径可能包含一个共享依赖。
这并不意味着第三方依赖默认是不负责任的。现代云服务由众多组件、供应商、区域、API、存储系统、身份服务和运营工具构建而成。问题在于依赖关系是否被理解、隔离、传达并设计为安全失败。一个可能损害核心客户工作流的隐藏依赖需要更有力的公开证据记录。
因此，Cloudflare 的故障后报告应被视为下游提供商的证据。它从 Cloudflare 的角度解释了其自身系统。Google Cloud 的关于 6 月 12 日服务中断的状态更新和Google Cloud 事件报告提供了上游背景。上游记录有助于解释更广泛的事件，但并不能回答 Cloudflare 客户的每个问题。Cloudflare 仍然控制着自己的产品依赖设计和客户沟通。
这种区别很重要。如果上游提供商被当作整个故事，Cloudflare 自身的连续性职责就消失了。如果将 Cloudflare 视为导致上游事件的原因，则会误解依赖结构。问责问题介于这两个极端之间：Cloudflare 依赖了什么？当该依赖失效时，哪些东西失败了？客户知道什么？之后发生了什么变化？
Workers KV 是存储原语，而非背景细节
Cloudflare 的Workers KV 文档描述了一种开发者使用的键值存储服务。Cloudflare Workers 文档和Workers KV 运行时 API 文档说明了该服务对边缘构建的应用程序的重要性。KV 可以保存配置、会话相关状态、功能标志、应用数据、访问规则、缓存元数据以及开发者可能视为高可用的其他值。
当存储原语受损时，故障可能以多种下游方式出现。网站可能加载但失去个性化。访问工具可能无法检索策略状态。安全产品可能缺乏配置数据。小型企业应用可能无法服务客户状态。SaaS 运营商可能在依赖 KV 的 Worker 中看到错误。用户可能不知道涉及 KV；他们只看到应用程序失败。
这就是受影响产品清晰度重要的原因。Cloudflare 的故障后报告控制了受影响服务的公开列表。负责任的文章不应推断 Cloudflare 未识别的产品受损。它也不应将每个 Cloudflare 产品视为同等受影响。客户需要具体的产品和依赖类别，以便确定自己的架构是否暴露。
面向开发者的服务承担着特殊的告知责任。开发者可能假设 Cloudflare 文档记录的服务属性来设计应用程序。如果一次中断揭示了隐藏的依赖，开发者可能需要调整架构、回退行为、错误处理以及客户沟通。提供商的故障后报告应提供足够的细节以供设计审查，同时不暴露会增加新风险的敏感内部实现。
Workers KV 还展示了为什么提供商的抽象可能隐藏状态集中。一个简单的键值 API 可能感觉是无服务器和分布式的。底层实现仍可能依赖特定的控制系统、元数据服务、存储层、第三方提供商或复制决策。客户不需要每个实现秘密，但他们需要知道哪些服务保证在提供商故障情况下有意义。
上游故障不能消除下游设计责任
Google Cloud 的可靠性指南架构框架：可靠性提供了设计承受故障系统的通用背景。AWS 的架构完善的可靠性支柱和 Microsoft 的Azure 架构完善的可靠性指南也提出了同样的跨云观点：韧性设计需要理解依赖、故障模式、恢复目标与权衡。
这些通用框架并非关于 Cloudflare 的事件发现。它们之所以有用，是因为它们定义了设计问题。如果提供商提供的服务被众多客户视为基础设施，该提供商必须决定哪些依赖是可接受的、哪些需要隔离、哪些需要故障转移、哪些可以降级。第三方故障测试了这些选择。
下游提供商的职责包括依赖映射、隔离、回退设计、状态沟通和恢复顺序。如果第三方服务失效，下游提供商应知道哪些内部产品依赖它、客户会出现什么症状、是否可能实现只读或降级模式、是否存在故障转移，以及如何告知客户哪些受到影响。这些职责即使在上游提供商导致初始中断时也存在。
这并不意味着每个下游产品都必须独立于任何第三方依赖。那是不现实的。某些依赖是深思熟虑且经济合理的。问责标准是相称性。如果依赖可能损害客户用于连续性的服务，提供商应为优雅降级进行设计，或明确说明其限制。服务越关键，客户应得到的证据越多。
Cloudflare 的公开故障后报告很有价值，因为它承认了依赖关系和修复承诺。后续的问责问题是完成度。依赖缩减步骤是否完成了？故障转移路径是否经过测试？受影响产品是否经过重新设计以更安全地降级？是否向客户提供了架构指南？故障后报告开始了修复记录，但并未完成它。
排版说明
降级模式是对客户的承诺
可靠性设计通常侧重于完全恢复。客户还需要降级模式。无法写入数据的服务可能仍然可以读取。无法更新的策略存储可能仍能执行最后已知的良好配置。无法访问依赖的开发者平台可能返回显式错误而非超时。状态系统可能迅速识别受影响的 API。降级模式是总混乱与受控限制之间的区别。
Google SRE 手册中关于处理过载的章节是相关的，因为过载和依赖压力需要系统卸载负载、保留优先级工作并预测性失效。关于管理关键状态的章节是相关的，因为状态依赖难以移动、缓存和恢复。Workers KV 是一个状态服务；故障设计必须考虑到状态不能总是立即重新计算。
对于客户来说，降级模式应成为产品预期的一部分。如果 KV 不可用或受损，应用程序应做什么？可以缓存最后已知值吗？应提供过时配置吗？安全策略应失败关闭吗？内容显示应失败开放吗？开发者应构建辅助存储吗？Cloudflare 可以提供文档和事件教训，帮助客户做出这些决定。
提供商的内部降级模式与客户应用程序的降级模式相互作用。Cloudflare 可能设计 KV 以某种方式降级。开发者可能处理也可能不处理该行为。如果提供商的故障后报告清晰解释了故障模式，开发者可以改进自己的设计。如果报告含糊不清，每个客户必须猜测要更改什么。
因此，问责标准不仅仅是“恢复更快”。它是“使故障可解读”。可解读的故障具有已知的症状、状态消息、错误行为、客户指导和恢复预期。隐藏的依赖故障之所以有害，部分是因为它在故障后报告解释之前是不可解读的。
中小企业继承提供商架构，却无法看见它
中小型企业通常使用云基础设施，正是因为他们无法自行构建全球可靠性。他们依赖提供商管理复杂性。这使得隐藏的依赖风险尤其重要。大企业可能有供应商风险团队、架构审查和多方提供商设计。小型开发者可能阅读产品文档，信任提供商，然后构建。
如果 Workers KV 中断影响小型企业应用程序，该企业可能没有准备好第二存储层。它可能不知道故障是自己的代码、Cloudflare、上游提供商、DNS、认证还是客户网络。它可能没有人员解析复杂的故障后报告。提供商的状态和沟通就成了该企业的事件响应。
NIST SP 800-34 修订版 1《联邦信息系统应急计划指南》是一个通用的连续性来源，但其基本教训适用：组织需要系统中断的应急计划。对中小企业而言，提供商的指导可以使这种规划可行。云提供商应提供实用模式：缓存策略、多区域考虑、数据导出、故障处理、状态订阅和测试方法。
NIST SP 800-160 第 2 卷修订版 1《开发网络韧性系统》将韧性定义为预期、承受、恢复和适应的能力。隐藏依赖中断是一次韧性测试，因为它询问系统能否在提供商下的提供商失效时适应。客户的韧性取决于提供商的透明度。
CISA 的关键基础设施韧性资源提供了系统依赖的公共部门框架。即使开发者服务并非对每个客户都是关键基础设施，这种模式也很重要：许多小服务可能依赖同一个隐藏的故障域。一次中断可能波及那些不知道共享依赖的企业。
状态沟通应分离产品层
多产品提供商的状态沟通必须分层。使用核心 CDN、安全、Workers、KV、Access、Pages 或其他服务的客户需要知道哪一层受影响。如果状态语言过于宽泛，未受影响的客户会恐慌。如果过于狭窄，受影响的客户可能错过连接。如果仅提及上游提供商，客户可能不知道哪些 Cloudflare 产品受损。
Cloudflare 的状态页面和历史提供了状态渠道背景。故障后报告提供了更深入的解释。两者应一致。状态更新应识别受影响的产品、客户症状、缓解进展以及恢复是否部分或完全完成。故障后报告应解释根本原因、依赖结构、时间线、影响和修复承诺。客户同时需要实时和回顾版本。
核心 CDN/安全产品与 Cloudflare 识别为受损的产品之间的区别很重要。Cloudflare 是一个广泛的平台。Workers KV 的故障不应自动被视为每个 Cloudflare 服务的故障。相反，使用依赖产品的客户不应从通用的平台通知中推断影响。产品层精度是一种信任控制。
良好的状态沟通也有助于客户撰写自己的通知。基于 Cloudflare 构建的 SaaS 运营商可能需要向客户解释服务降级。如果 Cloudflare 提供具体的受影响产品和时间信息，他们可以更准确地做到这一点。如果 Cloudflare 的状态含糊，下游通知也会变得含糊。不确定性会传播。
公开的故障后报告还应解决客户检测问题。客户会看到什么错误？哪些 API 或产品受损？客户可以使用哪些日志来确认影响？数据持久性、一致性受到影响，还是主要是可用性？如果公开记录不能回答每个问题，应说明客户可以在哪里寻求更多细节。
依赖映射应以受控形式面向客户
提供商不能发布每个内部依赖映射。那将带来安全和竞争风险。但他们可以发布受控的依赖信息，帮助客户评估故障域。例如，产品可以记录其是否依赖第三方云区域、是否存在多区域复制、客户应计划哪些故障模式，以及哪些服务级别目标排除了上游提供商的故障。
这不仅仅是法律细则。这是架构信息。设计韧性的客户需要知道选择 Cloudflare 加上另一个云提供商是否真正分散了特定风险。如果 Cloudflare Workers KV 在相关路径上依赖第三方提供商，客户应在有用级别上理解设计含义。否则，客户可能意外构建相关架构。
依赖透明度可以分层。公共文档可以描述广泛的架构和故障模式。企业信任材料可以在适当控制下提供更多细节。状态页面可以在依赖变得相关时披露事件特定的依赖。故障后报告可以解释什么发生了变化，同时不暴露敏感内部信息。目标是足够的信息用于客户设计，而非完整的内部图表。
2025 年 6 月的事件很有价值，因为它使依赖在事后变得可见。修复问题是依赖是否在下一事件之前变得足够可见。客户不应需要一次中断来了解两家提供商在其故障模型中相连。提供商应提前使重要的依赖选择可解读。
剩余未知与问责问题
公开记录留下了一些未知数。它没有提供 Workers KV 受损对每个客户的完整影响。它没有暴露 Cloudflare 在事件之前的整个内部依赖设计。它没有独立验证每个计划的依赖缩减承诺是否已完成。它没有证明每个客户在中断前是否拥有足够的架构信息来评估共同的故障域。
这些未知数并不使问责变得不可能。它们定义了客户和观察者接下来应寻找什么。Cloudflare 控制了 Workers KV 依赖的设计、受影响产品的沟通、降级模式行为、恢复顺序和修复承诺。Google Cloud 控制了自己的上游中断和状态报告。客户只能在其可见的产品行为和依赖模型范围内控制其应用回退行为。
问责问题是中断是否减少了未来的隐藏依赖风险。Cloudflare 是否清晰映射了依赖？它是否移除或隔离了故障路径？它是否改进了故障转移？它是否更新了客户文档？它是否在上游故障条件下测试了新设计？它是否解释了客户应做哪些不同的事情？后来的状态记录是否显示了改进的行为？
答案应基于证据。一份韧性得到改进的陈述只有当客户能看到韧性哪类发生了变化时才有帮助。读可用性是否改进？写可用性是否改进？产品依赖是否缩小？恢复时间是否下降？降级模式是否更安全？状态沟通是否更快？这些都是可测量的问题。
最终教训是多样化的证明
云客户通常通过选择多个供应商来实现多样化。该策略只有在供应商的内部依赖没有静默地重新连接同一个故障域时才有效。2025 年 6 月的 Cloudflare 事件提醒我们，多样化必须被证明，而非假定。客户可能将 Cloudflare 和 Google Cloud 视为不同选择；而一个内部依赖可能仍将它们通过特定产品路径连接起来。
这并不意味着客户应不信任所有抽象。抽象是云服务可用的原因。这意味着提供商应明确其销售抽象的韧性特性。如果服务是全球分布的，客户应了解哪些部分是全球分布的，哪些依赖更有限的系统。如果服务使用第三方基础设施，客户应了解该依赖是否会损害他们。
对于 Cloudflare，中断后的问责标准不是完美。而是学习的证据：更清晰的依赖映射、更安全的降级模式、按承诺减少依赖、更强的故障转移、更好的状态特异性，以及帮助开发者设计韧性应用的客户指导。对客户而言，教训是不仅要问“我使用哪个供应商？”还要问“我的供应商共享哪些故障域？”
这次中断属于风险与问责系列，因为它暴露了一种微妙的现代云风险。提供商可以在销售韧性的同时依赖其他提供商。这可能是合理的，但必须得到治理。连续性不仅仅是运行时间数字。它是知道哪些依赖将一起失效，并证明下一次失效会更小。
客户架构可能因合理原因出错
客户可能基于可用的信息做出合理的设计选择，但仍然误解故障域。开发者可能将应用逻辑放在 Cloudflare Workers 上，使用 Workers KV 用于配置或状态，并将其他服务托管在 Google Cloud 上，因为这看起来分散了风险。如果 Workers KV 在某些关键操作上依赖 Google Cloud 路径，架构可能比开发者预期的更具相关性。错误不是愚蠢。而是缺失依赖信息。
这就是提供商文档重要的原因。产品页面通常强调性能、规模、易用性和全球可用性。客户还需要故障域信息。哪些组件是复制的？哪些有第三方依赖？哪些依赖在读取路径、写入路径、控制路径或恢复路径中？哪些产品设计为在中断期间提供过时数据？哪些需要实时访问提供商依赖？
答案不需要暴露每个内部细节。客户不需要数据库表名或私有网络图。他们需要设计相关的类别。如果服务有第三方云依赖可能影响可用性，这一点可以在受控级别上表达。如果该依赖在事件后已被移除或减少，提供商可以说明哪类依赖发生了变化。
客户架构审查应随后整合这些事实。使用 KV 进行功能标志的企业可能决定过时读取是可接受的。使用 KV 进行策略的安全产品可能认为失败关闭行为更安全。消费应用可能决定在其他地方缓存非敏感内容。受监管服务可能需要第二家提供商或本地紧急模式。良好的依赖信息让不同客户做出不同选择。
没有这些信息，所有客户都继承了相同的意外。这就是云服务中的故障域问责问题：提供商拥有地图，但客户承担了部分中断成本。
服务级别语言应与依赖现实匹配
服务级别目标和状态页面可能无意中隐藏依赖边界。产品可能宣传可用性，但客户真正的问题是哪些故障模式下的可用性。承诺是否假定提供商自身基础设施健康？是否排除了上游云故障？是否包括依赖产品？是否区分读取和写入操作？是全局还是区域性适用？是否覆盖控制平面功能以及数据访问？
2025 年 6 月的中断使这个问题变得实际。评估 Workers KV 的客户可能不那么关心抽象的运行时间，而更关心依赖失效时会发生什么：应用能否读取现有密钥、写入新值、列出密钥、认证 API 调用、部署新 Worker 或提供旧配置？单一的可用性百分比无法回答所有这些问题。
状态页面应反映这种粒度。在事件期间，“性能降级”对于需要知道写入是否失败、读取是否过时、复制是否延迟或依赖产品是否受损的开发者来说可能过于模糊。提供商可能不会立即知道每个细节，但状态进展应在事实到来时缩小不确定性。故障后报告应随后闭环。
这不仅仅是客户体验问题。它塑造了事件响应。如果客户知道写入受损但读取安全，他们可以暂时冻结配置更改。如果他们知道策略读取可能失败，他们可以激活回退。如果他们只知道产品降级，他们可能采取更广泛、更具破坏性的行动。精确的提供商沟通减少了下游的过度反应。
因此，服务级别语言应针对事件进行测试。状态页面是否告诉了客户他们需要的信息？SLA 或 SLO 语言是否与故障一致？客户是否理解该事件是否计入承诺？产品文档是否解释了如何为这种故障模式设计？如果没有，提供商的可靠性承诺比看起来更不可用。
数据本地性与提供商依赖是不同的
客户通常从数据存储或处理位置的角度考虑数据本地性。隐藏的第三方依赖提出了一个相关但不同的问题：哪些提供商关系参与了服务运营？服务可能将数据存储在一个地方，在边缘处理请求，但仍然依赖另一个提供商来执行控制功能、存储后端、协调层或运营组件。即使不改变客户正式的数据驻留状态，依赖也可能对连续性很重要。
这种区别应在客户材料中明确。如果服务有区域数据位置保证，客户应知道这些保证是否解决了可用性依赖。客户可能符合数据本地性要求，但仍然有对其他提供商的连续性依赖。相反，第三方运营依赖可能不意味着客户数据暴露给该提供商。类别不应模糊。
在 Cloudflare 事件中，文章不应推断超出源记录的客户数据迁移。问责问题是连续性和依赖可见性，而非无依据的数据传输声明。但拥有数据主权担忧的客户可能仍然会问隐藏依赖是否影响其风险分析。提供商应准备好以精确术语回答：什么数据、什么元数据、什么控制信号、什么区域、什么提供商、什么故障模式。
精确保护双方。它防止客户在证据仅表明可用性受损时假设数据暴露。它也防止提供商像处理隐私误解一样驳回合法的依赖关注。连续性、隐私、本地性和韧性重叠，但它们并不相同。
最佳的客户文档将分离这些维度。数据驻留描述了客户数据存储或处理的位置。运营依赖描述了服务工作所需的系统。控制平面依赖描述了管理配置或协调的服务。故障域依赖描述了哪些外部中断可能损害产品。客户需要所有四个视角进行严肃架构。
恢复顺序是公开的可靠性信号
故障后报告应解释中断为何开始，以及恢复是如何排序的。哪些依赖必须首先恢复？哪些产品首先恢复？客户在写入之前是否能够提供读取？依赖产品是否在 Workers KV 之后恢复，还是某些需要额外修复？状态消息是否与技术恢复顺序相同？恢复顺序告诉客户提供商如何理解其依赖图。
对于广泛的提供商，恢复顺序也揭示了优先级。某些产品支持安全控制，某些支持开发者应用，某些支持客户访问，某些支持内部运营。在多产品受损期间，领导者必须决定首先恢复什么以及如何沟通部分恢复。客户不应猜测他们的产品是否在等待隐藏的前提条件。
公开的故障后报告不需要每个内部分钟。它应提供足够的顺序以显示因果关系和学习。如果 Workers KV 受损影响了依赖产品，报告应解释这种关系。如果第三方依赖在 Cloudflare 所有产品恢复之前返回，报告应解释为何需要额外的内部恢复。如果 Cloudflare 在事件期间实施了变通方案，客户应知道这些变通方案保护了什么，没有保护什么。
恢复顺序也支持客户规划。如果客户的应用程序依赖 KV 和另一个 Cloudflare 产品，知道哪个首先恢复有助于设计回退。如果写入在读取之后恢复，客户可以决定是否排队更新。如果控制平面恢复滞后于数据平面恢复，客户可以避免在事件期间进行更改。这些是透明排序带来的实用设计结果。
最强的修复记录将随后测试该顺序。在演练中，Cloudflare 能否模拟上游依赖故障并显示依赖产品恢复更快或降级更安全？状态更新能否更早识别故障层？客户能否看到更清晰的症状？此类测试的证据将比改进承诺更有说服力。
故障后承诺需要后续闭环
故障后报告很有价值，因为它将事件转化为公开承诺。它也创造了问责债务。当提供商表示将减少依赖、改进故障转移、重新设计架构或更改监控时，客户日后应能查看该工作是否完成。否则，故障后报告变成了愿望清单而非修复记录。
闭环可以是公开的，而不必鲁莽。提供商可以发布后续说明，表示依赖已从关键路径中移除、故障转移测试现已通过、状态页面自动化得到改进或客户文档已更新。它可以描述控制类别而非暴露内部信息。对企业客户，更多细节可以通过信任渠道共享。关键在于避免让承诺悬而未决。
客户也应跟踪这些承诺。供应商风险团队可以在审查期间记录故障后行动并询问闭环证据。开发者可以关注文档更新。安全团队可以在提供商修复后测试自己的回退。采购团队可以在续约讨论中包含依赖透明度。故障后报告不仅仅是阅读材料；它是供应商风险任务的来源。
Cloudflare 中断是一个很好的例子，因为源记录包括修复承诺。文章不应声明这些承诺在没有证据的情况下完成。它应将完成标识为下一个问责步骤。这保持了公开记录的公平性：承认提供商的透明度，同时仍要求修复证明。
这一标准也有助于提供商。公开闭环建立信任。如果提供商仅在中断热度期间发布故障后报告，但从不闭环，客户可能认为工作消失了。简洁的完成记录表明事件学习在服务恢复后仍然存在。
客户应假设提供商之提供商的故障
许多客户手册将提供商故障视为单一盒子。如果 Cloudflare 故障，做这个。如果 Google Cloud 故障，做那个。2025 年 6 月的记录表明一个更现实的模型：一个提供商的产品可能因为其下的提供商故障而失败。因此，客户手册应询问当供应商依赖重叠时如何响应。
第一步是清点。哪些应用程序依赖 Workers KV？它们在其中存储什么数据或配置？如果读取失败会怎样？如果写入失败会怎样？哪些面向用户的服务依赖这些应用程序？哪些客户或内部团队必须被通知？哪些回退值是安全的？哪些更改应暂停？没有这些清点，客户在尝试响应的同时发现依赖。
第二步是故障模式。应用程序能否提供过时内容？能否本地缓存配置？能否排队写入？能否对安全决策失败关闭？能否显示维护页面而非超时？能否切换到非关键数据的另一个存储？每个答案取决于应用目的。安全策略不应随意失败开启；营销横幅可能可以提供过时内容。
第三步是提供商沟通。客户应订阅相关状态页面，识别客户团队的升级路径，并知道故障后报告出现在哪里。在事件期间，客户团队应将提供商状态映射到自己的服务影响，并向下游沟通。提供商的特异性使这更容易，但客户仍需要自己的映射。
第四步是演练。客户可以模拟 KV 读取失败、写入失败、延迟、过时数据或状态不确定性。演练可能揭示应用代码假设 KV 始终可用、错误消息无帮助或支持团队不知道其中涉及哪个提供商依赖。在测试中发现的代价比真正提供商中断期间小。
多云并不自动等于多故障域
云市场常常将多云视为韧性。Cloudflare 事件显示了为什么该短语需要证据。多云可以减少某些风险并增加其他风险。它可能多样化供应商锁定、区域暴露、定价杠杆或特定服务故障。但如果一个提供商的产品在隐藏路径中依赖另一个提供商，如果身份集中化，如果 DNS 共享，如果可观测性单归属，如果员工无法操作回退，那么它可能不会多样化。
因此，客户应描述他们想要分离的具体故障域。他们想要独立于云区域？提供商控制平面中断？存储服务？身份提供商？DNS 提供商？边缘网络？计费或部署工具？正确的架构取决于故障域。供应商数量本身不是架构。
提供商可以通过在客户需要的级别描述自己的依赖来支持这一点。如果产品在组件上依赖第三方云，这仍然可能是可接受的。但使用该产品作为多样化层的客户应知道。提供商不需要承诺绝对独立；它需要避免意外的客户误解。
因此，2025 年 6 月的中断是一个有用的审计提示。客户应审查他们认为在哪里存在多样化，并询问什么证据支持该信念。提供商应审查客户可能假定独立的地方，并决定文档是否应澄清。当双方对正在多样化的依赖都明确时，韧性最强。
问责分裂应保持平衡
将 Cloudflare 视为造成了上游中断的每个事实是不公平的。将上游中断视为唯一的问责故事也是不完整的。平衡的观点根据控制分配职责。Google Cloud 拥有其服务中断和状态记录。Cloudflare 拥有依赖该服务的产品设计、客户通知、恢复和修复承诺。客户拥有其应用回退选择，但仅限于他们可用的信息。
这种分裂很重要，因为现代云事件通常是链式的。支付提供商依赖云提供商。SaaS 提供商依赖身份提供商。安全提供商依赖存储服务。开发者平台依赖第三方协调层。当上游组件失败时，下游提供商同时是受害者和责任方。他们没有造成上游故障，但他们设计了依赖路径。
公开问责应足够成熟以同时持有两种真相。仅归责的叙事会阻碍透明度。仅推卸的叙事会隐藏修复职责。有用的问题是，每一方在事件之前、期间和之后合理地做了什么。上游提供商沟通了吗？下游提供商隔离了吗？客户计划了吗？每个参与者在事后改进了吗？
Cloudflare 的故障后报告通过使依赖公开化提供了帮助。下一个建立信任的步骤是依赖被减少、隔离或变得安全的证据。这就是链式事件如何在下一次变成更短的链。
最终运营标准
提供商内部第三方连续性的最终标准包括五个部分。第一，充分了解依赖映射以预测客户症状。第二，设计关键产品在第三方依赖失效时安全降级。第三，在事件期间清晰沟通受影响的产品层。第四，发布区分上游原因和下游设计选择的故障后报告。第五，通过后续证据闭环承诺的修复。
这一标准要求很高，因为云提供商在复杂系统之上销售简单性。客户有权依赖这种简单性，但提供商不应让简单性隐藏风险。当隐藏依赖通过中断变得可见时，提供商有机会改进架构和信任。
Cloudflare 2025 年 6 月的 Workers KV 记录属于本系列，因为它展示了基础设施问责的现代形态。故障域不仅仅是服务器或区域。它是另一个提供商产品内部的一个提供商关系。这是客户日益面临且无法在没有帮助的情况下评估的风险。
持久的问题不是提供商是否可以使用其他提供商。他们会的。问题是依赖是否得到治理、为设计充分披露、在故障下测试以及损坏后修复。连续性现在依赖于这种诚实。