Análise de causa raiz dos 5 porquês (ACR)
Resumo
A análise de causa raiz dos 5 porquês (ACR) é 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 vira 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 de sistema — essa é a 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 a 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 — 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 pagamentos ficou sem memória e travou.
Por que 2: O serviço de pagamentos 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 release não inclui uma etapa de teste de desempenho.
Causa raiz: O processo de release não tem uma etapa obrigatória de teste de carga e 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 lista de verificação da release e treinar o time (gerente de engenharia, 20 de agosto)
Abraços!
Khawaja Rizwan
