A maioria das falhas de performance não são técnicas — são organizacionais. Times talentosos falham por padrões repetitivos que podem ser identificados e corrigidos. Este artigo explora os erros mais comuns e como evitá-los.
Se seu time continua tendo os mesmos problemas de performance, o problema não é técnico. É sistêmico.
Padrão 1: Performance como Afterthought
O problema
Sprint 1-5: Implementar features
Sprint 6: "Agora vamos otimizar"
Realidade:
- Dívida de performance acumulada
- Arquitetura difícil de otimizar
- Deadline pressionando
- "Otimização fica para depois"
Por que acontece
- Pressão por features visíveis
- Performance não é critério de "done"
- Não há SLOs definidos
- "Funciona na minha máquina"
Como evitar
Definition of Done:
- [ ] Feature implementada
- [ ] Testes passando
- [ ] Performance dentro do SLO
- [ ] Sem regressão em métricas
Shift Left:
- Testes de performance no CI
- SLOs desde o início
- Review de performance em PRs
Padrão 2: Otimização Prematura
O problema
# Dev passa 2 dias otimizando
cache = LRUCache(size=1000)
bloom_filter = BloomFilter(capacity=1000000)
sharding = ConsistentHash(nodes=16)
# Função é chamada 10 vezes por dia
# Tempo economizado: 0.001 segundos/dia
Por que acontece
- Não há profiling
- Otimizar é "divertido"
- Suposições sobre gargalos
- Síndrome do desenvolvedor entediado
Como evitar
# Regra: Profile first, optimize second
def should_optimize(function):
profile = run_profiler()
# Só otimiza se:
# 1. Está no top 10 de consumo
# 2. É chamada frequentemente
# 3. Tempo > threshold
if profile.is_hotspot(function):
return True
return False
Padrão 3: Culpar o Framework
O problema
"Node é lento"
"Python não escala"
"Java consome muita memória"
"Kubernetes é overhead"
Realidade:
- Netflix usa Node (bilhões de requests)
- Instagram usa Python (2B usuários)
- LinkedIn usa Java (em escala massiva)
- Google usa Kubernetes (tudo)
Por que acontece
- É mais fácil culpar tecnologia
- Evita admitir problemas de código
- Falta de conhecimento da ferramenta
- Grass is greener syndrome
Como evitar
Antes de culpar tecnologia:
1. Profile e identifique gargalo real
2. Pesquise se outros têm o mesmo problema
3. Verifique se está usando corretamente
4. Teste alternativas com dados reais
Regra: Se outros conseguem escalar, você também pode.
Padrão 4: Não Medir
O problema
"Parece mais lento"
"Acho que melhorou"
"Deve estar bom"
Sem métricas:
- Não sabe se melhorou ou piorou
- Não sabe o quanto
- Não sabe o impacto
- Decisões baseadas em feeling
Por que acontece
- "Monitoramento é caro"
- "Não temos tempo"
- "Depois a gente implementa"
- Falta de cultura de dados
Como evitar
Mínimo viável:
- Latência: p50, p95, p99
- Throughput: req/s
- Erros: % de falhas
- Saturação: CPU, memória, I/O
Ferramentas gratuitas:
- Prometheus + Grafana
- CloudWatch básico
- Elastic APM open source
Padrão 5: Testar Errado
O problema
Teste:
- 100 usuários
- 5 minutos
- Dados de dev
- Rede local
Produção:
- 10.000 usuários
- 24/7
- 10 milhões de registros
- Rede variável
Resultado: "Funcionou no teste, falhou em produção"
Por que acontece
- Testes são caros
- Ambiente de teste ≠ produção
- Não há dados realistas
- Pressa para entregar
Como evitar
Testes realistas:
Volume: Similar a produção
Duração: Tempo suficiente (soak test)
Dados: Tamanho e distribuição reais
Rede: Inclui latência real
Validação:
- Comparar métricas de teste com produção
- Se diferem muito, teste não é representativo
Padrão 6: Ignorar Alertas
O problema
Alerta: "CPU em 80%"
Time: "É só um spike, ignora"
Alerta: "CPU em 90%"
Time: "Ainda funciona"
Alerta: "CPU em 100%"
Time: "..."
Produção: Down
Por que acontece
- Alert fatigue (muitos alertas falsos)
- "Sempre foi assim"
- Falta de ownership
- Prioridades conflitantes
Como evitar
Alertas efetivos:
- Poucos e acionáveis
- Thresholds calibrados
- Runbooks claros
- Owner definido
Regra: Se alerta não requer ação, delete.
Padrão 7: Herói Individual
O problema
Time: 5 pessoas
Performance hero: 1 pessoa
Hero:
- Faz todos os profiling
- Resolve todos os incidentes
- Escreve todas as otimizações
Quando hero sai:
- Ninguém sabe como funciona
- Problemas se acumulam
- Conhecimento perdido
Por que acontece
- Hero é eficiente curto prazo
- Falta de tempo para treinar
- "João resolve mais rápido"
- Incentivos desalinhados
Como evitar
Distribuir conhecimento:
- Pair programming em incidentes
- Rotação de on-call
- Documentação obrigatória
- Sessions de knowledge sharing
Métrica: Bus factor > 2
Padrão 8: Resolver Sintomas
O problema
Sintoma: Sistema lento
"Solução": Adicionar mais servidores
Semana 1: 4 servidores
Semana 4: 8 servidores
Semana 8: 16 servidores
Custo: 4x
Root cause: Query N+1 não resolvida
Solução real: Adicionar índice
Custo: 0
Por que acontece
- Pressão por resolver rápido
- Mais fácil jogar hardware
- Falta de tempo para investigar
- "Scale first, optimize later"
Como evitar
Análise de root cause:
1. Sintoma identificado
2. 5 Whys para encontrar causa
3. Fix no root cause
4. Validar que sintoma sumiu
5. Postmortem documentado
Framework de Diagnóstico
## Checklist: Por que estamos falhando?
### Cultura
- [ ] Performance é prioridade visível?
- [ ] SLOs definidos e respeitados?
- [ ] Postmortems são blameless?
- [ ] Conhecimento distribuído?
### Processo
- [ ] Performance testing no CI?
- [ ] Alertas são acionáveis?
- [ ] Runbooks atualizados?
- [ ] Root cause analysis feita?
### Técnico
- [ ] Profiling regular?
- [ ] Testes representativos?
- [ ] Monitoramento adequado?
- [ ] Baseline definido?
Score:
0-4: Crítico
5-8: Precisa atenção
9-12: Saudável
Conclusão
Times falham em performance por padrões previsíveis:
| Padrão | Sintoma | Solução |
|---|---|---|
| Afterthought | Problemas em produção | Shift left |
| Prematura | Tempo desperdiçado | Profile first |
| Culpar tech | Mudança constante | Dominar ferramentas |
| Não medir | Decisões por feeling | Métricas básicas |
| Testar errado | Surpresas em prod | Testes realistas |
| Ignorar alertas | Incidentes evitáveis | Alertas acionáveis |
| Herói | Single point of failure | Distribuir conhecimento |
| Sintomas | Custos crescentes | Root cause analysis |
A boa notícia: todos são corrigíveis. A má notícia: requerem mudança de comportamento, não de tecnologia.
O problema raramente é que o time não sabe otimizar. O problema é que o time não está otimizando o que deveria.