# 一個一毫秒的錯誤令英國空域停擺六小時。

Published: 2026-09-25

9 月 8 日星期二上午 10:00，英國國家航空交通服務公司（NATS）國家空域系統（NAS）內一個例行應答器代碼請求在更新數值時，被一個更高優先級的訊息打斷。暴露視窗約為一毫秒。該請求隨後以錯誤的方式恢復，導致飛行數據損壞，到晚上 7:30，超過 2,000 班英國航班被延誤、取消或轉飛。

Canonical: https://thedailydiff.dev/zh-HK/video/2026-09-25-nats-millisecond/

## 本影片涵蓋的內容

- 10:00：一個請求在 1 毫秒的視窗內被中斷
- 時間線：10:00 應答器 → 10:02 故障 → 12:45 航班停止起飛 → 13:32 連結中斷
- 解決方案：重啟全國的航班數據
- 機制：寫入過程中途暫停
- 為何一個安全功能令天空停擺

## 章節

- 0:00 10:00：一個請求在 1 毫秒的視窗內被中斷
- 0:32 時間線：10:00 應答器 → 10:02 故障 → 12:45 航班停止起飛 → 13:32 連結中斷
- 1:03 解決方案：重啟全國的航班數據
- 1:22 機制：寫入過程中途暫停
- 1:37 為何一個安全功能令天空停擺
- 2:05 git blame — 舊程式碼 50 · 重啟計劃 30 · 10:02 警報 15 · 1 毫秒 5
- 2:24 影響範圍：原定 8,000 班，處理 6,094 班，三年內第三次故障
- 2:41 結論 + 星期一重點：原子寫入，響亮警報

## 翻譯的文字記錄

從英文原文旁白翻譯。可用的音頻和字幕由 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 發送你仍然不被允許談論的事件給我。 今天的差別就到這裡。

3:02 我是 Axrisi 的 Niko。 謹慎合併。

## 來源

- [NATS, Major Incident Preliminary Investigation Report, NAS incident 08 September 2026 (report date Sep 16)](https://www.nats.aero/wp-content/uploads/2026/09/NATS-Preliminary-Investigation-Report-into-NAS-Incident-on-08-Sept-2026-Issued-16-Sept-2026.pdf) — www.nats.aero
- [NATS press release, "NATS publishes preliminary report on technical incident of 8 September" (Sep 18, 2026)](https://www.nats.aero/news/nats-publishes-preliminary-report-on-technical-incident-of-8-september/) — www.nats.aero
- [NATS on X, 8 Sep](https://x.com/NATS/status/2097313182482084317) — x.com
- [BBC, "Flight chaos caused by 'millisecond' software defect, report says"](https://www.bbc.co.uk/news/articles/cw0kl1571lpmo) — www.bbc.co.uk
- [The Guardian (Sep 18, 2026)](https://www.theguardian.com/world/2026/sep/18/flight-chaos-affecting-hundreds-of-thousands-caused-in-millisecond-by-software-error-uk) — www.theguardian.com
- [Hacker News thread on the report](https://news.ycombinator.com/item?id=49754064) — news.ycombinator.com