45 minutos, US$ 460 milhões: quando falta governança de tecnologia

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

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

Knight Capital: 45 minutos, US$ 460 milhões

Em 1º de agosto de 2012, a Knight Capital era uma das maiores corretoras eletrônicas dos Estados Unidos. Para participar de um programa novo da bolsa de Nova York, precisava atualizar o roteador de ordens em oito servidores.

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

O detalhe que transforma um erro de deploy em falência: a equipe 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 religou esse código morto.

Nos primeiros 45 minutos de pregão, o roteador disparou mais de 4 milhões de ordens tentando executar 212 ordens de clientes. Foram 397 milhões de ações negociadas e uma perda de aproximadamente US$ 460 milhões.

Dois detalhes doem mais que o prejuízo:

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

A SEC concluiu que a empresa não tinha controles adequados, incluindo revisão de código obrigatória e um processo definido de deploy. A Knight só sobreviveu àquela semana com um aporte 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 hospedava repositórios Git e SVN e ferramentas de gestão de projeto. Tinha backup. Tinha até o que chamava de backup externo.

Um invasor conseguiu acesso 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 controle da conta, o invasor apagou o que alcançou: 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 invasor controlava.

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

O padrão por trás dos dois

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

• Processo que depende de alguém lembrar. Copiar um arquivo para oito servidores à mão funciona até o dia em que não funciona.
• Controle que nunca foi testado. Backup que ninguém restaurou é esperança, não é controle. 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 ação definida.
• Poder concentrado. Uma credencial que apaga a produção e o backup junto 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 desses pontos é uma decisão técnica difícil. Todos 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 piso. Cada item está ligado ao desastre que teria evitado.

1. Deploy automatizado e igual em todo lugar. Nenhum servidor é atualizado à mão, e o deploy termina conferindo 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. "A gente reverte se der errado" não é plano.
4. Todo alerta tem dono e ação. Se ninguém vai agir às seis da manhã, esse alerta não deveria existir. O que sobrar precisa 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 do alcance. Outra conta, outro provedor 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 parar? Como se para? 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 — roda toda segunda 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 num banco descartável
        run: ./scripts/restore-latest.sh --target ephemeral
      - name: Conferir invariantes do negócio (contagens, saldos, integridade)
        run: ./scripts/check-invariants.sh

O valor não está no arquivo. Está em ter, toda semana, uma resposta objetiva para a pergunta mais cara que existe: o backup de ontem presta?

O que isso tem a ver com a sua empresa

Nenhuma das duas era amadora. A Knight movimentava bilhões por dia. A Code Spaces vendia infraestrutura para times 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 o time de trabalhar. É o que faz a empresa sobreviver ao pior dia dela. Implantar os sete itens acima custa algumas semanas de trabalho. Não ter custou, nesses dois casos, a empresa inteira.

Leitura complementar

• Os sete itens acima viram 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).