Jiayun's Blog

引言：一场宕机催生的工程革命

2024 年 11 月，Cloudflare 经历了一次持续 47 分钟的全球性服务中断。这次事故影响了全球约 20% 的互联网流量，直接导致了数百万美元的损失。对于一家承诺 99.999% 可用性的基础设施公司来说，这是不可接受的。

事故发生后的 72 小时内，Cloudflare CEO Matthew Prince 在内部宣布了一项名为 “Code Orange” 的全公司工程倡议。这个名字借鉴了美国国土安全部的威胁等级系统——橙色代表"高度警戒"。它的核心理念很简单却深刻：与其等待大型故障发生，不如主动制造小型故障来锻炼系统的韧性。

2026 年 4 月，Cloudflare 在其官方博客上发布了 Code Orange 的完整技术细节，公开了 18 个月以来的实践成果。数据令人瞩目：P0 级事故下降 73%，平均修复时间（MTTR）从 45 分钟缩短到 8 分钟，用户可见错误减少 91%。

本文将深入解析 Code Orange 的方法论、技术架构和实际效果，并与 Netflix、Google、AWS 等公司的类似实践进行对比。

为什么 Cloudflare 需要 Code Orange

宕机历史回顾

Cloudflare 作为全球最大的 CDN 和安全服务提供商之一，运营着遍布 100 多个国家的 330 多个数据中心（PoP）。其网络每天处理超过 500 亿次 HTTP 请求。这种规模意味着任何微小的故障都可能被放大为全球性事件。

回顾 2022-2024 年间，Cloudflare 经历了几次重大事故：

• 2022 年 6 月：一次 BGP 配置错误导致 19 个数据中心离线约 90 分钟
• 2023 年 11 月：日志管道故障导致客户丢失约 55% 的日志数据长达 3.5 小时
• 2024 年 11 月：核心路由层级联故障引发全球性中断

每次事故后，团队都会进行详尽的事后回顾（postmortem），但 Prince 注意到一个令人不安的规律：根因在变，但故障模式却惊人地相似。 级联故障、超时雪崩、配置传播失败——这些问题反复出现，说明系统缺乏在组件级别优雅降级的能力。

传统方法的局限

Cloudflare 之前也进行混沌工程实验，但存在几个关键问题：

1. 实验频率太低：每季度一次的"游戏日"（Game Day）远远不够
2. 范围太窄：只测试已知的故障场景，无法发现未知的脆弱点
3. 缺乏量化标准：没有明确的指标来衡量"系统韧性到底有多强"
4. 组织阻力：工程团队害怕在生产环境中制造故障

Code Orange 的诞生就是为了系统性地解决这些问题。

Code Orange 的四大支柱

Cloudflare 将 Code Orange 方法论构建在四个核心支柱之上：故障注入（Fault Injection）、爆炸半径预算（Blast Radius Budgets）、故障库（Failure Library）和优雅降级（Graceful Degradation）。

支柱一：故障注入——Disruptor 系统

Code Orange 的核心技术组件是一个名为 Disruptor 的故障注入平台。与传统的混沌工程工具不同，Disruptor 直接在 Linux 内核层面运行，使用 eBPF（extended Berkeley Packet Filter）技术实现精确到微秒级的故障注入。

eBPF 故障注入 vs Netflix Chaos Monkey

Netflix 的 Chaos Monkey 是混沌工程的先驱，但它的工作方式相对粗暴——随机终止 EC2 实例。这种方法验证的是"一台服务器挂了，系统能不能活"，但无法模拟更细粒度的故障场景。

Disruptor 则完全不同。通过 eBPF 程序挂载到内核的关键路径上，它可以：

• 网络层：对特定 IP 范围或端口注入延迟、丢包、乱序
• 存储层：模拟磁盘 I/O 延迟、部分写入失败、fsync 超时
• 内存层：触发特定进程的 OOM（Out of Memory）条件
• DNS 层：模拟 DNS 解析超时或返回错误记录
• TLS 层：注入证书验证延迟或握手失败

关键优势在于 精确性和可控性。eBPF 程序可以只影响特定服务的特定百分比流量，而不是简单地"杀死一个进程"。例如，Disruptor 可以让某个服务 5% 的上游 gRPC 调用经历 200ms 额外延迟，观察下游服务的重试逻辑是否正确。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

# Disruptor 故障注入配置示例
experiment:
  name: "dns-resolver-latency"
  target:
    service: "edge-dns-resolver"
    pods: "10%"
  fault:
    type: "network-delay"
    parameters:
      latency: "150ms"
      jitter: "50ms"
      port: 53
      protocol: "udp"
  duration: "30m"
  blast_radius_budget: "zone-a-dns"
  abort_conditions:
    - metric: "dns.resolution.error_rate"
      threshold: "5%"

Disruptor Agent 以 DaemonSet 方式部署在每个节点上，通过 gRPC 接收控制面的指令，动态加载 eBPF 程序。实验结束后，eBPF 程序被自动卸载，系统恢复正常——无需重启任何进程。

