Realizar análises post mortem completas

Last reviewed 2024-12-30 UTC

Esse princípio no pilar de confiabilidade do Framework de arquiteturaGoogle Cloud fornece recomendações para ajudar você a realizar análises pós-ocorrência eficazes após falhas e incidentes.

Esse princípio é relevante para a área de foco da confiabilidade de aprendizado.

Uma análise post-mortem é um registro escrito de um incidente, do impacto dele, das ações tomadas para mitigá-lo ou resolvê-lo, das causas raiz e das ações de acompanhamento para evitar a recorrência do incidente. O objetivo de uma análise retrospectiva é aprender com os erros e não apontar culpados.

O diagrama a seguir mostra o fluxo de trabalho de uma análise pós-ocorrência:

O fluxo de trabalho de uma análise post-mortem.

O fluxo de trabalho de uma análise pós-ocorrência inclui as seguintes etapas:

  • Criar análise pós-ocorrência
  • Capturar os fatos
  • Identificar e analisar as causas raiz
  • Planejar para o futuro
  • Execute o plano.

Realize análises post-mortem após eventos importantes e não importantes, como estes:

  • Tempos de inatividade ou degradações visíveis para o usuário além de um determinado limite.
  • Perda de dados de qualquer tipo.
  • Intervenções de engenheiros de plantão, como uma reversão de lançamento ou redirecionamento de tráfego.
  • Tempos de resolução acima de um limite definido.
  • Monitorar falhas, o que geralmente implica a descoberta manual de incidentes.

Recomendações

Defina os critérios de análise pós-incidente antes que um incidente ocorra para que todos saibam quando uma análise pós-incidente for 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 pós-ocorrência 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 seu 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 feedback que atribui culpa e feedback sem culpa:

  • Feedback que atribui culpa: "Precisamos reescrever todo o sistema de back-end complicado. Ela está quebrando semanalmente nos últimos três trimestres, e tenho certeza de que todos nós estamos cansados de consertar as coisas aos poucos. Sério, se eu receber uma chamada mais uma vez, vou reescrever isso por conta própria…"
  • Feedback sem culpar ninguém: "Uma ação para reescrever todo o sistema de back-end pode impedir que essas páginas continuem a acontecer. O manual de manutenção dessa versão é bastante longo e muito difícil de ser totalmente treinado. Tenho certeza de que nossos engenheiros de plantão vão agradecer."

Tornar o relatório pós-fato 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 solicitar.

Evite soluções complexas ou excessivamente elaboradas.

Antes de começar a buscar soluções para um problema, avalie a importância dele e a probabilidade de repetição. Adicionar complexidade ao sistema para resolver problemas que provavelmente não vão ocorrer novamente pode aumentar a instabilidade.

Compartilhe a análise post-mortem o máximo 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 suporte 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 recorrentes é reduzida.