Este princípio no pilar de fiabilidade do Google Cloud Well-Architected Framework fornece recomendações para ajudar a realizar postmortems eficazes após falhas e incidentes.
Este princípio é relevante para a área de foco de aprendizagem da fiabilidade.
Vista geral do princípio
Uma análise post mortem é um registo escrito de um incidente, do respetivo impacto, das ações tomadas para mitigar ou resolver o incidente, das causas principais e das ações de seguimento para impedir a recorrência do incidente. O objetivo de um post mortem é aprender com os erros e não atribuir culpas.
O diagrama seguinte mostra o fluxo de trabalho de uma análise post mortem:
O fluxo de trabalho de uma análise post mortem inclui os seguintes passos:
- Crie uma análise post mortem
- Capture os factos
- Identificar e analisar as causas principais
- Planeie o futuro
- Execute o plano
Realize análises "postmortem" após eventos importantes e eventos não importantes, como os seguintes:
- Indisponibilidades ou degradações visíveis pelos utilizadores que excedam um determinado limite.
- Perdas de dados de qualquer tipo.
- Intervenções de engenheiros de serviço, como uma reversão de lançamento ou o reencaminhamento do tráfego.
- Tempos de resolução acima de um limite definido.
- Falhas de monitorização, que normalmente implicam a deteção manual de incidentes.
Recomendações
Defina critérios post mortem antes de ocorrer um incidente para que todos saibam quando é necessário um post mortem.
Para realizar postmortems eficazes, considere as recomendações nas seguintes subsecções.
Realize investigações "postmortem" sem culpa
As postmortems eficazes focam-se em processos, ferramentas e tecnologias, e não culpam indivíduos nem equipas. O objetivo de uma análise post mortem é melhorar a sua tecnologia e futuro, não encontrar o culpado. Todos cometem erros. O objetivo deve ser analisar os erros e aprender com eles.
Os exemplos seguintes mostram a diferença entre feedback que atribui culpas e feedback sem culpas:
- Feedback que atribui culpas: "Temos de reescrever todo o sistema de back-end complicado! Tem sido interrompido semanalmente nos últimos três trimestres e tenho a certeza de que estamos todos cansados de corrigir as coisas aos poucos. A sério, se receber mais um aviso, vou reescrever o código eu próprio…"
- Feedback sem culpa: "Um item de ação para reescrever todo o sistema de back-end pode, na verdade, impedir que estas páginas continuem a ocorrer. O manual de manutenção desta versão é bastante longo e é muito difícil receber formação completa sobre o mesmo. Tenho a certeza de que os nossos futuros engenheiros de serviço vão agradecer-nos!"
Tornar o relatório post mortem legível para todos os públicos-alvo pretendidos
Para cada informação que planeia incluir no relatório, avalie se essa informação é importante e necessária para ajudar o público a compreender o que aconteceu. Pode mover dados suplementares e explicações para um anexo do relatório. Os revisores que precisarem de mais informações podem solicitá-las.
Evite soluções complexas ou demasiado elaboradas
Antes de começar a explorar soluções para um problema, avalie a importância do problema e a probabilidade de recorrência. Adicionar complexidade ao sistema para resolver problemas que é improvável que ocorram novamente pode levar a uma maior instabilidade.
Partilhe a análise post mortem o mais amplamente possível
Para garantir que os problemas não permanecem por resolver, publique o resultado da análise post mortem para um público vasto e receba apoio técnico da gestão. O valor de uma análise post mortem é proporcional à aprendizagem que ocorre após a análise post mortem. Quando mais pessoas aprendem com os incidentes, a probabilidade de ocorrência de falhas semelhantes é reduzida.