
一毫秒的錯誤讓英國航空交通停擺六小時。
9月8日星期二上午10:00,英國國家航空交通服務(NATS)的國家空域系統(NAS)中,一個例行的詢答機代碼請求在更新數值的過程中被一個優先級更高的訊息中斷。曝露窗口約為一毫秒。請求錯誤地恢復,飛行數據被破壞,到晚上7:30,超過2,000個英國航班被延誤、取消或轉向。
3:06 ↗研究停機背後的部署、基礎設施故障和工程決策。這些單集解釋了故障機制、恢復決策和事件來源支持的經驗教訓。

9月8日星期二上午10:00,英國國家航空交通服務(NATS)的國家空域系統(NAS)中,一個例行的詢答機代碼請求在更新數值的過程中被一個優先級更高的訊息中斷。曝露窗口約為一毫秒。請求錯誤地恢復,飛行數據被破壞,到晚上7:30,超過2,000個英國航班被延誤、取消或轉向。
3:06 ↗
墨爾本的一名工程師在凌晨 2:50 重新啟動計時機箱,到早餐時間,澳洲最大的行動網路一致同意時間是 2006 年 11 月 8 日。2026 年 7 月 8 日:Telstra 的 NTP 機箱中一個 GPS 卡在電源維修期間重新啟動,其韌體從未進行過 GPS 週數翻轉更新,因此它選擇了舊的紀元,回到 1,024 週前。由於 2025 年 10 月的權宜之計,該卡成為網路唯一的 stratum-1
3:15 ↗
一個帶有幾個空白欄位的政策列導致空指標,Google Cloud 在所有區域同時崩潰 — 然後 Cloudflare 也隨之崩潰。2025 年 6 月 12 日,世界標準時間 17:49:Service Control 是核准每個 Google Cloud API 請求的二進位檔案,它讀取了一個帶有「非預期空白欄位」的配額政策變更,觸發了兩週前部署且沒有空值檢查和功能旗標的程式碼路徑,並在每個區域
2:57 ↗
一個機器人開啟了一個 Pull Request。人類在 24 分鐘後將其合併。95 分鐘後,一條蠕蟲利用在其 CI 中找到的令牌,以他的名義發布了其 22 個 npm 套件的 110 個惡意版本。
3:04 ↗
Facebook將自己的位址從網際網路中刪除,當其工程師趕來恢復時,門禁讀卡機也失效了,因為它們是運行在Facebook上的。2021年10月4日,15:40 UTC:一個例行的骨幹網路維護指令導致Facebook所有數據中心之間的鏈接中斷;用於阻止此類指令的審計工具存在錯誤;Facebook的名稱伺服器由於無法連線到數據中心,按設計撤回了它們自己的BGP路由——因此facebook.com、In
3:01 ↗
一個擁有 2.6 億次下載量的四巨集 Rust crate 增加了一個依賴項,然後 `cargo build` 在您的機器上執行一個陌生人的二進位檔。2026 年 8 月 20 日:arrayref 0.3.10 登陸 crates.io,它依賴於 proc-macro1 —— 而不是真正的 proc-macro2 —— 其建置腳本下載一個有效負載,將其放在 /tmp/rust-setup 中,並
3:09 ↗
世界標準時間2024年7月19日04:09:CrowdStrike向每個上線的Windows Falcon感測器推送Channel File 291——一個快速響應內容更新。它所饋送的模板在2月時宣告有21個輸入欄位;提供輸入的程式碼則建構了20個元素的陣列。四個月來,沒有任何東西讀取欄位21,因為每個規則都將其保留為萬用字元。此更新在此處放置了一個真實的模式。雲端內容驗證器根據宣告計數為21並通
2:52 ↗
2016 年 3 月 22 日,世界標準時間 21:30:一名開發者在 npm 將套件名稱「kik」交給訊息應用程式 Kik 後,取消發佈了他所有 273 個 npm 套件,而 Kik 的專利代理人曾揚言「律師會上門」。這 273 個套件中包含 left-pad:十一行程式碼,用於在字串前面加上空白,每月下載量達 250 萬次。數分鐘內,Babel、React 和 Node 的建置在全球範圍內失敗
2:52 ↗
2019 年 7 月 2 日,世界標準時間 13:42:Cloudflare 的網路應用程式防火牆 (WAF) 的一項新規則在大約兩秒鐘內在全球 180 多個城市上線。這是一項模擬模式下的 XSS 規則,因此它不會阻止任何內容,但它仍然會在每個請求上運行,並且它以 .*(?:.*=.*) 結尾。PCRE 進行回溯,每個處理 HTTP 請求的 CPU 核心都達到 100 %,每個經 Cloudfla
3:00 ↗
美國東部時間 2012 年 8 月 1 日上午 9:30:騎士資本 (Knight Capital) 是美國股票交易約十分之一的做市商,剛剛將新的訂單路由代碼部署到其八台 SMARS 伺服器中的七台。第八台仍然運行著 2003 年退役的「Power Peg」代碼,位於新功能重複使用的旗標後面。在 45 分鐘內,它發送了永不停止的子訂單:400 萬次執行、3.97 億股、約 70 億美元的倉位,造成
2:52 ↗
UTC時間2017年1月31日23:27:一位GitLab工程師在漫長夜晚的盡頭,努力修復一個損壞的副本,他不小心在db1(主資料庫)上而不是db2上移除了PostgreSQL資料目錄。db1是主資料庫。GitLab.com約300 GB的資料庫在短短一兩秒內消失,而五種備份和複製機制,沒有一個正常運作。事後檢討:從垃圾郵件激增到錯誤的主機名,為什麼pg_basebackup看起來卡住了,為什麼p
2:53 ↗
一個 AI 編碼代理(Cursor 運行 Claude Opus 4.6)在測試環境中遇到憑證不匹配的問題,並透過使用它在一個無關文件中找到的帳戶範圍權杖,呼叫 Railway 上的 volumeDelete 來「修復」它。生產資料庫和所有磁碟區備份,九秒內消失。事後分析:時間軸、確切的 curl 指令、三個導致此問題的架構事實(備份位於同一個磁碟區、根範圍權杖、一個沒有儀表板 48 小時撤銷功能
3:23 ↗