Análise de Causa Raiz
Indo além dos sintomas para encontrar causas sistêmicas.
1Por Que as Causas Raiz Importam
A maioria das soluções de problemas aborda sintomas, não causas.
O deploy falhou? Reverta e faça o deploy novamente. Bug em produção? Aplique um hotfix. O build está lento? Adicione mais servidores de build.
Essas correções abordam a dor imediata. O problema desaparece... até voltar. Porque você não corrigiu o que o causou.
Análise de causa raiz significa perguntar "por quê?" até encontrar a causa sistêmica—aquilo que, se corrigido, impediria a recorrência do problema.
O deploy não falhou por causa de uma falha aleatória. Ele falhou porque a suíte de testes é instável. A suíte de testes é instável porque os testes compartilham estado. Os testes compartilham estado porque o framework de testes não foi compreendido quando foi configurado.
Corrija o sintoma imediato (tente o deploy novamente) e você tentará novamente amanhã. Corrija a causa raiz (corrija a compreensão do framework de testes) e os deploys param de falhar.
A análise de causa raiz leva mais tempo inicialmente. Mas economiza exponencialmente mais tempo ao prevenir recorrências.
O Perigo das Correções Rápidas
Toda correção rápida que não aborda as causas raiz cria um padrão: o problema se repete, você o corrige novamente, ele se torna 'normal'. Eventualmente você tem um sistema mantido por soluções alternativas, onde os problemas reais são invisíveis sob camadas de remendos.
2Cinco Porquês
Os Cinco Porquês é a técnica de causa raiz mais simples: continue perguntando "por quê?" até chegar a uma causa raiz, geralmente em torno de cinco iterações.
Exemplo:
Problema: A produção ficou fora do ar por 2 horas.
- Por quê? Uma configuração ruim foi implantada.
- Por quê? A mudança de configuração não foi testada.
- Por quê? Não temos testes de mudança de configuração.
- Por quê? A configuração é gerenciada separadamente do código.
- Por quê? A equipe de infraestrutura a configurou antes da equipe de desenvolvimento adotar GitOps.
Causa raiz: Separação histórica da configuração do código no pipeline de implantação.
Contramedida: Mover a configuração para o mesmo repositório e pipeline de CI/CD do código da aplicação.
Armadilhas dos Cinco Porquês:
- Parar cedo demais: "Erro humano" nunca é uma causa raiz. Por que o erro aconteceu? Que sistema o permitiu?
- Caminho único: Problemas reais frequentemente têm múltiplas causas. Os Cinco Porquês podem perder cadeias causais paralelas.
- Baseado em opinião: Sem dados, você pode perguntar "por quê?" e obter especulação em vez de fato.
- Busca de culpados: Se os Cinco Porquês degeneram em "quem errou?", estão sendo mal utilizados.
Os Cinco Porquês funcionam melhor como ponto de partida, complementados com dados e múltiplas perspectivas.
3Diagramas de Ishikawa (Espinha de Peixe)
O diagrama de Ishikawa, também chamado de espinha de peixe ou diagrama de causa e efeito, ajuda a explorar múltiplas categorias de causas simultaneamente.
O problema é a "cabeça" do peixe. As principais categorias de causas são as "espinhas". As subcausas se ramificam de cada espinha.
Categorias comuns (os 6 M's):
- Mão de obra: Pessoas, habilidades, treinamento
- Método: Processos, procedimentos
- Máquina: Ferramentas, equipamentos, sistemas
- Material: Entradas, dados, dependências
- Medição: Métricas, monitoramento, feedback
- Meio ambiente: Fatores externos, contexto
Para software, você pode adaptar:
- Pessoas: Habilidades, comunicação, estrutura da equipe
- Processo: Fluxo de trabalho, transferências, políticas
- Tecnologia: Ferramentas, infraestrutura, arquitetura
- Dados: Entradas, estado, dependências
- Medição: Visibilidade, monitoramento, alertas
- Ambiente: Serviços externos, carga, contexto
O diagrama ajuda as equipes a fazer brainstorming de causas sistematicamente em vez de se fixar na primeira ideia. Ele revela que os problemas geralmente têm múltiplas causas contribuintes.
Combine Técnicas
Use os Cinco Porquês para aprofundar em cada ramo da espinha de peixe. A espinha de peixe garante que você explore amplamente; os Cinco Porquês garantem que você explore profundamente. Juntos eles são poderosos.
Incidente: Falha de deploy causou interrupção de 2 horas. Os Cinco Porquês levaram a: configuração não testada → configuração gerenciada separadamente → decisão de arquitetura histórica. A espinha de peixe revelou: também sem runbook de deploy (Processo), sem processo de canary (Método). Abordados os três.
Incidente: Falha de deploy causou interrupção de 2 horas. Conclusão do post-mortem: 'O desenvolvedor deveria ter sido mais cuidadoso'. Item de ação: 'Seja mais cuidadoso da próxima vez'. O problema se repete duas semanas depois com um desenvolvedor diferente.
- Corrigir sintomas sem causas raiz leva a problemas recorrentes
- Os Cinco Porquês aprofundam perguntando 'por quê?' repetidamente
- Erro humano nunca é uma causa raiz—pergunte que sistema o permitiu
- Diagramas de espinha de peixe ajudam a explorar múltiplas categorias de causas
- Use dados, não especulação, para validar cadeias causais
- •Parar em 'erro humano' ou 'falta de atenção'
- •Usar os Cinco Porquês sem dados para validar suposições
- •Encontrar uma causa e parar (problemas frequentemente têm múltiplas causas)
- •Transformar a análise de causa raiz em atribuição de culpa