Uma Análise Pública Post Mortem de Uma Interrupção

Muitas coisas na vida têm uma abordagem comumente aceita como “conservadora” e uma abordagem comumente aceita como “arriscada” que deveria ser evitada, ao menos de acordo com o sentimento popular. Nos investimentos, por exemplo, frequentemente vemos a compra de títulos governamentais ou municipais como de baixo risco e o investimento em ações (papéis de empresas) como de alto risco – mas os números estatísticos nos dizem que isso é o contrário e que quase todo mundo perde dinheiro com títulos e ganha dinheiro com ações. A “sabedoria” comum, quando colocada à prova, revela-se baseada puramente em emoções que, por sua vez, baseiam-se em equívocos, e a coisa mais arriscada nos investimentos é usar a emoção para conduzir as estratégias de investimento.

De modo semelhante, nas avaliações de risco de negócios, a abordagem comum é sentir uma resposta emocional ao perigo, e isso aciona uma reação de pânico e cria uma forte tendência de as pessoas supercompensarem o risco percebido. Vemos isso comumente em empresas pequenas, cuja infraestrutura de TI gera muito pouca receita ou não é muito essencial para as operações de curto prazo, gastando grandes somas de dinheiro para se proteger contra um risco que é apenas parcialmente percebido e muito mal articulado. Isso muitas vezes se torna tão dramático que o processo de mitigação frequentemente é conduzido de forma emocional, em vez de intelectual, e regularmente encontramos empresas implementando projetos de sistema ruins que, na verdade, aumentam o risco em vez de diminuí-lo, ao mesmo tempo em que gastam somas muito elevadas de dinheiro e, então, como o risco era em sua maior parte imaginário, declaram o projeto um sucesso baseado em camada sobre camada de equívocos: risco imaginário, mitigação de risco imaginária e sucesso imaginário.

No passado recente, tive a oportunidade de me envolver em um desastre completo para uma pequena empresa. O desastre atingiu o que foi quase um “pior cenário possível”. Não exatamente, mas muito perto. A resposta emocional na ocasião ao desastre foi forte e, uma vez que o desastre estava em pleno andamento, era comum que quase todos afirmassem e repetissem que o planejamento de desastres tinha sido falho e que o problema deveria ter sido evitado. Isso é muito comum em qualquer situação de desastre; os seres humanos sentem que deveria sempre haver alguém para culpar e que deveriam existir cenários de risco zero se fizermos nosso trabalho corretamente, mas isso está completamente errado.

Felizmente, realizamos um post mortem completo, como se deve fazer após qualquer desastre verdadeiro, para determinar o que tinha dado errado, o que tinha dado certo, como poderíamos corrigir processos e decisões que haviam falhado e como poderíamos manter aqueles que nos haviam protegido. Normalmente, quando algum grande evento de sistemas acontece, não tenho a oportunidade de falar sobre ele publicamente. Mas, de vez em quando, tenho. É tão comum reagir a um desastre, a qualquer desastre, e pensar “ah, se ao menos tivéssemos…”. Mas é preciso examinar o desastre. Há tanto a ser aprendido sobre os processos e sobre nós mesmos.

Primeiro, um pouco de contexto. Um servidor crítico, rodando em um datacenter corporativo, abriga várias cargas de trabalho essenciais que são muito importantes para várias empresas. Ele tem pouco mais de quatro anos e vinha rodando isoladamente havia muitos anos. Servidores mais antigos são sempre um tanto preocupantes à medida que se aproximam do fim de vida útil. Quatro anos dificilmente é fim de vida útil para um servidor de classe corporativa, mas certamente também não era novo.

Este era um único servidor, sem qualquer mecanismo de failover. Os backups eram tratados externamente em um appliance de backup corporativo no mesmo datacenter. Um projeto de sistema muito simples

Não incluirei todos os detalhes internos, pois qualquer situação como esta tem muitas complexidades no planejamento e na operação. Essas são mais bem deixadas para um processo de post mortem interno.

Quando o servidor falhou, falhou espetacularmente. A falha foi tão completa que não conseguimos diagnosticá-la remotamente, mesmo com a ajuda dos técnicos presentes no datacenter. Até o fornecedor do servidor foi incapaz de diagnosticar o problema. Isso nos deixou em uma posição difícil – como lidar com um servidor morto quando o hardware não pode ser consertado de forma confiável. Poderíamos trocar discos, poderíamos trocar fontes de alimentação, poderíamos trocar a placa-mãe. Quem sabia o que poderia ser a solução.

No fim, a decisão foi que tanto o servidor quanto o sistema de backup teriam que ser realocados de volta ao escritório principal, onde poderiam ser triados pessoalmente e com o máximo de recursos. No fim, o sistema acabou podendo ser reparado e nenhum dado foi perdido. A decisão de evitar recorrer ao backup foi tomada porque a recuperação dos dados era mais importante do que a disponibilidade do sistema.

Quando tudo foi dito e feito, o desastre foi um dos mais completos que se poderia imaginar sem que houvesse perda real de dados. A interrupção se prolongou por muitos dias e muitos equipamentos sobressalentes, horas de trabalho e tentativas de correção foram empregados. O processo foi exaustivo, mas, quando concluído, o sistema foi restaurado com sucesso.

A longa interrupção e a sensação de caos enquanto as coisas eram diagnosticadas e tentativas de reparo eram feitas levaram a uma sensação geral de fracasso. As pessoas começaram a dizê-lo e isso leva as pessoas a acreditar nisso. Sob uma condição de resposta a emergências, é muito fácil ficar excessivamente emocional, especialmente quando há muito pouco sono a se ter.

Mas, quando demos um passo atrás e olhamos para o resultado final, o que descobrimos surpreendeu quase todo mundo: a operação de triagem e o planejamento de risco inicial tinham sido bem-sucedidos.

