Un erro de un milisegundo detivo o tráfico aéreo do Reino Unido. Seis horas.
Ás 10:00 do martes, 8 de setembro, unha solicitude rutineira de código squawk dentro do Sistema Nacional de Espazo Aéreo (NAS) de NATS é interrompida por unha mensaxe de maior prioridade mentres está a medio actualizar un valor.
Ás 10:00 do martes, 8 de setembro, unha solicitude rutineira de código squawk dentro do Sistema Nacional de Espazo Aéreo (NAS) de NATS é interrompida por unha mensaxe de maior prioridade mentres está a medio actualizar un valor. A ventá de exposición é de aproximadamente un milisegundo. A solicitude retómase mal, os datos de voo saen corrompidos e ás 19:30 máis de 2.000 voos do Reino Unido foron atrasados, cancelados ou desviados.
Ler a edición escrita (inglés) ↗
Que abrangue este vídeo
- 10:00: unha solicitude, interrompida dentro dunha ventá de 1 ms
- Cronoloxía: 10:00 squawk → 10:02 blip → 12:45 as saídas paran → 13:32 ligazón perdida
- A cura: reiniciar os datos de voo de todo o país
- Mecanismo: pausado a medio escribir
- Por que unha característica de seguridade detivo o ceo
Transcrición traducida
Traducido da narración orixinal en inglés. O audio e os subtítulos dispoñibles son controlados por YouTube.
10:00: unha solicitude, interrompida dentro dunha ventá de 1 ms
0:00 Ás dez da mañá, unha solicitude rutineira dentro do sistema de datos de voo de Gran Bretaña interrómpese exactamente no milisegundo incorrecto, e pola noite máis de dous mil voos son atrasados, cancelados ou desviados. Iso é do informe preliminar de Nats, o servizo de tráfico aéreo do Reino Unido. Non hai sinais dun ataque, e ninguén premeu o botón incorrecto. Só un defecto herdado, e un milisegundo moi específico. Como sucedeu, por que un milisegundo foi suficiente, e quen recibe realmente a culpa. Isto é The Daily Diff, postmortem.
0:31 As dez. Alguén pide a man un código squawk, o número de catro díxitos que
Cronoloxía: 10:00 squawk → 10:02 blip → 12:45 as saídas paran → 13:32 ligazón perdida
0:36 vincula un punto de radar ao seu plan de voo. A solicitude é válida, e tamén o plan. As dez e dous. A conexión entre o Control de Área de Londres e o sistema central cae, despois volve por si mesma despois de corenta e cinco segundos. O ticket di recuperado, estable, sen impacto operacional. As doce e trinta e dous. A conexión comeza a caer de novo, cada vez máis rápido, e os controladores perden algunha automatización.
0:56 Ás doce e corenta e cinco, as saídas do Reino Unido están detidas. Á unha e trinta e dous, a conexión cae e permanece caída. A cura é un reinicio controlado, e esa é a parte cara,
A cura: reiniciar os datos de voo de todo o país
1:06 porque o mesmo sistema alimenta centros de control e aeroportos en todo o país. O erro vive no espazo aéreo de Londres. As restricións abranguen todo o Reino Unido. O reinicio dura desde as tres e cuarto ata as catro e dez, e desenredar os plans de voo duplicados leva ata as sete menos dez. Entón, por que foi suficiente un milisegundo?
Mecanismo: pausado a medio escribir
1:23 O sistema manexa tarefas por prioridade, e pausar unha tarefa pequena por unha urxente é normal. Pero esta tarefa estaba a medio actualizar un valor. A mensaxe urxente chega dentro dese milisegundo, e a actualización detense a medio camiño. Cando se retoma, non se retoma correctamente. Os datos erróneos entón filtran nalgúns das actualizacións de voo posteriores.
Por que unha característica de seguridade detivo o ceo
1:40 Londres intenta ler un, tarda demasiado e esgótase o tempo. Un tempo de espera corta a conexión, como está deseñado, para protexer ambos os sistemas. A característica de seguridade funciona perfectamente. Ese é o problema. As propias palabras do informe. Se a mensaxe urxente chegase un milisegundo antes ou despois, a actualización teríase completado normalmente. En Hacker News, un programador chama a un milisegundo unha eternidade absoluta,
2:02 garantido para suceder antes do martes desta semana. Era un martes.
git blame — código legado 50 · plan de reinicio 30 · a alarma das 10:02 15 · 1 ms 5
2:05 git blame. O código legado, cincuenta por cento, por unha actualización que pode ser pausada a medio camiño e volve mal. O plan de reinicio, trinta, porque un rexistro defectuoso en Londres significa reiniciar os datos de voo de todo o país. A alarma das dez e dous, quince, por curarse a si mesma e arquivarse como sen impacto. Cinco por cento ao milisegundo, pola súa sincronización. Radio de explosión. Nats planificara uns oito mil voos ese día e xestionou
Radio de explosión: 8.000 planificados, 6.094 xestionados, terceiro fallo en tres anos
2:27 uns seis mil. As saídas do Reino Unido detivéronse durante unhas catro horas e media, e o atraso tardou máis de dous días en despexarse. É o terceiro fallo do tráfico aéreo de Gran Bretaña en tres anos, e o conselleiro delegado chama a este erro moi, moi escuro.
Veredicto + a liña do luns: escrituras atómicas, alarmas ruidosas
2:41 Veredicto, postmortem: NEEDS REVIEW. O informe é rápido e específico, e a solución está escrita e en probas. Pero o plan é un reinicio máis rápido, non un máis pequeno. Liña do luns: se unha tarefa pode ser pausada, que a súa escritura sexa atomic, e trata unha alarma que se cura a si mesma como unha alarma. Envía o incidente do que aínda non se che permite falar, nos comentarios, ou en thedailydiff.dev. E esa é a diferenza de hoxe.
3:02 Son Niko de Axrisi. SHIP IT.
Fontes
- NATS, Major Incident Preliminary Investigation Report, NAS incident 08 September 2026 (report date Sep 16)www.nats.aero
- NATS press release, "NATS publishes preliminary report on technical incident of 8 September" (Sep 18, 2026)www.nats.aero
- NATS on X, 8 Sepx.com
- BBC, "Flight chaos caused by 'millisecond' software defect, report says"www.bbc.co.uk
- The Guardian (Sep 18, 2026)www.theguardian.com
- Hacker News thread on the reportnews.ycombinator.com



