A maioria das iniciativas de performance começa errado: com testes. Times configuram ferramentas, criam scripts, geram carga — e descobrem que não sabem o que estão medindo nem por quê. A metodologia OCTOPUS começa diferente: com observação.
Você não pode melhorar o que não entende. E não pode entender o que não observou.
Por Que Observar Primeiro
O erro comum
Abordagem típica:
1. "Vamos fazer load test"
2. Configura k6/Gatling/JMeter
3. Cria cenário genérico
4. Roda teste
5. "Latência média: 150ms"
6. "E daí? Isso é bom ou ruim?"
7. "..."
O problema
Sem observação prévia:
- Não sabe o que é "normal"
- Não sabe quais endpoints são críticos
- Não sabe qual carga esperar
- Não sabe o que os usuários realmente fazem
- Não sabe quais métricas importam
A abordagem OCTOPUS
1. Observar sistema em produção
2. Entender padrões reais
3. Identificar o que medir
4. Estabelecer baseline
5. Então, e só então, testar
O Que Significa Observar
Não é só monitorar
Monitorar: Olhar dashboards passivamente
Observar: Buscar ativamente entendimento
Monitorar: "CPU está em 45%"
Observar: "CPU fica em 45% porque o job de
relatórios roda às 14h e compete
com o pico de usuários"
Dimensões da observação
Técnica:
- Métricas de infraestrutura
- Logs de aplicação
- Traces de requests
- Profiles de código
Negócio:
- Jornadas de usuário
- Funcionalidades críticas
- Horários de pico
- Eventos importantes
Contexto:
- Arquitetura atual
- Dependências
- Limitações conhecidas
- Histórico de incidentes
Fase O: Observe na Prática
Passo 1: Mapear o sistema
## System Map
### Componentes
- API Gateway (Kong)
- 3 microserviços (Node.js)
- PostgreSQL (RDS)
- Redis (ElastiCache)
- S3 para assets
### Fluxos críticos
1. Login → Auth Service → DB
2. Listagem → Catalog Service → DB + Cache
3. Checkout → Order Service → DB + Payment Gateway
### Dependências externas
- Payment Gateway (Stripe)
- Email Service (SendGrid)
- Analytics (Segment)
Passo 2: Coletar métricas existentes
-- Entender padrões de tráfego
SELECT
date_trunc('hour', created_at) as hora,
count(*) as requests
FROM access_logs
WHERE created_at > now() - interval '7 days'
GROUP BY 1
ORDER BY 1;
# Distribuição de latência atual
histogram_quantile(0.50, rate(http_request_duration_seconds_bucket[24h]))
histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[24h]))
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[24h]))
Passo 3: Entender o negócio
## Perguntas para stakeholders
1. Quais funcionalidades são críticas para o negócio?
→ "Checkout não pode falhar, é onde geramos receita"
2. Qual o horário de maior uso?
→ "Das 10h às 12h e das 19h às 22h"
3. Há eventos especiais planejados?
→ "Black Friday em 3 meses, esperamos 10x tráfego"
4. Qual a tolerância para lentidão?
→ "Usuários reclamam se página demora mais de 3s"
5. Houve incidentes recentes?
→ "Mês passado tivemos outage por 2h no checkout"
Passo 4: Documentar descobertas
## Observações - Sistema XYZ
### Padrões de tráfego
- Pico: 10h-12h (3x baseline)
- Vale: 2h-6h (0.1x baseline)
- Fim de semana: 40% do weekday
### Latência atual
- p50: 45ms
- p95: 180ms
- p99: 450ms
### Gargalos observados
1. DB connection pool satura às 11h
2. Redis hit rate cai para 60% após deploys
3. Payment gateway tem picos de 2s
### Endpoints críticos
1. POST /api/checkout (receita)
2. GET /api/products (experiência)
3. POST /api/auth/login (acesso)
### Riscos identificados
- Single point of failure no DB
- Sem circuit breaker para payment
- Logs não estruturados dificultam debug
Ferramentas para Observação
Métricas
Infraestrutura:
- Prometheus + Grafana
- CloudWatch
- Datadog
Aplicação:
- APM (New Relic, Datadog, Dynatrace)
- Custom metrics
Negócio:
- Google Analytics
- Mixpanel
- Amplitude
Logs
Agregação:
- ELK Stack
- Loki + Grafana
- CloudWatch Logs
Análise:
- Queries estruturadas
- Correlação com traces
Traces
Distributed Tracing:
- Jaeger
- Zipkin
- Tempo
- X-Ray
Checklist de Observação
## Antes de testar, você sabe:
### Tráfego
- [ ] Requests por segundo atuais?
- [ ] Distribuição por endpoint?
- [ ] Padrão diário/semanal?
- [ ] Picos históricos?
### Performance
- [ ] Latência atual (p50, p95, p99)?
- [ ] Taxa de erro atual?
- [ ] Throughput máximo já atingido?
### Recursos
- [ ] Utilização de CPU/memória?
- [ ] Conexões de DB?
- [ ] Cache hit rate?
### Negócio
- [ ] Endpoints críticos?
- [ ] SLOs existentes?
- [ ] Tolerância a degradação?
### Contexto
- [ ] Arquitetura documentada?
- [ ] Dependências mapeadas?
- [ ] Histórico de incidentes?
Se respondeu "não" para mais de 3 itens,
você não está pronto para testar.
Quanto Tempo Observar
Regra geral
Mínimo: 1 semana de dados
Ideal: 1 mês de dados
Para eventos sazonais: 1 ano de dados
Por quê?
1 dia: Vê padrão diário, perde variação semanal
1 semana: Vê padrão semanal, perde mensal
1 mês: Vê maioria dos padrões normais
1 ano: Captura sazonalidade (Black Friday, férias, etc.)
Erros Comuns
1. Pular observação por pressa
❌ "Não temos tempo, vamos direto ao teste"
→ Testa errado, repete trabalho
✅ "Vamos investir 2 dias observando"
→ Testa certo, economiza semanas
2. Observar só infraestrutura
❌ "CPU e memória estão ok"
→ Ignora gargalo no código
✅ "CPU ok, mas latência p99 está alta"
→ Investiga além da infra
3. Não envolver negócio
❌ "O sistema aguenta 10K req/s"
→ Mas negócio precisa de 50K
✅ "Negócio espera 50K, hoje fazemos 10K"
→ Teste tem objetivo claro
Conclusão
A fase Observe da metodologia OCTOPUS estabelece a fundação:
- Entenda o sistema antes de estressar
- Conheça o baseline antes de medir mudanças
- Alinhe com negócio antes de definir metas
- Documente tudo para referência futura
Tempo investido em observação é multiplicado em qualidade de testes.
Testar sem observar é como dirigir sem saber para onde vai. Você vai chegar em algum lugar, mas provavelmente não onde precisa.
Este artigo faz parte da série sobre a metodologia OCTOPUS de Performance Engineering.