Economia de 300 + um erro igual multas milionarias

PlanejamentoPlanejar é preciso em todas as áreas, seja da vida pessoal ou profissional, pois do contrario não temos como nos preparar para as ocorrências e percalços do caminho e nem entendermos se os resultados encontrados são aqueles que realmente queremos. Nesse artigo irei mostrar a historia real de onde uma economia de 300 Libras anualmente gerou uma multa de mais de 100 milhões de Euros a um banco e criou a possibilidade de derrubar todo o sistema monetário do planeta.

Planejar segundo o dicionário Michaelis: “Ato de projetar um trabalho, serviço ou mais complexo empreendimento. Determinação dos objetivos ou metas de um empreendimento, como também da coordenação de meios e recursos para atingi-los; planificação de serviços. Dependência de uma indústria ou repartição pública, com o encargo de planejar serviços.”.

O texto abaixo é uma tradução livre minha de um artigo do Zerohedge, que por sua vez se baseou em outro artigo do b3ta, onde é contada a historia onde uma economia de 300 Euros em licenças anuais por parte de um banco gerou multas milionárias ao mesmo e a quase quebra do sistema monetário mundial.

T.I é um campo minado para erros caros

Há tantas maneiras diferentes de cometer um erro. O melhor que você pode esperar quando se trabalha em uma função de suporte é ser invisível. Se alguém notar a sua equipe de suporte trabalhando, pode ter certeza que é porque alguém cometeu um erro. Trabalhei em três grandes bancos de investimento, mas no primeiro eu presenciei um dos erros mais impressionantes que eu vi em toda minha carreira. Eu era parte da equipe de suporte da área de vendas e comercio, mas por agradecidamente não fui eu que cometi esse grave erro de julgamento.

(Irei aprofundar em níveis de detalhes específicos para adicionar contexto aqui se você estiver interessado, do contrario pode pular para próxima parte)

Esse banco havia sido pioneiro em um processo chamado stright-throught processing (STP) que removia o processo manual normal de verificação dos investimentos. Investimentos feitos no mercado global tipicamente tem um período de verificação de cinco dias para permitir que toda a papelada e contabilidade seja feita. Esse elaborado sistema permitia que essa verificação fosse feita no mesmo dia do investimento, algo que não fora possível anteriormente. O banco alcançara essa capacidade após um período de seis anos desenvolvendo um sistema com tal grau de complexidade para rivalizar com a SkyNet. Em 2006 ele possivelmente já tinha poder de processamento suficiente para se tornar consciente, e os requisitos de armazenamento eram colossais. Era consistido por centenas de servidores de ultima geração, diversos servidores de banco de dados dos mais avançados avaliados em milhões de libras esterlinas e o projeto tinha mais de 300 funcionários só para manter-se no ar. Para por isso em perspectiva, o armazenamento só desse sistema (um de 500 sistemas de grande porte de comercio neste banco) representava 80% do total de armazenamento dentro da empresa. O equivalente a centenas de DVDs de dados puros entrava o banco de dados diariamente conforme ele lidava com mais de um milhão de transações entre os bancos, cada uma com valores de iam de algumas centenas de dólares até aquelas de vários bilhões de dólares. Esse negocio era GRANDE.

Você deve imaginar que um sistema tão importante e caro iria rodar na melhor tecnologia de redundância tanto de hardware quanto de software. Infelizmente, ele havia crescido de uma maneira orgânica pelos anos, com pequenas partes sendo adicionadas aqui e ali e em todo o lugar. Havia partes do sistema que ninguém entendia mais, pois os desenvolvedores originais haviam mudado de empresa, emigrados ou morrido sem documentar seu trabalho (grifo meu). Eu duvido que eles houvessem previsto em que esse monstro iria se tornar eventualmente.

