Postmortem

Fato: Em algum ponto alguma coisa vai dar errado. Eu já falei aqui no blog que tudo é horrível. E se você está em TI – ou qualquer outra área técnica na verdade – já deve ter visto ou participado de algum problema que causou dor-de-cabeça, prejuízo, perda de clientes, indisponibilidade de sistemas ou serviços ou talvez até a demissão de alguém.

Erros e falhas são fatos da vida e vão acontecer com as melhores pessoas e com as melhores empresas. A diferença vai residir num elemento essencial: O que é aprendido com esse incidente.

Aqui entra o postmortem – ou Incident Report – que é a forma como uma empresa ou organização aprende com seus erros.

Por incrível que pareça, escrever postmortems não é parte da cultura de muitas empresas. E várias empresas que tem postmortem não sabem fazer direito. Ao invés de uma análise fria e realista o relatório vira um jogo de caça às bruxas, pessoas tentando tirar o delas da reta e, finalmente, acharem um bode-expiatório.

É a famosa espada de dois gumes. Se utilizado corretamente o postmortem é uma ferramenta poderosa para aumentar a resiliência de uma organização, mas se usada para “caçar os culpados” só vai piorar as coisas.

Lá na firma™ escrever postmortems é parte da cultura. E chamamos oficialmente de “blameless postmortem” (Postmortem sem culpados).

Modelos e templates variam e você deve criar ou adaptar algum que sirva para as suas necessidades. Eu ajudei a implementar postmortem em uma das empresas por onde passei e particularmente gosto desse modelo. Recomendo abrir e ler o link antes de continuar.

A primeira parte do relatório é um resumo executivo. Como você explicaria o que aconteceu em palavras simples, evitando jargões técnicos e em um ou dois parágrafos. Não só isso ajuda a responder perguntas de uma audiência maior, mas também permite que você – ao reescrever de forma simplificada – absorva melhor o que aconteceu.

Logo a seguir eu gosto de abordar o impacto nos clientes ou na renda, pra já deixar claro qual foi o tamanho do prejuízo. Não é sempre que o time de TI vai ter acesso a informações financeiras, mas faça o melhor que puder para que um diretor ou VP que olhe o relatório entenda o prejuízo em forma de dinheiro perdido (ou não ganho). Isso vai ajudar lá embaixo, na última sessão.

Aí então é hora de falar, passo-a-passo, o que aconteceu. Eu gosto de utilizar ISO 8601 pra ficar bem claro o horário. Felizmente é o parecido com o padrão no Brasil, então não é um problema por aí.  Mas pode ser um problema se você trabalha com um time de americanos e não utilizar a notação correta. 😛

Evite colocar informações inúteis ou irrelevantes para o problema em mãos, mas também não tenha muito pudor no que colocar. Inclua passos que tomou para diagnosticar o problema, mesmo que não tenham sido bem sucedidos.

Nessa seção é especialmente importante que a narrativa faça menção a departamentos e posições – e não a indivíduos. Isso faz uma grande diferença na parte do “sem culpados”.

A narrativa dessa seção só termina quando o serviço ou operações são restauradas ao estado original.

Logo depois vem a parte onde você deve analisar a raiz do problema. É a segunda parte mais importante do relatório. Vale a pena dizer que muita gente não entende e não sabe distingüir a raiz de um problema e um gatilho.

No documento exemplo que criei o router caiu por causa de um PDU (power distribution unit) com problema. Algumas pessoas podem assumir que a raiz do problema é simplesmente isso: Um PDU com problema. Mas não! PDU com problema foi um gatilho que fez com que o router caísse. Mas a raiz do problema é que o router só tem um PSU (power supply unit) e – portanto – estava conectado a apenas um PDU.

Coisas quebram o tempo todo. PDUs podem quebrar. O seu router, estando conectado a apenas um PDU, tinha um ponto único de falha. E isso é a raiz do seu problema. Tivesse conectado a dois PDUs e esse incidente nunca teria acontecido. E esse é o objetivo de analisar a raiz do problema: Já que é quase garantido que em algum momento um PDU pode falhar de novo, o que é possível fazer para que tudo continue no ar quando isso acontecer? Bom… no mínimo você precisa estar conectado em dois PDUs diferentes.

Da mesma forma é essencial no relatório constar claramente quando a solução para restaurar o serviço foi apenas uma mitigação temporária do problema. No exemplo a mitigação foi: Conectar router num PDU sadio. E isso foi o suficiente para restaurar o ambiente de volta ao estado original. Mas não para ser uma solução definitiva que vai fazer o serviço mais resiliente.

Finalmente vem a parte mais importante do relatório: Plano de ação para corrigir a raiz do problema.

Eu gosto de utilizar o formato tabela com colunas que indicam o que precisa ser feito, o tipo desejado de impacto (corrigir o problema, melhorar a resiliência, monitorar o ambiente, comunicar-se com clientes, etc), número ou protocolo para acompanhamento (do seu sistema de ticket, bug ou gerenciamento de projetos) uma data final para ter a resposta e/ou implementar a solução e o status atual.

Nessa seção é importante constar duas coisas: O mínimo que você precisa para evitar que esse mesmo problema aconteça de novo e outra possíveis soluções para potenciais problemas parecidos que foram descobertos por causa desse incidente.

No nosso exemplo é claro que o mínimo necessário é que nosso router seja capaz de conectar-se a dois PDUs diferentes. Então “dual PSU” é a ação corretiva que vai evitar que esse mesmo problema aconteça de novo.

Mas depois de pensar um pouco no incidente em mãos, você percebe que outro problema que pode acontecer é o próprio router pifar, ao invés do PDU. Então a solução ideal seria ter dois routers, cada um podendo se conectar a dois PDUs. Agora sim, além de resolver o problema em mãos você está adicionando resiliência ao seu serviço.
A questão aqui começa a ser custo. Por isso lá em cima é ideal ter uma idéia do prejuízo causado pela falha. Se você conseguir mostrar claramente para a diretoria que com $X eles podem evitar outro incidente que vai trazer 3$X de prejuízo é bem provável que consiga verba para melhorar o seu sistema.
Colocar possíveis melhorias no relatório é importante mesmo que você saiba que a diretoria nunca vai aprovar o orçamento. No caso do cenário hipotético se tornar real e um incidente que tinha sido anteriormente predito realmente acontecer, não só isso vai demonstrar claramente sua competência e preparo técnico, mas vai fazer a diretoria reavaliar a posição anterior. E, lógico, protege o seu traseiro.

E – finalmente – tente pensar num cenário utópico e ideal. O que seria preciso para tornar seu sistema quase indestrutível por causa de intercorrências parecidas com essa? Mesmo que seja apenas como um exercício mental, coloque no papel e discuta com outras pessoas da empresa.