Um bug intermitente costuma depender de uma condição que só existe em produção: volume, dados reais, horário, configuração ou uma integração externa. Para achar a causa, registre cada ocorrência, junte as evidências, procure o que as ocorrências têm em comum e confirme a causa antes de alterar o código.
Por que o erro só aparece em produção
O erro parece aleatório, mas quase sempre tem uma condição por trás. Ela só existe no ambiente real:
- Volume e acessos ao mesmo tempo: duas pessoas alterando o mesmo registro, ou muitos acessos no horário de pico, geram conflitos que não aparecem em testes com um usuário só. Isso é chamado de concorrência.
- Dados reais: cadastros antigos, campos vazios ou caracteres especiais que os dados de exemplo não têm.
- Configuração diferente: permissões, versões, parâmetros e serviços que não são iguais no ambiente de testes (homologação) e no de produção.
- Integrações externas: uma API ou serviço que às vezes demora a responder e estoura o tempo limite (timeout).
- Rotinas agendadas: processos que rodam em determinado horário e disputam os mesmos dados com os usuários.
Antes de mexer no código: registre cada ocorrência
A operação pode ajudar muito antes de qualquer análise técnica. Cada ocorrência bem registrada é uma pista:
| O que registrar | Por que ajuda |
|---|---|
| Data e hora exatas | Permite cruzar com os logs (registros que o sistema grava) e com rotinas agendadas |
| Usuário e tela ou rotina | Mostra se a falha depende de perfil, permissão ou funcionalidade |
| O que estava sendo feito | Ajuda a refazer o caminho até o erro |
| Mensagem de erro (print) | Evita interpretações diferentes da mesma falha |
| Registro envolvido (pedido, nota, cliente) | Permite verificar se o problema está no dado |
| Frequência | Indica se o erro aumenta com o volume ou com o horário |
Se o sistema não guarda logs suficientes para responder a essas perguntas, esse é o primeiro ajuste. Monitoramento e alertas ajudam a perceber a falha antes do usuário.
Passo a passo da investigação
- Meça o impacto e contenha: defina a urgência e, se preciso, um contorno temporário para a operação seguir. O contorno não pode esconder o erro: as ocorrências continuam sendo registradas.
- Junte as evidências: logs da aplicação, registros do banco de dados, histórico de mudanças recentes e as ocorrências anotadas pela operação.
- Procure o padrão: o que as ocorrências têm em comum? Horário, usuário, volume, tipo de dado, versão do sistema ou uma integração específica.
- Reproduza em ambiente separado: com o padrão em mãos, recrie as condições (cópia dos dados, acessos simultâneos, mesma configuração) fora da produção.
- Confirme a causa antes de alterar o código: corrigir pela suposição faz a falha sumir por um tempo e voltar depois.
- Corrija com testes e plano de reversão: teste o ajuste e as funções afetadas, aplique em uma janela combinada e tenha um caminho para desfazer a mudança se algo sair errado. Depois, acompanhe para confirmar que o erro não voltou.
Causas mais comuns
- Bloqueios no banco de dados: duas operações tentando alterar os mesmos dados ao mesmo tempo, gerando espera ou travamento (locks e deadlocks).
- Tempo de resposta de integrações: chamadas a APIs e sistemas externos sem tratamento para demora ou falha. Veja como tornar a integração de sistemas mais confiável.
- Dados fora do padrão: registros que a regra de negócio não previu.
- Diferenças entre ambientes: o que foi testado não é exatamente o que está em produção.
- Rotinas que se sobrepõem: processos agendados rodando junto com o uso intenso do sistema.
- Falta de recursos: memória, disco ou conexões com o banco que se esgotam em momentos de pico.
Erros comuns
- Corrigir pela suposição: a falha some por um tempo e volta, e a equipe perde a confiança no sistema.
- Reiniciar como solução: reiniciar alivia o sintoma, mas apaga pistas e não trata a causa. Registre o momento antes de reiniciar.
- Mudar várias coisas de uma vez: se o erro parar, ninguém sabe qual mudança resolveu.
- Testar só com dados de exemplo: o teste precisa reproduzir as condições reais.
- Não registrar o que foi encontrado: a próxima falha parecida começa do zero.
Quando chamar ajuda externa
Vale trazer uma equipe de fora quando a falha volta mesmo depois de correções, envolve mais de um sistema ou banco de dados, a equipe interna não tem tempo para uma investigação profunda ou o sistema foi herdado sem documentação.
A RTX investiga bugs complexos em sistemas, inclusive em sistemas desenvolvidos por outras equipes, analisando código, banco de dados, integrações e ambiente até confirmar a causa. Quando o problema é recorrente, a sustentação contínua mantém o sistema estável.