Um colega meu decidiu um dia fazer uma alteração durante o expediente sem autorização, o que era idiota, mas não incomum. Era uma mudança trivial para adicionar ainda mais armazenamento e ele já tinha feito isso diversas vezes e estava confiante. O cara estava apenas tentando ser prestativo para os desenvolvedores, que estavam sob constante pressão para manter o maldito sistema funcionando enquanto ele ficava mais inchado a cada dia, uma versão eletrônica do Sr Creosote.

Conforme meu colega aplicava a mudança naquela manhã, ele ativou um bug em um script reconhecidamente ruim que era responsável por colocar os novos discos de armazenamento online. O script havia sido feito internamente já que isso iria poupar ao banco cerca de 300 libras por ano em licenciamento para os agentes de armazenamento do fornecedor. Dinheiro esse, pensando agora, que talvez tive-se sido melhor gasto do que economizado. O código caseiro deu uma olhada na nova configuração e imediatamente enlouqueceu. Esse amontoado de texto malfeito em ‘alguma linguagem nerd’ havia decidido que a melhor atitude naquele momento era desligar o sistema de produção completamente e ativar o sistema de recuperação em desastres (Disaster Recorver – DR), o que é um processo normal quando se detecta uma falha ‘catastrófica’. Ele é projetado para colocar em funcionamento o lado que estiver funcionando adequadamente do sistema o mais rápido possível. Infelizmente, por esse sistema ser de redundância completa em ambos os lados (para [aham] garantir uma recuperação sem falhas), o mesmo bug entrou em ação quase que imediatamente no lado do DR também, então em menos de um minuto, o maldito script havia derrubado todo o sistema da mesma maneira que enfiar um espanador em um motor funcionando pode parar um carro. O banco de dados, como sempre, estava gravando seus preciosos dados em diversos discos enquanto isso acontecia, então uma grande quantidade de dados foi perdida irreversivelmente. Então era isso, o maior sistema no banco, talvez no mundo, estava fora do ar.

E ele não voltaria ao ar rapidamente

(OK, fim dos detalhes técnicos)

No momento em que essa falha ocorria havia mais de $12 TRILHÕES em transações em vários estágios de verificação no sistema. Isso representava por volta de 20% de TODAS as transações no mercado global de ações, já que outros bancos haviam se conectado nesse mamute e usando suas capacidades. Se essas transações não fossem concretizadas dentro do período contratado, o banco iria ser multado por cada uma delas, e os valores resultantes dessas multas seriam maiores que o valor de mercado da empresa, e por isso ela sairia do mercado. Simples assim.

Minha equipe largou tudo o que fazia e gastou 4 horas sólidas e brutais recuperando cada componente do sistema em uma tentativa desesperada de fazer o teimoso sistema ficar operante novamente. Depois de um curto período, o chefe do Banco Central Europeu estava em uma ligação de crise com o CEO da nossa empresa, exigindo uma atualização sobre o porquê de tantas transações estarem dando erro naquele dia. Aparentemente (conforme nos foi dito depois), o volume financeiro contido dentro daquela besta era tão grande que uma falha para completar as transações teria um valor negativo significante no valor do Euro. Essa cagada sozinha quase começou uma crise econômica global numa escala semelhante a recente crise do credito sub-prime. Com duas horas para o limite em que o Banco Central Europeu teria que ir a publico e ajustar o valor do cambio do Euro para compensar, o sistema voltou ao ar, mas apenas suficientemente. Cada um de nós operava um sub-componente critico e direcionamos todos os recursos para os processadores de transações. Os desenvolvedores configuraram o sistema para priorizar as transações por valor. Tudo mais nesses servidores foi desligado para garantir que cada ciclo de CPU e operação de disco pude-se ser utilizada. Isso saturou essas maquinas com processamento enquanto nós apenas observávamos tudo em silencio, incapazes de influenciar no resultado de tudo aquilo.

