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 这次事故是这条线最直白的注脚。不是新技术不够好不是自动化不够强是一个本该被审核的配置被自动化流程放了过去。自动化可以帮你发现问题但不能替你承担责任。回滚按钮可以帮你止损但不能替你判断这个变更该不该上线。这就是运维这个职业存在的理由。不是因为你比机器更会执行命令而是因为当机器出错的时候你是那个必须知道该怎么办的人。一期一会 · 本期核心笔记Cloudflare 全球宕机根因是 BGP 路由配置错误一个被系统标记为“低风险”的变更跳过了人工审核。BGP 的信任机制导致错误路由信息一旦扩散修正成本极高。基础协议越底层出错影响越大。变更管理三条铁律没有真正的低风险变更、审批流程必须有人的硬阻断点、回滚必须比变更更快。这一期我们聊了网络配置和变更管理聊的是“人”在自动化链条里的位置。但还有一个更根本的问题谁来监控那些监控系统本身巧了Linux 基金会最近成立了一个专门的工作组研究 eBPF 的安全边界。我们下一期聊聊这个。这是《AI视界——从资讯看技术》的第十期。十期了感谢你还在。我们继续。如果这篇文章让你有所思考欢迎在评论区聊聊你遇到过因为配置错误导致的事故吗当时是怎么恢复的— Compiled and Authored by Whisky — July 16 th, 2026
Cloudflare全球宕机3小时：一个配置错误，如何让半个互联网瘫痪？
发布时间：2026/7/16 21:23:12
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 这次事故是这条线最直白的注脚。不是新技术不够好不是自动化不够强是一个本该被审核的配置被自动化流程放了过去。自动化可以帮你发现问题但不能替你承担责任。回滚按钮可以帮你止损但不能替你判断这个变更该不该上线。这就是运维这个职业存在的理由。不是因为你比机器更会执行命令而是因为当机器出错的时候你是那个必须知道该怎么办的人。一期一会 · 本期核心笔记Cloudflare 全球宕机根因是 BGP 路由配置错误一个被系统标记为“低风险”的变更跳过了人工审核。BGP 的信任机制导致错误路由信息一旦扩散修正成本极高。基础协议越底层出错影响越大。变更管理三条铁律没有真正的低风险变更、审批流程必须有人的硬阻断点、回滚必须比变更更快。这一期我们聊了网络配置和变更管理聊的是“人”在自动化链条里的位置。但还有一个更根本的问题谁来监控那些监控系统本身巧了Linux 基金会最近成立了一个专门的工作组研究 eBPF 的安全边界。我们下一期聊聊这个。这是《AI视界——从资讯看技术》的第十期。十期了感谢你还在。我们继续。如果这篇文章让你有所思考欢迎在评论区聊聊你遇到过因为配置错误导致的事故吗当时是怎么恢复的— Compiled and Authored by Whisky — July 16 th, 2026
