Análise de
causa raiz:
por que falhou — e como não voltar

Quando algo dá errado — uma queda de serviço, um prazo estourado, um defeito que chegou ao cliente, um negócio perdido — a pressão é por uma resposta rápida: quem fez, o que reverter, seguir em frente. A análise de causa raiz (RCA) resiste a essa pressa. Ela pergunta: o que teria de ser diferente, de forma permanente, para que esse tipo de falha não pudesse mais acontecer?

O que a RCA não é

"Causa raiz" no singular é quase sempre errado

Falhas relevantes raramente têm uma causa. Têm um gatilho (o que disparou naquele momento) e um conjunto de condições contribuintes (o que já estava lá, tornando o sistema vulnerável). Remover só o gatilho conserta aquele incidente; remover condições contribuintes conserta a classe de incidentes. A boa RCA mira a segunda.

Definição de trabalho (a que usaremos na apostila inteira)

Relação com as outras apostilas da trilha

A de Estruturação de Problemas usa árvore para causas independentes e estáveis; a de Pensamento Sistêmico cuida de causas estruturais que se realimentam. Esta apostila é o tratamento fundo do caso específico da investigação de uma falha — sobretudo incidentes: como coletar fatos sem contaminá-los, como não parar cedo, e como o postmortem deve ser escrito para que as ações realmente aconteçam.

2.1 O que a culpa faz com a investigação

Quando errar tem custo pessoal alto, quem estava perto da falha vai — racionalmente — omitir, minimizar, encontrar como "não foi bem assim". Você perde o acesso justamente à informação de que mais precisa: o que a pessoa viu, pensou e por que aquilo fazia sentido para ela naquele momento. Sem isso, a RCA para em "erro humano" — que não é uma causa, é o começo da investigação.

"'Erro humano' nunca é a causa. É o ponto onde a sua investigação deve começar, não terminar."

2.2 A primeira e a segunda história

• Primeira história: "fulano cometeu um erro; se tivesse tido mais atenção, não teria acontecido." Simples, satisfatória, inútil — não muda nada no sistema.
• Segunda história: "dada a informação que a pessoa tinha, a pressão de tempo, a interface confusa e a ausência de checagem automática, a ação dela era previsível — outra pessoa competente teria feito parecido." Essa aponta o que consertar.

A RCA madura sempre procura a segunda história. Se a sua conclusão é "a pessoa deveria ter tido mais cuidado", você ainda não terminou.

2.3 Vieses que a culpa alimenta

2.4 Como conduzir uma investigação sem culpa (na prática)

3.1 Construir a linha do tempo

Liste os eventos em ordem, cada um com hora, o que aconteceu (observável), e fonte (log, mensagem, relato de quem estava). Vá do início plausível (a última vez que estava tudo bem) até a resolução. Inclua o que não aconteceu quando deveria (o alerta que não disparou, a revisão que não houve).

3.2 Fato vs. interpretação

Na linha do tempo, só fatos. "14:05 deploy concluído" é fato. "O deploy foi mal-feito" é interpretação — vai para a análise, depois. Misturar os dois faz a investigação herdar as suposições cedo demais e parar de procurar. Marque cada linha: observado (O) ou inferido (I)?

3.3 Condições que já estavam lá

Além da sequência de eventos, registre o estado do sistema antes do gatilho — o que era "normal na época" e contribuiu: o alerta configurado para 50% (e não 5%), o checklist de release sem o passo de teste de pagamento, a ausência de ambiente de staging que espelhasse produção, a pessoa de plantão sem acesso ao rollback. Essas não aparecem na linha do tempo dos eventos, mas são metade da causa.

3.4 Cuidados na coleta

4.1 Como funciona

Parta do problema e pergunte "por quê?" repetidamente, cada resposta virando a próxima pergunta, até chegar a uma causa sobre a qual você pode agir de forma durável. O "5" é aproximado — pode ser 3, pode ser 7.

4.2 As três armadilhas

4.3 Quando os 5 porquês servem bem

• Incidentes específicos e reproduzíveis com uma cadeia dominante clara.
• Como ferramenta de aprofundamento depois que a árvore de fatores (cap. 5) identificou os ramos que valem a pena investigar.
• Para testar rapidamente se uma causa proposta realmente explica o efeito (se o "por quê" não conecta, a causa é fraca).

