Ninguém Consegue Reproduzir o Problema em Produção

“Funciona para a gente”

Um usuário relata:

“Pagamentos falham aleatoriamente.”

O Desenvolvimento tenta. Funciona.

O QA tenta. Funciona.

UAT? Funciona lá também.

Depois vem a frase que pode matar uma investigação silenciosamente:

“A gente não consegue reproduzir.”

Isso não significa que o problema não existe.

Significa:

Ainda não reproduzimos as condições que o criam.

É aí que a investigação começa.

Aqui está a situação

Imagine uma plataforma de e-commerce.

Alguns clientes dizem que pagamentos às vezes falham depois que clicam em Pagar Agora.

Nenhum padrão óbvio.

O QA roda vinte pagamentos com sucesso na UAT.

O Desenvolvimento tenta localmente. Sucesso.

O monitoramento de produção não mostra nenhuma queda importante.

Então, e agora?

O erro é rodar o mesmo teste de novo e de novo.

A pergunta melhor é:

O que foi diferente quando a falha aconteceu?

Vamos seguir um pagamento que falhou e descobrir.

1. Escute & Capture — consiga a história de verdade

Não comece com:

“Você consegue reproduzir de novo?”

Comece com o que realmente aconteceu. Pergunte:

• O que você estava tentando fazer?
• Quando aconteceu?
• O que você esperava?
• O que aconteceu em vez disso?
• Já aconteceu antes?
• Tentar de novo funcionou?

Capture qualquer evidência disponível:

timestamp → ID de usuário/referência → ID de transação/pedido → erro → screenshot → sequência

Compare esses dois relatos:

“O pagamento falhou ontem.”

versus:

“O Pedido 78431 falhou às 14:07 depois da verificação de OTP.”

O segundo dá ao time por onde começar.

No nosso caso de pagamento — capturamos: pedido 78431, horário 14:07, dispositivo Android, pagamento cartão internacional, falha depois da verificação de OTP.

Já ali, “aleatório” ficou um pouco menos aleatório.

2. Colete Evidências — antes que elas desapareçam

Problemas intermitentes são mais fáceis de investigar enquanto a evidência ainda existe. Procure por:

• logs da aplicação
• respostas de API
• IDs de correlação ou trace
• timestamps
• histórico de auditoria
• monitoramento
• detalhes de requisição/resposta onde for apropriado

Não colete dado sensível de produção sem cuidado. Use acesso aprovado, mascaramento e controles de segurança.

O objetivo não é mais logs. O objetivo é seguir uma jornada com falha.

No nosso caso de pagamento — o time rastreia o pedido 78431. A requisição de pagamento chegou na aplicação. Passou pela verificação de OTP. Depois um serviço de pagamento downstream rejeitou a requisição. Agora sabemos onde olhar a seguir.

3. Entenda o Contexto — o que foi diferente?

A mesma funcionalidade pode se comportar de forma diferente dependendo do que a cerca. Confira as condições ao redor da falha:

• Usuário — papel, permissões, tipo de cliente
• Dispositivo — navegador, versão do app, sistema operacional
• Localização — região, rede, fuso horário
• Dado — estado da conta, valor, moeda, produto
• Timing — período de pico, jobs agendados, janelas de batch
• Sequência — o que aconteceu imediatamente antes da falha?

Talvez o problema afete só:

Usuários Android numa versão mais antiga do app.

Ou:

Clientes com dois endereços.

Ou:

Transações acima de um certo valor.

Ou:

Requisições chegando enquanto um batch agendado trava um registro.

Você está procurando um padrão escondido dentro da palavra “aleatório.”

No nosso caso de pagamento — o time compara transações com sucesso e com falha. Uma pista aparece: a maioria das falhas envolve cartões internacionais. Essa vira a próxima hipótese.

4. Compare Ambientes — não compare só código

Uma suposição comum é:

“Mesmo código, então deveria se comportar do mesmo jeito.”

Mas a produção pode diferir da UAT em:

• dado
• configuração
• feature flags
• permissões
• integrações
• versões de serviço
• tráfego
• comportamento de rede
• agendamentos
• infraestrutura

Então compare UAT vs Produção, não só código vs código. Pergunte:

O que existe na produção que nosso ambiente de teste não reproduz?

No nosso caso de pagamento — a UAT usa um provedor de pagamento de teste. A produção roteia certos pagamentos internacionais através de outro provedor. Mesma aplicação. Caminho diferente. Agora a investigação está ficando mais estreita.

5. Replique de Forma Mais Inteligente — recrie condições, não só passos

O usuário seguiu:

Login → Selecionar produto → Pagar → Falha

Repetir esses passos pode não recriar o problema. Tente combinar as condições ao redor:

