Cloudflare全球宕机3小时：一个配置错误，如何让半个互联网瘫痪？

《AI视界——从资讯看技术》专栏 · 第十期

不管你跑的是容器还是 Wasm，底层网络配错了一样全球宕机。这是运维的残酷法则，也是一次值得反复回看的经典案例。

本系列专栏其他文章欢迎访问：AI视界——从资讯看技术

我的主页：AOwhisky，这里有更多运维系统性知识整理和其他有趣内容，欢迎与我一起探讨学习~

一、半个互联网，同时断了

2025年11月18日，无数用户突然发现：网站打不开了。

不是某个小网站。是大量依赖 Cloudflare CDN 和 DNS 服务的企业站点，同时报 502 错误。故障持续了整整三个小时。

Cloudflare 是全球最大的内容分发网络之一，承载着互联网上相当比例的流量。它一宕机，半个互联网跟着抖动。

事故已经过去了大半年，但上个月 Cloudflare 发布了更详细的后续改进报告，让这个案例重新回到了技术讨论的中心。而它揭示的问题，到今天依然普遍存在。

上一期我们聊了 Docker 和 Wasm，聊的是容器技术的新方向。结尾我埋了一句话：不管你跑的是传统容器还是 Wasm 模块，如果底层网络配置出了错，一样都得崩。

Cloudflare 这次事故，就是这句话最典型的注脚。

二、BGP是什么？为什么一个配置错误能炸全球？

先解决基础概念。

BGP，全称 Border Gateway Protocol，边界网关协议。它是互联网的“导航系统”。

你访问一个网站，数据包从你的电脑出发，经过若干个路由器的转发，最终到达目标服务器。BGP 的作用，就是告诉每一台路由器：要去这个IP地址，应该往哪个方向走。

互联网由无数个自治系统组成。每个自治系统都有自己的 IP 地址段和路由策略。BGP 让它们互相宣告：我这儿有一条路，能到达某个网段，你可以把流量发给我。

问题在于，BGP 是一个建立在“信任”之上的协议。

当你向邻居宣告“我能到达某个网段”时，对方默认会相信你。如果你的配置写错了——比如把一条不该宣告的路由广播了出去，或者把别人的流量引到了错误的路径上——整个互联网的路由表都会被污染。

Cloudflare 这次事故就是这样。一条错误的 BGP 宣告被发布后，大量流量被引向了不存在的路径，导致服务大面积中断。而且因为 BGP 的传播机制，错误的路由信息一旦扩散，修正过来需要很长时间。每一台收到错误信息的路由器，都要等到新的正确宣告到达，才能恢复正常。

打个比喻：

• 正常的 BGP 宣告，是在地图上标注“此路通”。
• Cloudflare 的错误配置，相当于在地图上标注“此路不通”——而且还被其他导航系统抄了过去。
• 所有跟着导航走的用户，全堵在了死路上。

三、更扎心的事：错误是怎么逃过审核的？

如果只是配置出错，这事还不值得单独写一期。

真正让运维人后背发凉的，是事故报告中这一段话：

“该变更由于审批流程存在缺陷，跳过了人工审核环节，直接被发布。”

一个能影响全球网络的配置变更，居然没有被人看过就上线了。

Cloudflare 不是小公司。它有完善的运维体系、有自动化变更平台、有审批流程。但恰恰是这套系统出了问题——审批流程的设计有一个盲区，某些类型的配置变更被系统默认为“低风险”，自动放行。而这次的错误配置，恰好落在了这个盲区里。

这才是本期的核心问题：当自动化流程本身成为漏洞时，你怎么防？

四、运维视角：变更管理的三条铁律

Cloudflare 这次事故，把变更管理这个老生常谈的话题重新推到了聚光灯下。变更管理不是什么新鲜词，但每次重大事故，根因排查到最后，十有八九都落在这个区域。

以下三条不是理论，是用真金白银和凌晨三点的告警电话换来的教训。

铁律一：没有“低风险”的变更，只有“低概率”的后果

Cloudflare 这次出事的配置，在分类系统里是“低风险”。但后果是全球宕机三小时。

风险不是由变更类型决定的，是由影响范围决定的。一个修改单行配置的变更，如果影响的是核心网络设备，风险就是最高的。分类系统可以辅助判断，但不能替代判断。

实操建议：对影响网络、存储、认证系统等基础设施的变更，无论改了几行代码，一律走最高级别的审批流程。

铁律二：审批流程必须有“人”的硬阻断点

自动化流水线能让变更更快，但不能让它变成“无人驾驶”。

Cloudflare 的问题在于，系统认为某些变更是安全的，就自动放行了。正确的设计应该是：自动化可以做检查、做测试、做预验证，但最终的“执行”按钮，必须由人来按。

这不是效率低，这是最后一道防线。

铁律三：回滚必须比变更更快

变更出错不可怕，可怕的是回滚不了。

Cloudflare 这次花了三个小时才恢复，因为 BGP 的错误宣告传播出去后，修正需要时间。但如果变更系统本身支持一键回滚，至少在出问题的第一时间就能止损。

实操建议：做任何变更之前，先确认回滚方案能不能在五分钟内完成。如果答案是不能，变更就不该被批准。

五、回归我们一直在聊的那条线

第十期了。

回头看看，我们聊过 AI 写代码、Agent 拿权限、K8s 画蓝图、法规提要求、供应链被投毒、GPT-5 拿钥匙、内核透明化、容器未来态——十期文章，话题五花八门，但有一条线贯穿始终。

技术越自动化，人的判断力越稀缺。

Cloudflare 这次事故，是这条线最直白的注脚。不是新技术不够好，不是自动化不够强，是一个本该被审核的配置，被自动化流程放了过去。

自动化可以帮你发现问题，但不能替你承担责任。回滚按钮可以帮你止损，但不能替你判断这个变更该不该上线。

这就是运维这个职业存在的理由。不是因为你比机器更会执行命令，而是因为当机器出错的时候，你是那个必须知道该怎么办的人。

一期一会 · 本期核心笔记

1. Cloudflare 全球宕机根因是 BGP 路由配置错误，一个被系统标记为“低风险”的变更跳过了人工审核。
2. BGP 的信任机制导致错误路由信息一旦扩散，修正成本极高。基础协议越底层，出错影响越大。
3. 变更管理三条铁律：没有真正的低风险变更、审批流程必须有人的硬阻断点、回滚必须比变更更快。

这一期我们聊了网络配置和变更管理，聊的是“人”在自动化链条里的位置。但还有一个更根本的问题：谁来监控那些监控系统本身？巧了，Linux 基金会最近成立了一个专门的工作组，研究 eBPF 的安全边界。我们下一期聊聊这个。

这是《AI视界——从资讯看技术》的第十期。十期了，感谢你还在。我们继续。

如果这篇文章让你有所思考，欢迎在评论区聊聊：你遇到过因为配置错误导致的事故吗？当时是怎么恢复的？