Processo de post-mortem: descobrindo a causa raiz de um incidente

Uma vez que se descubra que há um incidente de tecnologia em curso, a principal providência é fazer o sistema voltar a funcionar para controlar os danos. Depois é que se corre atrás de limpar alguma coisa que tenha restado, e de investigar e identificar a causa raiz. Parte-se então para escrever o post-mortem, que é um relatório descrevendo o que ocorreu e propondo providências para o futuro. 

Como se faz o post-mortem de um incidente de tecnologia?

Para o post-mortem, uma possível estratégia é adotar os 5 porquês  desenvolvidos na Toyota para resolver problemas de qualidade de seus produtos. A técnica preconiza perguntar “por quê?” várias vezes para estimular uma discussão a partir de diferentes ângulos de analisar o que gerou o problema, como : 

• Por que aconteceu esse incidente? 
• É a complexidade do sistema? 
• Por que o sistema caiu?
• Por que o sistema permitiu mudanças dessa natureza?
• Qual a probabilidade de isso acontecer de novo? 

A partir de questionamentos da equipe responsável pela investigação do incidente, é possível começar a pensar em alguma ação estruturante para o futuro. O foco de buscar a causa raiz é gerar aprendizado e evitar que o mesmo problema, ou problemas semelhantes, volte a aparecer. Pode-se chegar à conclusão, por exemplo, que uma causa raiz é a vulnerabilidade da própria infraestrutura e dos processos da instituição, que precisarão ser reavaliados. A ideia é também tornar o ambiente cada vez mais seguro. 

Outro ponto importantíssimo é que tudo isso se passe em um clima blameless ou isento de culpabilização — o blameless postmortem é uma análise de incidentes sem apontar dedos. A princípio ninguém é responsável pelo incidente. Ele aconteceu. E quanto mais freios e contrapesos – checks and balances – houver na organização, com a cadeia de desenvolver o código, validar, executar testes, fazer revisão de código etc, mais se tira o foco de buscar culpados. 

É verdade que na maioria dos casos é o código novo, sob a responsabilidade de uma pessoa, que causa um incidente, mas as validações teriam que ter garantido depois que aquilo não seria problema. Falhas humanas são esperadas e isso precisa estar integrado ao sistema de gestão de riscos.

O processo de post-mortem tem que ter como finalidade melhorar o estado das plataformas, ferramentas, sistemas e processos. O que se busca é subir a barra para que incidentes não aconteçam com frequência.  

Falhas humanas são esperadas e isso precisa estar integrado ao sistema de gestão de riscos.

Investigação de um incidente de tecnologia: muitas perguntas

Por mais que a liderança de uma instituição possa reforçar que a cultura ali é blameless, sem atitudes concretas que indiquem isso ninguém vai acreditar. E como fazer isso? 

• A liderança deve falar bastante sobre a cultura blameless com todos na empresa. 
• Estabelecendo um fórum semanal de post-mortem para avaliar e rever as ocorrências de incidentes da semana anterior.
• A engenharia inteira da companhia deve ser convidada a participar do post-mortem. 
• Deve-se reforçar o conceito de blameless nessas ocasiões coletivas, relembrando sempre que o post-mortem serve para o aprendizado.

Direcionar o post-mortem para o aprendizado cria um ciclo para evitar problemas recorrentes e débitos técnicos.