Como identificar quais sao as causas de um problema sistêmico
A maioria das pessoas começa pela lista de sintomas. Vejo isso todo dia em fóruns técnicos e em reuniões de equipe. Você entra num projeto com o problema já explodido e ninguém sabe o quê, só que algo está errado. A primeira coisa que eu faço não é buscar soluções, é mapear o que aconteceu antes do problema aparecer. Isso leva tempo, mas economiza semanas de tentativa e erro depois.
quais sao as causas: o método que eu uso na prática
Eu uso uma variação do método dos 5 porquês combinada com um diagrama de Ishikawa, mas sem a burocracia das ferramentas corporativas. Começo anotando o evento problema em uma linha do tempo. Depois rastreo para trás até encontrar o primeiro ponto de divergência entre o esperado e o real. Esse ponto é onde as causas raízes começam a se formar. Um detalhe que pouca gente leva a sério: causas nunca vêm sozinhas. Sempre há pelo menos dois fatores convergindo. Eu já perdi meio dia investigando um bug que parecia ser de lógica, quando na verdade era um problema de timing entre dois serviços que só acontecia sob carga específica. Descobri isso depois de notar que o erro só aparecia entre 14h e 16h, quando o serviço de cache atingia pico de uso.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Aqui vai o passo concreto que funciona: pegue o problema e escreva três afirmações sobre ele. Uma que todo mundo concorda, uma que ninguém quer discutir, e uma que é óbvio mas ninguém mencionou. Isso já te dá duas das três causas prováveis em dez minutos. O terceiro passo é o mais importante e o mais ignorado. Você pergunta: qual causa, se removida, elimina o problema por completo? Não parcialmente. Completamente. Se a resposta não for clara, você ainda não achou a causa raiz. Achou apenas um sintoma com roupas diferentes.
Existem situações em que esse método simplesmente não funciona bem. Quando o sistema tem dezenas de variáveis interconectadas e nenhuma linha clara de causalidade, tipo em infraestruturas distribuídas complexas ou ambientes com falhas intermitentes que dependem de condições externas imprevisíveis. Nesses casos, eu recomendo usar análises estatísticas de correlação primeiro, ou monitoramento com log aggregation durante pelo menos duas semanas, antes de tentar encontrar causas individuais. Fazer análise causal em cima de dados insuficientes é a maneira mais rápida de culpar o vilão errado e gastar recurso resolvendo o problema errado. O que eu vejo muita gente errar é achar que causa raiz é a mesma coisa que causa principal. São coisas diferentes. A causa raiz é o elo mais profundo na cadeia que, se quebrado, impede que a cadeia se forme de novo. A causa principal é apenas o elo mais visível. Confundir os dois faz você aplicar um remendo onde precisava de uma reconstrução.
Sobre ferramentas, eu uso planilhas simples com colunas de data, evento, impacto e causa provável. Nada de software caro. Ferramentas caras criam a ilusão de controle sem melhorar a qualidade da análise. O que importa é o rigor com que você separa fato de suposição em cada linha que escreve.
