"Os dados mostram que precisamos agir." Mas fazer o quê, exatamente? Dados de performance são abundantes, mas transformá-los em decisões é uma habilidade rara. Este artigo ensina a usar dados para guiar escolhas, não apenas para gerar relatórios.
Dados informam decisões. Eles não tomam decisões.
O Gap Entre Dados e Decisão
Dados que não viram ação
Cenário comum:
Dashboard: "p99 latência = 2s"
Reunião: "Interessante"
Ação: Nenhuma
Por quê:
- Dado não conectado a impacto
- Nenhum threshold definido
- Responsabilidade não clara
- Próximo passo não óbvio
Dados que viram ação
Cenário efetivo:
Dashboard: "p99 = 2s (SLO: 1s) - Afeta 5% dos checkouts"
Reunião: "Estamos 2x acima do SLO"
Ação: "Sprint de otimização de DB"
Diferença:
- Dado conectado a SLO
- Impacto quantificado
- Owner identificado
- Ação clara
Framework de Decisão
1. Conectar dado a objetivo
Dado bruto:
"CPU em 85%"
Com contexto:
"CPU em 85% (target: <70% para headroom)
Risco: Próximo pico pode causar degradação"
Com decisão:
"Opções:
A) Escalar agora ($X/mês)
B) Otimizar código (Y sprints)
C) Aceitar risco (probabilidade Z%)"
2. Definir thresholds de ação
Para cada métrica crítica, definir:
p95 Latência de Checkout:
Verde: < 500ms → Nenhuma ação
Amarelo: 500-800ms → Investigar em 48h
Vermelho: > 800ms → Ação imediata
Crítico: > 2s → Incident
Error Rate:
Verde: < 0.5% → Nenhuma ação
Amarelo: 0.5-1% → Investigar
Vermelho: > 1% → Ação imediata
Crítico: > 5% → Incident
3. Mapear decisões padrão
Se [condição], então [ação], owner [quem]
Exemplos:
Se p95 > SLO por 2 dias:
→ Criar ticket de investigação
→ Owner: Tech Lead
→ Prazo: 5 dias úteis
Se CPU > 80% por 1 hora:
→ Alerta para on-call
→ Avaliar escala automática
→ Owner: SRE
Se error rate > 1% por 15 min:
→ Incident automático
→ Owner: On-call
→ Comunicação: Slack #incidents
Tipos de Decisão
Decisões operacionais (minutos)
Gatilho: Alerta de threshold
Dados: Métricas real-time
Decisor: On-call / automação
Exemplos:
- Escalar automaticamente
- Ativar circuit breaker
- Redirecionar tráfego
- Rollback de deploy
Framework:
Se X, então Y automaticamente
Se não resolver em Z minutos, escalar
Decisões táticas (dias/semanas)
Gatilho: Trend de degradação / Gap em SLO
Dados: Métricas agregadas, análise de causa
Decisor: Tech Lead / Engineering Manager
Exemplos:
- Priorizar otimização no sprint
- Adicionar cache para endpoint
- Refatorar query problemática
- Aumentar capacidade de infra
Framework:
Análise de custo-benefício
Priorização no backlog
Timeline de implementação
Decisões estratégicas (meses)
Gatilho: Capacity planning / Roadmap
Dados: Trends de longo prazo, projeções
Decisor: VP Eng / CTO
Exemplos:
- Migrar para arquitetura diferente
- Investir em plataforma de observabilidade
- Contratar time de SRE
- Mudar provedor de cloud
Framework:
Business case com ROI
Análise de alternativas
Roadmap de implementação
Traduzindo Dados para Stakeholders
Para engenharia
Dados técnicos detalhados:
- Percentis de latência por endpoint
- Breakdown de tempo por componente
- Utilização de recursos
- Correlações identificadas
Decisão clara:
"Query X é responsável por 40% da latência.
Adicionar índice resolve em 2 horas.
Priorizar?"
Para produto
Dados de experiência:
- Tempo de carregamento por feature
- Taxa de erro por fluxo
- Impacto em funil de conversão
Decisão clara:
"Checkout lento está causando 5% de abandono.
Investir 1 sprint melhora conversão em ~1%.
Valor: $X/mês. Priorizar?"
Para executivos
Dados de impacto:
- Receita em risco
- Custo de inação
- ROI de investimento
Decisão clara:
"Capacidade atual não suporta Black Friday.
Opção A: $50K para garantir.
Opção B: Risco de $200K em vendas perdidas.
Decisão necessária até [data]."
Documentando Decisões
Template de decisão
# Decisão: [Título]
## Contexto
- Data: [quando]
- Gatilho: [o que motivou]
- Dados: [métricas relevantes]
## Problema
[Descrição clara do problema]
## Opções Consideradas
### Opção A: [Nome]
- Descrição: [o que fazer]
- Custo: [tempo, dinheiro, esforço]
- Benefício: [resultado esperado]
- Risco: [o que pode dar errado]
### Opção B: [Nome]
[mesma estrutura]
## Decisão
- Escolhida: [qual opção]
- Razão: [por quê]
- Owner: [quem executa]
- Prazo: [quando]
## Métricas de Sucesso
- [Como saberemos se funcionou]
## Revisão
- Data: [quando reavaliar]
Registro de decisões (ADR)
Manter histórico de:
- Decisões tomadas
- Contexto na época
- Resultado obtido
- Lições aprendidas
Benefícios:
- Evita repetir erros
- Documenta raciocínio
- Facilita onboarding
- Cria base de conhecimento
Armadilhas na Tomada de Decisão
1. Paralisia por análise
❌ "Precisamos de mais dados antes de decidir"
(Enquanto problema persiste)
✅ "Dados atuais suportam decisão X com 80% confiança.
Risco de esperar: Y. Decidindo agora."
2. Decisão sem dados
❌ "Vamos adicionar cache porque sempre ajuda"
✅ "Dados mostram cache hit rate de 30%.
Melhorar para 80% reduziria latência em 40%.
Custo: 2 dias. Decidindo implementar."
3. Viés de confirmação
❌ Buscar dados que suportem decisão já tomada
✅ Analisar dados objetivamente, inclusive
os que contradizem a hipótese
4. Ignorar incerteza
❌ "Dados mostram que A é melhor"
(Sem intervalo de confiança)
✅ "Dados sugerem A é melhor (IC 95%: 5-15% melhoria).
Probabilidade de B ser melhor: 20%."
Automatizando Decisões
Quando automatizar
Automatizar se:
- Decisão é frequente
- Critérios são claros
- Risco de erro é baixo
- Velocidade é importante
Exemplos:
- Autoscaling baseado em CPU
- Circuit breaker baseado em error rate
- Rollback automático por métrica
Quando manter humano
Manter decisão humana se:
- Contexto é complexo
- Trade-offs não são claros
- Impacto é alto e irreversível
- Fatores não-técnicos importam
Exemplos:
- Mudança de arquitetura
- Investimento em infra
- Priorização de roadmap
Conclusão
Decisões baseadas em dados requerem:
- Conectar dados a objetivos - não números isolados
- Definir thresholds - quando agir
- Mapear ações - o que fazer quando
- Traduzir para audiência - linguagem apropriada
- Documentar decisões - criar conhecimento
Dados são o início, não o fim. O valor está na ação que eles informam.
Dados sem decisão são custo. Dados com decisão são investimento.
Este artigo faz parte da série sobre a metodologia OCTOPUS de Performance Engineering.