5.1 O diagrama de Ishikawa (espinha de peixe)

Uma seta central aponta para o efeito (a falha). Dela saem "espinhas", uma por categoria de causa. As 6 categorias clássicas (6M), adaptáveis:

Você preenche cada categoria com candidatas, mesmo as que parecem improváveis. O objetivo é não esquecer uma família inteira de causa.

5.2 A árvore de fatores causais com E/OU

O Ishikawa lista; a árvore estrutura a lógica. Da falha, você desce por nós:

• Nó OU: qualquer um dos filhos sozinho teria causado o efeito. (Redundância ausente.)
• Nó E: o efeito só aconteceu porque todos os filhos ocorreram juntos. (Múltiplas barreiras furadas — cap. 6.)

Ler a árvore: tirar qualquer um dos nós E teria evitado ou reduzido drasticamente a falha. Isso te dá várias contramedidas independentes — e você escolhe pela hierarquia de controles (cap. 8).

5.3 Ishikawa alimenta a árvore

Fluxo prático: brainstorm de candidatas por categoria (Ishikawa) → montar a árvore ligando as candidatas reais com E/OU → aprofundar os ramos mais fortes com 5 porquês (cap. 4) → testar cada folha por contrafactual (cap. 7).

6.1 O modelo

James Reason: imagine cada defesa do sistema (revisão de código, testes, checklist, alerta, plantão) como uma fatia de queijo suíço. Cada fatia tem buracos — falhas pontuais. Normalmente, um buraco numa fatia é coberto pela fatia seguinte. Uma falha grave só acontece quando os buracos de todas as fatias se alinham e a trajetória passa direto.

6.2 Falhas ativas vs. condições latentes

• Falha ativa: o ato ou evento imediato que dispara — o commit com o bug, o comando errado, o clique. Visível, próximo no tempo.
• Condição latente: a fragilidade que já estava no sistema, criada por decisões antigas — o checklist desatualizado, o alerta mal calibrado, a ausência de staging fiel, a documentação errada. Invisível no dia a dia, "adormecida" até um gatilho a ativar.

Consertar só a falha ativa (reverter o commit, punir o clique) deixa todas as condições latentes de pé — prontas para a próxima. A RCA que vale a pena mira as condições latentes.

6.3 Deriva para a falha (drift)

Condições latentes muitas vezes se acumulam por normalização do desvio: um atalho é tomado sob pressão, não dá problema, vira prática; a folga é cortada, o sistema aguenta, o corte vira permanente; um alerta ruidoso é silenciado "temporariamente". Cada passo parece razoável; o conjunto move o sistema para perto da borda. (Liga com a apostila de Pensamento Sistêmico, arquétipo "metas que escorregam".)

6.4 Perguntas do queijo suíço

7.1 O teste contrafactual

Para cada causa candidata C, pergunte: "se C não tivesse ocorrido (ou fosse diferente), o efeito ainda teria acontecido?"

• Se a resposta é "não teria acontecido": C é uma causa contribuinte real. Vale uma contramedida.
• Se a resposta é "teria acontecido do mesmo jeito": C não é causa — é ruído, ou um fator presente mas irrelevante. Não gaste contramedida nele.
• Se a resposta é "teria acontecido, mas menor / mais tarde / mais fácil de conter": C é uma causa contribuinte de mitigação — não evita, mas reduz. Também vale.

7.2 Necessário, suficiente e a cadeia

Distinga (emprestando da apostila de Argumentação, cap. 5): uma condição necessária é aquela sem a qual a falha não acontece — é o melhor alvo de contramedida, porque removê-la quebra a cadeia. Uma condição suficiente sozinha bastaria — perigosa, merece barreira. A maioria das condições contribuintes é "necessária em conjunto": nenhuma sozinha causa, mas remover qualquer uma teria evitado.

7.3 Cuidado com o contrafactual fantasioso

7.4 Priorizar as causas testadas

Depois de filtrar as candidatas pelo contrafactual, ordene as sobreviventes por: quão cedo na cadeia ela está (mais cedo = quebra mais coisa), quantos outros incidentes ela poderia causar (condição latente antiga e ampla > pontual), e custo/viabilidade da contramedida. As de cima entram no plano; as de baixo ficam registradas.

