Esse princípio do pilar de confiabilidade do Google Cloud framework bem arquitetado fornece recomendações para ajudar você a conduzir análises post-mortem eficazes após falhas e incidentes.
Esse princípio é relevante para o aprendizado área de foco de confiabilidade.
Visão geral do princípio
Uma análise post-mortem é um registro escrito de um incidente, o impacto dele, as ações tomadas para atenuar ou resolver o incidente, as causas raiz e as ações de acompanhamento para evitar que o incidente se repita. O objetivo da análise post-mortem é aprender com os erros e não apontar culpados.
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 raiz
- Planejar o futuro
- Execute o plano.
Realize análises post-mortem após eventos importantes e não graves, como os seguintes:
- Inatividades visíveis ao usuário ou degradações além de um determinado limite.
- Perdas de dados de qualquer tipo.
- Intervenções de engenheiros de plantão, como reversão de versão ou redirecionamento do tráfego.
- Tempos de resolução acima de um limite definido.
- Monitorar falhas, que geralmente implicam a descoberta manual de incidentes.
Recomendações
Defina critérios de análise post-mortem antes que ocorra um incidente para que todos saibam quando o processo é necessário.
Para conduzir análises post-mortem eficazes, considere as recomendações nas subseções a seguir.
Realize análises post-mortem sem apontar culpados
As análises post-mortem eficazes se concentram em processos, ferramentas e tecnologias e não culpam indivíduos ou equipes. O objetivo dessa análise é melhorar a tecnologia e o futuro, e não descobrir quem é o culpado. Todo mundo comete erros. A meta deve ser analisar os erros e aprender com eles.
Os exemplos abaixo mostram a diferença entre o feedback que atribui culpa e um feedback sem culpa:
- Feedback que atribui culpa: "Precisamos reescrever todo o sistema de back-end complicado. Nos últimos três trimestres, está se desfazendo das coisas, e tenho certeza de que estamos cansados de fazer as coisas aos poucos. Sério, se eu receber uma página mais uma vez, eu mesmo vou reescrever..."
- Feedback sem culpa: "Um item de ação para reescrever todo o sistema de back-end pode impedir que essas páginas continuem acontecendo. O manual de manutenção desta versão é muito longo e muito difícil de ser totalmente treinado. Tenho certeza de que nossos futuros engenheiros de plantão nos agradecerão!"
Torne 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 elas são importantes e necessárias para ajudar o público a entender o que aconteceu. É possível mover dados e explicações complementares para um apêndice do relatório. Os revisores que precisarem de mais informações poderão solicitá-las.
Evite soluções complexas ou com excesso de engenharia
Antes de começar a explorar soluções para um problema, avalie a importância dele e a probabilidade de recorrência. Se o sistema for mais complexo para resolver problemas que dificilmente ocorrerão novamente, isso poderá aumentar a instabilidade.
Compartilhar a análise post-mortem da maneira mais ampla possível
Para garantir que os problemas não permaneçam sem resolução, publique o resultado da análise 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 post-mortem. Quando mais pessoas aprendem com os incidentes, a probabilidade de que falhas semelhantes ocorram novamente é reduzida.