O caos que ocorre durante uma triagem muitas vezes faz com que as coisas pareçam muito piores do que realmente são. Mas nosso tratamento da triagem tinha sido excelente. Triagem não significa mágica e há uma fase de descoberta e uma fase de reação. Quando analisamos a ordem dos eventos e os dispusemos em uma linha do tempo, descobrimos que tínhamos agido tão bem que praticamente não havia nenhum ponto possível em que pudéssemos ter encurtado o prazo. Tínhamos feito bons diagnósticos, envolvido as partes certas no momento certo, colocado as peças em movimento logístico o mais cedo possível e a maior parte do que parecia ter sido tempo frenético e desperdiçado era, na verdade, “tempo de preenchimento”, no qual estávamos tentando determinar se havia opções adicionais ou se erros tinham sido cometidos enquanto aguardávamos as peças necessárias para o reparo. Isso fez com que as coisas parecessem muito piores do que realmente eram, mas todo esse foi o conjunto correto de ações a serem tomadas.

Da perspectiva da triagem e da recuperação, o processo tinha transcorrido de forma impecável, mesmo que a interrupção tenha acabado levando muitos dias. Uma vez que o desastre aconteceu e aconteceu na extensão incrível em que aconteceu, a recuperação, na verdade, transcorreu de forma incrivelmente tranquila. Nada é absolutamente perfeito, mas correu extremamente bem. A máquina funcionou conforme o pretendido.

A parte muito mais surpreendente foi analisar o impacto do desastre. Há duas maneiras de olhar para isso. Uma é a mais sábia, a abordagem “sem retrospectiva”. Aqui, olhamos para o desastre, o custo de impacto do desastre, o custo da mitigação e aplicamos a probabilidade de que o desastre teria acontecido e determinamos se a decisão de planejamento correta tinha sido tomada. Isso é difícil de calcular, porque o fator de risco é sempre um número estimado, mas normalmente é possível chegar a algo preciso o suficiente para saber o quão bom foi o seu planejamento. A segunda maneira é a abordagem da retrospectiva perfeita – e se soubéssemos que esse desastre iria acontecer, o que teríamos feito para evitá-lo? É obviamente totalmente injusto remover o fator de risco e ver quanto o desastre custou em números brutos, porque não temos como saber o que vai dar errado e planejar apenas para aquela única possibilidade, ou gastar dinheiro ilimitado por algo que, na verdade, não sabemos se vai acontecer. As empresas frequentemente cometem o erro de usar o último cálculo e culpar os planejadores por não terem tido uma previsão perfeita.

Neste caso, estávamos razoavelmente confiantes de que tínhamos feito a aposta certa desde o início. O sistema estivera em operação por quase uma década com zero tempo de inatividade. O custo geral do sistema tinha sido baixo, o custo da triagem tinha sido moderado e o evento tinha sido extremamente improvável. Que, ao considerar o fator de risco, tínhamos feito um bom planejamento não foi, de modo geral, surpreendente para ninguém.

O que foi surpreendente é que, quando rodamos os cálculos sem o fator de risco, mesmo que soubéssemos que o sistema iria falhar e que uma interrupção prolongada ocorreria, ainda assim teríamos tomado a mesma decisão! Isso foi absolutamente chocante. O custo da interrupção prolongada foi, na verdade, menor do que o custo do equipamento necessário, da hospedagem e da mão de obra para se ter construído um sistema funcional de mitigação de risco – neste caso, isso teria sido ter um servidor totalmente redundante no datacenter junto com aquele que estava em produção. Na verdade, a economia de custos por aceitar essa interrupção prolongada havia poupado quase dez mil dólares!

Isso acabou sendo um caso extremo, no qual a interrupção foi devastadoramente ruim, difícil de prever, impossível de reparar rapidamente e, ainda assim, resultou em uma enorme economia de custos a longo prazo, mas a lição é importante. Há tanta bagagem emocional que acompanha qualquer desastre que, se não fizermos uma análise post mortem adequada e não trabalharmos para remover as respostas emocionais da nossa tomada de decisão, frequentemente saltaremos para uma perda financeira de grande escala ou para a atribuição incorreta de culpa, mesmo quando as coisas correram bem. Muitas empresas teriam olhado para este desastre e reagido gastando dramaticamente em excesso para evitar que o mesmo evento improvável se repetisse no futuro, mesmo tendo a matemática diante de si para lhes dizer que fazê-lo desperdiçaria dinheiro ainda que esse evento de fato se repetisse!

Houve outras lições a serem aprendidas com essa interrupção. Aprendemos onde as comunicações não tinham sido ideais, onde as pessoas certas nem sempre estavam no ponto certo de tomada de decisão, onde as comunicações com o cliente não foram o que deveriam ter sido, onde o cliente não nos havia informado adequadamente sobre as mudanças e muito mais. Mas, de modo geral, as lições foram que tínhamos planejado corretamente, que nossa operação de triagem tinha funcionado corretamente e que tínhamos economizado ao cliente vários milhares de dólares em relação ao que teria parecido ser a abordagem “conservadora” e que, ao fazer um bom post mortem, conseguimos impedir que eles, e nós, reagíssemos de forma exagerada e transformássemos uma boa decisão em uma ruim daqui para frente. Sem um post mortem, muito provavelmente teríamos mudado nossos bons processos pensando que eles tinham sido ruins.

As lições que quero transmitir a você, leitor, são que os post mortems são uma etapa crítica em qualquer desastre, que o pensamento conservador tradicional é frequentemente muito arriscado e que as reações emocionais ao risco frequentemente causam desastres financeiros maiores do que os técnicos contra os quais elas buscam proteger.