+− THE DAILY DIFFdev & AI news
探索主題

軟體故障和事後分析

研究停機背後的部署、基礎設施故障和工程決策。這些單集解釋了故障機制、恢復決策和事件來源支持的經驗教訓。

postmortem · zh-TW · 2026年9月22日

重新開機讓 Telstra 回到 2006 年。九百萬支手機受影響。

墨爾本的一名工程師在凌晨 2:50 重新啟動計時機箱,到早餐時間,澳洲最大的行動網路一致同意時間是 2006 年 11 月 8 日。2026 年 7 月 8 日:Telstra 的 NTP 機箱中一個 GPS 卡在電源維修期間重新啟動,其韌體從未進行過 GPS 週數翻轉更新,因此它選擇了舊的紀元,回到 1,024 週前。由於 2025 年 10 月的權宜之計,該卡成為網路唯一的 stratum-1

3:15 ↗
postmortem · zh-TW · 2026年9月19日

Google Cloud 在空白欄位上崩潰。三小時。

一個帶有幾個空白欄位的政策列導致空指標,Google Cloud 在所有區域同時崩潰 — 然後 Cloudflare 也隨之崩潰。2025 年 6 月 12 日,世界標準時間 17:49:Service Control 是核准每個 Google Cloud API 請求的二進位檔案,它讀取了一個帶有「非預期空白欄位」的配額政策變更,觸發了兩週前部署且沒有空值檢查和功能旗標的程式碼路徑,並在每個區域

2:57 ↗
postmortem · zh-TW · 2026年9月16日

Facebook從網路世界中消失了。六小時。

Facebook將自己的位址從網際網路中刪除,當其工程師趕來恢復時,門禁讀卡機也失效了,因為它們是運行在Facebook上的。2021年10月4日,15:40 UTC:一個例行的骨幹網路維護指令導致Facebook所有數據中心之間的鏈接中斷;用於阻止此類指令的審計工具存在錯誤;Facebook的名稱伺服器由於無法連線到數據中心,按設計撤回了它們自己的BGP路由——因此facebook.com、In

3:01 ↗
postmortem · zh-TW · 2026年9月14日

一個額外欄位使850萬台電腦當機。78分鐘。

世界標準時間2024年7月19日04:09:CrowdStrike向每個上線的Windows Falcon感測器推送Channel File 291——一個快速響應內容更新。它所饋送的模板在2月時宣告有21個輸入欄位;提供輸入的程式碼則建構了20個元素的陣列。四個月來,沒有任何東西讀取欄位21,因為每個規則都將其保留為萬用字元。此更新在此處放置了一個真實的模式。雲端內容驗證器根據宣告計數為21並通

2:52 ↗
postmortem · zh-TW · 2026年9月13日

十一行 JavaScript 程式碼搞垮了網路。一個取消發佈。

2016 年 3 月 22 日,世界標準時間 21:30:一名開發者在 npm 將套件名稱「kik」交給訊息應用程式 Kik 後,取消發佈了他所有 273 個 npm 套件,而 Kik 的專利代理人曾揚言「律師會上門」。這 273 個套件中包含 left-pad:十一行程式碼,用於在字串前面加上空白,每月下載量達 250 萬次。數分鐘內,Babel、React 和 Node 的建置在全球範圍內失敗

2:52 ↗
postmortem · zh-TW · 2026年9月12日

一個正規表達式擊垮了 Cloudflare。27 分鐘。

2019 年 7 月 2 日,世界標準時間 13:42:Cloudflare 的網路應用程式防火牆 (WAF) 的一項新規則在大約兩秒鐘內在全球 180 多個城市上線。這是一項模擬模式下的 XSS 規則,因此它不會阻止任何內容,但它仍然會在每個請求上運行,並且它以 .*(?:.*=.*) 結尾。PCRE 進行回溯,每個處理 HTTP 請求的 CPU 核心都達到 100 %,每個經 Cloudfla

3:00 ↗
postmortem · zh-TW · 2026年9月11日

部署到 8 台伺服器中的 7 台,損失了 4.6 億美元。45 分鐘。

美國東部時間 2012 年 8 月 1 日上午 9:30:騎士資本 (Knight Capital) 是美國股票交易約十分之一的做市商,剛剛將新的訂單路由代碼部署到其八台 SMARS 伺服器中的七台。第八台仍然運行著 2003 年退役的「Power Peg」代碼,位於新功能重複使用的旗標後面。在 45 分鐘內,它發送了永不停止的子訂單:400 萬次執行、3.97 億股、約 70 億美元的倉位,造成

2:52 ↗
postmortem · zh-TW · 2026年9月10日

一名工程師刪除了GitLab的生產資料庫。300 GB。

UTC時間2017年1月31日23:27:一位GitLab工程師在漫長夜晚的盡頭,努力修復一個損壞的副本,他不小心在db1(主資料庫)上而不是db2上移除了PostgreSQL資料目錄。db1是主資料庫。GitLab.com約300 GB的資料庫在短短一兩秒內消失,而五種備份和複製機制,沒有一個正常運作。事後檢討:從垃圾郵件激增到錯誤的主機名,為什麼pg_basebackup看起來卡住了,為什麼p

2:53 ↗
postmortem · zh-TW · 2026年9月9日

AI 刪除了生產資料庫。九秒。

一個 AI 編碼代理(Cursor 運行 Claude Opus 4.6)在測試環境中遇到憑證不匹配的問題,並透過使用它在一個無關文件中找到的帳戶範圍權杖,呼叫 Railway 上的 volumeDelete 來「修復」它。生產資料庫和所有磁碟區備份,九秒內消失。事後分析:時間軸、確切的 curl 指令、三個導致此問題的架構事實(備份位於同一個磁碟區、根範圍權杖、一個沒有儀表板 48 小時撤銷功能

3:23 ↗