Problemas de performance em produção não avisam. O sistema que respondia em milissegundos começa a arrastar, e cada minuto de lentidão custa usuários, receita e reputação. A boa notícia: com um método disciplinado, dá para diagnosticar e corrigir sem transformar o incidente em catástrofe. Este guia entrega o passo a passo que engenheiros experientes usam quando o ambiente é real e o relógio está correndo.
Antes de começar, você precisa de acesso a métricas de infraestrutura e aplicação, logs centralizados, ferramentas de tracing distribuído e permissão para reiniciar serviços ou ajustar configurações. Sem isso, o diagnóstico vira adivinhação.
Passo 1: Estabeleça a linha de base e o desvio
Não dá para consertar o que você não mede. Antes de tocar em qualquer coisa, registre o comportamento atual: latência média e percentil 95, taxa de erros, throughput e uso de recursos (CPU, memória, disco, rede). Compare com o mesmo horário de dias anteriores. O desvio é a pista.
Erro comum: olhar apenas a média. Uma média de 200 ms pode esconder picos de 5 segundos que afetam parte dos usuários. Sempre cheque os percentis 95 e 99.
Passo 2: Isole o componente culpado
Com o desvio mapeado, divida o sistema em camadas: front-end, API, banco de dados, cache, filas. Meça a latência de cada salto. Se a API responde rápido mas o banco demora, o gargalo está na consulta. Se o front-end demora mas a API está ok, o problema pode ser renderização ou rede.
Dica: use tracing distribuído para ver o tempo gasto em cada serviço. Sem ele, você fica no escuro. Evite reiniciar serviços aleatoriamente antes de isolar a camada, isso só apaga evidências.
Passo 3: Analise logs e traces com foco
Logs de erro são úteis, mas logs de lentidão são ouro. Procure por consultas SQL lentas, timeouts, garbage collection frequente, locks de banco e filas entupidas. Filtre por período e por transação específica. Ferramentas de APM mostram traces completos de uma requisição lenta.
Erro comum: ignorar logs de aviso. Um aviso de conexão reciclada pode ser o sintoma de um pool mal dimensionado que só quebra sob carga.
Passo 4: Reproduza o cenário em ambiente controlado
Se possível, replique a carga e os dados de produção em um ambiente de staging. Use dados anonimizados ou sintéticos que mantenham a mesma distribuição. Rode testes de carga com ferramentas como k6 ou JMeter para confirmar a hipótese. Se não puder reproduzir, documente as condições exatas do incidente para correlacionar depois.
Dica: não confie em ambientes de teste com volume de dados irrisório. Um banco com 100 linhas não simula um com 10 milhões.
Passo 5: Aplique correções graduais e mensuráveis
Corrija uma variável por vez. Ajuste um índice, aumente o pool de conexões, otimize uma consulta. Meça o impacto imediatamente. Se a latência cair, mantenha. Se não, reverta. Isso evita que você crie novos problemas sem saber a causa.
Erro comum: fazer várias mudanças de uma vez. Quando o sistema melhora, você não sabe o que funcionou; quando piora, não sabe o que quebrou.
Passo 6: Valide em produção e monitore de perto
Após a correção, acompanhe as mesmas métricas da linha de base por pelo menos 24 horas. Verifique se o desvio sumiu e se não surgiram efeitos colaterais. Documente a causa raiz e a solução no post-mortem. Isso acelera incidentes futuros.
Dica: mantenha um canal de comunicação com o time de plantão. Se algo sair do controle, o rollback precisa ser rápido.
Checklist rápido
- Linha de base registrada (latência, erros, throughput, recursos)
- Componente isolado por camadas
- Logs e traces analisados com foco em lentidão
- Cenário reproduzido em ambiente controlado
- Correção aplicada de forma gradual e mensurável
- Validação em produção com monitoramento contínuo
- Post-mortem documentado
FAQ
O que fazer primeiro ao perceber lentidão em produção?
Registre a linha de base e o desvio. Meça latência, erros e uso de recursos antes de qualquer alteração. Isso evita que você perca evidências e permite comparar o antes e o depois com precisão.
Posso debugar diretamente em produção?
Sim, com cautela. Use ferramentas de observabilidade que não interfiram no sistema, como tracing e logs. Evite reiniciar serviços ou alterar configurações sem isolar o problema. Se precisar testar, faça em ambiente controlado primeiro.
Como saber se o problema é no banco de dados ou na aplicação?
Meça a latência de cada camada. Se a aplicação responde rápido mas a consulta ao banco demora, o gargalo está no banco. Tracing distribuído mostra o tempo gasto em cada serviço e ajuda a isolar a causa.
Qual a importância dos percentis 95 e 99?
Eles revelam a experiência da cauda longa de usuários. Uma média baixa pode esconder picos que afetam parte do público. Monitorar percentis altos garante que você não ignore problemas que atingem usuários específicos.
Devo fazer várias correções de uma vez?
Não. Altere uma variável por vez e meça o impacto. Isso permite identificar o que realmente funcionou e evita que novas mudanças mascarem ou piorem o problema original.
Como validar se a correção funcionou?
Compare as métricas atuais com a linha de base por pelo menos 24 horas. Verifique se o desvio sumiu e se não surgiram efeitos colaterais. Documente a causa raiz e a solução no post-mortem para referência futura.
