Análise de causa raiz (ACR) dos 5 porquês
Resumo
A análise de causa raiz (ACR) dos 5 porquês é uma técnica estruturada de resolução de problemas em que você começa com uma definição do problema e pergunta "Por quê?" cinco vezes em sequência. Cada resposta serve de base para a próxima pergunta. O objetivo é ir além dos sintomas e identificar 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
pessoas que investigam problemas ou incidentes recorrentes
Como usá-lo
Escreva uma definição clara do problema, 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 possa ser tratada com uma mudança no processo ou no sistema, esta é a sua causa raiz.
Defina ações corretivas: atribua a cada ação um titular e um prazo.
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 do ar por 3 horas em 12 de agosto, gerando aproximadamente 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 tem um 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 de lançamento não inclui uma etapa de teste de desempenho.
Causa raiz: O processo de lançamento não inclui uma etapa obrigatória de teste de carga/desempenho.
Ações corretivas:
Adicionar teste de carga automatizado ao pipeline de CI (líder de DevOps, 30 de agosto)
Definir alertas de memória em 80% de uso (time de SRE, 22 de agosto)
Atualizar a lista de verificação de lançamento e treinar o time (gerente de engenharia, 20 de agosto)
Abraços!
Khawaja Rizwan
