A Knights Tale Phil Factor Há tantas lições a serem aprendidas com a história de Knight Capital perder quase meio bilhão de dólares como resultado de uma implantação errada. O Knight Capital Group (KCG N) foi uma empresa americana de serviços financeiros globais envolvida na criação de mercado, execução eletrônica e vendas e negociações institucionais. De acordo com a recente ordem (File No.3.15570) contra Knight Capital por US Securities and Exchange Commissionacirc, Knight tinha, por muitos anos, usado algum software que quebrou as ordens 8220parent8221 recebidas em ordens 8220child8221 menores que foram então transmitidas para várias bolsas ou locais de negociação Para execução. Uma função tracking 8216cumulative quantity8217 contou o número de ordens 8216child8217 e parou o processo uma vez que o total de ordens filho correspondeu ao 8216parent8217 e assim a ordem pai tinha sido concluída. De volta à névoa do tempo, algum código tinha sido adicionado a ele que foi excuted se um determinado flag foi definido. Era chamado 8216power peg8217 e parece ter tido um design e propósito semelhantes, mas, uma suposição, teria compartilhado a mesma função de rastreamento. Este código tinha sido abandonado em 2003, mas nunca excluído. Em 2005, a função de rastreamento foi movida para um ponto anterior no processo principal. Parece do relato que, a partir desse ponto, se aquela bandeira tivesse sido definida, o velho 8216Power Peg8217 teria sido executado como Godzilla estourando do gelo, fazendo ordens infantis sem limite sem qualquer função de rastreamento. Ele wasn8217t, presumivelmente porque o software que definiu o sinalizador foi removido. Em 2012, quase uma década após a 8216Power Peg8217 ter sido abandonada, Knight preparou um novo módulo para seu software para lidar com o iminente Retail Liquidity Program (RLP) para a Bolsa de Valores de Nova York. Por esta altura, a bandeira tinha permanecido inutilizado e alguém tomou a decisão fatídica de reutilizá-lo, e substituir o antigo 8216power peg8217 código com este novo código RLP. Se as duas ações tivessem sido feitas em conjunto em uma única implantação automatizada, ea nova implantação testada, tudo teria sido bem. Não foi. 8220 Começando em 27 de julho de 2012, Knight implantou o novo código RLP em SMARS em etapas, colocando-o em um número limitado de servidores em SMARS em dias sucessivos. Durante a implantação do novo código, no entanto, um dos técnicos Knight8217s não copiar o novo código para um dos oito servidores de computador SMARS. Knight não tinha um segundo técnico revisar essa implantação e ninguém em Knight percebeu que o código Power Peg não havia sido removido do oitavo servidor, nem o novo código RLP adicionado. Knight não tinha procedimentos escritos que exigissem tal revisão.8221 (parágrafo 15) 8220O primeiro de agosto, Knight recebeu ordens de intermediários cujos clientes eram elegíveis para participar no RLP. Os sete servidores que receberam o novo código processaram essas ordens corretamente. No entanto, as ordens enviadas com a bandeira repurposed para o oitavo servidor acionado o código Power Peg defeituoso ainda presente nesse servidor. Como resultado, este servidor começou a enviar ordens secundárias para certos centros de negociação para execução. Como a função de quantidade cumulativa tinha sido movida, este servidor enviou continuamente ordens de filho, em sequência rápida, para cada ordem de entrada de pai, independentemente do número de execuções de ações que Knight já havia recebido de centros de negociação. Embora uma parte do sistema de tratamento de pedidos do Knight8217s reconhecesse que as ordens dos pais haviam sido preenchidas, essas informações não foram comunicadas à SMARS.8221 (parágrafo 16) A SMARS encaminhou milhões de ordens para o mercado ao longo de um período de 45 minutos e obteve mais de 4 milhões Execuções em 154 ações para mais de 397 milhões de ações. No momento em que Knight deixou de enviar as ordens, Knight tinha assumido uma posição líquida longa em 80 ações de aproximadamente 3,5 bilhões e uma posição líquida curta em 74 ações de aproximadamente 3,15 bilhões. As ações da Knight8217s caíram mais de 20 depois que os traders viram picos de volume extremos em várias ações, incluindo ações preferenciais da Wells Fargo (JWF) e da empresa de semicondutores Spansion (CODE). Ambos os estoques, que veem aproximadamente 100.000 trocas por dia, mudaram de mãos mais de 4 milhões de vezes no final da manhã. Em última análise, Knight perdeu mais de 460 milhões deste selvagem 45 minutos de negociação. Obviamente, estou interessado em tudo isso porque, ao mesmo tempo, eu costumava escrever sistemas de negociação para a cidade de Londres. Obviamente, os EUA SEC está em uma posição muito melhor do que qualquer um de nós para trabalhar as falhas do departamento de TI Knight8217s, eo relatório faz para a leitura dolorosa. Contudo, não posso deixar de observar que mesmo com os erros de tirar o fôlego ao longo do caminho, um processo robusto de implantação automatizada, que foi testado de sopa para nozes, teria evitado o desastre. O relatório lê como uma tragédia grega. Todo o caminho ao longo de um quer gritar 8216Não que way8217 e 8216Aargh Don8217t fazê-lo8217. À medida que a tragédia se desenrola, o público chora pelos jogadores, presos por um destino cruel. Todo o desenvolvimento e implantação de aplicativos exige uma defesa em profundidade. Tudo vai mal de vez em quando, mas se houver uma cultura de programação defensiva por toda parte, as conseqüências são geralmente contêmveis. Para sistemas financeiros, essas defesas são exigidas por estatuto, e ignorado apenas pelo tolo. Knight8217s erros weren8217t feita por apenas um infeliz sysadmin, mas foram erros progressivos por uma cultura de TI abrangendo pelo menos dez anos. Pode-se soletrar isso, mas acho que eles são óbvios. Só se pode esperar que a indústria estuda o que aconteceu em detalhes, aprende com os erros e tira as conclusões corretas. Subscrever para mais artigos boletins quinzenais ajudam a aguçar suas habilidades e mantê-lo à frente, com artigos, ebooks e opinião para mantê-lo informado. Artigos relacionados Também nos Blogs As novas tabelas temporais no SQL Server 2016 são interessantes, pois parecem uma maneira muito melhor de armazenar qualquer informação financeira do que tabelas relacionais convencionais. Eles foram referidos por alguns como 8220SQL Server8217s time machine8221. Eles são tabelas com versão do sistema que permitem que o SQL Server mantenha as diferentes versões de cada linha, usando hellip Leia mais cópia 2005 - 2017 Red Gate Software Ltd O que você acha do novo Simple Talk Dê-nos o seu software de feedbackZombie Blamed para Knight Capital Trading Snafu Uma notícia da Bloomberg News ontem derramou um pouco mais de insight sobre o que causou a incontrolada negociação eletrônica pelo mercado fazendo corretagem Knight Capital há algumas semanas. Parece que um programa de legado adormecido foi de alguma forma reativado quotinentemente. E depois interferiu com (ou assumiu) a negociação da empresa em 1 de agosto, quando um novo programa de comércio de software Knight tinha instalado começou a operar. Uma vez desencadeada em 1 de agosto, o sistema adormecido começou a multiplicar os negócios em ações por mil, disse Bloomberg por duas fontes anônimas que foram informadas sobre o assunto. Hmm, software morto torna-se reanimado, assume um sistema de computador e, em seguida, corre amok. Eu acho que eu vi esse filme em algum lugar. Além disso, de acordo com as fontes, a equipe de ldquoKnightrsquos olhou através de oito conjuntos de software antes de determinar o que aconteceu. Quase parece que havia um cemitério cheio de software morto pronto para ser reanimado. Infelizmente, o artigo não diz nada mais sobre como o software adormecido despertou e se interpôs quando se tratava de executar negócios que deveriam ser iniciados pelo novo software que Knight tinha instalado. Também não diz por que Knight iria manter ldquoeight conjuntos de softwarerdquo aparentemente residentes em seu ambiente de execução. Wersquoll provavelmente terá que esperar até que a SEC termine sua investigação para descobrir o que realmente aconteceu, bem como, presumivelmente, alguns detalhes suculentos sobre o desenvolvimento de software Knight e as práticas de teste do sistema. No entanto, o chamado "rastreamento" (entre outros) estimulou os reguladores da Ásia e da Austrália a diminuir o número de empresas comerciais de alta freqüência, informou o Financial Times nesta semana. Os reguladores estão lançando propostas abrangentes que exigiriam que os comerciantes tivessem controles sobre seus sistemas e os testassem anualmente para evitar a interrupção do mercado, segundo o jornal. Os reguladores querem controles de risco ldquopre-traderdquo no lugar para manter o comércio ldquoaberrantrdquo de acontecer, bem como ldquokill troca switchrdquo quando os controles de risco falhar. Em notícias relacionadas, o FT também informou que a falha recente na Bolsa de Valores de Tóquio foi rastreada para um mau ldquorouter em seu sistema de negociação de derivativos Tdex. rdquo Por razões ainda não explicadas, um roteador de backup não conseguiu chutar. Esta é a segunda vez Este ano que um sistema de backup TSE não chutar quando era necessário. Um problema de roteador também causou problemas durante várias horas ontem de manhã no Californiarsquos Departamento de Veículos Motorizados (DMV). De acordo com a Associated Press. Um problema com um roteador de estado da Califórnia causou o DMVrsquos computadores para se tornar desligado da rede statersquos de cerca de 0800 para meio-dia hora local, sem dúvida exasperar e irritar muitos clientes. De acordo com a estação de televisão CBS Sacramento. O DMV Califórnia pediu desculpas aos seus clientes através do Twitter 26 vezes sozinho desde fevereiro para dificuldades técnicas. A estação tem investigado sem muita sorte as paradas do DMV que aparentemente estão tomando o sistema para baixo com alguma regularidade desde 2007. Por coincidência, diversas outras agências de estado de Califórnia tiveram problemas de rede de computador ontem também, que o estado culpou em um ldquocircuit inexplicado reconfigurationrdquo problema . Esta questão não relacionada, os relatórios da AP, também foi corrigida no meio-dia de ontem. Finalmente, Manganese Bronze, a empresa que fabrica Londonrsquos táxi preto familiar, anunciou esta semana que ldquoit está atrasando a liberação de seus resultados semestrais não auditados para os seis meses findos em 30 de junho de 2012. devido à necessidade de reapresentar anos anteriores resultados financeiros porque De erros contábeis que vieram à luz. rdquo Os erros poderiam provavelmente ser rotulados erros relacionados com computadores, no entanto, ao invés de contabilidade. De acordo com um comunicado da empresa, em agosto de 2010, um novo sistema integrado de contabilidade de TI, que foi instalado para ajudar a gerenciar a empresa, ldquocomplex cadeia global de abastecimento, rdquo perdeu algumas transações chave durante o corte: ldquoDue a uma combinação de sistema e erros processuais , Um número de transacções relativas a 2010 e 2011 e alguns saldos residuais do sistema anterior não foram devidamente processados através do novo sistema de TI. Este problema levou à sobre-declaração de estoque e under-statement de passivos nas demonstrações financeiras de anos anteriores. rdquo Como resultado, a empresa subestimada por £ 3,9 milhões suas perdas históricas. Manganese Bronze tem estado sob forte pressão competitiva, ou em suas próprias palavras, ldquoTrading nos primeiros sete meses do ano tem sido difícil e continua a ser um desafio com o Grupo continuar a negociar em uma loss. rdquo Embora espera que a situação para eventualmente melhorar, A forte concorrência atual da Mercedes-Benz (que agora fornece quase um terço da frota de táxis de Londres) e alguns espera nova concorrência de Nissanrsquos táxis de baixa emissão de novos não pode ser um bom presságio para a saúde financeira futuro companyrsquos. O FT informou que o estoque de Manganês Bronze caiu 34 por cento sobre a notícia da atualização de resultados e agora só tem um valor de mercado de cerca de libra5 milhões. Versão em Português: http://www. polomercantil. com. br Fonte do artigo: http://pt. articlesnatch. com Sobre o autor: A Comissão de Valores Mobiliários e Câmbio anunciou hoje que Knight Capital Americas LLC concordou em pagar 12 milhões para liquidar as acusações que ele Violou a regra de acesso ao mercado de agencyrsquos em conexão com o firmrsquos 01 de agosto de 2012 incidente comercial que perturbou os mercados. Uma investigação da SEC descobriu que a Knight Capital não tinha garantias adequadas para limitar os riscos decorrentes do seu acesso aos mercados e não conseguiu impedir a entrada de milhões de ordens erradas. A Knight Capital também não realizou análises adequadas da eficácia de seus controles. Trata-se da primeira acção de execução da SECrsquos ao abrigo da regra de acesso ao mercado, adoptada em 2010 como regra 15c3-5. LdquoA regra de acesso ao mercado é essencial para proteger os mercados, e as violações de Knight Capitalrsquos colocam a empresa e os mercados em risco, disse Andrew Ceresney, co-diretor da SECrsquos Divisão de Execução. Devido ao rápido ritmo de negociação nos mercados de hoje e ao potencial impacto maciço das falhas de controle, os corretores devem ser mantidos em conformidade com os altos padrões de conformidade necessários para o funcionamento seguro e ordenado dos mercados. rdquo Daniel M. Hawke, SEC Divisão de Abuso de Mercado, adicionado, ldquoBrokers e negociantes devem olhar para cada componente em cada um de seus sistemas e perguntar-se o que aconteceria se o componente funciona mal e quais redes de segurança estão no lugar para limitar o dano que poderia causar. Knight Capitalrsquos falha em fazer essas perguntas teve conseqüências catastróficas. Segundo a ordem SECrsquos, Knight Capital fez dois erros críticos de tecnologia que levou ao incidente comercial em 01 de agosto de 2012. Knight Capital mudou uma seção de código de computador em 2005 para um Ponto anterior na seqüência de código em um roteador de eqüidade automatizado, tornando uma função do roteador defeituoso. Embora essa função não fosse usada, Knight a deixou no roteador. No final de julho de 2012, quando se preparava para a participação no NYSErsquos novo Retail Liquidity Program, a Knight Capital implantou incorretamente novo código no mesmo roteador. Como resultado, certas encomendas elegíveis para o programa NYSErsquos desencadeou a função defeituosa no roteador Knight Capitalrsquos, que foi então incapaz de reconhecer quando as encomendas tinham sido preenchidas. Durante os primeiros 45 minutos após o mercado abriu em 1 de agosto, o roteador Knight Capitalrsquos rapidamente enviou mais de 4 milhões de pedidos no mercado ao tentar preencher apenas 212 pedidos de clientes. Knight Capital negociou mais de 397 milhões de ações, adquiriu vários bilhões de dólares em posições indesejadas e, eventualmente, sofreu uma perda de mais de 460 milhões. A ordem SECrsquos também descobre que um sistema interno do Capital Knight gerou 97 e-mails automatizados que foram para um grupo de pessoal. Esses emails referenciaram o roteador e identificaram um erro antes que os mercados abrissem em 1 de agosto. Essas mensagens foram causadas pela falha na implantação do código, mas a Knight Capital não agiu em 1 de agosto. Alertas, eles forneceram uma oportunidade para identificar e corrigir o problema antes da abertura dos mercados. A ordem SECrsquos imputa à Knight Capital a violação da regra de acesso ao mercado das seguintes maneiras: Não dispunha de controles adequados em um ponto imediatamente anterior à sua apresentação de ordens ao mercado, como um controle para comparar ordens deixando o roteador com as entradas. Baseado em controles de risco financeiro que não eram capazes de impedir a entrada de ordens que excedessem os limites de capital pré-estabelecidos para a empresa no agregado. Não ligou a conta que recebeu as execuções em 1 de agosto para controles automatizados sobre a exposição financeira global da firma. Não dispunha de controles e procedimentos adequados para implantação de código e testes para seu roteador de pedidos de ações. Não dispunha de controles suficientes e procedimentos escritos para orientar os funcionários e responder a incidentes tecnológicos e de conformidade significativos. Não revisou adequadamente sua atividade comercial em conexão com seu acesso ao mercado para assegurar a eficácia geral de seus controles de gestão de risco e procedimentos de supervisão. Sua avaliação se concentrou principalmente na compilação de um inventário de controles existentes e garantindo que eles funcionassem conforme o esperado, em vez de se concentrar em tais riscos como possíveis falhas em seu roteador de pedidos automatizado. A empresa também reagiu a eventos anteriores de forma demasiado estreita e não considerou adequadamente as causas de origem de incidentes anteriores. Não dispunha de uma descrição escrita adequada dos seus controlos de gestão de risco. Não certificou em sua certificação anual de CEO de 2012 que os controles de gerenciamento de risco da Knight Capitalrsquos e os procedimentos de supervisão cumpriram a regra de acesso ao mercado. A ordem SECrsquo também imputa à Knight Capital violações das Regras 200 (g) e 203 (b) do Regulamento SHO, que exigem a devida marcação de ordens de venda a descoberto e localização de ações para contrair empréstimos para vendas a descoberto. A ordem SECrsquos exige que a Knight Capital pague uma penalidade de 12 milhões e retém um consultor independente para conduzir uma revisão abrangente dos controles e procedimentos da firma para garantir o cumprimento da regra de acesso ao mercado. Sem admitir ou negar as descobertas, Knight Capital concordou com a ordem SECrsquos, que censura a empresa e exige que ela cesse e desista de cometer ou causar essas violações. A investigação SECrsquos foi conduzida por pessoal da Unidade de Abuso de Mercado, incluindo Jason Burt, Carolyn Welshhans, William Max Hathaway e Ainsley Kerr. O caso foi supervisionado pelo Sr. Hawke eo co-adjunto de unitrsquos chefe Robert Cohen. O SECrsquos National Exam Program ea Divisão de Negociação e Mercados forneceram assistência substancial. Eu estava falando em uma conferência no ano passado sobre os tópicos de DevOps, Configuração como Código e Entrega Contínua e usou a seguinte história para demonstrar a importância de fazer implantações totalmente automatizadas E repetível como parte de uma iniciativa DevOpsContinuous Delivery. Desde aquela conferência, fui convidado por várias pessoas a compartilhar a história através do meu blog. Esta história é verdade que isso realmente aconteceu. Esta é a minha contar a história com base no que eu li (eu não estava envolvido neste). Esta é a história de como uma empresa com quase 400 milhões em ativos faliu em 45 minutos por causa de uma falha de implantação. Histórico Knight Capital Group é uma empresa americana de serviços financeiros globais que se dedica à criação de mercado. Execução eletrônica e vendas e negociações institucionais. Em 2012 Knight foi o maior trader em ações dos EUA com quota de mercado de cerca de 17 em cada NYSE e NASDAQ. O Grupo de Negociação Eletrônica Knights (ETG) gerenciou um volume de negociação médio diário de mais de 3,3 bilhões de negociações diárias, negociando mais de 21 bilhões de dólares diariamente. Isso não é brincadeira Em 31 de julho de 2012 Knight tinha aproximadamente 365 milhões em dinheiro e equivalentes. A NYSE estava planejando lançar um novo Programa de Liquidez de Varejo (um programa destinado a fornecer melhores preços para os investidores de varejo através de corretores de varejo, como Knight) em 1 de agosto de 2012. Na preparação para este evento Knight atualizou seus algoritmos automatizados de alta velocidade Roteador que envia ordens para o mercado para execução conhecido como SMARS. Uma das principais funções do SMARS é receber ordens de outros componentes da plataforma de negociação Knights (ordens dos pais) e, em seguida, enviar uma ou mais ordens filho para execução. Em outras palavras, SMARS receberia grandes encomendas da plataforma de negociação e quebrá-las em várias ordens menores, a fim de encontrar uma partida de comprador para o volume de ações. Quanto maior a ordem pai, mais ordens filho serão geradas. A atualização para SMARS destinava-se a substituir o antigo, código não utilizado como Power Peg funcionalidade que Knight hadnt usado em 8 anos (por que código que tinha sido morto por 8 anos ainda estava presente na base de código é um mistério, mas thats Não o ponto). O código que foi atualizado reutilizou uma bandeira antiga que foi usada para ativar a funcionalidade Power Peg. O código foi completamente testado e comprovado para funcionar correta e confiável. O que poderia ir mal O que poderia eventualmente ir errado De fato, entre 27 de julho de 2012 e 31 de julho de 2012 Knight manualmente implantado o novo software para um número limitado de servidores por dia oito (8) servidores em todos. Isto é o que o depósito SEC diz sobre o processo de implantação manual (BTW se houver um depósito SEC sobre sua implantação algo pode ter ido terrivelmente errado). Durante a implantação do novo código, no entanto, um dos técnicos Knights não copiar o novo código para um dos oito servidores de computador SMARS. Knight não tinha um segundo técnico revisar essa implantação e ninguém em Knight percebeu que o código Power Peg não havia sido removido do oitavo servidor, nem o novo código RLP adicionado. Knight não tinha procedimentos escritos que exigissem tal revisão. SEC liberação de registro No. 70694 16 de outubro de 2013 Às 9:30 AM Eastern Time em 1 de agosto de 2012 os mercados abriram e Knight começou a processar ordens de corretores em nome de seus clientes para o novo Programa de Liquidez de Varejo. Os sete (7) servidores que tiveram a implantação SMARS correta começaram a processar essas ordens corretamente. As ordens enviadas para o oitavo servidor acionaram a bandeira suposível repurposed e trouxeram de volta dos mortos o velho código Power Peg. Ataque do Zombies de Killer Code É importante entender o que o código de Power Peg morto foi feito para fazer. Esta funcionalidade destinava-se a contar o boughtsold partes contra uma ordem pai como ordens filho foram executadas. Power Peg instruiria o sistema a parar de rotear ordens filho uma vez que a ordem pai foi cumprida. Basicamente, Power Peg iria manter o controle das ordens filho e pará-los uma vez que a ordem pai foi concluída. Em 2005, Knight moveu essa funcionalidade de rastreamento cumulativo para um estágio anterior na execução do código (removendo assim o rastreamento de contagem da funcionalidade Power Peg). Quando a bandeira Power Peg no oitavo servidor foi ativada, a funcionalidade Power Peg começou a rotear ordens infantis para execução, mas não estava monitorando a quantidade de ações contra a ordem pai, como um loop infinito. 45 Minutos do Inferno Imagine o que aconteceria se você tivesse um sistema capaz de enviar ordens automatizadas de alta velocidade para o mercado sem qualquer rastreamento para ver se as encomendas tinham sido executadas. Sim, foi tão ruim assim. Quando o mercado abriu às 9:30 da manhã pessoas rapidamente sabia algo estava errado. Às 9h31 era evidente para muitas pessoas em Wall Street que algo sério estava acontecendo. O mercado estava sendo inundado com ordens fora do comum para volumes de negociação regulares em determinadas ações. Às 9:32 da manhã muitas pessoas em Wall Street estavam se perguntando por que não tinha parado. Esta foi uma eternidade em termos comerciais de alta velocidade. Por que alguém hadnt hit o kill-switch em qualquer sistema estava fazendo isso Como ele gira para fora não havia nenhum interruptor de matar. Durante os primeiros 45 minutos de negociação Knights execuções constituíram mais de 50 do volume de negociação, dirigindo certas ações acima de mais de 10 de seu valor. Em conseqüência outros estoques diminuíram no valor na resposta às trocas erradas. Para piorar as coisas, o sistema Knights começou a enviar mensagens de e-mail automatizadas mais cedo no dia tão cedo quanto 8:01 AM (quando SMARS tinha processado pedidos elegíveis para negociação pré-mercado). As mensagens de email referenciam SMARS e identificaram um erro como Power Peg desativado. Entre 8:01 AM e 9:30 AM havia 97 destes email enviados ao pessoal de Knight. Claro que esses e-mails não foram projetados como alertas do sistema e, portanto, ninguém olhou para eles imediatamente. Ups. Durante os 45 minutos do Inferno que Knight experimentou eles tentaram várias medidas de contador para tentar parar as negociações erradas. Não houve nenhum kill-switch (e nenhum procedimento documentado para como reagir), então eles ficaram tentando diagnosticar o problema em um ambiente de negociação em que 8 milhões de ações estavam sendo negociadas a cada minuto. Como eles não conseguiram determinar o que estava causando as ordens erradas, eles reagiram desinstalando o novo código dos servidores nos quais ele foi implantado corretamente. Em outras palavras, eles removeram o código de trabalho e deixaram o código quebrado. Isso só amplificou os problemas causando pedidos pai adicionais para ativar o código Power Peg em todos os servidores, e não apenas aquele que não foi implantado corretamente. Eventualmente eles foram capazes de parar o sistema após 45 minutos de negociação. Nos primeiros 45 minutos o mercado estava aberto o código Power Peg recebeu e processou 212 ordens dos pais. Como resultado, SMARS enviou milhões de ordens infantis para o mercado resultando em 4 milhões de transações contra 154 ações por mais de 397 milhões de ações. Para viciados em mercado de ações isso significava que o Cavaleiro assumiu aproximadamente 3,5 bilhões de posições longas líquidas em 80 ações e 3,15 bilhões de posições líquidas em 74 ações. Em termos laymen8217s, Knight Capital Group realizou uma perda de 460 milhões em 45 minutos. Lembre-se, Knight só tem 365 milhões em dinheiro e equivalentes. Em 45 minutos, Knight passou de ser o maior trader em ações dos EUA e um grande fabricante de mercado na NYSE e NASDAQ a falência. Eles tinham 48 horas para aumentar o capital necessário para cobrir suas perdas (o que eles conseguiram fazer com um investimento de 400 milhões de cerca de meia dúzia de investidores). A Knight Capital Group foi finalmente adquirida pela Getco LLC (Dezembro de 2012) ea empresa resultante da fusão passou a ser denominada KCG Holdings. Uma lição para aprender Os eventos de 1 de agosto de 2012 devem ser uma lição para todas as equipes de desenvolvimento e operações. Não é suficiente para construir um grande software e testá-lo você também tem que garantir que é entregue ao mercado corretamente para que seus clientes recebem o valor que você está entregando (e assim você não falir sua empresa). O engenheiro (s) que implantou SMARS não são apenas a culpa aqui o processo Knight tinha criado não era adequado para o risco que foram expostos. Além disso, o seu processo (ou falta dele) era inerentemente propenso a erros. Sempre que seu processo de implantação depende de seres humanos lendo e seguindo instruções, você está se expondo a riscos. Os seres humanos cometem erros. Os erros poderiam estar nas instruções, na interpretação das instruções, ou na execução das instruções. As implementações precisam ser automatizadas e repetíveis e livres de possíveis erros humanos quanto possível. Se Knight implementasse um sistema de implantação automatizado completo com configuração, implantação e automação de teste, o erro que causaria o Knightmare teria sido evitado. Alguns dos princípios para a Entrega Contínua aplicam-se aqui (mesmo se você não estiver implementando um processo de Entrega Contínua Completa): Liberar o software deve ser um processo repetível e confiável. Automatize tanto quanto é razoável. Um cenário: vamos supor que eles tinham muito bom DevOps. Portanto, todos os servidores estarão sincronizados. Mas 8211 assumem que o novo código tinha um bug. Assim, todos os servidores estão em sincronia, mas têm o mesmo código buggy. E se duas versões do código, ou seja, as últimas 2 implementações tivessem esse bug. Então, uma vez que eles percebem que algo está errado, they8217d reverter o código, o bug ainda stays8230 Minutos preciosos passaram. Talvez 20 minutos em vez dos 45 minutos em seu artigo. Assim, em curto 8211 seu desastre kill-switch é uma implantação de rollback de código em um ambiente ao vivo. Isso ainda seria um projeto defeituoso. O que eles precisariam seria um grande interruptor vermelho (quase literalmente, em algum lugar em seu painel) para parar imediatamente. Onde está a regra de negócios que diz 8220não faça primeiro nenhum mal8221. VJ se a implantação para todos os servidores tinha funcionado, eles teriam sido ok. Mas, neste caso, 7 de 8 para um subsistema foram implantados corretamente. Devido ao mau comportamento, eles reverteram os outros 7 pensando que o novo código nesse subsistema era o problema. Isso multiplicou o problema até o eventual interruptor de matar. Os desastres são quase sempre complexos. Nesse caso, eram práticas de codificação deficientes, além de práticas de inspeção de códigos de teste questionáveis, além de um erro na implantação, além de uma reversão na granularidade do subsistema em vez de todo o sistema. Se você resolver qualquer desses problemas, você não terá um desastre. Uma das coisas que foram vistas em empresas que não reconhecem a verdadeira importância e impacto de seus sistemas de TI é que elas não fornecem orçamento para atualizações de código legado. Por exemplo: Já vi situações em que a TI não tem orçamento. Tem de justificar tudo o que faz contra uma despesa de negócio. O que significa constantemente lutando para alinhar novos projetos. Negócios raramente vê a necessidade de atualizar software antigo que está funcionando atualmente, então eles se recusam a pagar por ele. O resultado é um novo código constante, feito pelos codificadores mais baratos possíveis, sem investir em tecnologias que, em última instância, melhorariam o desempenho e mitigariam os riscos. Porque Porque estes são vistos como 8220IT problemas8221 e não o purview de qualquer projeto que as pessoas de TI estão trabalhando, então ninguém vai pagar por isso. Uma grande leitura sobre esta prática é o projeto de Phoenix por Gene Kim, Kevin Behr, e George Spafford. Obrigado por aplicar o cérebro para o hype. Provavelmente, deve-se perguntar por que os técnicos envolvidos chegaram a assumir a culpa, mas não conseguiram autoridade para matar o interruptor por conta própria. Oh direito, that8217s porque você pôs OpsSRE no lugar de qualquer maneira. 8220R8221 é responsável, aka isca de chama. Escrevi um pouco sobre esse evento e gostaria de alertar alguém para usar o relatório da SEC como qualquer outra coisa senão para o que a SEC precisava. Kitchensoap20131029counterfactuals-knight-capital Fascinante ler. Eu trabalhei em uma grande casa de leilões de frutas e legumes, uma vez que uma nova versão de software foi instalado e falhou, levando a grandes perdas para os comerciantes (embora não tão grande como estes). Este também foi um caso de implantação imprópria e não fall-back. A lição a ser aprendida é que existem domínios onde o computador não deve tomar qualquer decisão sem validação humana. O que acontece com as pessoas que perderam seus empregos porque, oops, havia um bug E sobre as outras empresas que talvez entrou em trubble por causa da mudança súbita do valor da ação Automation of 8220high level decisions8221 deve ser tratado com cuidado8230 Nice e pós educacional Btw. Usando o quadro Cynefin fornece uma melhor caracterização desta falha 8216DevOps8217 Este post parece ter sido escrito a partir de uma perspectiva DevOps. As soluções sugeridas são consistentes com uma perspectiva de DevOps 8211 examinar o processo de liberação, automatizar mais e criar um interruptor de matar com recursos de reversão. Alguém pode ler o post e colocar muita ênfase no técnico Knight que não copiar o código antigo para um dos oito servidores. Alguém pode simplificar demais uma relação de causa e efeito. 8211 Aumentar a diversidade para analisar a situação e sintetizar melhores opções 8211 Melhorar a comunicação entre especialidades 8211 Melhorar a coordenação implícita entre especialidades 8211 Recrutar indivíduos com mais Especialização para escrever e rever o código Um fator importante que limitou a melhoria da capacidade da equipe de nove anos antes do evento de falha significativo foi mis-caracterização do sistema. In a Cynefin framework, confining this failure to a DevOps problem is associating the system with the 8220Obvious8221 domain where there are simple cause and effect relationships that are recognizable by 8216professionals.8217 The failure should not be associated with the Cynefin 8220Complicated8221 domain where a significant analysis by 8216specialists8217 would have prevented the failure. The system should be associated with the Cynefin 8220Complex8221 domain 8211 a complex adaptive system. The system is dispositional. The same initial conditions will not produce the same failure (except by accident). For more information about Cynefin, visit en. wikipedia. orgwikiCynefin and CognitiveEdge. I appreciate your highlighting the tacit factors in such a catastrophe. Like the author, I also work in operations, and it8217s easy to fall into the same old thought patterns on causes and solutions. I particularly enjoy your point relating to diversity (Which comes in all forms: experience levels, cultural and educational backgrounds, skillsets, age, etc.), as I think this is a strong driver behind the success of DevOps itself. Having a variety of perspectives, both within and without your team, looking at your project has strong, demonstrable potential and can help curb oversights such as the one brought up in this article. gt why code that had been dead for 8-years was still present in the code base is a mystery, but thats not the point On the contrary, that8217s exactly the point. Code with unused, and therefore untested, configuration possibilities is a disaster waiting to happen. This is why I8217m very sceptical about feature-flag-based approaches generally. Configuration is as much a part of your program as code is, and configuration changes should go through the same lifecycle 8211 pull request, code review, release, deploy to staging 8211 as any other change. If your release process is too heavy and you need to make fast config changes to production, fix your release process. There were too many mistakes to attribute the epic failure to just DevOps (though I do fully agree that automation and testing is the only way): 8211 No teamwork and checklists while doing an update on production servers. Any update on production should require a team watching over each other, and going through a checklist. 8211 8 years of unused old code in production. That tells you a lot about the lack of understanding about the risks of dangling 8220unused8221 code. 8211 Insufficient logging from the code, and insufficient real-time log monitoring, correlation and analysis. That would have triggered enough clues early one to the engineers and ops folks. 8211 No hot-hot failover to a cluster with the previous version. That would have stopped all issues after 1 or 2 minutes. (That8217s the bug red button that the article mentions) If you also have been architecting software, systems and enterprises for a long time, you know disaster happens, you know some bugs are only caught in the wild and not during simulations, just like you know machines will go down. You need to prepare for the worst case in both scenarios. Murphy8217s Law is so true in our world I8217ve been in what is now called the 8220DevOps8221 space for nearly 20 years, over half of that in the financial world. Knight was both a vendor to and a competitor of the company I currently work for. Deployment automation might have helped. Talvez. But few companies can afford exactly duplicate environments, and this was essentially caused by environmental differences. Even automated validation of deployment might not have helped in this case if the automation didn8217t know about the environmental difference. Automation is only as good as the knowledge of the people setting it up. If a manual install wasn8217t aware of the old system, then there8217s a good chance the automated system wouldn8217t have known to check for it either. Automation of a rollback is also only as good as the decision-making on whether to make the roll-back. And if the automation inadventently started the old system, there8217s also no guarantee that switching the contemporary system back would have stopped the old system 8211 you could have ended up with the same problem even after an automated rollback of the contemporary system. Which brings me to a final point: Automation is a requirement in large, modern, environments. But over-reliance on it can lead to the people operating the system being unaware of what it8217s doing. Automation is most useful for validations, because validating things are done correctly is tedious and easy to skimp on when done manually. Even when automating, having human-involved breakpoints or human-driven steps helps insure that those operating the system know the system and how it operates, greatly improving their ability to troubleshoot issues, diagnose problems, and make appropriate suggestions on what steps to take to stop or mitigate a problem. Automation is a tool, but it is only one tool and it still requires a craftsman to wield it appropriately. Expertise is what makes and keeps great systems great. Reblogged this on Garrett S. Y. Hampton and commented: Incredible. DevOps always watch, document, and review your deployments
No comments:
Post a Comment