2025 年 11 月 18 日，Cloudflare 网络出现严重故障，导致网络流量传输中断了大约两小时十分钟。将近三周后，在 2025 年 12 月 5 日，Cloudflare 网络再次出现故障，导致 28% 受到我们网络支持的应用程序无法访问，整个事件持续了大约 25 分钟。
虽然 Cloudflare 在两次事件发生之后已经发布了详细的事后分析博客文章，但我们深知，还需要付出更多努力才能赢回客户的信任。今天，我们将分享 Cloudflare 正在落实的各项工作的详细信息，以防止此类服务中断事件再次发生。
我们将计划命名为“橙色警报：小规模故障”，这反映了我们的目标，即：提高 Cloudflare 网络的韧性，防范可能引发重大中断事件的错误或过失。“橙色警报”表示，此项目相关工作的优先级高于一切。作为参考，Cloudflare 此前曾发布过一次“橙色警报”，因为当时发生了另一起重大事件，需要公司所有员工给予该项目最高优先级。我们认为，最近发生的事件也需要予以同等重视。“橙色警报”是我们实现这一目标的方式，让团队能够在必要时进行跨职能协作以完成相应的高优先级工作，同时暂停任何其他工作。
“橙色警报”工作分为三个主要领域：
对传播到网络的任何配置更改进行受控部署，就像我们目前对软件二进制版本发布所做的一样。
审核、改进并测试所有处理网络流量的系统的故障模式，确保这些系统在所有条件下（包括意外错误状态）均表现出明确定义的行为。
更改 Cloudflare 内部的“紧急访问”*规程并消除任何循环依赖关系，以便我们和客户在发生事件期间都能快速行动，并顺利访问所有系统。
我们将采取迭代改进的方式来逐步推进这些项目，而不是在项目结束时进行一次“大爆炸”式的变更。每一次单独更新都将有助于提高 Cloudflare 的韧性。最终，我们预计 Cloudflare 网络韧性将得到增强，能够更好地应对诸如过去两个月内发生的全球性事件所引发的问题。
我们理解，这些事件给 Cloudflare 客户和整个互联网社群造成了困扰。我们对此深感不安，这正是我们将这项工作列为 Cloudflare 所有员工的首要任务的原因所在。
*Cloudflare 的“紧急访问”规程让特定人员能够在特定情况下提高权限，执行紧急操作以解决严重问题。
在第一次事件中，访问 Cloudflare 客户网站的用户看到了错误页面，提示 Cloudflare 无法响应其请求。在第二次事件中，用户看到了空白页面。
这两次中断都遵循相似的故障模式。在每次事件发生前的几分钟，我们都即刻在全球数百个城市的数据中心部署了配置更改。
11 月的更改是 Cloudflare 机器人管理分类器的自动更新。我们运行各种人工智能模型，这些模型学习流经 Cloudflare 网络的流量，以构建用于识别机器人的检测规则。我们不断更新这些系统，以抢先防范那些试图规避 Cloudflare 安全保护措施并访问客户网站的恶意行为者。
在 12 月的事件过程中，为了保护我们的客户免受流行的开源框架 React 中的漏洞影响，我们对安全分析师使用的一款安全工具进行了更改，以改进签名机制。与新的机器人管理更新的紧迫性类似，我们需要抢在企图利用此漏洞的攻击者之前采取行动。当时正是这项更改触发了事件。
这种模式暴露了 Cloudflare 在部署配置更改与发布软件更新方面存在的一个严重缺陷。我们以受控和受监测的方式发布软件版本更新。对于每个新的二进制版本，必须成功完成多个阶段的验证才部署，然后为全球流量提供服务。我们首先将其部署到员工流量，然后谨慎地将其推广到全球越来越多的客户，首先从免费用户开始。如果在任何阶段检测到异常，我们都可以在无需人工干预的情况下回滚版本。
我们尚未将这种方法应用于配置更改。与发布为 Cloudflare 网络提供支持的核心软件不同，进行配置更改时，我们修改的是软件行为参数值，并且可以立即生效。我们也赋予客户这种能力：如果在 Cloudflare 解决方案中更改设置，更改将在几秒钟内在全球范围内传播。
虽然这种速度具有优势，但也伴随着需要加以解决的风险。过去的两次事件表明，我们必须以对待软件版本变更同样的谨慎态度，来对待网络流量传输方式的任何更改。
我们将改变 Cloudflare 部署配置更新的方式
两次事件的核心共同点，是我们能够在几秒钟内在全球范围内部署配置更改。在这两次事件中，错误的配置都在几秒钟内导致了 Cloudflare 网络瘫痪。
就像对软件版本已经采用的做法那样，引入受控配置部署是我们“橙色警报”计划中最重要的工作流程。
Cloudflare 配置更改会非常快速地传播至网络。当用户创建新的 DNS 记录或新的安全规则后，它会在几秒钟内到达网络上 90% 的服务器。这由我们内部称为 Quicksilver 的软件组件提供支持。
Quicksilver 也用于我们内部团队所需的任何配置更改。速度是其优势：我们可以非常快速地响应并全局更新 Cloudflare 网络行为。然而，在这两次事件中，这都导致破坏性更改在几秒钟内传播到了整个网络，而没有经过任何测试环节进行验证。
虽然可以近乎即时地将更改部署到网络的功能在许多情况下都很有用，但很少需要使用这项功能。我们正在努力以相同的方式处理配置管理与代码管理，具体方法是在 Quicksilver 中引入受控部署机制来管理任何配置更改。
我们每天通过内部称之为“运行状况调解部署”（Health Mediated Deployment，简称 HMD）的系统，多次向 Cloudflare 网络发布软件更新。在此框架下，Cloudflare 旗下拥有服务（部署于 Cloudflare 网络中的软件）的每个团队都必须定义用于衡量部署成功或失败的各项指标、发布计划，以及部署失败时应该采取的步骤。
不同的服务拥有略微不同的变量。有些服务可能需要更长的等待时间，才能继续发送到更多数据中心；而另一些服务可能对错误率的容忍度较低，即使这会导致误报。
部署完成后，HMD 工具包将开始根据计划谨慎地推进部署流程，并监测每个步骤，然后继续下一步。如果任何步骤失败，则系统会自动启动回滚，并且可以根据需要，通知相关团队。
在橙色警报结束时，配置更新将遵循相同的流程。我们希望，这种做法让我们能够快速发现过去这两次事件中出现的类似问题，并在这些问题演变成普遍问题之前予以解决。
虽然我们乐观地认为，加强对配置更改的控制可以帮助我们在问题演变成事件之前及时发现这些问题，但我们知道，错误仍然会不可避免地发生。在这两次事件中，Cloudflare 网络的一部分错误演变成了大部分技术栈问题，包括客户用于配置其 Cloudflare 解决方案使用方式的控制平面。
我们需要思考如何谨慎、分阶段地推出，不仅要考虑地理区域的扩展（扩展到更多数据中心），而且还要考虑用户群体的扩展（扩展到各种不同的员工和客户类型）。我们还需要规划提高部署的安全性，以防止故障从一项服务（例如，Cloudflare 机器人管理服务）蔓延到另一项不相关的服务（例如，Cloudflare 仪表板）。
为此，我们正在审核构成 Cloudflare 网络的每个关键产品和服务的接口合同，以确保：a) 假设每个接口之间会发生故障，以及 b) 尽量以最合理的方式处理这些故障。
回到 Cloudflare 机器人管理服务故障事件，至少有两个关键接口，如果我们当时假设这些接口会发生故障，便可以从容不迫地处理，客户原本也不太可能受到影响。第一个故障点是读取已损坏配置文件的接口。我们不应陷入恐慌，而应该设置一组合理的、经过验证的默认值，以便让流量流经 Cloudflare 网络，而即使在最坏的情况下，我们也只会丢失用于机器人检测机器学习模型的实时微调数据。
第二个接口位于运行 Cloudflare 网络的核心软件与机器人管理模块之间。如果机器人管理模块发生故障（正如实际事件中发生的那样），我们不应该默认丢弃流量。相反，我们可以再次设置一个更合理的默认值，让流量以尚可接受的分类流经 Cloudflare 网络。
在之前的事件中，我们花费了过长时间来解决问题。在这两次事件中，我们的安全系统都阻止了团队成员访问其所需的工具来解决问题，这使得情况变得更加糟糕；在某些情况下，循环依赖关系拖慢了我们的速度，因为一些内部系统也变得不可用。
作为一家安全公司，我们所有的工具都受到了身份验证层的保护，并且配备了精细化访问控制，以确保客户数据安全并防止未经授权的访问。这种做法是正确的，但与此同时，在速度至关重要的情况下，现有流程和系统却拖慢了我们的处理速度。
循环依赖关系也影响了我们的客户体验。例如，在 11 月 18 日的事件中，我们的无验证码机器人解决方案 Turnstile 变得无法使用。由于 Cloudflare 仪表板的登录流程中使用了 Turnstile，因此，在最需要进行关键更改时，没有活动会话或 API 服务令牌的客户无法登录 Cloudflare。
Cloudflare 团队将审核并改进所有紧急访问规程和技术，以确保在必要时，我们能够以最快的速度访问适当的工具，同时维持我们的安全要求。这包括检查和消除循环依赖关系，或者在发生事件后能够快速“绕过”这些依赖关系。我们还将提高培训演习的频率，以便所有团队都能够充分理解相关流程，做好应对未来可能会发生的任何潜在灾难情况的准备。
虽然这篇文章并未涵盖 Cloudflare 正在进行的所有内部工作，但上述工作流程描述了公司要求内部团队关注的首要优先事项。每个工作流程对应一个详细的计划，几乎涉及 Cloudflare 的所有产品和工程团队。我们还有很多工作要做。
到第一季度末，并且很大程度上在此之前，我们将：
其中一些目标将会是持续性的长期目标。随着不断推出新软件，我们始终需要更好地处理循环依赖关系，并且我们也需要更新紧急访问规程，以体现 Cloudflare 安全技术随着时间的推移而发生的变化。
在过去的两次事件中，我们辜负了用户和整个互联网社群的期望。我们必须努力加以改正。我们计划在推动此项工作的过程中适时分享最新进展，同时真诚地感谢客户和合作伙伴提出的问题与反馈。