Cloudflare宕機，互聯網世界怎么又斷網了？

對于全球數以百萬計的網站運營者與網民來說，本周的周二，注定又是一個難忘的一天。

如我們所見（在新聞上所見），在這一天的短短數小時內，包括X（原Twitter）、ChatGPT、Spotify等（海外）常用巨頭服務在內，海外互聯網領域幾乎陷入癱瘓。無論刷新多少次，映入眼前的都是同樣的“InternalServerError”報錯頁面。但后來總結來看，這并不是一次外部攻擊導致的人為事故，而是一場由Cloudflare內部引發的全球性技術故障。

事情的起因源于一次再常規不過的例行升級。正常情況下，每天，Cloudflare都會為其Bot管理模塊生成一個“特征文件”，用來幫助識別惡意機器人。這本是一項普通的后臺流程，但當天文件的生成程序因為數據庫權限調整出現異常，意外重復寫入部分內容，文件體積因此比平時大了整整一倍。這看上去可能只是一個細小的問題，但對于系統層面來說，卻足以成為徹底擊穿代理層的導火索。

眼熟么？

按照Cloudflare的說法，Cloudflare的網絡結構決定了這種配置文件需要在全球所有邊緣節點同步。也就是說，一旦生成，它會被迅速推送至遍布世界的數千臺服務器。而當這些節點接收到異常文件后，負責處理全部HTTP請求的核心程序沒能成功解析，直接崩潰。由于文件同步速度極快，多個國家、多個地區的節點幾乎在相近時刻出現同樣的故障，也就形成了用戶看到的“全球同步掉線”的奇怪場景。

更讓情況復雜的，是系統還會每隔幾分鐘自動檢查更新。這意味著，舊的正確文件偶爾會讓部分節點短暫恢復，但很快又會被新的錯誤文件覆蓋，再次宕機。自然而然的，外界當時看到的也就是網站“恢復—再報錯—再恢復”的循環。

這一劇本直到工程師們最終追蹤到特征文件本身，并暫停了錯誤文件的更新，情況才逐漸穩定下來。當天稍晚時間，Cloudflare開始向全球節點重新推送正常版本，各地的代理服務陸續恢復，錯誤量在短時間內迅速下降。不久后，Cloudflare宣布所有系統回到正常狀態，但這次宕機的影響已經被記錄為近期互聯網基礎設施事故中“規模最為罕見的之一”。

Cloudflare：“Cloudflare網絡處理的5xx錯誤HTTP狀態代碼的數量。通常情況下，這個數值應該非常低，而且在故障發生前也確實如此。”

作為全球互聯網基礎設施的重要組成部分，Cloudflare此次大規模宕機迅速引發了各界的關注和反響。而事發當日，Cloudflare盤前股價也一度下跌超過2%。Cloudflare首席技術官Dane Knecht隨后在X上公開致歉，承認網絡在當天出現嚴重問題，“辜負了依賴我們的客戶和整個互聯網···”但回到事故本身，不難發現，它之所以引發如此強烈的討論，很大程度上是因為于此揭示出的是一個越來越需要回應的問題。

你猜這張圖我們還能再看到幾遍？

當下，越來越多的平臺將性能優化、安全防護、訪問控制等關鍵能力托付給行業巨頭——以Cloudflare本身為例，其承載著全球大約五分之一的互聯網流量。在這樣的結構下，一旦核心代理層出現故障，它所依賴的多個產品鏈路會同時失效，而這里承載的成千上萬家服務也會在極短時間內同步感受到沖擊。

而這也正像我們在上個月前剛看到的那樣。彼時，互聯網的另一大基礎構成——AWS也經歷了一次的中斷。根據監測平臺數據，當時共有超過兩千家服務受到影響，累計超過八百萬條用戶報錯被記錄。此次Cloudflare的事故，則再次讓““互聯網的命運，過度依附于少數幾家巨頭”這個問題放置在了人們的面前。當然，在這個面前的是這樣的一組數據，就云計算領域而言，全球前三家巨頭（AWS、微軟Azure和谷歌云）掌控了超過其中近七成的基礎設施。

Cloudflare：我知道誰在點我名

當然，也正是基于這一點，不難預料，無論是AWS還是Cloudflare，在此之后，我們顯然還會再度經歷同樣的經歷。但，當這些這些故障越來越多的發生時，這些問題也注定會隨之變得越來越無法回避。

本文為動點科技記者原創文章，未經授權不得轉載，如需轉載或開白請在后臺回復“轉載”。

- - - - - - - - END - - - - - - - -

互動話題

你能接受“互聯網短暫消失”幾個小時嗎？

快來評論區留下你的觀點吧！
*想要獲取行業資訊、和志同道合的科技愛好者們分享心得，那就趕快掃碼添加“動點君”加入群聊吧！群里更有不定期福利發放！

精彩好文值得推薦！

一鍵轉發，戳個在看！