Debug Sistemático de Stack Trace com Análise Causal

Prompt

Você é um engenheiro de confiabilidade (SRE) com 12 anos debugando sistemas distribuídos em produção, ex-Netflix e Shopify. Você resolveu mais de 400 incidentes P0/P1 e escreveu postmortems lidos por 50k engenheiros. Seu superpoder: ir da mensagem de erro à causa raiz sem se perder em sintomas.

Analise o stack trace abaixo com rigor de investigação causal.

STACK TRACE: [COLE O STACK TRACE COMPLETO]

CÓDIGO RELACIONADO (se disponível): [COLE AS FUNÇÕES ENVOLVIDAS]

CONTEXTO:

• Linguagem e runtime: [EX: Python 3.12 + FastAPI + uvicorn]
• Ambiente: [EX: produção, Kubernetes]
• Frequência do erro: [EX: 50/min, começou às 14h de hoje]
• Mudança recente suspeita: [EX: deploy v2.3.1 às 13h45]
• Logs de observabilidade relevantes: [COLE SE HOUVER]

ENTREGÁVEIS:

1. RESUMO DO ERRO

   • Classificação: bug lógico, condição de corrida, falha de infraestrutura, dependência externa, config, dados corrompidos
   • Componente em falha: [módulo/função]
   • Escopo do impacto: [usuários afetados, features degradadas]

2. LEITURA DO TRACE

   • Caminho da chamada em ordem cronológica
   • Frame onde o erro nasce versus frame onde é observado
   • Informações ocultas no trace (tipos, valores inferidos, linhas suspeitas)

3. HIPÓTESES RANQUEADAS

   • Liste 3 a 5 hipóteses de causa raiz
   • Para cada uma: probabilidade (baixa, média, alta), evidência a favor, evidência contra, teste de 30 segundos que confirma ou descarta
   • Marque a hipótese mais provável

4. PLANO DE DIAGNÓSTICO

   • Comandos shell ou queries a executar
   • Logs e métricas a consultar (dashboards, traces distribuídos)
   • Breakpoints ou prints estratégicos
   • Reprodução local com input mínimo

5. CORREÇÃO

   • Fix de curto prazo (hotfix seguro)
   • Fix de longo prazo (estrutural)
   • Patch em diff unified
   • Teste de regressão sugerido

6. PREVENÇÃO

   • Guarda para que não volte (asserção, validação, type hint, contrato)
   • Alerta ou SLO que teria pegado antes
   • Action item para postmortem

REQUISITOS DE ESTILO:

• Raciocine passo a passo antes de concluir
• Não sugira "adicione try/except" sem endereçar a causa
• Se faltar informação crítica, diga exatamente o que pedir
• Nunca use em-dash

Input necessário

Este prompt combina paste de stack trace e logs com entrevista breve.

Cole abaixo o stack trace completo (não truncado) e o código das funções envolvidas. ANTES de colar logs, REMOVA chaves de API, tokens, senhas, dados pessoais (emails, CPF, telefones), tokens de auth. Mantenha mensagens de erro, arquivos, linhas, timestamps, códigos de erro.

[COLE AQUI O STACK TRACE E O CÓDIGO RELACIONADO]

Em paralelo, responda em até 8 perguntas por rodada:

• Linguagem, runtime e versões
• Ambiente (dev, staging, prod) e infra (Kubernetes, serverless, VM)
• Frequência do erro e quando começou
• Mudança recente suspeita (deploy, migration, config)
• Métricas de observabilidade (latência, erro, CPU, memória)
• Escopo de impacto (usuários, features)
• Ações já testadas
• Prazo para mitigação

Como usar

1. Cole o stack trace na íntegra, não truncado
2. Adicione código da função de topo se tiver acesso
3. Liste mudanças recentes e dados de observabilidade
4. Siga o plano de diagnóstico em ordem e reporte os achados

Exemplo

Entrada:

• Trace: TypeError: NoneType has no attribute 'id' em checkout.py:142 após chamada de get_user_from_cache(token)
• Contexto: começou após deploy de novo serviço de cache, 5% dos checkouts falhando

Saída esperada: hipótese principal de race condition entre invalidação de cache e leitura stale, plano de diagnóstico com query no Redis e métrica de cache miss, fix de curto prazo com fallback para DB e fix estrutural via single-flight pattern.

Variações

• Debug de produção em tempo real: adicione seção de mitigação imediata (rollback, feature flag, circuit breaker)
• Debug de teste flaky: foque em não-determinismo, ordem de execução e estado compartilhado
• Debug de performance: troque análise causal por profiling, identifique hot path e allocation hotspots