• mesmo dado
• mesmo tipo de usuário
• mesmo dispositivo/versão do app
• mesma configuração
• mesmo caminho de integração
• mesma sequência
• timing/carga parecidos onde for seguro

O objetivo não é copiar a produção de forma irresponsável. É recriar o menor conjunto de condições que dispara a falha.

No nosso caso de pagamento — o QA agora testa: cartão internacional → mesma rota de pagamento → payload parecido. A falha aparece. Pela primeira vez, o time consegue reproduzir.

6. Aumente a Visibilidade — quando o sistema não está te contando o suficiente

Às vezes você não consegue reproduzir um problema porque o sistema não expõe evidência suficiente. Essa ausência já é uma informação útil. O time pode precisar de:

• logging mais estruturado
• IDs de correlação
• métricas
• alertas
• eventos de auditoria
• diagnósticos temporários
• monitoramento mais seguro no nível da funcionalidade

Um BA não precisa desenhar a plataforma de observabilidade. Mas um BA pode perguntar:

“Se isso acontecer de novo, que evidência a gente vai precisar para provar onde falhou?”

Isso pode virar um requisito.

7. Isole & Estreite — mude uma coisa por vez

Uma vez que você tem uma hipótese, estreite ela. Suponha que pagamentos internacionais pareçam suspeitos. Compare:

• Doméstico vs internacional.
• Uma moeda vs outra.
• Mobile vs web.
• Cliente existente vs cliente novo.
• Provedor de pagamento A vs provedor B.
• Uma configuração vs outra.

Não mude cinco variáveis juntas. Você está tentando transformar:

“Falha às vezes.”

em:

“Falha quando essas condições são verdadeiras.”

No nosso caso de pagamento — o time eventualmente isola isto: cartão internacional + provedor de pagamento específico + endereço contendo um caractere especial. Agora a falha não é mais aleatória.

8. Prove & Corrija — não pare em “provavelmente”

A causa raiz é encontrada. Um serviço de pagamento downstream rejeita certos caracteres de endereço por causa de um problema de codificação. Agora temos:

gatilho → ponto de falha → causa raiz

O time corrige. Mas não pare aí. Verifique se:

1. a condição de falha original agora funciona
2. os cenários relacionados continuam funcionando
3. a correção se comporta corretamente sob condições parecidas com a produção
4. o monitoramento consegue detectar recorrência onde for apropriado

“O desenvolvedor disse que corrigiu” não é encerramento.

Evidência é encerramento.

Lugares comuns para investigar

Quando você ainda não tem uma hipótese forte, olhe algumas áreas amplas.

• Dado — nulos, formatos inesperados, valores de fronteira, registros antigos ou migrados
• Configuração — feature flags, variáveis de ambiente, limites, regras de roteamento
• Código / Lógica — casos extremos, condições de corrida, tratamento de erro, transições de estado
• Dependências — serviços de terceiros, timeouts, problemas de rede, diferenças de versão
• Usuário / Acesso — permissões, papéis, direitos, segmentos de cliente
• Timing / Carga — tráfego de pico, jobs agendados, processamento assíncrono, concorrência

Não marque caixas cegamente. Use essas áreas para gerar hipóteses melhores.

O erro de BA a evitar

Um usuário diz:

“Falhou.”

O time diz:

“A gente testou e funciona.”

As duas afirmações podem ser verdadeiras.

Não transforme a investigação num debate sobre quem está certo. Pergunte:

“O que foi diferente quando falhou?”

Fique curioso. Não defensivo.

Antes de fechar o problema

Às vezes um problema intermitente não pode ser tornado perfeitamente determinístico. Tudo bem.

O encerramento deveria ainda assim se basear em evidência — não exaustão.

O Playbook de Investigação de Problema em Produção

• Escute & Capture → Consiga a história exata.
• Colete Evidências → Preserve a jornada com falha.
• Entenda o Contexto → Encontre as condições ao redor.
• Compare Ambientes → Identifique o que difere.
• Replique de Forma Mais Inteligente → Recrie condições, não só passos.
• Aumente a Visibilidade → Capture a evidência que está faltando.
• Isole & Estreite → Encontre o gatilho.
• Prove & Corrija → Confirme, corrija e verifique.

Checklist de Investigação de Problema em Produção

Copie isso para o Jira, Confluence ou suas notas de incidente.

O que fica

“Não conseguimos reproduzir” não é uma causa raiz.

É um status de investigação.

Se o usuário está enfrentando isso, o problema é real — mesmo quando seu teste passa.

Não fique repetindo o mesmo teste esperando que o bug apareça.

Capture a jornada com falha. Compare as condições. Encontre o que mudou. Estreite o gatilho. Depois prove.

Uma boa investigação transforma “aleatório” num padrão — e um padrão numa correção.