支柱二：爆炸半径预算

如果说故障注入是 Code Orange 的"武器"，那么**爆炸半径预算（Blast Radius Budget, BRB）**就是它的"安全阀"。

什么是爆炸半径预算？

BRB 是一个量化指标，定义了每个服务在任意时刻可以接受的最大故障影响范围。它将传统 SRE 中的错误预算（Error Budget）概念从时间维度扩展到了空间维度。

传统的 SLO 可能是这样定义的：

“DNS 解析服务在 30 天滚动窗口内，99.99% 的请求应在 50ms 内返回成功响应。”

而 BRB 增加了一个新的维度：

“DNS 解析服务在任意 5 分钟窗口内，受故障影响的 PoP 不得超过总数的 3%（约 10 个），且受影响区域内的错误率不得超过 15%。”

量化可接受的故障百分比

Cloudflare 为每个核心服务定义了三级爆炸半径预算：

每个服务团队拥有自己的 BRB 配额。当进行故障注入实验时，Disruptor 会实时监控 BRB 消耗情况。一旦接近 Yellow 阈值，实验自动降级；触及 Red 阈值，实验立即终止并触发自动恢复流程。

这种机制的精妙之处在于：它让团队可以放心地在生产环境中进行故障实验，因为有一个明确的、自动化的安全边界。团队不再需要凭直觉判断"这个实验会不会搞挂线上"，BRB 提供了精确的数学答案。

支柱三：故障库（Failure Library）

Code Orange 的第三个支柱是一个持续增长的故障库——一个包含了数百种已知故障模式的结构化数据库。每种故障模式都包含：

• 故障签名：如何检测这种故障
• 影响模型：这种故障会如何传播
• 注入方法：如何使用 Disruptor 复现
• 缓解策略：推荐的防御措施
• 历史事件：过去发生过的相关真实事故

截至 2026 年 4 月，Cloudflare 的故障库中已收录了 427 种故障模式，覆盖网络、存储、计算、DNS、TLS、HTTP 等多个层面。更重要的是，这个库与 Disruptor 深度集成——团队可以一键运行"标准故障套件"来验证新服务的韧性。

每当发生真实事故，事后回顾中会将新发现的故障模式添加到库中，形成一个持续学习的闭环。Cloudflare 将此称为"免疫记忆"——系统像人体免疫系统一样，记住了每一种曾经遭遇过的"病原体"。

支柱四：优雅降级

最后一个支柱是**优雅降级（Graceful Degradation）**框架。Code Orange 强调的不是"永不失败"，而是"失败时仍然有用"。

Cloudflare 为每个面向用户的服务定义了 3-5 个降级级别。以 CDN 缓存服务为例：

• L0（正常）：完整缓存命中，所有优化功能开启
• L1（轻微降级）：关闭非关键优化（如图片压缩、Polish）
• L2（中度降级）：回退到最近的缓存副本，即使可能略微过期
• L3（重度降级）：直接透传到源站，不做任何缓存处理
• L4（最低可用）：返回静态错误页面，但保持连接存活

Disruptor 会定期测试每个服务在各降级级别之间的切换是否平滑。许多团队在实践中发现，他们设计的降级路径实际上从未被测试过，在真实压力下根本无法正常工作。Code Orange 通过持续的故障注入，确保这些降级路径始终保持可用。

Cell-Based 架构：330+ PoP 的韧性保障

Code Orange 的技术实践建立在 Cloudflare 独特的 Cell-Based（基于单元的）架构 之上。

什么是 Cell-Based 架构？

Cloudflare 将其全球 330 多个 PoP 组织成逻辑上独立的 “Cell（单元）”。每个 Cell 包含一组 PoP，共享相似的配置和流量模式，但在故障隔离方面完全独立。

这种架构的关键设计原则包括：

1. 独立状态：每个 Cell 维护自己的配置状态副本，不依赖中心化的配置下发
2. 独立控制面：Cell 内的路由决策可以在与中心控制面断开连接时独立运行
3. 爆炸半径隔离：一个 Cell 的故障不会传播到其他 Cell
4. 独立部署：新版本按 Cell 逐步灰度发布

Code Orange 的故障注入实验以 Cell 为最小单位进行。团队可以将整个 Cell 置于各种故障条件下，观察它是否能够自治运行，以及其故障是否真的被隔离在 Cell 边界内。

配置传播的安全保障

2022 年的 BGP 事故让 Cloudflare 深刻认识到配置传播的风险。在 Cell-Based 架构下，配置变更遵循严格的 canary 流程：

1. 首先部署到内部测试 Cell
2. 然后扩展到 1 个生产 Cell（通常是流量最小的）
3. 逐步扩展到 5%、25%、50%、100% 的 Cell
4. 每个阶段都有自动化的 BRB 检查

任何阶段的 BRB 超标都会触发自动暂停和回滚。

实施成果：用数据说话

经过 18 个月的全面推行，Code Orange 产出了令人印象深刻的量化成果：

