+− THE DAILY DIFFdev & AI news
NEEDS REVIEW

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

Às 10:00 de terça-feira, 8 de setembro, uma solicitação rotineira de código squawk dentro do Sistema Nacional de Espaço Aéreo (NAS) da NATS é interrompida por uma mensagem de maior prioridade enquanto está parcialmente atualizando um valor.

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

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

O que este vídeo aborda

  • 10:00: uma solicitação, interrompida dentro de uma janela de 1 ms
  • Cronologia: 10:00 squawk → 10:02 blip → 12:45 partidas param → 13:32 link perdido
  • A cura: reiniciar os dados de voo de todo o país
  • Mecanismo: pausado na metade de uma gravação
  • Por que um recurso 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: uma solicitação, interrompida dentro de uma janela de 1 ms

0:00 Às dez da manhã, uma solicitação rotineira dentro do sistema de dados de voo da Grã-Bretanha é interrompida exatamente no milissegundo errado, e à noite mais de dois mil voos são atrasados, cancelados ou desviados. Isso é do relatório preliminar da Nats, o tráfego aéreo do Reino Unido serviço. Nenhum sinal de ataque, e ninguém apertou o botão errado. Apenas um defeito legado e um milissegundo muito específico. Como aconteceu, por que um milissegundo foi suficiente e quem realmente leva a culpa. Este é The Daily Diff, post-mortem.

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 partidas param → 13:32 link perdido

0:36 liga um ponto de radar ao seu plano de voo. A solicitação é válida, e o plano também. Dez e dois. O link entre o Controle de Área de Londres e o sistema central cai, depois volta sozinho após quarenta e cinco segundos. O bilhete diz recuperado, estável, sem impacto operacional. Doze e trinta e dois. O link 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 interrompidas. À uma e trinta e dois, o link cai e permanece inativo. 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 controle e aeroportos em todo o país. O bug mora no espaço aéreo de Londres. As restrições cobrem todo o Reino Unido. O reinício vai das três e quinze às quatro e dez, e o desenrolar dos planos de voo duplicados leva até as seis e cinquenta. Então, por que um milissegundo foi suficiente?

Mecanismo: pausado na metade de uma gravação

1:23 O sistema lida com tarefas por prioridade, e pausar uma tarefa pequena por uma urgente é normal. Mas esta tarefa estava na metade da atualização de um valor. A mensagem urgente chega dentro desse milissegundo, e a atualização para na metade. Quando ela é retomada, não é retomada corretamente. Os dados ruins então vazam para algumas das atualizações de voo posteriores.

Por que um recurso de segurança parou o céu

1:40 Londres tenta ler um, leva muito tempo e expira. Um tempo limite derruba o link, como projetado, para proteger ambos os sistemas. O recurso 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 garantido para acontecer até terça-feira desta semana. Era 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 na metade e volta errada. O plano de reinício, trinta, porque um registro ruim em Londres significa reiniciar o os dados de voo de todo o país. O alarme das dez e dois, quinze, por se curar e ser arquivado como sem impacto. Cinco por cento para o milissegundo, pelo seu tempo. Raio de explosão. A Nats planejou cerca de oito mil voos naquele dia e tratou

Raio de explosão: 8.000 planejados, 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 esse bug de muito, muito obscuro.

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

2:41 Veredito, post-mortem: 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 uma tarefa pode ser pausada, torne sua escrita atômica, e trate um alarme que se cura como um alarme. Envie-me o incidente sobre o qual você ainda não tem permissão para falar, nos comentários, ou em thedailydiff.dev. E essa é a diferença de hoje.

3:02 Eu sou o Niko da Axrisi. Faça o merge com responsabilidade.

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