# 一毫秒的错误导致英国空中交通停摆六小时。

Published: 2026-09-25

9月8日星期二上午10:00，英国国家航空交通服务（NATS）的国家空域系统（NAS）内，一个例行应答码请求在更新某个值的中途被一个优先级更高的消息打断。暴露窗口约为一毫秒。请求错误地恢复，航班数据损坏，到晚上7:30，超过2,000架英国航班被延误、取消或改道。

Canonical: https://thedailydiff.dev/zh-CN/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。 这就是今天的The Daily Diff。

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

## 来源

- [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