Esse princípio no pilar de confiabilidade do Google Cloud Well-Architected Framework fornece recomendações para ajudar você a realizar análises post-mortem eficazes após falhas e incidentes.
Esse princípio é relevante para a área de foco de aprendizado da confiabilidade.
Visão geral do princípio
Uma análise post-mortem é um registro escrito de um incidente, do impacto dele, das ações tomadas para atenuar ou resolver o incidente, das causas principais e das ações de acompanhamento para evitar que o incidente se repita. O objetivo de uma análise post-mortem é aprender com os erros e não culpar ninguém.
O diagrama a seguir mostra o fluxo de trabalho de uma análise post-mortem:
O fluxo de trabalho de uma análise post-mortem inclui as seguintes etapas:
- Criar análise post-mortem
- Capturar os fatos
- Identificar e analisar as causas principais
- Planejar para o futuro
- Executar o plano
Realize análises post-mortem após eventos importantes e não importantes, como os seguintes:
- Tempos de inatividade ou degradações visíveis ao usuário além de um determinado limite.
- Perdas de dados de qualquer tipo.
- Intervenções de engenheiros de plantão, como um rollback de lançamento ou redirecionamento de tráfego.
- Tempos de resolução acima de um limite definido.
- Falhas de monitoramento, que geralmente implicam descoberta manual de incidentes.
Recomendações
Defina critérios de análise post-mortem antes que um incidente ocorra para que todos saibam quando uma análise post-mortem é necessária.
Para realizar análises post-mortem eficazes, considere as recomendações nas subseções a seguir.
Realizar análises post-mortem sem culpa
As análises post-mortem eficazes se concentram em processos, ferramentas e tecnologias e não culpam indivíduos ou equipes. O objetivo de uma análise post-mortem é melhorar sua tecnologia e o futuro, não encontrar quem é culpado. Todo mundo comete erros. O objetivo é analisar os erros e aprender com eles.
Os exemplos a seguir mostram a diferença entre o feedback que atribui culpa e o feedback sem culpa:
- Feedback que atribui culpa: "Precisamos reescrever todo o sistema de back-end complicado! Ele tem quebrado semanalmente nos últimos três trimestres e tenho certeza de que todos estamos cansados de corrigir as coisas aos poucos. Sério, se eu receber mais uma chamada, vou reescrever tudo sozinho…"
- Feedback sem culpa: "Uma ação necessária para reescrever todo o sistema de back-end pode realmente impedir que essas páginas continuem acontecendo. O manual de manutenção dessa versão é bastante longo e muito difícil de ser totalmente treinado. Tenho certeza de que nossos futuros engenheiros de plantão vão nos agradecer!"
Tornar o relatório de análise post-mortem legível para todos os públicos-alvo
Para cada informação que você planeja incluir no relatório, avalie se ela é importante e necessária para ajudar o público a entender o que aconteceu. Você pode mover dados e explicações complementares para um apêndice do relatório. Os revisores que precisarem de mais informações podem solicitá-las.
Evitar soluções complexas ou superprojetadas
Antes de começar a explorar soluções para um problema, avalie a importância dele e a probabilidade de recorrência. Adicionar complexidade ao sistema para resolver problemas que provavelmente não vão ocorrer novamente pode levar a um aumento da instabilidade.
Compartilhar a análise post-mortem da maneira mais ampla possível
Para garantir que os problemas não permaneçam sem solução, publique o resultado da análise post-mortem para um público amplo e receba apoio da gerência. O valor de uma análise post-mortem é proporcional ao aprendizado que ocorre após a análise. Quando mais pessoas aprendem com incidentes, a probabilidade de falhas semelhantes se repetirem é reduzida.