電腦產業近期重大事件：Google Cloud 崩潰引發連鎖反應
在歷史上，近期的重大錯誤幾乎都是由許多小錯誤累積而成。少犯一個錯誤，結果可能就會不同。2025 年 6 月 12 日，Google Cloud 因一個程式碼漏洞而崩潰，導致全球網際網路服務大規模連鎖崩潰，這是電腦產業近期的重大錯誤之一。
問題源頭：Google Cloud 的服務控制系統
問題的根源在於 Google Cloud 中一個名為「服務控制」的系統。每個 API 專案開發者都知道，接收外部請求時通常先進行過濾，像是身分驗證、黑名單、白名單、限制數量和流量等常見檢查，一般由統一管理系統負責，而服務控制就是 Google 的內部 API 管理系統。
2025 年 5 月 29 日，開發團隊升級了服務控制的線性策略功能。雖然 Google 未公布具體升級內容，但重要的是新程式碼忘了做一個非常基本的事情——錯誤處理。如果有人在服務控制系統中寫入一個包含空值的新策略，就會引發指標異常，導致整個服務控制系統崩潰，這是開發階段出現的第一個小錯誤。
測試階段的疏忽
許多人在工作中遇到過某些功能易寫難測的情況，因為這些功能可能對系統有巨大影響。在開發者的本地環境中容易實現，但在多人使用的狀態環境中，測試自己的功能並影響其他日常工作測試就相當麻煩。因此，有些人為了節省時間和風險，會跳過狀態環境測試，只在本地運行幾個單元測試。
根據研究報告，Google Cloud 共有 76 個 API 產品需要通過服務控制系統。如果在預發環境中測試新功能，可能會影響其他 76 個開發團隊的日常工作。無論是提前與 76 個團隊協商，還是長時間等待後被 76 個團隊責備，都令人深思。最終，服務控制團隊選擇冒險直接通過預發測試，未被發現的空指標異常偷偷進入了生產環境，這是測試階段出現的第二個小錯誤。
部署階段的失誤
2025 年 6 月 12 日上午 10 點 45 分，在日常工作中，Google Cloud 某個分支的服務控制策略資料庫中寫入了一個新策略，其中包含一個空值。雖然 Google 未公布具體是哪個分支和策略，但重要的是這個新策略不僅僅影響了這一個分支。
參與過系統發布、部署和運營的人應該熟悉灰度發布的概念。對於大型、多分段的系統，發布新功能和更新時，最常見的方法有逐漸增加比例的金絲雀發布、更安全穩定的藍綠部署、基於地理分段的基於地理位置的部署，以及基於用戶分段的基於分段的部署。然而，服務控制系統採用的並非上述任何一種發布模式。
因為其產品經理認為，為用戶提供最實時同步的服務比確保系統安全更重要，所以他們使用分布式資料庫推出策略。當那個空策略被寫入其中一個分布式資料庫時，全球 42 個分支同時同步了相同的策略，導致所有分支同時出現空指標異常，這是部署階段出現的第三個小錯誤。
運營階段的問題
相比開發團隊，Google 的運營團隊專業得多。他們在 10 分鐘內找到了問題源頭，花了十幾分鐘寫出補丁，又花了十幾分鐘將補丁發布到所有分支，整個過程不到 40 分鐘。但故事並未就此結束。
很久以前，軟體運行出錯時，我們會讓它自行運行直到問題解決。但在 20 世紀 70 年代，科學家發現這樣容易導致死循環，於是發明了指數退避運行機制，並在 20 世紀 80 年代首次應用於乙太網路協議。這種機制既能快速運行，又能防止死循環導致任務中毒和資源消耗爆炸，是一種完美平衡效率和安全性的機制。
此後，分布式計算、雲服務等行業也借鑒了這種機制。由於這些行業有許多服務同時運行，一旦出現錯誤也會同時發生。即使有指數退避，大家仍會同時工作，導致資源擁擠。因此，為每次退避增加隨機性的隨機化指數退避成為了行業主流做法。
依賴 76 個產品的服務控制系統理應考慮到這個問題，但從調查報告可知，它既沒有隨機化也沒有指數化。因此，像美國中部一號這樣較大的分支，在服務控制系統恢復運行後，由於大量堆棧任務同時進行，系統再次崩潰，整個分支再次癱瘓，這是運營階段出現的第四個也是最後一個錯誤。
由於團隊被迫手動限制任務並將部分任務拖到其他區域，花了近三個小時才消化完所有這些大規模的收集任務。最終統計，Google Cloud 在全球 42 個區域的 76 個產品，從太平洋時間 11 點 48 分到 18 點 27 分，共停擺 6 小時 41 分鐘。根據其 99.99% 的 SLA 承諾，相當於未來七年半不能有一秒鐘的錯誤，只能祝他們好運。
連鎖反應：Cloudflare 崩潰
如果只是 Google Cloud 癱瘓，最多讓我們嘲笑 Google 是個小丑。但被牽連而癱瘓的 Cloudflare，讓整個行業開始懷疑自己是否才是小丑。Cloudflare 作為全球最大的網路服務之一，六年前曾發生過全球故障，這在第 15 個影片中有詳細介紹。
當時，他們的錯誤是由於一個政治聲明中的程式碼漏洞。大家都是商人，能理解寫和修補漏洞的尷尬，所以能容忍 Cloudflare 的巨大失敗。但這次 Cloudflare 的連鎖崩潰非常令人難以接受。因為他們的業務可以說是全球網際網路框架的基礎設施部分，人們基於對其獨立性、安全性和穩定性的信任，將生活的根基託付給 Cloudflare。
然而，Cloudflare 背叛了大家的信任。他們有一個產品 Worker's KV，自稱是高性能的 KVS。Cloudflare 的 22 個核心系統和服務都使用這個 KVS 作為主資料庫，用於存儲 API 存儲、各種系統配置文件和用戶 ID 信息等。就是這樣一個核心產品，在 Google Cloud 崩潰後也崩潰了，原因是它不是部署在自己的伺服器上，而是在 Google Cloud 上。
一個依賴平台服務的基礎設施服務已經夠離譜了，Cloudflare 不僅依賴 Google Cloud，而且只依賴 Google Cloud，甚至沒有勇氣部署在其他地方。於是出現了這樣一個奇怪的場景：平台服務 Google Cloud 一片混亂，不僅導致部署在其上的許多網際網路應用混亂，還導致其下的基礎設施服務 Cloudflare 混亂。
Cloudflare 的崩潰導致更多平台服務和網際網路應用崩潰，最終導致半個網際網路崩潰。我之所以稱這一事件為電腦產業近期事件，是因為它與航空產業近期事件類似。看過《空難系列》紀錄片的人都知道，歷史上近期的大多數事故都不是由重大故障引起的，而是許多人在許多小事上犯小錯誤的結果。
行業反思
這些不起眼的小錯誤最終變成了大麻煩。如今的飛行旅行，從登機到降落，每個細節、每個要求，無論看起來多麼荒謬，都是數百條生命換來的教訓。整個航空產業也會認真對待每一次近期事故的調查報告，其中要求的每項修改，全球的航空公司、機場、飛行員和地勤人員都會嚴格執行。
我們可能永遠無法預測下一個問題會在哪裡，但至少可以避免再犯同樣的錯誤，這是航空產業的態度。在這一點上，航空產業是我們應該學習的榜樣。因為在電腦產業，從來沒有對可能出現的問題做出認真嚴謹的回應，這就是為什麼頂尖大公司最重要的系統上會出現這麼多低級錯誤。
在這一事件中，每個問題都可以用教科書入門級的軟體工程錯誤來解釋。就像第 15 和第 35 個影片中提到的事件一樣，這些錯誤更多地顯示了一個團隊、一個組織甚至一個行業的理論缺陷。我認為整個行業仍然停留在上世紀那種小規模的極客心態中，似乎大家都沒有社會責任感，沒有意識到自己的行為會影響全球數千萬人。
我和其他行業的一些朋友聊過，他們總是羨慕我們電腦產業有多自由。作為醫生和建築師，他們每天都要努力工作，一輩子都不能犯錯，犯一個錯誤可能就會失去工作甚至陷入麻煩。我認為電腦產業應該接受這樣的待遇，也許這是讓編程再次偉大的唯一途徑。
{# 
{# 
{# 
{# 
{#