8.1 A hierarquia (da mais forte à mais fraca)

Quanto mais alto o nível, menos a contramedida depende de um humano lembrar e acertar sob pressão — e mais durável ela é. Contramedidas de nível 5 (procedimento, treinamento) são as mais fáceis de propor e as que menos previnem repetição, porque a próxima pessoa sob pressão vai esquecer ou pular.

8.2 O reflexo a combater: "vamos criar um processo"

"Se a resposta ao incidente é 'adicionar um passo ao procedimento' e 'reforçar o treinamento', você provavelmente não achou a causa — ou não quis pagar o preço de consertá-la."

Não que procedimento e treinamento sejam inúteis — são o que dá para fazer hoje, e complementam. Mas toda RCA deveria perguntar, para cada causa: existe uma contramedida de nível 1-3 aqui, e por que não estamos fazendo ela?

8.3 A boa ação corretiva

8.4 Não conserte tudo

Uma falha gera 8 causas contribuintes. Você não vai atacar as 8 — algumas são raras, caras de consertar, e de baixo impacto. Escolha as 2-4 de maior alavancagem (mais cedo na cadeia, condição latente ampla, contramedida viável de nível alto). Registre as outras. Um postmortem com 15 ações vira um postmortem com 15 ações não feitas.

Investigar é um movimento: fatos → barreiras que falharam → gatilho e condições latentes → teste contrafactual → contramedidas por nível. A demo mostra a análise se formando.

10.1 Quando o incidente é sintoma de estrutura

Se falhas parecidas se repetem apesar das contramedidas, a causa não está em nenhum incidente — está numa estrutura que continua produzindo incidentes: pressão crônica por velocidade que faz todo mundo pular etapas, subinvestimento em ferramentas que deixa o trabalho frágil, rotatividade que apaga o conhecimento tácito. Aí a ferramenta certa é o diagrama de laços da apostila de Pensamento Sistêmico, não mais um postmortem. Sinal: as ações corretivas dos últimos 5 postmortems são todas variações de "ter mais cuidado / mais um passo".

10.2 Vieses que atacam a investigação

10.3 Os limites da RCA

10.4 O propósito, de novo

A RCA existe para reduzir a probabilidade e o impacto da próxima falha da mesma classe — não para produzir um documento, não para atribuir responsabilidade, não para tranquilizar. Se a análise não termina em uma mudança durável no sistema, com dono e acompanhamento, ela não cumpriu a função — por mais bem escrita que seja.

12.1 Plano de treino — 30 dias, ~20 min/dia

12.2 Template de postmortem (kit)

12.3 Checklist universal (antes de fechar uma investigação)

12.4 Como levar isso para o currículo e a entrevista

• Nomeie com o vocabulário do mercado: "análise de causa raiz", "postmortem blameless", "melhoria contínua", "engenharia de confiabilidade", "5 porqués / Ishikawa / FMEA".
• Prove com artefatos: um postmortem que você escreveu com contramedidas de nível alto e ações concluídas; a autópsia de caso do Exercício 11.2; uma auditoria de acompanhamento que mudou o processo.
• Nas entrevistas ("conte de uma falha"): não conte só o que deu errado — conte a investigação: linha do tempo, gatilho vs. condições, o contrafactual, a contramedida durável, e se ela impediu a repetição.
• Meça: recorrência da classe de falha depois da contramedida, fração de ações de postmortem concluídas, quase-acidentes investigados antes de virarem incidentes.

12.5 Biblioteca essencial para seguir avançando

• Cultura e investigação: "The Field Guide to Understanding 'Human Error'" (Sidney Dekker) · "Pre-Accident Investigations" (Todd Conklin) · o capítulo de postmortems do "SRE Book" do Google (gratuito)
• Modelos: "Managing the Risks of Organizational Accidents" (James Reason, o queijo suíço) · material sobre Causal Factor Tree e Apollo Root Cause Analysis
• Sistemas complexos: "Normal Accidents" (Charles Perrow) · "Drift into Failure" (Sidney Dekker) · "The Checklist Manifesto" (Atul Gawande) para o lado das contramedidas
• Qualidade / indústria: materiais sobre 8D, FMEA e A3 (Toyota) para RCA estruturada em manufatura e operações