+− THE DAILY DIFFdev & AI news
NEEDS REVIEW

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

  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

Vídeos relacionados