+− 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。 这就是今天的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-CN · 2026年9月22日

一次重启让Telstra回到了2006年。九百万部手机受到影响。

墨尔本的一名工程师在凌晨2:50重新启动了一个时序机箱,到早餐时间,澳大利亚最大的移动网络竟然认为现在是2006年11月。2026年7月8日:Telstra的NTP机箱中的一张GPS卡在电源维修期间重启,其固件从未进行过GPS周翻转更新,因此它选择了旧的纪元,回到了1024周之前。由于2025年10月的一个权宜之计,这张卡成为了网络中唯一的层级1(stratum-1)时间源——并且2020年切换到

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

Google Cloud 因空白字段而崩溃。历时三小时。

一个包含几个空白字段的策略行触发了一个空指针,导致 Google Cloud 所有区域同时崩溃,随后 Cloudflare 也随之瘫痪。2025 年 6 月 12 日,世界标准时间 17:49:Service Control(批准每个 Google Cloud API 请求的二进制文件)读取了一个配额策略变更,其中包含“意外的空白字段”,触发了两周前发布的代码路径(没有空检查和功能标志),并进入了

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

Facebook 从互联网上删除了自己。六小时。

Facebook 从互联网上移除了自己的地址,当其工程师赶到现场恢复服务时,门禁读卡器也失灵了,因为它们也在 Facebook 上运行。2021 年 10 月 4 日,世界标准时间 15:40:一条例行的骨干网维护命令导致 Facebook 数据中心之间的所有链接中断;用于阻止该命令的审计工具存在一个错误;Facebook 的域名服务器,由于无法访问数据中心,根据设计撤回了它们自己的 BGP 路由

3:01 ↗
postmortem · zh-CN · 2026年9月12日

一个正则表达式搞垮了 Cloudflare,持续 27 分钟。

2019 年 7 月 2 日,UTC 时间 13:42:Cloudflare Web 应用程序防火墙的一条新规则在大约两秒钟内在全球 180 多个城市生效。这是一条模拟模式下的 XSS 规则,因此它不会阻止任何内容,但它仍然在每个请求上运行,并且以 .*(?:.*=.*) 结尾。PCRE 回溯,每个处理 HTTP 请求的 CPU 核心都达到 100%,每个由 Cloudflare 代理的网站都在

3:00 ↗