45 minutos, 460 milhões de dólares: quando falta governança de tecnologia

Governança tem fama de burocracia: comité, política, documento que ninguém lê. Mas quando olho para os desastres de tecnologia que de facto encerraram empresas, quase nunca encontro um bug genial. Encontro um controlo simples que ninguém tinha.

Dois casos explicam isto melhor do que qualquer apresentação sobre risco.

Knight Capital: 45 minutos, 460 milhões de dólares

Em 1 de Agosto de 2012, a Knight Capital era uma das maiores corretoras electrónicas dos Estados Unidos. Para participar num programa novo da bolsa de Nova Iorque, precisava de actualizar o router de ordens em oito servidores.

Sete receberam o código novo. Um não recebeu.

O pormenor que transforma um erro de deploy numa falência: a equipa tinha reaproveitado uma flag que, anos antes, ligava um sistema chamado Power Peg — um código fora de uso desde 2003, que nunca foi removido. No servidor esquecido, a flag voltou a ligar esse código morto.

Nos primeiros 45 minutos de negociação, o router disparou mais de 4 milhões de ordens a tentar executar 212 ordens de clientes. Foram negociadas 397 milhões de acções e um prejuízo de aproximadamente 460 milhões de dólares.

Dois pormenores doem mais do que o prejuízo:

• Os alertas existiam. Antes da abertura do mercado, um sistema interno disparou 97 e-mails automáticos a apontar o problema. Ninguém agiu.
• A reacção piorou a situação. Os técnicos desinstalaram o código novo dos sete servidores que o tinham recebido. As ordens erradas continuaram a sair.

A SEC concluiu que a empresa não tinha controlos adequados, incluindo revisão de código obrigatória e um processo definido de deploy. A Knight só sobreviveu a essa semana graças a uma injecção de capital de emergência. Menos de um ano depois, foi vendida numa fusão e deixou de existir como empresa independente.

Code Spaces: 12 horas

Em Junho de 2014, a Code Spaces alojava repositórios Git e SVN e ferramentas de gestão de projecto. Tinha backup. Tinha até o que chamava de backup externo.

Um atacante conseguiu aceder ao painel da AWS da empresa, iniciou um ataque de negação de serviço e exigiu pagamento. Quando a Code Spaces tentou retomar o controlo da conta, o atacante apagou tudo o que conseguiu alcançar: snapshots, buckets, imagens de máquina e instâncias. Nas palavras da própria empresa, "a maior parte dos nossos dados, backups, configurações de máquina e backups externos".

O problema não era não ter backup. Era o backup viver dentro da mesma conta que o atacante controlava.

No mesmo dia, o comunicado no site dizia que a empresa não teria condições de continuar a operar. Uma empresa inteira encerrada em horas, porque uma credencial dava acesso a tudo — incluindo à cópia de segurança.

O padrão por trás dos dois

Décadas diferentes, sectores diferentes, tecnologias diferentes. O padrão é o mesmo:

• Processo que depende de alguém se lembrar. Copiar um ficheiro para oito servidores à mão funciona até ao dia em que deixa de funcionar.
• Controlo que nunca foi testado. Backup que ninguém restaurou é esperança, não é controlo. Rollback que ninguém ensaiou também.
• Alerta sem dono. 97 e-mails não são um alerta, são ruído. Alerta é o que chega a uma pessoa específica com uma acção definida.
• Poder concentrado. Uma credencial que apaga a produção e o backup em conjunto não é praticidade, é risco existencial.
• Código morto que ficou. O que não é removido continua executável, e um dia alguém reaproveita a chave que o liga.

Nenhum destes pontos é uma decisão técnica difícil. Todas são decisões de governança: quem decide, quem confere, quem é dono, de quanto em quanto tempo se testa.

O mínimo de governança que evita os dois

Se a sua empresa opera software em produção, este é o patamar mínimo. Cada item está ligado ao desastre que teria evitado.

1. Deploy automatizado e igual em todo o lado. Nenhum servidor é actualizado à mão, e o deploy só termina depois de confirmar que todos estão na mesma versão.
2. Sem código morto, sem flag reaproveitada. Remover faz parte da tarefa. Um botão de desligar tem nome próprio e faz uma coisa só.
3. Rollback ensaiado. Antes da janela de deploy, alguém executa o rollback num ambiente igual. "Se correr mal, revertemos" não é um plano.
4. Todo o alerta tem dono e acção. Se ninguém vai agir às seis da manhã, esse alerta não devia existir. O que restar tem de chegar a uma pessoa, não a uma caixa de entrada.
5. Acesso mínimo e separado. MFA obrigatório, credenciais de produção separadas das de desenvolvimento e ninguém capaz de apagar tudo sozinho.
6. Backup fora de alcance. Outra conta, outro fornecedor ou armazenamento imutável, com retenção definida — e restore testado no calendário, não na emergência.
7. Dono por sistema e runbook de incidente. Quem decide interromper? Como se interrompe? Por escrito, antes do incidente.

O teste de restore é o mais fácil de automatizar e o mais caro de não ter:

# .github/workflows/restore-test.yml — corre toda segunda-feira e falha alto
name: restore-test
on:
  schedule:
    - cron: "0 6 * * 1"
jobs:
  restore:
    runs-on: ubuntu-latest
    steps:
      - name: Restaurar o backup mais recente numa base de dados descartável
        run: ./scripts/restore-latest.sh --target ephemeral
      - name: Confirmar as invariantes do negócio (contagens, saldos, integridade)
        run: ./scripts/check-invariants.sh

O valor não está no ficheiro. Está em ter, todas as semanas, uma resposta objectiva para a pergunta mais cara que existe: o backup de ontem presta?

O que isto tem a ver com a sua empresa

Nenhuma das duas era amadora. A Knight movimentava milhares de milhões por dia. A Code Spaces vendia infra-estrutura a equipas de desenvolvimento. As duas tinham gente boa. O que faltou foi combinar, por escrito e antes do incidente, quem decide o quê e o que é testado com que frequência.

Governança de tecnologia não é o que impede a equipa de trabalhar. É o que faz a empresa sobreviver ao pior dia dela. Implementar os sete itens acima custa algumas semanas de trabalho. Não os ter custou, nestes dois casos, a empresa inteira.

Leitura complementar

• Os sete itens acima tornam-se trabalho em Engenharia de Plataforma: pipeline, observabilidade, runbook e teste de restore no calendário.
• Do outro lado da mesma moeda, um número que quase ninguém calcula: o número mais desconfortável da sua base.

Fontes

• Ordem administrativa da SEC contra a Knight Capital Americas (16 de Outubro de 2013) e o comunicado da SEC sobre o caso.
• Reportagem do The Register sobre o fim da Code Spaces (18 de Junho de 2014).