Como diferenciar sintoma de causa raiz

O problema

Tem investigação que para cedo demais.

O time vê:

• timeout
• erro 500
• CPU alta
• fila crescendo

E trata isso como se fosse a causa em si.

Só que, na maioria das vezes, isso ainda é o que apareceu na superfície.

Não o que originou o comportamento.

Modelo mental

Pense assim:

• sintoma é o sinal visível
• causa raiz é a condição que explica por que aquele sinal apareceu

Exemplo simples:

• sintoma: tempo de resposta explodiu
• causa raiz possível: conexão com serviço externo começou a travar sem timeout adequado

O sintoma grita.

A causa raiz costuma ficar alguns passos abaixo.

Quebrando o problema

Sintoma é importante

Sintoma não deve ser desprezado.

Ele é a porta de entrada da investigação.

Também é o que costuma orientar mitigação imediata:

• reduzir carga
• abrir circuito
• desligar funcionalidade
• voltar release

Mas mitigar o sintoma não significa que o problema foi explicado.

Causa raiz precisa explicar a cadeia

Uma causa raiz útil não é só algo “mais profundo”.

Ela precisa explicar uma cadeia plausível:

1. algo mudou ou falhou
2. isso criou certa condição
3. essa condição gerou o sintoma observado

Se a explicação não fecha essa cadeia, talvez você ainda esteja olhando para outra camada do sintoma.

Parar cedo demais faz o problema voltar

Exemplo clássico:

• sintoma: fila crescendo
• ação: aumentar número de workers

Talvez isso alivie por um tempo.

Mas e se a causa raiz for:

• um consumidor travando em dependência externa
• ou uma mensagem específica quebrando repetidamente

Sem entender isso, o sistema pode piorar de novo na primeira pressão parecida.

Causa raiz não precisa ser metafísica

Outro extremo também atrapalha.

Tem investigação que continua cavando sem parar atrás da “causa mais fundamental do universo”.

Em engenharia, causa raiz útil é a explicação acionável suficiente para:

• corrigir
• reduzir chance de repetição
• melhorar sistema ou processo

Não precisa virar filosofia infinita.

Exemplo simples

Imagine aumento de 500 no checkout.

Camada de sintoma:

• 500 subiu
• latência piorou

Primeira hipótese superficial:

• “o checkout está quebrado”

Descendo mais:

• erro concentra pagamentos com antifraude
• chamadas externas estão levando 8 segundos
• timeout local está alto demais
• threads ficam presas

Aqui a causa raiz útil pode ser algo como:

• dependência externa degradou e o serviço não tinha timeout e contenção adequados

Perceba a diferença.

“Erro 500” não era a causa.

Era o efeito visível.

Erros comuns

• Confundir alerta com explicação.
• Parar a análise no primeiro comportamento estranho encontrado.
• Chamar qualquer camada interna de causa raiz sem fechar a cadeia causal.
• Achar que mitigação bem-sucedida prova entendimento completo.
• Continuar cavando sem fim e atrasar correção acionável.

Como um senior pensa

Quem tem mais experiência costuma separar duas perguntas:

1. o que eu preciso fazer agora para reduzir dano?
2. o que realmente explica por que isso aconteceu?

Essa separação ajuda muito.

Porque evita dois erros:

• tratar mitigação como explicação
• atrasar mitigação porque a causa raiz ainda não ficou perfeita

O que o entrevistador quer ver

Em entrevista, esse tema mede profundidade de investigação.

O avaliador quer ver se você:

• separa sinal de explicação
• monta uma cadeia causal coerente
• entende mitigação como etapa distinta
• procura uma causa raiz acionável, não uma abstração vazia

Uma resposta forte costuma soar assim:

“Eu trataria o sintoma como ponto de entrada e iria descendo até uma explicação que feche a cadeia do comportamento observado. Mitigar rápido pode ser necessário, mas eu não confundiria isso com ter entendido a causa raiz.”

Sintoma diz onde doeu. Causa raiz diz por que doeu ali.