互联网的脆弱时刻
北京时间的今天晚上，Cloudflare 突然遭遇了大规模宕机。如果不出现意外，这次事故的波及范围之广、持续时间之长，大概率会被写进互联网运维的教科书里，成为「载入史册」的负面案例。
原本今晚的计划是如常更新日更博客，但当我习惯性地打开编辑器页面时，迎接我的并不是熟悉的界面，而是一串冰冷的报错代码。排查了一圈，本地网络一切正常，托管博客的 Bearblog 平台也没有发布故障公告，唯独套在最外层的 Cloudflare 彻底罢工了。
看着浏览器上那个标志性的连接错误图标，我脑海里立刻浮现出之前写过的那篇《互联网服务终究不可托付》。其实把时间轴拉长来看，这种无力感并不新鲜。我们不得不承认一个事实：在这个星球上，没有任何一个服务商是绝对可靠的。无论它的市值是几千亿还是几万亿，无论它标榜的服务等级协议后面有多少个 9，物理世界的熵增定律和系统架构的复杂性终究会教做人。
说到这里，我们不妨看看这两年里，那些被我们视为「互联网基础设施」的巨头们都发生了什么：
- 阿里云：2023 年 11 月 12 日，这应该是中国互联网史上很难被遗忘的一天。由于底层鉴权组件的逻辑缺陷，导致阿里云全线产品在全球范围内出现大规模不可用。整整几个小时，无数依赖其服务的企业业务停摆，运维人员除了干瞪眼什么都做不了。
- AWS：2023 年 6 月 13 日，这一天美东地区（US-East-1）遭遇了严重故障。Lambda、Delta Lake 等核心服务瘫痪，直接导致美国的达美航空、汉堡王等实体企业的数字化业务中断，甚至连亚马逊自家的电商页面都受到了波及。
- GitHub：2024 年 8 月 15 日，就在几个月前，GitHub 因为数据库基础设施变更导致了严重的性能降级和中断。对于全球开发者而言，那是「无法提交代码、无法部署上线」的黑色数小时。
- Cloudflare：在今晚之前，2023 年 11 月 2 日的那次事故也同样严重。当时因为俄勒冈州的数据中心断电引发了一系列连锁反应，导致其控制平面和分析服务即使在电力恢复后也长时间无法上线，全球大量开发者无法登录后台进行配置。
很多时候，我们产生「互联网很稳定」的错觉，是因为我们把鸡蛋放在了不同的篮子里。但像 Cloudflare 这样的 CDN 和安全服务商，本质上已经成为了互联网的「单一故障点」。当它发生故障时，不再是某一个网站打不开，而是你日常访问的半个互联网可能瞬间消失。
这引发了一个更深层的思考：我们为了便利，出让了太多的控制权。
在 Web 1.0 时代，我们哪怕在物理机上跑一个 httpd 服务，只要电缆没断，服务大概率就在。而现在，一个简单的博客请求，可能要经过 DNS 解析、边缘节点缓存、WAF 过滤、源站处理、数据库查询。每一个环节都是一个黑盒，每一个黑盒都掌握在不同的巨头手中。我们以为自己拥有数据，但实际上我们只是拥有了「在服务商不出错时访问数据」的权利。
这次宕机也是一个提醒。像我这种仅仅部署了寥寥几个服务的边缘用户，都要被迫停摆，那些真正跑在云端的商业业务，以及那些承载了庞大流量的企业，此刻面临的恐怕是更加焦头烂额的局面。我们引入 CDN 和各种云服务本是为了更快、更安全，但当这层原本用来抵御风浪的保护壳自己先塌了的时候，事情就变得有些荒诞。