# Knight Capital: quarenta e cinco minutos, e um rollback que espalhou o defeito

> Uma corretora responsável por um décimo do volume de ações americano implantou código novo em sete dos seus oito servidores. O oitavo ainda guardava uma função morta desde 2005, ligada a uma flag que o código novo reaproveitara. Noventa e sete e-mails de aviso saíram antes de o mercado abrir. E quando os engenheiros entenderam o que acontecia, fizeram rollback - pondo o código defeituoso nos oito.

Source: https://ronutz.com/pt-BR/learn/knight-capital-and-the-rollback-that-made-it-worse  
Updated: 2026-09-09

---

## O cenário

O Knight Capital 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](https://ronutz.com/pt-BR/learn/ariane-5-and-the-assumption-that-expired) 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 SNMP, 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](https://ronutz.com/pt-BR/learn/the-target-breach) é 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](https://ronutz.com/pt-BR/learn/there-is-no-perfect-code) em sua forma mais crua, porque aqui o relógio já corria antes de o mercado abrir.

## Fontes

- [Securities and Exchange Commission dos Estados Unidos, comunicado sobre as acusações: o Knight Capital moveu um trecho de código em 2005 para um ponto anterior da sequência num roteador automatizado de ações, tornando uma função do roteador defeituosa; embora essa função não devesse ser usada, o Knight a deixou no roteador; no fim de julho de 2012, preparando-se para o Retail Liquidity Program da NYSE, o Knight implantou incorretamente código novo no mesmo roteador, de modo que certas ordens elegíveis dispararam a função defeituosa, que não conseguia reconhecer quando as ordens tinham sido preenchidas; nos primeiros 45 minutos após a abertura do mercado em 1º de agosto o roteador enviou mais de 4 milhões de ordens ao tentar preencher apenas 212 ordens de clientes, negociando mais de 397 milhões de papéis, adquirindo vários bilhões de dólares em posições indesejadas e sofrendo perda de mais de 460 milhões de dólares](https://www.sec.gov/newsroom/press-releases/2013-222)
- [Doug Seven, citando a ordem da SEC, Release n. 70694 de 16 de outubro de 2013: durante a implantação do código novo, um dos técnicos do Knight não copiou o código para um dos oito servidores SMARS; o Knight não teve um segundo técnico revisando a implantação e ninguém percebeu que o código Power Peg não fora removido do oitavo servidor, nem o novo código RLP acrescentado; o Knight não tinha procedimentos escritos exigindo tal revisão; nos primeiros 45 minutos o código Power Peg recebeu e processou 212 ordens-mãe, resultando em 4 milhões de transações contra 154 ações e mais de 397 milhões de papéis, cerca de 3,5 bilhões de dólares comprados em 80 ações e 3,15 bilhões vendidos em 74; o Knight tinha 365 milhões em caixa e levantou 400 milhões em 48 horas, sendo adquirido pela Getco em dezembro de 2012](https://dougseven.com/2014/04/17/knightmare-a-devops-cautionary-tale/)
- [Sobre o reaproveitamento da flag e os alertas: o novo código RLP reaproveitou uma flag antes usada para ativar a antiga funcionalidade Power Peg; durante a implantação iniciada em 27 de julho de 2012 um técnico deixou de copiar o código novo para um dos oito servidores, e a empresa não tinha procedimentos escritos de implantação nem exigência de revisão por pares; na manhã de 1º de agosto, a partir de aproximadamente 8h01 no horário do Leste - antes de o mercado abrir às 9h30 - o sistema interno do Knight gerou 97 mensagens automáticas de e-mail referindo-se ao SMARS e identificando um erro descrito como "Power Peg disabled"](https://soundofdevelopment.substack.com/p/the-knight-capital-disaster-how-a)
- [Profound, resumindo o processo de cessação da SEC: o código Power Peg não foi retestado depois de movido, para ver se a aplicação ainda funcionaria corretamente caso fosse utilizada; na instalação, o novo código RLP foi implantado em apenas sete dos oito servidores; o processo enfatizou que um segundo técnico não revisou a mudança e que não havia procedimentos estabelecidos exigindo tal revisão; em 45 minutos o SMARS produziu mais de 4 milhões de execuções em 154 ações representando mais de 397 milhões de papéis](https://www.profound-deming.com/blog-1/a-devops-automated-governance-story-knight-capital)
- [Sobre o rollback: o código depreciado vivia atrás de uma flag nos servidores de produção desde 2003, e os engenheiros que preparavam o suporte ao Retail Liquidity Program da NYSE reaproveitaram a mesma flag supondo que o Power Peg estava morto e a flag estava livre; a implantação foi manual e escalonada, com técnicos copiando o código para cada servidor, e um foi acidentalmente pulado sem que uma segunda pessoa verificasse; depois de os engenheiros perceberem que um servidor não fora atualizado, tentaram reverter todos os servidores para a versão antiga para recuperar consistência, mas a versão antiga ainda tinha a lógica do Power Peg ligada à flag reaproveitada, de modo que, em vez de isolar o problema num servidor, a reversão propagou o comportamento defeituoso para todos eles](https://www.ankur.blog/2025/05/the-460-million-mistake-that-crashed.html)