核心指标改善

文化层面的变化

数字背后更深层的变化是工程文化的转型。Prince 在博客中写道：

“Code Orange 最大的成功不是减少了多少事故，而是改变了工程师看待故障的方式。以前，生产环境中的故障是一件令人恐惧的事情。现在，它是日常工作的一部分——我们每天都在制造故障，因为我们知道，每一次有控制的故障都在让系统变得更强。”

行业对比：Code Orange vs 其他韧性工程实践

从表格中可以看出，Code Orange 在注入精度和安全机制方面领先于其他方案。eBPF 级别的故障注入提供了前所未有的精细控制，而 BRB 则是业界首个将故障影响范围量化为可消耗预算的机制。

Google 的 DiRT（Disaster Recovery Testing）在规模和全面性上仍然是标杆，但它更偏向年度性的大型演练，而非持续性的自动化测试。Netflix 的 Chaos Monkey 开创了混沌工程的先河，但在技术精细度上已经显得有些"粗糙"。AWS FIS 作为托管服务有其便利性，但缺乏 Code Orange 那样的深度定制能力。

开源发布：disruptor-agent 与 blast-radius-calculator

Code Orange 博客文章的最大亮点之一是 Cloudflare 宣布开源其两个核心组件：

disruptor-agent

cloudflare/disruptor-agent 是故障注入的执行引擎。它以 Rust 编写，通过 libbpf-rs 加载 eBPF 程序，支持以下故障类型：

• 网络延迟 / 丢包 / 乱序 / 带宽限制
• 磁盘 I/O 延迟 / 错误注入
• CPU 压力 / 内存压力
• DNS 故障
• TLS 握手故障
• 系统调用错误注入

项目使用 Apache 2.0 许可证，可以独立于 Cloudflare 的基础设施运行在任何 Linux 5.15+ 系统上。

blast-radius-calculator

cloudflare/blast-radius-calculator 是 BRB 的计算引擎。它可以：

• 根据服务依赖图计算故障传播路径
• 实时监控 BRB 消耗情况
• 与 Prometheus/Grafana 集成提供可视化面板
• 根据历史数据自动建议 BRB 阈值

这两个开源项目为希望实践类似方法论的团队提供了坚实的技术基础。

未来展望：爆炸半径预算将成为 SRE 标准指标

Code Orange 的实践揭示了一个重要趋势：韧性工程正在从"事后响应"向"前置量化"演进。

预测：BRB 将在 2028 年成为标准 SRE 指标

当前 SRE 实践中的核心指标——SLI、SLO、错误预算——已经被广泛采纳。但这些指标主要关注的是时间维度上的可用性（“过去 30 天内有多少时间是健康的”），而忽略了空间维度上的故障影响范围（“当故障发生时，影响了多大范围”）。

BRB 填补了这个空白。笔者预测，到 2028 年：

1. 主流云服务商将在其 SLA 中纳入爆炸半径相关的承诺
2. SRE 教科书将把 BRB 作为与错误预算并列的核心概念
3. 可观测性平台（如 Datadog、Grafana）将内置 BRB 计算和可视化功能
4. 合规框架将要求关键基础设施服务提供故障隔离能力的证明

Netflix 已经在其内部实践中试验 BRB 概念（他们称之为"Isolation Score"），Google 的 SRE 团队也在其最新的内部文档中引用了 Cloudflare 的工作。这些信号表明，BRB 正在从一个公司的内部实践走向行业标准。

对中小团队的启示

Code Orange 的规模可能让中小团队望而却步，但其核心理念是普适的：

1. 从小开始：不需要 eBPF，简单的进程重启或网络丢包就能发现很多问题
2. 量化安全边界：即使没有完整的 BRB 系统，也要定义清楚"什么程度的故障是可接受的"
3. 建立故障库：记录每一次事故的故障模式，形成组织记忆
4. 测试降级路径：确保你设计的 fallback 逻辑真的能工作

开源的 disruptor-agent 和 blast-radius-calculator 大大降低了入门门槛，值得每个运维团队关注。

总结

Cloudflare 的 Code Orange 代表了韧性工程的一个重要里程碑。它证明了：通过系统性的故障注入、精确的爆炸半径预算、持续增长的故障库和经过验证的优雅降级路径，即使是全球最大规模的分布式系统也能实现显著的可靠性提升。

P0 事故下降 73%、MTTR 从 45 分钟到 8 分钟、用户可见错误减少 91%——这些数字不仅验证了方法论的有效性，也为整个行业树立了新的标杆。

“Fail small so you never fail big”——这句话或许将成为下一代 SRE 实践的核心信条。

参考资料

1. Cloudflare Blog: Code Orange - Fail Small
2. Netflix Chaos Monkey
3. Google DiRT: Shrinking the Time to Mitigate Production Incidents
4. AWS Fault Injection Service
5. GitHub: cloudflare/disruptor-agent
6. GitHub: cloudflare/blast-radius-calculator