Resumo

  • A interrupção de longa distância da AT&T em 15 de janeiro de 1990 não deve ser lida como colapso nacional de hardware nem como ataque: o registro público aponta para um gatilho local em Nova York, uma rotina normal de recuperação de quatro a seis segundos, uma falha de software introduzida em atualização comum de dezembro e uma condição de temporização envolvendo mensagens IAM e processadores DLN no ambiente CCS7.
  • A responsabilidade técnica central está na capacidade de validar transições de estado, isolar a exposição de uma mudança comum, manter inventário de versão, reduzir tráfego de sinalização sem apagar visibilidade, executar reversão verificável e distinguir, em relatórios públicos, gatilho, defeito latente, mecanismo de propagação, mitigação e impacto medido.

Incidente e limite de evidência

A interrupção de 15 de janeiro de 1990 na rede de longa distância da AT&T pertence a uma categoria específica de falha: uma instabilidade do plano de sinalização em uma rede telefônica nacional baseada em comutadores 4ESS e CCS7. Ela não deve ser misturada com incidentes posteriores de telefonia sem fio, falhas de energia, cortes de fibra, eventos de 911, panes de frame relay ou narrativas modernas sobre exploração maliciosa de SS7.

O objeto aqui é mais estreito e mais exigente: uma mudança comum de software em uma frota de comutadores de longa distância, uma rotina de recuperação que deveria restaurar serviço, mensagens de estabelecimento de chamada que eram válidas, e uma condição de temporização que fez a própria lógica de recuperação repetir a instabilidade.

A distinção importa porque a análise de responsabilidade muda conforme o plano afetado. O problema não foi simplesmente que usuários não conseguiram completar chamadas; isso foi o efeito visível. O controle técnico estava no sistema que permitia aos comutadores trocar informações de chamada, estado, disponibilidade e recuperação. O CCS7 era a camada de sinalização comum que ligava funções de rede e carregava mensagens essenciais para estabelecer e administrar chamadas. As recomendações ITU-T da família Q.700 ajudam a explicar essa arquitetura, incluindo o papel do Message Transfer Part, funções de rede, monitoramento, desempenho e medições.

Elas não provam, por si só, que a operadora de 1990 descumpriu uma recomendação específica. Servem, antes, para localizar o domínio de controle: se a sinalização comum perde coerência, a rede de voz pode permanecer fisicamente existente e, ainda assim, ficar operacionalmente indisponível para grande parte do tráfego.

A operadora em questão era a rede de longa distância da AT&T histórica, não uma projeção retroativa da forma societária atual da AT&T Inc. Essa cautela não é cosmética. Em incidentes antigos, nomes comerciais sobrevivem a cisões, fusões, reorganizações e mudanças regulatórias. A responsabilidade técnica deve seguir os controles da época: propriedade da versão de software, operação da frota 4ESS, autoridade de liberação, observabilidade, isolamento de sinalização e comando de incidente.

O gatilho de recuperação em Nova York

O ponto inicial atribuído à própria AT&T ocorreu por volta das 14h30, horário do leste dos Estados Unidos, em 15 de janeiro de 1990. Uma central interurbana 4ESS em Nova York sofreu um pequeno problema de hardware em uma interface de tronco. O evento acionou a rotina normal de recuperação do equipamento. Essa rotina suspendia por cerca de quatro a seis segundos o processamento de novas chamadas e informava comutadores 4ESS conectados de que não deveriam encaminhar novo tráfego naquele intervalo.

Esse detalhe é a primeira fronteira factual do caso. O evento de hardware foi o gatilho, não a raiz nacional do incidente. Uma falha localizada em uma interface de tronco podia justificar a entrada temporária de um comutador em recuperação. Ela não explica, sozinha, por que uma rede nacional passaria a sofrer falhas repetidas. Também não autoriza a conclusão de que todos os 114 sistemas 4ESS tenham falhado ao mesmo tempo, nem que a rede inteira tenha sofrido uma pane homogênea. O registro público descreve uma cascata sob certas condições de sinalização e temporização; não uma queda simultânea e uniforme de cada componente.

A rotina de quatro a seis segundos também mostra por que a fronteira entre manutenção e operação é enganosa. Recuperação automática parece uma função de resiliência. Em uma rede nacional, porém, recuperação é código operacional crítico. Ela muda estados, informa vizinhos, redireciona tráfego e pode gerar mensagens que outros sistemas interpretam como sinais de disponibilidade ou indisponibilidade. Uma rotina de recuperação que funciona quando testada isoladamente pode se comportar de outro modo quando todos os vizinhos, cargas de chamada e enlaces de sinalização continuam ativos.

