+− THE DAILY DIFFdev & AI news
NEEDS REVIEW

Um erro de um milissegundo parou o tráfego aéreo do Reino Unido. Seis horas.

Às 10:00 de terça-feira, 8 de setembro, um pedido de código squawk de rotina dentro do Sistema Nacional de Espaço Aéreo (NAS) da NATS é interrompido por uma mensagem de prioridade mais alta enquanto está a meio de uma atualização de valor.

Às 10:00 de terça-feira, 8 de setembro, um pedido de código squawk de rotina dentro do Sistema Nacional de Espaço Aéreo (NAS) da NATS é interrompido por uma mensagem de prioridade mais alta enquanto está a meio de uma atualização de valor. A janela de exposição é de cerca de um milissegundo. O pedido retoma incorretamente, os dados de voo saem corrompidos, e até às 19:30 mais de 2.000 voos no Reino Unido foram atrasados, cancelados ou desviados.

Ler a edição escrita (Inglês) ↗

O que este vídeo aborda

  • 10:00: um pedido, interrompido dentro de uma janela de 1 ms
  • Cronologia: 10:00 squawk → 10:02 blip → 12:45 paragem de partidas → 13:32 ligação perdida
  • A cura: reiniciar os dados de voo de todo o país
  • Mecanismo: pausado a meio de uma escrita
  • Porque é que uma funcionalidade de segurança parou o céu

Transcrição traduzida

Traduzido da narração original em inglês. Áudio e legendas disponíveis são controlados pelo YouTube.

10:00: um pedido, interrompido dentro de uma janela de 1 ms

0:00 Às dez da manhã, um pedido de rotina dentro do sistema de dados de voo da Grã-Bretanha é interrompido exatamente no milissegundo errado, e ao fim da tarde mais de dois mil voos são atrasados, cancelados ou desviados. Isso é do relatório preliminar da Nats, o serviço de tráfego aéreo do Reino Unido. Nenhum sinal de ataque, e ninguém pressionou o botão errado. Apenas um defeito legado, e um milissegundo muito específico. Como aconteceu, porque um milissegundo foi suficiente, e quem realmente leva a culpa. Este é The Daily Diff, postmortem.

0:31 Dez horas. Alguém pede manualmente um código squawk, o número de quatro dígitos que

Cronologia: 10:00 squawk → 10:02 blip → 12:45 paragem de partidas → 13:32 ligação perdida

0:36 liga um ponto de radar ao seu plano de voo. O pedido é válido, assim como o plano. Dez e dois. A ligação entre o Controlo da Área de Londres e o sistema central cai, depois volta sozinha após quarenta e cinco segundos. O bilhete diz recuperado, estável, sem impacto operacional. Doze e trinta e dois. A ligação começa a cair novamente, mais rápido a cada vez, e os controladores perdem alguma automação.

0:56 Às doze e quarenta e cinco, as partidas do Reino Unido são paradas. À uma e trinta e dois, a ligação cai e permanece inativa. A cura é um reinício controlado, e essa é a parte cara,

A cura: reiniciar os dados de voo de todo o país

1:06 porque o mesmo sistema alimenta centros de controlo e aeroportos em todo o país. O erro vive no espaço aéreo de Londres. As restrições cobrem todo o Reino Unido. O reinício decorre das três e um quarto às quatro e dez, e o desenrolar dos planos de voo duplicados leva até às sete menos dez. Então, por que um milissegundo foi suficiente?

Mecanismo: pausado a meio de uma escrita

1:23 O sistema lida com trabalhos por prioridade, e pausar um pequeno trabalho por um urgente é normal. Mas este trabalho estava a meio de uma atualização de valor. A mensagem urgente chega dentro desse milissegundo, e a atualização para a meio. Quando retoma, não retoma corretamente. Os dados errados depois vazam para algumas das atualizações de voo posteriores.

Porque é que uma funcionalidade de segurança parou o céu

1:40 Londres tenta ler um, demora muito e esgota o tempo. Um tempo limite derruba a ligação, como projetado, para proteger ambos os sistemas. A funcionalidade de segurança funciona perfeitamente. Esse é o problema. As próprias palavras do relatório. Se a mensagem urgente tivesse chegado um milissegundo antes ou depois, a atualização teria sido concluída normalmente. No Hacker News, um programador chama um milissegundo de uma eternidade absoluta,

2:02 garantida para acontecer até terça-feira desta semana. Foi uma terça-feira.

git blame — código legado 50 · plano de reinício 30 · o alarme das 10:02 15 · 1 ms 5

2:05 git blame. O código legado, cinquenta por cento, para uma atualização que pode ser pausada a meio e volta errada. O plano de reinício, trinta, porque um registo mau em Londres significa reiniciar os dados de voo de todo o país. O alarme das dez e dois, quinze, por se curar sozinho e ser arquivado como sem impacto. Cinco por cento para o milissegundo, pelo seu tempo. Raio de explosão. A Nats planeou cerca de oito mil voos naquele dia e tratou

Raio de explosão: 8.000 planeados, 6.094 tratados, terceira falha em três anos

2:27 cerca de seis mil. As partidas do Reino Unido pararam por cerca de quatro horas e meia, e o atraso levou mais de dois dias para ser resolvido. É a terceira falha de tráfego aéreo da Grã-Bretanha em três anos, e o diretor executivo chama este erro de muito, muito obscuro.

Veredito + a linha de segunda-feira: escritas atómicas, alarmes altos

2:41 Veredito, postmortem: NEEDS REVIEW. O relatório é rápido e específico, e a correção está escrita e em teste. Mas o plano é um reinício mais rápido, não um menor. Linha de segunda-feira: se um trabalho pode ser pausado, torne a sua escrita atómica, e trate um alarme que se cura sozinho como um alarme. Envie-me o incidente sobre o qual ainda não lhe é permitido falar, nos comentários, ou em thedailydiff.dev. E essa é a diferença de hoje.

3:02 Eu sou o Niko da 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