Incrivelmente, a maior parte das transações de alto valor foi liberada antes do horário limite, e o desastre foi evitado por uma margem menor que um fio de água. Apesar de tudo isso, as transações restantes de baixo valor ainda custaram mais de $100 milhões em multas. Até esse dia poucas pessoas realmente entendem a real origem dessas penalidades no relatório anual dos acionistas da empresa. A reputação é o rei no mundo bancário e todos os envolvidos – incluindo eu – foram orientados de maneira bem explicita a manterem os bicos fechados. Naturalmente eu não “posso” identificar o banco em questão, mas se você ainda estiver curioso, me gaz e eu vou te apontar na direção correta…

Epilogo… O banco comprou os scripts corretos rapidamente, mas o pobre infeliz que começou toda essa confusão foi mandado embora no dia seguinte em uma cerimônia de apontamento de culta, o que foi muito injusto já que todo o problema foi causado pela programação mal feita do script. A empresa decidiu que todo incêndio precisa de uma fagulha para começar, e ele seria o bote expiatório da vez. Essa foi uma das maiores razões pela qual eu decidi sair da empresa (mas não antes de dar uma bela envergonhada no gerente global de tecnologia durante a festa de natal). Até hoje meu colega ainda é uma das únicas pessoas que entende a maior parte daquele sistema de computadores metidos a besta, então ele conseguiu seu emprego de volta em menos de seis meses – mas com um salário melhor do que antes 😉

Conclusão: a maior parte dos bancos é insana e eles nunca arrumam nada até “depois” que isso tiver custado muito dinheiro a eles. Eu ouvi você mencionar comprimento? Segundo a calculadora do Google 100 milhões de notas de dólares em multas uma após a outra é suficiente para cobrir 9,500 milhas (15,2 quilômetros)

* * * * * * * * * * * ** * * * * ** * * FIM DA TRADUÇÃO ** * * * * ** * * * * ** * * * * ** * * * * **

Para o ZeroHedge a lição a se tirar daqui é que todo esse dinheiro que guardamos em contas correntes e usamos nossos celulares e computadores para acessar e nossos cartões para movimentar não esta seguro: basta alguém cometer um deslize que pode se tornar uma avalanche de proporções horríveis em pouco tempo. Para o autor do b3ta, a lição já é sobre o comportamento reativista dos bancos e os custos que isso pode gerar.

Meu ponto de vista é mais amplo: tanto a visão emergencial e financeira quanto a tecnológica estão corretas, mas pelo relato é claro que não havia uma visão clara do que era mais importante para o banco em um nível global, ou para as pessoas em um nível mais baixo. Os desenvolvedores e qualquer outra pessoa devem imaginar sempre que o seu trabalho pode ultrapassar a sua estadia na empresa e ou mesmo no planeta e que outra pessoa pode ter que assumir o seu serviço e dar continuidade a ele, por isso a documentação é tão importante. Não podemos ser egoístas e pensarmos somente no nosso bônus de fim de ano devido a aquelas pequenas economias que fazemos durante o ano, sem pensar em seu impacto maior ou então em não documentarmos nossos passos para nos tornarmos ‘insubstituíveis’ dentro da empresa e assim garantirmos nosso emprego. Essas economias podem garantir a nossa felicidade, mas podem ferir nossos próximos e até nós mesmos em um futuro. Usando como exemplo esse caso: bastava que a poupança do gestor que tomou a decisão de usar o script domestico para economizar 300 libras fosse perdida por causa dessa falha, ou então que a conta corrente do desenvolvedor que não documentou o seu projeto também fosse perdida. O coitado que fez a mudança sem autorização também deveria ter se planejado melhor, pois talvez tive-se mantido seu emprego, porém em seu caso, após o período desempregado ele conseguiu ser recontratado e até com um aumento.

Devemos planejar nossas ações para evitarmos esse tipo de ‘susto’: às vezes um ponto não observado pode ser o responsável por muitos problemas.

Fonte da imagem: http://wp.bartonconsultingservices.com/wp-content/uploads/2012/06/HiRes.jpg

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.