Como a temporização das IAMs expôs o defeito DLN

Quando o comutador de Nova York voltou ao processamento, ele enviou Initial Address Messages, ou IAMs, a comutadores adjacentes. No CCS7, a IAM faz parte do processo de estabelecimento de chamadas. O relato técnico atribuído à AT&T diz que um processador Direct Link Node, ou DLN, em um comutador receptor usava essas mensagens para atualizar seu mapa de estado e reconhecer que Nova York havia retornado ao serviço. Durante alguns segundos dessa atualização, o processador ficava vulnerável a uma condição dependente de temporização.

O ponto crítico não é que as IAMs fossem inválidas. O relato atribuído à AT&T descreve mensagens válidas chegando em um momento crítico. Se duas IAMs chegassem dentro de um centésimo de segundo, dados poderiam ser danificados durante a atualização do mapa de estado, levando o processador DLN a reinicializar. O processador duplicado assumia o tráfego, mas podia ser atingido pela mesma condição se outro par de mensagens muito próximas chegasse durante a transição equivalente. O resultado era isolamento temporário do comutador em relação à rede de sinalização CCS7.

Essa sequência precisa ser mantida separada do gatilho de hardware. O hardware em Nova York iniciou uma recuperação comum. O defeito latente estava no software de atualização de estado de sinalização. A condição de propagação dependia de mensagens IAM próximas no tempo, processadores duplicados expostos à mesma lógica e pressão contínua de chamadas e sinalização. A mitigação veio depois, pela redução de tráfego em enlaces de sinalização de reserva e pela reversão ao programa anterior. Misturar esses planos transforma uma falha de controle verificável em uma história genérica sobre “pane de computador”.

Relatos secundários posteriores descrevem o defeito como um problema de programação específico, inclusive narrativas sobre uma instrução de controle colocada em lugar errado. Essas descrições podem ser citadas apenas como narrativas atribuídas. Elas não substituem o código-fonte público, que não está disponível no pacote de evidências. Portanto, a análise não depende de afirmar uma linha exata de código. Ela depende do comportamento operacional atribuído: durante uma transição de estado, uma combinação de mensagens válidas e temporização estreita corrompia o estado de um processador de sinalização.

Por que processadores duplicados não eram independência real

A arquitetura duplicada do DLN parecia oferecer redundância. Um processador falhava ou reinicializava, o parceiro assumia. Esse desenho só cria independência quando a segunda unidade não está exposta ao mesmo defeito, ao mesmo estado vulnerável e ao mesmo padrão de entrada. No caso de 1990, o problema descrito não era a destruição física de um processador único. Era uma condição lógica compartilhada. Se os dois processadores executavam o mesmo código e atualizavam estado a partir das mesmas classes de mensagem, a duplicação podia se tornar apenas uma repetição rápida do mesmo domínio de falha.

Essa é uma lição de infraestrutura que continua atual. Redundância não é uma palavra mágica; é uma relação entre domínios de falha. Dois elementos são redundantes de modo efetivo quando uma causa plausível não os derruba pelo mesmo caminho. Se uma mudança comum de software entra em todos os elementos, se as rotinas de recuperação são idênticas, se o teste não força a transição de estado sob carga realista, e se o tráfego que deveria confirmar recuperação também pode reativar o defeito, então a redundância técnica existe como inventário, mas não necessariamente como independência operacional.

O mesmo vale para a sinalização de reserva. A atualização de meados de dezembro, segundo a AT&T, pretendia permitir que os comutadores acessassem mais rapidamente uma rede de sinalização de reserva. Essa intenção tinha aparência resiliente. Mas, se o código que melhora o caminho de reserva é o mesmo código que torna vulnerável a transição de estado, a reserva passa a compartilhar a condição que deveria contornar. A pergunta de controle não é “havia reserva?”, e sim “o caminho de reserva tinha domínio de falha separado, versão separável, teste separado e isolamento executável sob carga?”.

Como a recuperação virou mecanismo de propagação

