Análise de Causa Raiz: métodos RCA, 5 Porquês e Fishbone em TI

Resolver um incidente e restaurar o serviço é apenas metade do trabalho. A outra metade — frequentemente negligenciada na correria do dia a dia — é garantir que o mesmo problema não ocorra novamente. Sem uma análise estruturada das causas, os mesmos incidentes se repetem em ciclos previsíveis, consumindo tempo de engenharia e erodindo a confiança dos usuários.

A análise de causa raiz (RCA — Root Cause Analysis) é o processo que fecha esse ciclo. Ela vai além do sintoma imediato para identificar os fatores sistêmicos que tornaram possível o incidente, gerando ações de melhoria que reduzem a probabilidade de recorrência.

Este guia técnico explica o que é RCA, os principais métodos aplicados em ambientes de TI e SRE, como conduzir uma análise eficaz e como conectar os resultados ao postmortem e às métricas DORA.

O que é análise de causa raiz (RCA)?

Análise de causa raiz é um processo estruturado de investigação que busca identificar a origem real de um problema — não apenas o sintoma que disparou o alerta, mas os fatores subjacentes que criaram as condições para o incidente ocorrer.

A distinção entre sintoma e causa raiz é fundamental. Um servidor que ficou sem memória é um sintoma. A causa raiz pode ser um vazamento de memória introduzido em um deploy recente, que por sua vez foi causado por ausência de testes de performance no pipeline de CI/CD. Tratar apenas o sintoma — reiniciar o servidor — resolve o incidente momentaneamente sem eliminar a causa.

Em ambientes de TI distribuídos, a causa raiz raramente é única. Sistemas complexos falham por conjuntos de fatores que se combinam — uma sequência de decisões, ausências de controles e condições ambientais que se alinham em um momento específico. A RCA eficaz mapeia essa cadeia causal completa.

Principais métodos de análise de causa raiz

5 Porquês

O método mais simples e amplamente usado. Partindo do problema observado, pergunta-se “por quê?” a cada resposta até chegar à causa raiz sistêmica. O número cinco é uma referência, não um limite fixo — o processo termina quando a resposta não tem mais “por quê” acionável.

Exemplo aplicado a um incidente de latência elevada:
Por que a latência aumentou? → Porque o banco de dados estava lento.
Por que o banco estava lento? → Porque havia queries sem índice causando full table scans.
Por que havia queries sem índice? → Porque um deploy adicionou uma nova query sem revisão de performance.
Por que passou sem revisão? → Porque o processo de code review não inclui checklist de performance.
Por que não inclui? → Porque nunca foi definido um padrão de revisão de queries.

A causa raiz não é “a query ruim” — é a ausência de um padrão de revisão. A ação corretiva é criar e implementar o checklist, não apenas adicionar o índice.

Diagrama de Ishikawa (Espinha de Peixe)

O diagrama de Ishikawa organiza as causas potenciais de um problema em categorias visuais, permitindo que a equipe explore múltiplas dimensões causais simultaneamente. As categorias clássicas para TI são: pessoas, processos, ferramentas, ambiente e dados.

Esse método é especialmente útil em incidentes complexos onde múltiplos fatores contribuintes precisam ser mapeados antes de identificar as causas mais prováveis. O diagrama funciona como ferramenta de facilitação em grupos — evita que a análise fique presa na primeira explicação plausível.

Análise de árvore de falhas (FTA)

A Fault Tree Analysis constrói um diagrama lógico top-down que decompõe um evento de falha em suas causas contribuintes usando operadores lógicos (AND/OR). É o método mais rigoroso para sistemas críticos onde múltiplas combinações de falhas precisam ser analisadas.

Em ambientes de microsserviços, a FTA é útil para mapear como falhas em serviços individuais se propagam para causar degradação no sistema como um todo — conectando diretamente com os dados de rastreamento distribuído e correlação de eventos.

Como conduzir uma RCA eficaz em TI

A qualidade de uma RCA depende de dados, não de memória. O primeiro passo é coletar a telemetria do incidente — logs, métricas e traces do período afetado — antes de começar qualquer análise. Memória individual em situações de pressão é pouco confiável.

O segundo passo é construir a linha do tempo do incidente com timestamps precisos. Quando o problema começou realmente (não quando foi detectado), quando cada ação de mitigação foi tomada e qual efeito produziu. Essa linha do tempo é a base factual sobre a qual a análise causal vai operar.

O terceiro passo é aplicar o método de análise escolhido — 5 Porquês para incidentes mais diretos, Ishikawa para problemas com múltiplas causas potenciais, FTA para sistemas críticos. O objetivo é chegar em causas sistêmicas acionáveis, não em erros individuais.

O quarto passo — e o mais crítico — é definir ações corretivas com dono e prazo. Uma RCA que não gera ações implementadas é documentação sem valor. As ações devem atacar as causas sistêmicas identificadas, não apenas os sintomas.

RCA vs Postmortem: qual a diferença?

Os dois conceitos são complementares e frequentemente usados juntos, mas têm escopo diferente.

A RCA é uma técnica analítica — um processo de investigação focado em identificar causas. Ela pode ser usada fora do contexto de incidentes, por exemplo, para analisar por que uma funcionalidade tem alta taxa de bugs ou por que o tempo de deployment é consistentemente alto.

O postmortem é um processo organizacional mais amplo — um documento estruturado que inclui a linha do tempo do incidente, o impacto quantificado, o que funcionou bem, o que pode melhorar e as ações de melhoria com responsáveis. A RCA é um componente do postmortem, não um substituto.

Em times de SRE maduros, toda violação significativa de SLO dispara um postmortem que inclui uma RCA formal. O resultado da RCA alimenta diretamente os action items do postmortem.

Conexão com métricas DORA e observabilidade

A análise de causa raiz tem impacto direto em duas das métricas DORA. A Change Failure Rate alta indica que deploys estão causando incidentes recorrentes — um padrão que só é resolvido com RCA sistemática que identifica as falhas no processo de entrega (testes insuficientes, ausência de rollback automatizado, falta de feature flags).

O Failed Deployment Recovery Time (MTTR) se reduz quando os times têm processos de diagnóstico rápido — que dependem de observabilidade estruturada e familiaridade com os padrões de falha do sistema, construída exatamente através de postmortems e RCAs anteriores.

A relação com observabilidade é igualmente direta: plataformas de AIOps usam histórico de incidentes e suas causas raiz para treinar modelos de correlação automática. Quanto mais RCAs bem documentadas, mais precisa fica a correlação automática em incidentes futuros.

Conclusão

A análise de causa raiz é o mecanismo que transforma incidentes em aprendizado organizacional. Sem ela, os mesmos problemas se repetem em ciclos — cada vez consumindo o mesmo tempo de engenharia, com o mesmo impacto nos usuários e no error budget.

Os métodos 5 Porquês, Ishikawa e FTA oferecem estrutura para chegar nas causas sistêmicas, não apenas nos sintomas. A eficácia da análise depende de dados de telemetria de qualidade, linha do tempo precisa e — fundamentalmente — ações corretivas implementadas com dono e prazo. Para referência técnica aprofundada, o capítulo de cultura de postmortem do Google SRE Book trata RCA e postmortem como práticas integradas.

Para estruturar seus processos de RCA e resposta a incidentes, fale com nossos especialistas.