1066, mais de 200 anos se passaram desde o início da invasão viking da Inglaterra. O rei Harold, colecionando um destacamento de cavaleiros, marchou para o rio Derwent para uma batalha decisiva com as tropas de seu homônimo - o rei norueguês Harald. Os armeiros trabalharam por um mês para forjar armaduras de nova geração suficientes que pudessem proteger o cavaleiro de ser atingido por um machado escandinavo. E quantas experiências e testes em torneios haviam sido antes! Mas a expectativa deveria ter se justificado - equipamentos leves, porém confiáveis, permitiam, mesmo a pé, sem grandes perdas, dispersar o pássaro Viking. E, finalmente, eles se conheceram em Stamford Bridge. O principal destacamento de cavaleiros, liderado por um comandante de armadura brilhante, colidiu no meio de uma ponte com inimigos. Sim, o aço dos mestres podgorny aguenta o soco!
Lenta mas seguramente, os vikings estão se movendo para uma defesa round-robin. A vitória parece estar próxima. E finalmente, no campo de batalha, o comandante do cavaleiro e o jarl norueguês se encontram.
O machado do jarl de duas mãos já está quebrado e ele é forçado a se defender com um saxão comum, que não pode ser comparado a um cavaleiro e meia espada. Uma onda com uma adaga - para a armadura do comandante é como um canivete, mas passa através da armadura e ... parece que a magia entrou em jogo - a armadura dos cavaleiros vizinhos está espalhada! Outra onda, novamente no alvo, e agora nos cavaleiros do flanco esquerdo a armadura brilha de repente em brasa. O terceiro golpe - os cavaleiros nadam diante de seus olhos, tropeçam, caem e nunca mais se levantam.
"*** ** **** ****!" Gritou Petrovich, acordando às 5 da manhã de segunda-feira suando frio. Tudo deu errado: às 11 da noite, ele subiu à Wikipedia em busca de materiais para o relato da criança sobre a natureza da tundra, mas na hora da noite, de alguma forma, se viu na descrição da invasão viking da Inglaterra. E também, no fim de semana, eles colocam em batalha o próximo lançamento, que deve começar hoje. Como sempre, nós o testamos por um longo tempo e minuciosamente, conduzimos através de sistemas de integração contínua um milhão de vezes, se tudo corre bem ...
Felizmente para alguns, mas infelizmente para as vítimas, sempre há a oportunidade de aprender com os erros dos outros, de melhorar algo em casa e obter uma porção extra de confiança. Com este artigo traduzido, queremos mais uma vez, com mais detalhes, relembrar um dos casos no "nosso" setor.
No ano passado, na conferência, falei sobre DevOps, configuração como código e entrega contínua. Usando a história abaixo, expliquei a importância de criar implantações totalmente automatizadas e reproduzíveis como parte da iniciativa DevOps / Entrega Contínua. Após a conferência, várias pessoas me pediram para compartilhar uma história em um blog. Esta é uma história absolutamente verdadeira. Esta é uma recontagem do que li, eu mesmo não participei disso.
Portanto, a história de como uma empresa com ativos de quase US $ 400 milhões faliu em 45 minutos devido a uma implantação malsucedida.
Um pouco de fundo
O Knight Capital Group ("Knight" em inglês significa "cavaleiro") é uma empresa financeira global americana envolvida em criação de mercado, execução eletrônica, vendas e negociações institucionais. Em 2012, Knight era o maior negociador de ações dos Estados Unidos, com uma participação de mercado de cerca de 17% na NYSE e NASDAQ. O Electronic Trading Group (ETG) da Knight gerenciava um volume médio diário de mais de 3,3 bilhões de transações por dia, negociando mais de US $ 21 bilhões ... por dia. Isso não é uma piada!
Em 31 de julho de 2012, a Knight possuía aproximadamente US $ 365 milhões em dinheiro e equivalentes.
Em 1º de agosto de 2012, a NYSE planejava lançar um novo programa de liquidez de varejo, o Retail Liquidity Program (um programa projetado para melhorar os preços para investidores de varejo por meio de corretores de varejo, como Knight). Em preparação para este evento, a Knight atualizou seu roteador algorítmico automatizado, de alta velocidade, SMARS, que envia aplicativos ao mercado para execução. Uma das principais funções do SMARS é receber aplicativos de outros componentes da plataforma de negociação Knights (aplicativos "pais"), seguidos pelo envio de um ou mais aplicativos "filhos" para execução. Em outras palavras, a SMARS receberá grandes pedidos da plataforma de negociação e os dividirá em vários pequenos para encontrar um comprador / vendedor de ações. Quanto maior o aplicativo pai, mais aplicativos filhos serão criados.
A atualização do SMARS deveria substituir o código antigo e não usado chamado “Power Peg” - essa funcionalidade que Knight não usava há 8 anos (por que o código que estava morto por tanto tempo ainda estava na base de códigos é um mistério, mas essa não é a principal). O código atualizado reatribuiu o sinalizador antigo usado para ativar a funcionalidade Power Peg. O código foi completamente testado, funcionou corretamente e era confiável. O que poderia ter dado errado?
O que poderia ter dado errado? E realmente!
Entre 27 de julho de 2012 e 31 de julho de 2012, a Knight implantou manualmente novo software em um número limitado de servidores por dia - um total de oito (8) servidores. Aqui está o que o
documento da
SEC diz sobre a implantação manual (a SEC é a Comissão de Valores Mobiliários, o órgão regulador americano do mercado de ações).
“Durante a implantação do novo código, um dos funcionários da Knight não copiou o novo código para um dos oito servidores SMARS. Knight não conduziu uma segunda revisão técnica dessa implantação; portanto, o código do Power Peg não foi excluído do oitavo servidor e o novo código RLP não foi adicionado. A empresa não possuía procedimentos que exigissem reexame. ” Versão nº 70694, 16 de outubro de 2013
Em 1º de agosto de 2012, às 21h30, EST, os mercados foram abertos e a Knight começou a processar solicitações de corretoras em nome de seus clientes no novo Programa de Liquidez do Varejo. Sete (7) servidores implantados corretamente começaram a processar aplicativos corretamente. E os aplicativos que foram para o oitavo servidor provavelmente ativaram o sinalizador alterado e ressuscitaram o Power Peg.
Zombie Attack: Killer Code
Aqui você precisa explicar por que o código Power Peg "morto" foi necessário. Essa funcionalidade foi projetada para contar as ações compradas / vendidas mediante solicitação dos pais, à medida que os pedidos da criança são concluídos. Depois que o aplicativo pai é executado, o Power Peg proíbe o envio de aplicativos filhos. Em princípio, o Power Peg rastreará os pedidos filhos e interromperá sua execução após o processamento do aplicativo pai. Em 2005, Knight reverteu essa funcionalidade de rastreamento cumulativo para um estágio anterior da execução do código (removendo assim o rastreamento de quantidade do Power Peg).
Quando o sinalizador Power Peg no oitavo servidor foi ativado, o Power Peg começou a rotear ordens filho para execução, mas não as correlacionou com o número de compartilhamentos na ordem pai - um tipo de loop fechado surgiu
Infernal 45 minutos
Imagine: você tem um sistema que pode enviar aplicativos automáticos de alta velocidade ao mercado sem nenhum rastreamento e a capacidade de verificar se aplicativos suficientes foram concluídos. Sim, tudo ficou tão ruim.
Quando o mercado abriu às 9h30, as pessoas rapidamente perceberam que algo estava errado. Às 9:31 da manhã, muitos em Wall Street perceberam que algo sério estava acontecendo. O mercado foi inundado por ofertas com um volume incomum, comparado com a situação normal, ao volume negociado de determinadas ações. Às 9:32 em Wall Street, eles se perguntavam por que essa desgraça não para. Quase sempre em negociações de alta velocidade. Por que alguém não clicou no botão kill no sistema que fez isso? Como se viu, não havia interruptor. Durante os primeiros 45 minutos de negociação, a execução de transações da Knight atingiu mais de 50% do volume negociado, aumentando algumas ações em mais de 10% do seu valor. Como resultado, outras ações caíram de valor devido a transações incorretas.
E para piorar a situação, o sistema Knight começou a enviar e-mails automatizados mesmo antes desses eventos - já às 8:01 da manhã (quando a SMARS processava pedidos adequados para negociação antes do mercado). Nas mensagens, o sistema se referia ao SMARS e mostrava o erro "O Power Peg não está disponível". Entre 8:01 e 9:30, 97 cartas foram enviadas aos funcionários da Knight. Obviamente, essas cartas não pareciam avisos do sistema, então ninguém as olhou imediatamente. Ai.
Por 45 minutos infernais, Knight tentou parar a transação errônea. Não foi possível desligar o sistema (como não havia procedimentos documentados para responder a essa situação), portanto, tentando lidar com o problema em condições de negociação ao vivo, eles permaneceram no mercado, onde foram vendidas 8 milhões de ações a cada minuto. Como os funcionários da empresa não conseguiram determinar de onde os aplicativos errados vieram, eles removeram o novo código dos servidores em que foram implantados corretamente. Em outras palavras, eles excluíram o código de trabalho e foram quebrados. Isso só exacerbou os problemas que causavam solicitações adicionais dos pais para ativar o código do Power Peg em todos os servidores, e não apenas onde o código foi originalmente implantado incorretamente. No final, consegui parar o sistema - após 45 minutos de negociação.
Enquanto as negociações estavam em andamento, o código do Power Peg recebeu e processou 212 solicitações dos pais. Como resultado, a SMARS enviou milhões de subsidiárias ao mercado, completou 4 milhões de transações em 154 transações com mais de 397 milhões de ações. Para os conhecedores do mercado de ações, isso significou que a Knight comprou ações de 80 empresas diferentes por US $ 3,5 bilhões e vendeu ações de 74 empresas por US $ 3,15 bilhões.No ponto de vista de não profissionais, o Knight Capital Group perdeu US $ 460 milhões em 45 minutos. Mas Knight tem apenas US $ 365 milhões em dinheiro e equivalentes. Em 45 minutos, Knight se transformou do maior negociador de ações americanas e um dos principais formadores de mercado da NYSE e NASDAQ em falência. Eles tiveram 48 horas para coletar o valor necessário para cobrir as perdas (o que puderam fazer graças a um investimento de US $ 400 milhões de cerca de meia dúzia de investidores). Por fim, o Knight Capital Group foi adquirido pela Getco LLC (em dezembro de 2012) e agora a empresa combinada se chama KCG Holdings.
Que conclusões você precisa tirar
Os eventos de 1º de agosto de 2012 devem ser uma lição para todas as equipes de desenvolvimento e equipes de projeto. Não basta criar um ótimo software e testá-lo; Você também precisa garantir que ele seja entregue corretamente ao mercado para que seus clientes recebam exatamente o valor que você fornece (e que você não irá à falência da sua empresa). O (s) engenheiro (s) que implantaram o SMARS não são os únicos responsáveis pelo fato de que o procedimento seguido na Knight não levou em consideração os riscos. O procedimento (ou a sua ausência) foi obviamente errado. Sempre que o processo de implantação depende de como as pessoas leem e seguem as instruções, você se coloca em risco. As pessoas cometem erros. Os erros podem estar nas instruções, na interpretação das instruções ou na sua implementação.
O layout deve ser automatizado, reproduzível e o mais livre possível de erros humanos. Se a Knight tivesse implementado um sistema de implantação automatizado - um conjunto de configurações, implantação automática e teste -, o erro que se transformou no pesadelo de Knight poderia ter sido evitado.
Aqui estão alguns princípios de entrega contínua (mesmo que você não implemente o processo completo de entrega contínua):
- A liberação do software deve ser um processo repetível e confiável.
- Automatize tudo o que puder.