Bolsa de Tóquio parou em 2005: 4h30 de bug da Fujitsu

Em 1º de novembro de 2005, uma terça-feira, os operadores da Bolsa de Tóquio ligaram o sistema de negociação às 6h30, como em qualquer dia útil. O sistema leu um arquivo, achou que algo estava errado e parou. A maior bolsa da Ásia ficou sem negociar ações por quatro horas e meia. Não houve invasor, ransomware nem ataque: foi um bug que estava dormindo no código e acordou no pior dia possível.

O que aconteceu em 1º de novembro de 2005

Segundo a cobertura da época (Mail & Guardian), foi a primeira vez que a Tokyo Stock Exchange (TSE) suspendeu a negociação de todas as ações. Pelo comunicado da própria bolsa, reproduzido pela Global Custodian, a negociação ficou suspensa das 9h às 13h30. A negociação voltou às 13h30 e o índice Nikkei 225 ainda fechou em alta de 261,36 pontos, aos 13.867,86.

O Register descreveu o episódio como a pior interrupção da história da bolsa. O mercado estava aquecido, e o susto aconteceu justamente quando a TSE tentava ganhar capacidade para aguentar volumes maiores de ordens.

O que causou a falha na Bolsa de Tóquio?

Um defeito num programa que processa dados das corretoras, exposto por uma atualização de capacidade feita em outubro de 2005 pela Fujitsu. Na partida do sistema, a leitura dos arquivos de dados dos participantes falhou, o sistema detectou que o conteúdo lido não era o esperado e se desligou. Ao tentar reiniciar, o problema persistiu e o sistema travou de novo.

A explicação oficial da TSE falava em um bug latente, que já existia num programa ligado a esses arquivos e só apareceu depois da ampliação da capacidade de processamento de ordens. Um porta-voz da bolsa disse à Reuters que instruções falhas recebidas da Fujitsu sobre as melhorias no software pareciam ter causado o problema.

As consequências para a Fujitsu

A conta chegou rápido. Segundo o Register, o conselho da Fujitsu cortou pela metade o salário do presidente, Hiroaki Kurokawa, por seis meses, e aplicou cortes de 10% a 25% em outros executivos, inclusive os da divisão de sistemas financeiros. Três dias depois, a bolsa de Nagoia teve uma parada parecida, também atribuída a software da Fujitsu.

O ponto interessante é o que aparece no comunicado da TSE: foi publicado um relato detalhado do que falhou, com pedido de desculpas. Isso é prática de post-mortem, e boa parte da área de segurança e operações ainda tenta chegar nesse nível de transparência.

Disponibilidade também é segurança

Quando se fala em segurança da informação, o modelo clássico tem três pilares: confidencialidade, integridade e disponibilidade. Dá pra perder o terceiro sem nenhum atacante envolvido. Uma bolsa, um banco ou um e-commerce parado custa dinheiro igual, venha a causa de um criminoso ou de um deploy mal feito.

Esse padrão se repete na história que já contei por aqui:

• O apagão da CrowdStrike em julho de 2024 derrubou milhões de máquinas Windows por causa de uma atualização, não de um ataque.
• O SQL Slammer mostrou o outro lado: um worm de 376 bytes que sobrecarregou redes e serviços inteiros em 2003.
• No caso Colonial Pipeline, a operação parou por precaução depois de um ransomware.

O que dá pra aplicar na sua empresa ou no seu home lab

Você não opera uma bolsa, mas a mecânica do erro é a mesma em qualquer atualização:

1. Teste o caminho de partida, não só o funcionamento. O defeito da TSE só apareceu na hora de ligar o sistema e ler os arquivos. Reinicie o ambiente de teste do zero.
2. Tenha plano de volta. Antes de qualquer atualização grande, saiba como reverter: snapshot da VM, imagem do sistema ou versão anterior do pacote.
3. Atualize em ondas. Um servidor ou um grupo piloto primeiro; o resto só depois de algumas horas sem problema.
4. Evite mudança em véspera de pico. Fim de mês, virada de folha e dia de promoção não são hora de mexer.
5. Teste a restauração. Backup que nunca foi restaurado é suposição; a regra 3-2-1 de backup só vale se alguém já recuperou um arquivo de verdade.

Lição maior

O erro de 2005 não foi só de código. Foi de processo: uma correção entrou em produção com instruções erradas, e ninguém percebeu até a manhã em que o mercado abriu. Nem todo incidente tem um vilão. Boa parte é uma mudança sem teste de partida e sem plano de reversão. Se quiser seguir pelo mesmo caminho, leia sobre o que de fato quebrou no apagão da CrowdStrike.

Fontes consultadas: Mail & Guardian (1/11/2005), Global Custodian — comunicado da TSE (21/11/2005), The Register (25/11/2005), Computer History Museum. Observação: a duração varia entre as fontes; usei o horário de suspensão informado pela própria TSE.