A cascata descrita pela AT&T é um caso de recuperação que se transforma em mecanismo de propagação. Um comutador perde seus processadores de sinalização e anuncia indisponibilidade. Depois reinicializa, retoma sinalização e comunica aos vizinhos que voltou. Esses vizinhos, ao reconhecerem o retorno, atualizam mapas de estado. Sob a pressão de mensagens de chamada em andamento, eles podem receber IAMs próximas no tempo durante a mesma janela vulnerável. A falha não precisa de mensagem malformada nem de carga anormal. O próprio fluxo válido do plano de controle pode reproduzir o estado ruim.

Estudos acadêmicos posteriores tratam incidentes desse tipo como exemplos de mensagem de controle que envenena o plano por acionar defeito latente. A palavra “envenenar”, nesse contexto, não significa ataque. Significa que uma mensagem aparentemente legítima, processada por uma implementação vulnerável, altera a estabilidade do sistema de controle. Essa distinção é essencial para não transformar o incidente em narrativa de intrusão. O pacote de evidências não estabelece vírus, sabotagem, comprometimento malicioso ou violação deliberada de padrão.

A arquitetura CCS7 torna essa cascata especialmente instrutiva. Em redes telefônicas de sinalização comum, mensagens de controle são compartilhadas entre funções e comutadores para viabilizar chamadas. Quando estado de disponibilidade, roteamento ou recuperação deixa de ser confiável, a falha de uma parte afeta decisões de outras. A continuidade, portanto, depende tanto do plano de sinalização quanto do transporte físico. A chamada que o usuário tenta completar não falha apenas porque um circuito de voz específico desapareceu; ela pode falhar porque a rede não consegue administrar, estabelecer ou confiar no estado necessário para completá-la.

A fronteira da mudança comum de dezembro

A AT&T afirmou que o defeito entrou na frota em uma atualização de software de meados de dezembro. A finalidade declarada era alcançar a rede de sinalização de reserva com mais rapidez. Um relato contemporâneo da revista Telephony, reproduzido em discussões técnicas da época, diz que o novo código foi carregado nos processadores de front-end de todos os 114 sistemas 4ESS. Essa informação deve ser tratada com precisão: ela sustenta a análise de mudança comum ampla, mas não prova que todos os sistemas tenham falhado simultaneamente nem que cada chamada tenha sido afetada do mesmo modo.

A fronteira de responsabilidade fica nessa implantação ampla. Quanto maior a uniformidade de versão em uma frota crítica, mais rigorosos precisam ser os controles de exposição gradual, inventário e reversão. Uma atualização pode ter objetivo correto e ainda assim criar risco sistêmico se entra em muitos comutadores antes de uma implantação canário com exposição limitada, antes de condições de parada claras, ou antes de testes que reproduzam o retorno ao serviço sob rajadas de sinalização. O ponto não é exigir que toda combinação possível seja prevista.

O ponto é reconhecer que mudanças em sinalização comum têm uma superfície de falha diferente de mudanças locais: elas podem se comunicar.

A AT&T disse que o software havia sido rigorosamente testado em laboratório e que a combinação exata não havia sido prevista. Essa afirmação não encerra a análise. Laboratório é relevante, mas a pergunta de controle é o que o laboratório modelou. Ele testou a reintegração de um 4ESS ao CCS7 enquanto vizinhos recebiam IAMs em intervalos de centésimos de segundo? Testou o par de processadores DLN como sistema acoplado, e não como componentes independentes? Testou o comportamento de anúncios de recuperação repetidos sob pressão de chamada? Testou reversão e redução de tráfego de sinalização sem perda de diagnóstico?

Sem esses registros, a conclusão pública deve permanecer limitada: houve teste declarado, mas a transição crítica não foi suficientemente antecipada no registro disponível.

Diagnóstico, estabilização e reversão

Durante a interrupção, os engenheiros tentaram procedimentos padrão e descobriram que eles não bastavam. O registro atribui a investigação ao exame de padrões de mensagens de erro, comportamento dos comutadores, suporte técnico e equipes do Bell Labs. Essa progressão é importante porque mostra que a falha não era apenas uma capacidade estática de equipamento. Era um problema dinâmico: uma sequência de estado e mensagem que precisava ser observada e reproduzida.

A estabilização veio por uma medida operacional estreita: a AT&T suspendeu temporariamente tráfego de sinalização em enlaces de reserva para reduzir a carga de mensagens sobre processadores afetados. A empresa disse que o último enlace foi limpo às 23h30, horário do leste. No dia seguinte, removeu a atualização defeituosa, voltou temporariamente ao programa anterior, reproduziu o problema em laboratório, corrigiu a falha e testou a alteração antes de restaurar os enlaces de reserva.

