"O sistema aguenta 2000 usuários. Esperamos 5000 na Black Friday." Isso não é um problema técnico — é uma decisão de negócio. Investimos para escalar? Aceitamos o risco de degradação? Limitamos as vendas? Este artigo ensina a transformar resultados técnicos em opções executivas.
Capacidade é uma decisão de negócio, não uma constante técnica.
A Natureza Executiva do Stress Testing
O que engenharia entrega
Resultado técnico:
- Capacidade atual: 2000 req/s
- Breaking point: 2800 req/s
- Gargalo: Database connections
- Modo de falha: Graceful degradation
Isso responde: "O que o sistema pode fazer?"
O que negócio decide
Decisão executiva:
- Qual capacidade precisamos?
- Quanto investir para atingir?
- Qual risco é aceitável?
- Qual trade-off escolher?
Isso responde: "O que queremos que o sistema faça?"
Framework de Decisão
Mapeando opções
Situação: Capacidade atual 2000, necessário 5000
Opção A - Escalar:
Custo: $50K em infra + 2 sprints
Resultado: Capacidade para 6000
Risco: Baixo
Trade-off: Investimento antecipado
Opção B - Otimizar:
Custo: 3 sprints de engenharia
Resultado: Capacidade para 4000
Risco: Médio (pode não ser suficiente)
Trade-off: Tempo de engenharia
Opção C - Aceitar degradação:
Custo: Implementar rate limiting + filas
Resultado: Atende 2000 com qualidade, resto em fila
Risco: Alto (experiência degradada)
Trade-off: UX prejudicada
Opção D - Limitar demanda:
Custo: Menor promoção de marketing
Resultado: Demanda dentro da capacidade
Risco: Baixo
Trade-off: Receita potencial perdida
Critérios de decisão
Perguntas para stakeholders:
1. Custo de falha:
"Se o sistema cair por 2 horas no pico,
quanto perdemos?"
→ Define budget máximo para mitigação
2. Probabilidade de pico:
"Qual a confiança na previsão de 5000 usuários?"
→ Ajusta tolerância ao risco
3. Tolerância a degradação:
"Usuários aceitam espera de 30s no checkout?"
→ Viabiliza opções de graceful degradation
4. Impacto em marca:
"Qual o dano reputacional de falha pública?"
→ Pode justificar investimento maior
Comunicando Resultados para Executivos
O que não funciona
❌ "P95 latency sobe para 2s acima de 2500 req/s"
→ Executivo não sabe o que fazer com isso
❌ "Precisamos de mais 4 instâncias EC2 c5.2xlarge"
→ Sem contexto de por quê ou alternativas
❌ "O sistema vai cair se tiver muita carga"
→ Alarmista e vago
O que funciona
✅ "Com a carga esperada de Black Friday, 40% dos
clientes terão experiência degradada (checkout > 10s)
ou não conseguirão completar a compra."
✅ "Temos 3 opções:
- Investir $50K agora para garantir capacidade
- Gastar 2 sprints otimizando (risco de não resolver)
- Aceitar perda de ~$200K em vendas no pico"
✅ "Recomendamos a opção A pelo ROI: $50K para evitar
potencial perda de $200K+. Decisão necessária até
[data] para implementação."
Template de apresentação executiva
# Capacity Decision Brief - Black Friday 2024
## Situação
- Carga esperada: 5000 usuários simultâneos
- Capacidade atual: 2000 usuários
- Gap: 60%
## Impacto se não agir
- 60% dos usuários com experiência degradada
- Estimativa de perda: $200-400K em vendas
- Risco reputacional: Reclamações em redes sociais
## Opções
| Opção | Investimento | Resultado | Risco |
|-------|--------------|-----------|-------|
| A: Escalar infra | $50K | 100% capacidade | Baixo |
| B: Otimização | 2 sprints ($30K) | 80% capacidade | Médio |
| C: Rate limiting | 1 sprint ($15K) | Fila controlada | Alto |
| D: Reduzir marketing | $0 | Demanda menor | Baixo |
## Recomendação
Opção A: Melhor ROI considerando receita potencial
## Timeline
- Decisão necessária: [data - 30 dias]
- Implementação: 2 semanas
- Teste de validação: 1 semana
- Margem de segurança: 1 semana
## Próximo passo
Aprovação de orçamento para iniciar provisionamento
Quantificando Risco
Modelo de impacto
Cenário: Black Friday sem escalar
Probabilidade de pico > capacidade: 70%
Se ocorrer:
- Usuários afetados: 3000 (60% do pico)
- Taxa de conversão normal: 3%
- Taxa degradada: 0.5%
- Ticket médio: $100
- Duração do pico: 4 horas
Cálculo:
Conversões perdidas: 3000 × (3% - 0.5%) = 75
Receita perdida por hora: 75 × $100 = $7,500
Receita perdida total: $7,500 × 4 = $30,000
Ajustado por probabilidade: $30,000 × 70% = $21,000
Conclusão:
Investimento de $15K para evitar é justificado
Matriz de risco
│ Baixo Impacto │ Alto Impacto
───────────┼───────────────┼──────────────
Alta │ Monitorar │ AGIR AGORA
Probabili- │ │
dade │ │
───────────┼───────────────┼──────────────
Baixa │ Aceitar │ Plano de
Probabili- │ │ contingência
dade │ │
Exemplo:
- Black Friday: Alta prob. + Alto impacto → AGIR
- Bug viral: Baixa prob. + Alto impacto → Contingência
- Pico diário: Alta prob. + Baixo impacto → Monitorar
Trade-offs Comuns
Performance vs Custo
Opção A: 10 servidores small
- Custo: $500/mês
- Capacidade: 3000 req/s
- Latência: p95 = 500ms
Opção B: 3 servidores large
- Custo: $600/mês
- Capacidade: 3000 req/s
- Latência: p95 = 200ms
Decisão: Quanto vale 300ms de latência?
- Se aumenta conversão em 0.5%: vale $600/mês
- Se não impacta conversão: escolher A
Capacidade vs Tempo de desenvolvimento
Opção A: Escalar hardware
- Tempo: 1 semana
- Custo recorrente: $2K/mês
- Sustentável: limitado
Opção B: Otimizar código
- Tempo: 4 semanas
- Custo recorrente: $0
- Sustentável: indefinido
Decisão:
- Se evento em 2 semanas: Opção A
- Se evento em 2 meses: Opção B
- Se ambos: A agora, B depois
Disponibilidade vs Custo
99.9% disponibilidade:
- Downtime: 8.7 horas/ano
- Custo: $10K/mês
- Complexidade: Baixa
99.99% disponibilidade:
- Downtime: 52 minutos/ano
- Custo: $50K/mês
- Complexidade: Alta
Decisão:
- Custo de downtime/hora: $X
- Break-even: quando $40K/mês < 8h × $X
- Se $X > $5K/hora: 99.99% vale a pena
Documentando Decisões
Template de decisão
# Decisão: Capacidade Black Friday 2024
## Contexto
- Data: 2024-10-15
- Decisor: [Nome, Cargo]
- Participantes: [Engenharia, Produto, Financeiro]
## Situação
[Resumo do problema]
## Opções Consideradas
1. [Opção A]: [Descrição]
2. [Opção B]: [Descrição]
3. [Opção C]: [Descrição]
## Decisão
Escolhida: [Opção X]
Razão: [Justificativa]
## Trade-offs Aceitos
- [O que estamos abrindo mão]
- [Riscos que estamos aceitando]
## Métricas de Sucesso
- [Como saberemos se deu certo]
## Revisão
- Data: [Quando reavaliar]
- Gatilhos: [O que mudaria a decisão]
Conclusão
Stress testing informa decisões de negócio:
- Traduzir técnico para impacto - números que executivos entendem
- Apresentar opções - não só problemas
- Quantificar risco - probabilidade × impacto
- Recomendar com ROI - justificar investimento
- Documentar decisão - para accountability
Capacidade não é determinada por engenharia — é escolhida pelo negócio com base em trade-offs que engenharia esclarece.
O trabalho de engenharia é dar opções. O trabalho de executivos é escolher entre elas.
Este artigo faz parte da série sobre a metodologia OCTOPUS de Performance Engineering.