Knightmare: uma história de alerta para DevOps (2014)

• Artigo sobre a história de alerta da Knight Capital Group, uma importante empresa global de serviços financeiros, em 2012, um caso em que ela foi à falência em 45 minutos devido a uma implantação de software malsucedida.
• Em 2012, a Knight Capital Group era a maior negociadora de ações dos EUA, com volume médio diário de mais de 3,3 bilhões de operações e mais de US$ 21 bilhões negociados por dia.
• A empresa atualizou o SMARS, um roteador algorítmico automatizado de alta velocidade, enquanto se preparava para o lançamento do novo Retail Liquidity Program da NYSE.
• Essa atualização tinha como objetivo substituir um código antigo e sem uso chamado "Power Peg", que a Knight não utilizava havia 8 anos.
• O novo código foi implantado manualmente em 8 servidores, mas, por erro do técnico, o novo código não foi copiado para um dos servidores, fazendo com que o antigo código Power Peg fosse ativado.
• A funcionalidade Power Peg começou a encaminhar execuções de ordens filhas sem rastrear a quantidade de ações das ordens pai, causando um loop infinito de ordens.
• Quando o mercado abriu, o sistema da Knight inundou o mercado com ordens, fazendo com que algumas ações subissem mais de 10% em relação ao seu valor, enquanto outras caíram em resposta às negociações errôneas.
• O sistema da Knight enviou 97 mensagens automáticas de e-mail mencionando o SMARS e identificando o erro como "Power Peg disabled", mas elas não foram projetadas como alertas de sistema e não foram verificadas imediatamente.
• Nos 45 minutos após o início das negociações, o código Power Peg processou 212 ordens pai e executou 4 milhões de operações em 154 ações, tratando mais de 397 milhões de ações.
• A Knight Capital Group registrou uma perda de US$ 460 milhões em 45 minutos, o que a levou à falência. Ela levantou o capital necessário para cobrir as perdas por meio de um investimento de US$ 400 milhões de meia dúzia de investidores.
• O artigo enfatiza a importância de tornar as implantações totalmente automatizadas e repetíveis para evitar falhas desse porte, como parte de um plano de DevOps/Continuous Delivery.
• O autor sugere que lançamentos de software devem ser processos repetíveis e confiáveis e, sempre que possível, automatizados para reduzir o risco de erro humano.

[GN⁺]

Opiniões no Hacker News

• A implantação automatizada pode não ter evitado o problema e talvez até o tenha ampliado por causa de código incompatível.
• Sistemas de negociação automatizada devem ter um kill switch embutido, e ele deve ser testado regularmente para garantir seu funcionamento.
• Um sistema de implantação contínua talvez não tivesse bloqueado esse bug, que foi um erro lógico e levou a uma falha catastrófica.
• A expressão "dar uma de Knight Capital" é conhecida nas finanças quantitativas para descrever cortar caminho em sistemas importantes e depois enfrentar as consequências.
• Trading de alta frequência é um exemplo extremo de como as coisas podem dar errado rapidamente.
• Em sistemas que lidam com grande volume de vendas, é importante ter processos manuais, etapas de rollback e feature flags para mitigar riscos.
• O incidente da Knight Capital foi resultado de ignorar um sistema automático de SCRAM que interrompia todas as negociações ou alertava para intervenção manual.
• A existência de código morto na base de código por 8 anos indica risco e mostra falta de trabalho ativo de manutenção.
• Se configuração e binários tivessem sido lançados ao mesmo tempo, esse tipo de problema poderia ter sido evitado.
• Reutilizar flags antigas foi um erro grave e reforça a importância de práticas adequadas em implantações.