A ordem desses passos deve ser preservada. A redução de tráfego em enlaces de reserva foi mitigação de estabilização, não explicação causal original. A reversão ao programa anterior foi controle de retorno de versão, não prova de que qualquer versão antiga fosse ideal. A reprodução em laboratório e a correção posterior reforçam que a falha estava em comportamento de software sob condição específica, mas não tornam público o código, a matriz completa de testes ou a cadeia interna de aprovação.

A responsabilidade operacional fica no fato de que uma rede nacional precisa ter meios de reduzir exposição, isolar sinalização, reverter versão e confirmar causa sem depender apenas de tentativa e erro em tempo real.

Impacto e limites de medição

Os relatos públicos contemporâneos convergem em severidade, mas não em uma contagem única. AT&T e jornais importantes relataram que aproximadamente metade das tentativas de chamadas de longa distância falhou durante partes substanciais da interrupção. A UPI atribuiu a estimativa de 50 milhões de chamadas bloqueadas e mencionou efeitos sobre serviços de número 800 e linhas de computador. Narrativas posteriores apresentam totais maiores. Esses números devem permanecer separados e atribuídos. “Metade das chamadas” é uma caracterização de taxa ou proporção em determinados períodos; “50 milhões” é uma estimativa atribuída de volume bloqueado.

Unir os dois em uma cifra única, ou converter isso em perda monetária precisa, inventaria precisão que as fontes deste pacote não demonstram.

Essa limitação não reduz a gravidade. Uma rede de longa distância nacional é infraestrutura de dependência pública mesmo quando o tráfego afetado não é todo idêntico. Chamadas pessoais, serviços empresariais, números gratuitos, conexões de dados e dependências institucionais podem usar a mesma superfície de continuidade. Mas a análise responsável não deve preencher lacunas com suposições sobre impacto financeiro, serviços de emergência, transações bancárias ou disponibilidade geográfica uniforme.

O que se pode dizer, com base no pacote, é que uma parcela muito grande das tentativas de chamada falhou por horas, que havia estimativas contemporâneas de dezenas de milhões de chamadas bloqueadas, e que o registro público não fornece uma auditoria reconciliada de impacto por cliente, região ou serviço.

A boa medição teria separado pelo menos cinco camadas: chamadas tentadas, chamadas bloqueadas, duração de falhas por rota, efeitos sobre serviços dependentes e tempo de restauração por domínio de sinalização. Também teria preservado o estado de cada comutador, versão de software, estado DLN, tráfego em enlaces principais e de reserva, sequência de anúncios de indisponibilidade e retorno, além de marcadores de reversão. Sem esse registro operacional de estado, a narrativa pública tende a oscilar entre a anedota e a simplificação.

Gatilho, causa raiz, propagação e mitigação

O caso de 1990 exige uma gramática causal disciplinada. O gatilho foi o problema menor de hardware no 4ESS de Nova York. A causa técnica latente foi o defeito de software introduzido em atualização comum de dezembro, associado à atualização de estado do DLN sob mensagens IAM próximas no tempo. A propagação ocorreu quando recuperação, indisponibilidade, reinicialização e retorno ao serviço geraram novas condições para comutadores vizinhos atravessarem a mesma janela vulnerável.

A mitigação operacional incluiu reduzir tráfego de sinalização em enlaces de reserva, limpar enlaces, reverter ao programa anterior, reproduzir a falha em laboratório, corrigir e testar.

Essas fronteiras impedem três erros frequentes. O primeiro é culpar o hardware local por um evento nacional. O segundo é tratar a mensagem IAM como se fosse maliciosa ou inválida, quando o relato atribui o problema a mensagens válidas chegando em uma janela de temporização estreita. O terceiro é transformar uma história de mudança comum de software em moralismo sobre programadores individuais. A evidência pública não identifica uma pessoa culpada, não expõe o código completo e não demonstra uma violação jurídica específica.

O que ela demonstra é a insuficiência de uma barreira operacional: uma versão comum e um processo de recuperação puderam reproduzir instabilidade em escala.

O teste de responsabilidade, então, não é encontrar um vilão. É perguntar quem controlava a mudança, quem autorizava a exposição, quem sabia quais versões estavam em cada comutador, quem podia reduzir tráfego de sinalização, quem podia reverter, quem podia distinguir sintomas de causa, e quem podia verificar, de forma independente, que a correção realmente cobria a transição vulnerável.