一个数据库权限的简单更改，让大半个互联网心脏骤停
引言
现代互联网的体量和复杂度已经远远超过传统系统的承载边界，每一次大规模事故都像一面镜子，逼迫基础设施公司重新审视自己的架构与工具。Cloudflare 的那次全球性故障不仅暴露了问题，更像是一道分水岭，让整个行业开始重新思考"在极端压力下，系统到底应该如何被观察、如何被理解、如何在失控边缘保持清醒"。
而在这段重建可观测性与分析能力的过程中，一家来自俄罗斯工程师文化、带着几乎传奇色彩的公司——ClickHouse，却意外成为故事的另一主角。它的技术哲学、成长轨迹以及在灾难级场景中的表现，与 Cloudflare 的演进彼此交错，形成了一条独特的技术叙事线。
接下来的内容，从 Cloudflare 的复盘，到 ClickHouse 的极限性能，再到两者相遇后的系统变革，将构成一个关于现代互联网韧性、工程执念与技术命运交汇的完整故事。
事故回顾
2025 年 11 月 18 日，Cloudflare 发生了近六年来最严重的一次全球性服务中断。此次故障不是网络攻击，也不是硬件故障，而是一次数据库权限的变更——更准确地说，是 ClickHouse 数据库查询行为的变化，引发了连锁反应，最终导致 Cloudflare 大规模 5xx 错误。
根据 W3Techs 报道，截至 2025 年 1 月，互联网上约有 19.3% 的网站使用 Cloudflare 的网络安全服务。在本次事故中整个互联网约有 30% 网站宕机。
下图分别是 Cloudflare 报错页面、各大网站报错页面与 Cloudflare 在本次事故后的日志报告。
故障时间线
2025 年 11 月 18 日 11:20 UTC，Cloudflare 全球网络开始出现严重异常，核心流量在全球范围内大面积中断。用户在访问任何依赖 Cloudflare 的网站时，都只能看到错误页，提示 Cloudflare 网络发生故障。此次事件并非来源于攻击、DDoS 或恶意流量，而是一次看似普通的数据库权限变更，引发了连锁反应，最终导致了核心代理软件崩溃。
根本原因分析
问题起源
问题最初发生在 Cloudflare 机器人管理系统（Bot Management）使用的"特征文件"。
这个特征文件由底层 ClickHouse 数据库集群每隔五分钟生成，用于更新机器学习模型的输入特征，使系统可以及时识别新的攻击模式。由于一次数据库用户权限的显式化调整，ClickHouse 的元数据查询开始返回比以往更多的列，导致负责生成特征文件的查询出现重复数据。原本几十条特征被意外扩展到超过两倍，特征文件的体积也因此直接翻倍。
连锁反应
特征文件随后被推送到 Cloudflare 全球所有边缘节点。负责处理流量的核心代理（Frontline/FL 与 FL2）在读取文件时触发了内部大小限制。这些模块会预分配特征所需的内存，并强制限制最大特征数量，但这次的文件突破了该限制，导致核心代理线程直接崩溃。
请求的入口在代理层就无法继续处理，因此对外表现为大范围的 5xx 状态码。更复杂的是，ClickHouse 集群正在逐步升级，每个分片可能处于不同状态，因此每五分钟集群可能会产生一次正确文件、一次错误文件，边缘节点会在正确状态和错误状态之间反复切换。这种波动一度让团队误以为存在超大规模攻击。直到所有节点都统一生成错误文件后，系统才完全进入持续故障状态。
深层技术问题
问题的根源来自 ClickHouse 查询行为的变化。Cloudflare 使用分布式表（Distributed 引擎）从各个分片的基础表（例如 r0 数据库）中聚合数据。过去在查询 system.columns 等系统表时，用户只能看到 default 数据库的元数据。更新之后，用户对 r0 中基础表的访问权限被显式开放，使得系统表查询开始返回两套相同的列。生成特征文件的查询并没有按数据库名过滤，因此原先的列集合被直接复制了一份。对于像 ClickHouse 这种高性能列式数据库而言，system.* 查询通常被频繁用于动态生成配置，而 Cloudflare 的机器人管理模块也正依赖这些查询构建模型特征。因此元数据的成倍增加直接引发了最终的特征文件膨胀。
特征文件被加载至边缘节点后，预分配的特征内存上限（约 200 个特征）被突破，代理模块中的 Rust 代码在 unwrap() 错误处理路径上崩溃，线程 panic，从而引发了全球范围内的 5xx 错误。虽然旧代理 FL 并未直接报错，但得到了错误的特征文件，导致所有流量的机器人评分被设为零，使基于机器人控制的客户出现大量误报。新代理 FL2 则直接进入崩溃状态，显示明显的错误页面。
Cloudflare 的状态页原本托管在外部，但在此期间恰好也无法访问，使内部团队短暂怀疑存在协同攻击。随着调查深入，团队最终确认问题来自特征文件扩张。14:30 UTC，Cloudflare 手动停止了错误文件的生成，将旧的正确文件重新写入分发队列，并强制重启全球核心代理。随后数小时内，所有系统逐步恢复，CPU 大量消耗于调试与错误跟踪，导致延迟增加，但最终在 17:06 UTC 全面恢复。
此次故障也间接影响了 Workers KV、Access、Turnstile 以及依赖 KV 的控制面板登录功能。部分系统通过绕过核心代理的热补丁在 13:04 降低了影响，但仍出现登录拥堵、重试堆积等连带效果。
事后，Cloudflare 明确指出：这是一场由数据库权限变更 + ClickHouse 元数据行为变化 + 缺乏特征文件防御隔离共同造成的系统性事故。ClickHouse 虽然是以高性能著称的分析数据库，但其 system.* 元数据查询在分布式环境中会直接反映权限模型的变化，而 Cloudflare 的生成逻辑错误地依赖了"查询结果规模稳定"这一假设。用户权限显式化后，分布式元数据暴露了基础表架构，导致特征数量翻倍，从而触发上层模块的内存控制保护机制。
从工程视角看，这次事件非常典型：下层数据库行为变化通常不会直接导致业务宕机，但当系统依赖元数据结构构建核心配置文件时，风险会被放大。ClickHouse 的分布式查询和系统表行为必须结合权限模型理解，否则集群分片在升级过程中的非一致性会让系统呈现间歇性错误。而上层模块如果没有将"内部生成的配置文件"与"用户输入"作同等严格的隔离，就会在异常情况下放大影响面。
Cloudflare 最终承诺未来会强化配置文件摄取安全性、为特征启用全局熔断机制、限制错误报告的资源占用、并全面审查核心代理的错误模式。Cloudflare 认为这是自 2019 年以来最严重的一次事故，也提醒所有依赖高性能分布式数据库的工程团队：任何依赖元数据、自动生成配置、频繁同步到全网的链路，都必须对"规模意外膨胀"进行防御性设计，哪怕原因只是一次看似普通的权限变更。
ClickHouse 的崛起
作为全球最大的 CDN 分发商，出现这样低级的数据库权限变更失误属实让人大跌眼镜。难道在公司内部没有代码的流程管理？没有严格的更改权限申请？事已至此，Cloudflare 的 CEO 在官方博客中对此次事故的复盘也没有谈及更深层的缘由。
但跳出这次事故，我反而对这次事故背后的数据库公司 ClickHouse 很感兴趣。在网上一番查询后，我发现在 Cloudflare 的整体数据架构中，对于实时性、规模化和分布式可靠性这些核心诉求，ClickHouse 扮演着一个越来越重要的分析引擎角色。
ClickHouse 的特点
ClickHouse 并不是传统意义上的"通用数据库"，而是围绕着列式存储、向量化执行与面向 CPU cache 的极致优化而构建。这意味着它能够将海量日志、事件与指标类数据，在毫秒级粒度上完成扫描、过滤与聚合，而无需复制多份索引，也不依赖复杂的二级结构。
为什么选择 ClickHouse
ClickHouse 之所以适合 Cloudflare 的场景，是因为它生来就是为日志与指标数据设计的。
Cloudflare 的边缘网络每天产生惊人规模的原始请求信息、WAF 决策、CDN 缓存命中情况以及反向代理层的行为模式，传统行式数据库在这种吞吐下几乎不能工作。而 ClickHouse 通过列式布局让相同字段的数据在物理上紧密排列，从而形成了极高的压缩率与极高的扫描效率。结合 ClickHouse 的分区策略，它可以将日志按时间窗口自然切分，既便于 TTL 自动清理，也可以减少查询范围，进一步降低 IO 和 CPU 负载。
向量化执行与实时性
在执行层面，ClickHouse 的向量化流水线让查询能够在 CPU 的 L1 和 L2 cache 中完成大部分运算，这也是为什么它在 TB 到 PB 级别的日志分析中仍能保持亚秒级延迟。
Cloudflare 用它处理例如"过去 10 分钟来自某区域的 Edge 请求速率异常上升"这种需要即时判断的场景时，可以做到几乎实时的扫描，避免延迟带来的隐患。
分布式能力
分布式能力也是 ClickHouse 在 Cloudflare 体系里被重度依赖的重要原因。Cloudflare 的网络是全球性、高并发、实时性的，每个数据中心都产生海量数据，不可能将所有数据集中到某个中心处理。因此 ClickHouse 的分布式表和复制表机制，允许它在横向扩展的同时保持高可用，并在集群内部容忍节点失效。Replica 机制配合 quorum 特性，使得日志数据即使部分节点不可用，仍然可以保证写入成功并维持数据一致性。
在 Cloudflare 生态中的位置
与 Cloudflare 现有的 KV、Durable Objects、R2、D1/D2 存储体系相比，ClickHouse 更偏向"强分析型组件"，不是直接提供给用户，也不是作为事务数据库存在，而是作为整个平台的内部可观测性基础设施。
它适合承接的任务包括：
- 实时流量分析
- 长期趋势观察
- WAF 规则命中统计
- 安全事件关联
- 多维度 Aggregation 查询
- 大规模分组分析
这类任务不适合用 KV 或 D1，因为 KV 是毫秒级读写的小对象系统，D1 是针对 SQL 事务负载优化的，均不擅长高吞吐日志分析；而 ClickHouse 的列式引擎正好弥补了这部分能力缺口。
与 Cloudflare 生态的契合
ClickHouse 强调顺序写入与批量压缩，因此能与 Cloudflare 自身的日志流系统（如流式 workers、Logpush、Kafka-like queue）实现天然的对接。边缘数据以批量流式方式进入 ClickHouse，通过 MergeTree 系列引擎进行后台合并，使存储在长期保持紧凑的同时读取性能越来越好。
这种"写入成本前置，读取极快"的思路和 Cloudflare 的服务理念非常契合：将难题留给基础设施，把最终的实时体验留给用户。
未来的 AI 协同
更长远来看，ClickHouse 与 Cloudflare 的 AI 推理平台也存在协同潜力。由于它擅长生成高维度统计、长时序聚合与异常轮廓，这种结构化的分析结果可以直接作为 AI 模型的输入，帮助自动调整安全策略、识别流量模式、生成行为偏差审计、训练检测模型。未来如果 Cloudflare 想进一步构建行为级安全系统，那么 ClickHouse 基于列式数据的高维特征提取能力，会成为推动 AI 引擎的关键之一。
ClickHouse 的位置
ClickHouse 在 Cloudflare 的架构里是一种面向高并发、高吞吐、全球分布式环境而设计的日志/指标分析引擎，它利用列式存储、向量化执行、分区策略与分布式复制机制，使得平台能够在极端流量规模下保持稳定、快速和可靠的洞察能力，为整个边缘网络的实时决策、安全防护和运营分析提供坚实基础。
共同成长
事故背后的转变
Cloudflare 在事故之后开始重新审视自己的可观测性与数据分析体系，而有趣的是，这段改造历程恰好与 ClickHouse 公司的传奇发展轨迹产生了某种微妙的共振。
Cloudflare 过去也尝试过依靠 Kafka、Elasticsearch 等主流组件去处理全球每天数百亿级别的边缘日志；但事故暴露出的核心问题在于，系统的查看能力必须是实时的、可预期的、在极端情况下依然能保持快速响应，而这正是传统系统很难满足的部分。
当时工程团队内部有人提出是否有更极致的分析引擎，能在 PB 级数据量下仍然做到毫秒级聚合，那一刻 ClickHouse 被重新翻了出来。
ClickHouse 的传奇
ClickHouse 本来就是为"极端高并发和海量日志"这种灾难级压力而生的。在 Cloudflare 进行事故复盘时，他们发现 ClickHouse 的架构理念正好和自身需求不谋而合。
边缘网络的行为数据需要被快速摄入、实时压缩、立即可查询，不允许有长时间索引重建，也不能依赖过度复杂的分片逻辑。ClickHouse 的列式存储、压缩分区、向量化执行，恰好构成了一个在事故场景下依然能保持稳定的基础层。
双向赋能
而在这个时期内，ClickHouse 公司也正处于从 Yandex 独立、全球化扩张的关键阶段。对于这家刚脱离大型集团、正在自建商业体系的年轻公司来说，Cloudflare 这样的超级规模客户不仅是技术验证，也是文化认同。
ClickHouse 一直强调"在真实世界的极端场景中验证性能"，而 Cloudflare 的事故和随后的系统重建，给了它一个绝佳的舞台。如果 ClickHouse 能撑住全球数千个 PoP、数万台机器产生的实时事件流，那几乎等于在整个行业面前完成一次史诗级压力测试。
相互成就
Cloudflare 的采用也反过来影响了 ClickHouse 的产品路线。为了支撑 Cloudflare 那种"全球分布式写入 + 毫秒级聚合"模式，ClickHouse 团队开始强化分布式复制一致性、改进 MergeTree 合并策略、优化 ingestion pipeline 的延迟。一些今天广为人知的高性能特性就在这种巨大生产压力下被催生出来。
换句话说，Cloudflare 的事故不仅推动了自身架构的现代化，也加速了 ClickHouse 这家公司的技术进化，使它从一个"极客级数据库"真正进入了"互联网基础设施核心组件"的位置。
尾声：共同成长的故事
Cloudflare 与 ClickHouse 形成了一种几乎是"共同成长"的关系。一边是经历全球级事故后转向极致可观测性系统的边缘网络巨头；另一边是从 Yandex 走出、凭极端工程文化迅速崛起的新型数据库公司。两者在事故后相遇，并共同塑造了一个能够承受超级规模流量的实时分析体系。
Cloudflare 在事故中学到的韧性，与 ClickHouse 在技术上体现出的偏执和勇气，意外地成为了同一段技术叙事的两面，彼此补足，也共同构成了业界今天看到的那套快到不可思议的全球日志分析能力。
最后的思考
在经历事故、重构体系、重新认识可观测性之后，Cloudflare 与 ClickHouse 的故事最终汇聚成一个朴素却重要的结论：真正支撑互联网的，并不是完美无缺的系统，而是那些在崩溃之后仍愿意深入底层、重写关键路径、把复杂世界重新建立起来的工程师们。
技术从来不是点缀，而是基础设施公司的生命线；而能够承受全球级冲击的系统，也往往是在无数次失败和复盘中一点点打磨出来的。
当我们回头看到今天全球性的宕机事故，便是现代互联网在极端不确定性下的一次集体成长：我们如何收集、传输、处理数据？互联网永远在变化，只要底层基础设施仍在被认真、坚定地重写，它就能继续向前运行，这些看不见的工程努力，正是整个网络世界得以维系的理由。