"Resolvemos o problema de performance." Até o próximo deploy. Até o próximo feature. Até o próximo crescimento de usuários. Performance não é um projeto com início e fim — é uma prática contínua que precisa estar integrada à cultura de engenharia.
Performance não é um destino. É uma jornada que nunca termina.
O Ciclo Vicioso de Performance
O padrão comum
Fase 1: Desenvolvimento
"Foco em features, performance depois"
Fase 2: Lançamento
"Está funcionando, vamos entregar"
Fase 3: Crescimento
"Por que está ficando lento?"
Fase 4: Crise
"Precisamos de um projeto de performance!"
Fase 5: Correção
"Resolvemos!" (volta para Fase 1)
Por que acontece
Incentivos desalinhados:
- Features são visíveis, performance não
- Deadline pressiona cortar "extras"
- Performance parece funcionar até quebrar
Falta de processo:
- Sem SLOs definidos
- Sem testes de performance em CI
- Sem monitoramento proativo
Débito técnico:
- "Otimizamos depois"
- "Funciona para o volume atual"
- "Quando for problema, resolvemos"
Integrando Performance no Ciclo
Shift-Left: Performance desde o design
No Design:
- Considerar escala esperada
- Escolher arquitetura adequada
- Definir SLOs preliminares
No Desenvolvimento:
- Profiling local
- Testes de performance unitários
- Code review com olhar de performance
No PR:
- Testes de carga automatizados
- Benchmark antes/depois
- Verificação de regressão
SLOs como contrato
Definir SLOs antes de desenvolver:
Checkout API:
- Latência p95: < 500ms
- Disponibilidade: 99.9%
- Error rate: < 0.1%
Tracking:
- Dashboard de SLO compliance
- Alertas quando degradando
- Error budget review semanal
Performance no CI/CD
Pipeline stages:
1. Unit tests (inclui performance):
- Benchmarks de funções críticas
- Comparação com baseline
- Fail se regressão > 10%
2. Integration tests:
- Load test básico (smoke)
- Verifica se ainda funciona sob carga
3. Pre-prod:
- Load test completo
- Comparação com produção atual
- Gate de aprovação
4. Deploy:
- Canary com métricas
- Rollback automático se degradar
Cultura de Performance
Ownership distribuído
Não é responsabilidade de um time:
❌ "O time de performance resolve"
É responsabilidade de todos:
✅ "Cada time é dono da performance do seu serviço"
Modelo:
- Time A: SLO de serviço A
- Time B: SLO de serviço B
- Platform: Ferramentas e padrões
- SRE: Alertas e incident response
Métricas visíveis
Dashboards públicos:
- SLO compliance por serviço
- Trending de latência
- Error budget restante
Revisões regulares:
- Weekly: Team review de métricas
- Monthly: Engineering-wide review
- Quarterly: Executive report
Incentivos alinhados
OKRs que incluem performance:
❌ "Entregar feature X"
✅ "Entregar feature X mantendo p95 < 500ms"
Celebrar melhorias:
- Reconhecer otimizações
- Compartilhar aprendizados
- Post-mortems de melhorias (não só incidentes)
Práticas Contínuas
Monitoring como hábito
Diário:
- Revisar dashboards key
- Verificar alertas pendentes
- Notar tendências
Semanal:
- Review de SLO compliance
- Análise de slow queries
- Revisão de error budget
Mensal:
- Capacity planning update
- Trend analysis
- Próximos bottlenecks
Performance reviews
A cada release major:
- Stress test completo
- Comparação com release anterior
- Identificar regressões
A cada quarter:
- Revisão de arquitetura
- Validar que escala para próximo quarter
- Identificar débito de performance
Chaos engineering
Regular:
- Falhar instâncias
- Simular latência de dependências
- Testar circuit breakers
Gamedays:
- Simular Black Friday
- Resposta a incidentes
- Validar runbooks
Planejando para Crescimento
Capacity planning contínuo
Dados necessários:
- Crescimento histórico de carga
- Capacidade atual (do stress test)
- Eventos futuros conhecidos
Processo mensal:
1. Atualizar projeção de carga
2. Comparar com capacidade
3. Identificar quando atinge limite
4. Planejar ações (escalar, otimizar)
Output:
- Timeline de capacidade
- Budget necessário
- Decisões para próximo quarter
Roadmap de performance
Assim como roadmap de produto:
Q1:
- Implementar caching layer
- Otimizar queries críticas
- Setup de stress test automatizado
Q2:
- Read replicas para DB
- CDN para assets estáticos
- Autoscaling configuration
Q3:
- Sharding de dados
- Async processing para jobs
- Cache de edge
Q4:
- Multi-region setup
- Global load balancing
- Disaster recovery
Evitando Regressões
Gates de qualidade
PR não passa se:
- Benchmark regredir > 5%
- Novo endpoint sem SLO definido
- Query sem EXPLAIN documentado
- Falta de cache para dados estáticos
Deploy não acontece se:
- Load test falhar
- Canary mostrar degradação
- Error budget exaurido
Alertas proativos
Alertar antes de virar problema:
Trend alerts:
- Latência crescendo 5%/dia por 3 dias
- Memory crescendo consistentemente
- Error rate aumentando gradualmente
Capacity alerts:
- CPU approaching 70%
- Disk approaching 80%
- Connection pool approaching limit
O Papel da Liderança
Executivos
Responsabilidades:
- Incluir performance em goals
- Alocar budget para infraestrutura
- Celebrar melhorias publicamente
Perguntas a fazer:
- "Qual nossa capacidade atual?"
- "Quando atingimos o limite?"
- "Qual o custo de não investir?"
Engineering managers
Responsabilidades:
- Proteger tempo para performance
- Balancear features com tech debt
- Garantir ownership de SLOs
Perguntas a fazer:
- "Quais são os SLOs do time?"
- "Estamos dentro do error budget?"
- "Qual o maior risco de performance?"
Engenheiros
Responsabilidades:
- Considerar performance no design
- Escrever código com performance em mente
- Monitorar serviços que desenvolveu
Perguntas a fazer:
- "Isso escala para 10x?"
- "Qual a complexidade dessa operação?"
- "Precisa de cache?"
Conclusão
Performance sustentável requer:
- Integração no ciclo - não como afterthought
- SLOs como contrato - definidos e medidos
- Ownership distribuído - cada time responsável
- Monitoramento contínuo - não só quando quebra
- Planejamento proativo - capacity planning regular
- Cultura de performance - incentivos alinhados
A metodologia OCTOPUS não é um projeto — é uma prática contínua.
O melhor momento para pensar em performance é antes de ter problema. O segundo melhor momento é agora.
Este artigo encerra a série sobre a metodologia OCTOPUS de Performance Engineering.