O cenário

O Group era, em meados de 2012, responsável por cerca de um décimo de todas as negociações de ações nos Estados Unidos. Seu roteador de ordens, o SMARS, pegava a ordem de um cliente e a quebrava em ordens filhas enviadas ao mercado.

Dentro desse roteador havia uma função chamada Power Peg. Segundo a ordem da Securities and Exchange Commission, o Knight movera um trecho de código em 2005 para um ponto anterior da sequência, o que tornou a função defeituosa - ela deixou de reconhecer quando as ordens tinham sido preenchidas, e portanto continuaria enviando. A função não deveria ser usada. O Knight a deixou no roteador mesmo assim, e ela não foi retestada depois da mudança para ver se a aplicação ainda funcionaria caso fosse invocada.

Ficou lá sete anos, sem uso e quebrada, atrás de uma flag que a ligava.

A implantação

No fim de julho de 2012 o Knight se preparava para participar de um novo mecanismo da NYSE, o Retail Liquidity Program. O código novo foi escrito para substituir a lógica não usada do Power Peg - e reaproveitou a mesma flag. O raciocínio é fácil de reconstruir e era inteiramente banal: o Power Peg está morto, então a chave está livre.

A implantação começou em 27 de julho. Era manual e escalonada, um técnico copiando o código atualizado para cada um dos oito servidores SMARS, um por um.

Um servidor foi esquecido.

Nenhum segundo técnico revisou a implantação. O Knight não tinha procedimento escrito que exigisse isso. Então ninguém notou que no oitavo servidor o código novo estava ausente e o antigo Power Peg defeituoso continuava presente - agora alcançável por uma flag que o resto do parque estava prestes a começar a acionar para um propósito completamente diferente.

A manhã

Por volta das 8h01 da manhã de 1º de agosto, uma hora e meia antes de o mercado abrir, os próprios sistemas do Knight começaram a mandar avisos automáticos. Noventa e sete e-mails, referindo-se ao SMARS, reportando um erro descrito como "Power Peg disabled".

O sistema disse o nome da coisa que estava prestes a destruir a empresa, noventa e sete vezes, antes de alguém ter perdido um centavo. As mensagens não foram encaminhadas a ninguém que agisse sobre elas.

Às 9h30 o mercado abriu. Sete servidores processaram o programa novo corretamente. O oitavo recebeu ordens elegíveis ao novo mecanismo, acionou a flag reaproveitada, e invocou uma função quebrada desde 2005 - uma que não sabia dizer quando uma ordem fora preenchida, e por isso seguia preenchendo.

Em quarenta e cinco minutos, tentando atender 212 ordens de clientes, o roteador mandou mais de quatro milhões de ordens ao mercado, produzindo mais de quatro milhões de execuções em 154 ações e mais de 397 milhões de papéis. O Knight terminou com cerca de 3,5 bilhões de dólares em posições compradas indesejadas em 80 ações e uns 3,15 bilhões vendidas em 74. A perda passou de 460 milhões de dólares. A empresa tinha uns 365 milhões em caixa.

Sobreviveu ao fim de semana com um aporte emergencial de 400 milhões, e foi adquirida em poucos meses.

O rollback

Esta é a parte que faz o caso merecer artigo próprio, e é a parte que a maioria dos relatos pula.

Quando os engenheiros descobriram que um dos oito servidores não recebera o código novo, fizeram o que todo instinto e todo runbook mandam fazer: restauraram a consistência revertendo todos os servidores para a versão anterior.

A versão anterior continha o Power Peg, ligado à flag que o mercado agora acionava.

O rollback pegou um defeito que existia num servidor e o pôs nos oito. A ação mais razoável disponível, tomada sob pressão de tempo por gente competente e com o diagnóstico correto, ampliou o dano - porque o "estado bom conhecido" ao qual voltavam era justamente o estado que continha o defeito.

O que um profissional deve tirar disso

Um rollback é uma implantação. Carrega o mesmo risco de qualquer outra mudança, merece o mesmo escrutínio, e deve ser raciocinado e não reflexo. O instinto de restaurar um estado bom conhecido supõe que o estado antigo seja bom, e em todo caso em que o defeito antecede a mudança - código morto, uma configuração latente, um certificado vencido, uma dependência que se moveu - essa suposição está exatamente errada. A pergunta antes de puxar a alavanca é estreita: para o que estou voltando, e isso contém a coisa que está me machucando?

Código morto não é inerte. A comissão do Ariane 5 fez o mesmo achado sobre uma rotina que servia a um propósito apenas antes da decolagem e seguiu rodando. A função do Knight estava quebrada havia sete anos e não custara nada por sete anos, que é justamente por que ninguém a removeu. O custo do código não usado é zero até o dia em que não é.

Nunca reaproveite um identificador que ainda significa algo em algum lugar. Flags, portas, identificadores de rede local virtual, comunidades , tags de rota, nomes de grupo - o raciocínio "aquilo está obsoleto, então o nome está livre" só é seguro se a coisa obsoleta tiver sido de fato removida, e não apenas desligada. Deprecie removendo, ou não reaproveite.

Implantação parcial é um estado que ninguém projeta. Sete de oito não é "quase implantado"; é uma configuração que nunca foi testada, nunca pretendida e nunca documentada. A automação remove esse modo de falha não por ser esperta, mas por ser uniforme, e um passo de verificação que responda "todo nó está rodando a versão que eu penso?" teria pego isso em segundos.

E um alerta que ninguém lê é pior que nenhum alerta. Noventa e sete mensagens, noventa minutos antes, nomeando o componente. A invasão da Target é a mesma falha com outra consequência: a detecção não é o controle, a resposta é o controle, e o intervalo entre as duas é onde a perda se acumula. É o argumento do relógio em sua forma mais crua, porque aqui o relógio já corria antes de o mercado abrir.

Fontes