Análise de causa raiz: 5 porquês
Resumo
A Análise de causa raiz dos 5 porquês é uma técnica estruturada de solução de problemas em que você começa com a definição do problema e pergunta "Por quê?" cinco vezes em sequência. Cada resposta torna-se o assunto da próxima pergunta. O objetivo é ir além dos sintomas e revelar a falha subjacente no processo ou no sistema que você realmente pode corrigir.
Quem pode usar
times de produto e engenharia
times de operações e DevOps
times de suporte e atendimento ao cliente
Gerentes de projeto
times de garantia de qualidade
Qualquer pessoa investigando problemas ou incidentes recorrentes
Como usá-lo
Escreva uma definição do problema clara, o que aconteceu, quando e qual foi o impacto.
Pergunte "Por que isso aconteceu?" e registre a resposta (Resposta 1).
Pergunte "Por que a Resposta 1 aconteceu?" e registre a resposta (Resposta 2).
Repita para as Respostas 3, 4 e 5.
Pare quando chegar a uma causa que você possa corrigir com uma mudança de processo ou sistema, esta é a sua causa raiz.
Defina ações corretivas: atribua a cada ação um titular e uma data de conclusão.
Dica: uma boa causa raiz aponta para um processo ou sistema, não para uma pessoa. Se sua resposta for um nome, pergunte por que mais uma vez.
Exemplo
Definição do problema: A página de checkout ficou fora por 3 horas em 12 de agosto, aprox. USD 18.000 em pedidos perdidos e mais de 40 chamados de suporte. (Investigado em 13 de agosto pela equipe de plataforma.)
Por que 1: O servidor de pagamento ficou sem memória e travou.
Por que 2: O serviço de pagamento apresenta vazamento de memória.
Por que 3: A versão de 8 de agosto não fecha conexões antigas com o banco de dados.
Por que 4: A versão nunca foi testada em carga antes de entrar em produção.
Por que 5: A lista de verificação da versão não inclui uma etapa de teste de desempenho.
Causa raiz: O processo de liberação não tem uma etapa obrigatória de teste de carga/desempenho.
Ações corretivas:
Adicionar teste automatizado de carga ao pipeline de CI (líder de DevOps, 30 de agosto)
Configurar alertas de memória em 80% de uso (time de SRE, 22 de agosto)
Atualizar a lista de verificação da versão e treinar o time (gerente de engenharia, 20 de agosto)
Saúde!
Khawaja Rizwan
