+− THE DAILY DIFFdev & AI news
NEEDS REVIEW

一毫秒的錯誤讓英國航空交通停擺六小時。

9月8日星期二上午10:00,英國國家航空交通服務(NATS)的國家空域系統(NAS)中,一個例行的詢答機代碼請求在更新數值的過程中被一個優先級更高的訊息中斷。

9月8日星期二上午10:00,英國國家航空交通服務(NATS)的國家空域系統(NAS)中,一個例行的詢答機代碼請求在更新數值的過程中被一個優先級更高的訊息中斷。曝露窗口約為一毫秒。請求錯誤地恢復,飛行數據被破壞,到晚上7:30,超過2,000個英國航班被延誤、取消或轉向。

閱讀書面版(英文) ↗

本影片重點

  • 10:00:一個請求在1毫秒的窗口內被中斷
  • 時間線:10:00 詢答機代碼 → 10:02 閃爍 → 12:45 航班出發停止 → 13:32 連結遺失
  • 解決方案:重新啟動全國的飛行數據
  • 機制:寫入過程中途暫停
  • 為何一個安全功能讓天空停擺

翻譯文字稿

譯自英文原版旁白。可用的音訊和字幕由 YouTube 控制。

10:00:一個請求在1毫秒的窗口內被中斷

0:00 上午十點,英國飛行數據系統中的一個例行請求 在錯誤的毫秒被中斷,到晚上超過兩 千個航班被延誤、取消或轉向。 這是英國航空交通服務Nats的初步報告。 沒有攻擊跡象,也沒有人按錯按鈕。 只是一個遺留缺陷,和一個非常特定的毫秒。 它是如何發生的,為什麼一毫秒就足夠了,以及誰實際上該 受責備。這裡是 The Daily Diff,事後分析。

0:31 十點。有人手動請求一個詢答機代碼,這是將

時間線:10:00 詢答機代碼 → 10:02 閃爍 → 12:45 航班出發停止 → 13:32 連結遺失

0:36 雷達閃爍與其飛行計畫聯繫起來的四位數號碼。 請求有效,計畫也有效。 十點零二分。 倫敦區域管制與核心系統之間的連結斷開, 然後在四十五秒後自行恢復。 票務顯示已恢復、穩定、無運營影響。 十二點三十二分。連結再次開始斷開, 每次都更快,並且管制員失去了一些自動化功能。

0:56 到十二點四十五分,英國出發的航班停飛。 一點三十二分,連結斷開並保持斷開狀態。 解決方案是受控重啟,這就是昂貴的部分,

解決方案:重新啟動全國的飛行數據

1:06 因為同一個系統為全國各地的控制中心和機場提供服務。 這個錯誤發生在倫敦的空域。 限制涵蓋整個英國。 重啟從三點十五分運行到四點十分, 而理清重複的飛行計畫則需要到六點五十分。 那麼為什麼一毫秒就足夠了?

機制:寫入過程中途暫停

1:23 系統按優先順序處理任務,暫停一個小任務去處理緊急任務 是正常的。但這個任務正在更新一個數值。 緊急訊息落在那個毫秒內,更新中途停止。 當它恢復時,它沒有正確恢復。 然後錯誤數據洩漏到後來的某些航班更新中。

為何一個安全功能讓天空停擺

1:40 倫敦嘗試讀取一個,花費太長時間並超時。 超時會斷開連結,這是設計好的,以保護兩個系統。 安全功能完美運行。 這就是問題所在。 報告自己的話。 如果緊急訊息早一毫秒或晚一毫秒到達, 更新將正常完成。 在 Hacker News 上,一位程式設計師稱一毫秒是絕對的永恆,

2:02 保證會在本週二發生。 那天是星期二。

git blame — 遺留代碼 50 · 重啟計畫 30 · 10:02 警報 15 · 1 毫秒 5

2:05 git blame。遺留代碼,百分之五十,因為一個可以中途暫停 並錯誤恢復的更新。 重啟計畫,百分之三十,因為倫敦的一個錯誤記錄意味著要重啟 全國的飛行數據。 十點零二分的警報,百分之十五,因為它自行恢復並被歸檔為無 影響。百分之五給毫秒,因為它的時間。 影響範圍。Nats 計畫當天處理約八千個航班,實際處理了

影響範圍:計畫 8,000 班,處理 6,094 班,三年內第三次故障

2:27 約六千個。 英國出發的航班停飛了約四個半小時, 積壓的航班需要兩天多才能清理完畢。 這是英國三年內第三次航空交通故障, 首席執行官稱這個錯誤非常、非常隱蔽。

結論 + 星期一警示:原子寫入,響亮警報

2:41 結論,事後分析:NEEDS REVIEW。 報告快速而具體,修復程式已撰寫並正在測試中。 但計畫是更快的重啟,而不是更小的重啟。 星期一警示:如果一個任務可以暫停,請使其寫入具有原子性, 並將自行恢復的警報視為警報。 在評論中或在 thedailydiff.dev 上向我發送您仍然不允許談論的事件。 在評論中,或在 thedailydiff.dev。 這就是今天的 The Daily Diff。

3:02 我是 Axrisi 的 Niko。 SHIP IT。

來源

  1. NATS, Major Incident Preliminary Investigation Report, NAS incident 08 September 2026 (report date Sep 16)www.nats.aero
  2. NATS press release, "NATS publishes preliminary report on technical incident of 8 September" (Sep 18, 2026)www.nats.aero
  3. NATS on X, 8 Sepx.com
  4. BBC, "Flight chaos caused by 'millisecond' software defect, report says"www.bbc.co.uk
  5. The Guardian (Sep 18, 2026)www.theguardian.com
  6. Hacker News thread on the reportnews.ycombinator.com

相關影片

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月12日

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

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

3:00 ↗