Bug intermitente: por onde começar

O problema

Bug intermitente mexe com a confiança do time.

Hoje falha. Amanhã passa. No seu computador funciona. Em produção volta.

E como ele não respeita roteiro, muita gente entra no modo errado:

• chama de “flaky” cedo demais
• tenta corrigir sem recorte
• troca configuração no escuro
• torce para sumir

Só que bug intermitente quase nunca é azar puro.

Normalmente existe uma condição que ainda não foi isolada.

Modelo mental

Pense assim:

bug intermitente é um bug cujo padrão ainda não foi descoberto

Essa frase ajuda porque tira a conversa do misticismo.

Se existe comportamento, existe alguma combinação de fatores por trás:

• instancia especifica
• volume
• timing
• dado
• browser
• tenant
• dependência externa

Seu trabalho é descobrir qual dessas variáveis está participando.

Quebrando o problema

Comece procurando diferença entre casos bons e ruins

Uma falha isolada conta pouco sozinha.

O que ajuda mesmo é comparar:

• quando falha
• quando passa
• o que muda entre os dois cenarios

Às vezes a pista não está no erro. Ela está no contraste.

Foque em variaveis escondidas

Quando um bug não é constante, suspeite de coisas como:

• uma instancia só do pool
• um conjunto pequeno de dados
• timeout sob latência maior
• ordem diferente de eventos
• cache velho
• dependência externa oscilando

Intermitência costuma ser a assinatura de alguma condição que não está presente o tempo todo.

Tente aumentar a chance de repetir

Nem sempre você consegue reproduzir 100%.

Mas pode aumentar a probabilidade:

• repetir muitas vezes o mesmo fluxo
• fixar o mesmo input
• testar um horario parecido
• direcionar para a mesma instancia
• simular latência
• reduzir ruido e variar uma condição por vez

Reprodução parcial já ajuda muito.

Trate cada tentativa como experimento

Se você muda cinco coisas ao mesmo tempo, o bug continua intermitente e sua investigação vira intermitente também.

Mude uma condição, observe, anote.

Esse ritmo parece menos heroico. Mas quase sempre funciona melhor.

Exemplo simples

Imagine um endpoint de salvar perfil que falha em algo perto de 1 a cada 20 requests.

Olhar só para a ultima falha pode levar a:

• mexer no ORM
• aumentar timeout
• reiniciar tudo

Mas, ao comparar requests que passam com requests que falham, o time percebe uma diferença importante:

• todas as falhas foram atendidas pelo mesmo pod

Agora o bug deixa de ser “aleatório”.

Ele vira uma pergunta objetiva:

o que existe nesse pod que não existe nos outros?

Talvez uma variável de ambiente faltando. Talvez cache corrompido. Talvez uma versão antiga ainda rodando.

O ponto é este: a comparação limpou boa parte da névoa.

Erros comuns

• Chamar de instável sem tentar achar padrão.
• Investigar só a request que falhou e ignorar as que deram certo.
• Tentar “resolver” com retry antes de entender a origem.
• Aceitar “sumiu depois do restart” como explicação.
• Confundir baixa frequência com ausência de causalidade.

Como um senior pensa

Quem tem mais experiência costuma desacelerar a ansiedade do time.

O raciocínio normalmente é:

“Se aparece e some, alguma variável ainda está escapando da nossa observação. Antes de corrigir, eu quero comparar casos bons e ruins e descobrir o que muda entre eles.”

Esse tipo de pensamento não romantiza o bug.

Só trata intermitência como falta de visibilidade suficiente.

O que o entrevistador quer ver

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

O avaliador quer ver se você:

• procura padrão em vez de reclamar da aleatoriedade
• compara casos que passam e falham
• levanta hipóteses sobre variáveis escondidas
• tenta aumentar a reproducibilidade com método

Uma resposta forte costuma soar assim:

“Eu partiria da comparação entre requests boas e ruins para descobrir o que muda de verdade. Bug intermitente normalmente aponta para uma condição que aparece só em parte do tempo, então eu tentaria isolar ambiente, dado, timing ou instância antes de propor correção.”

Bug intermitente não é bug sem causa. É bug com causa ainda mal observada.

Quando o padrão aparece, a intermitência deixa de ser mistério e vira engenharia de novo.