Testes de carga antes do pico

Tema Performance no blog de engenharia operacional UCloud.

O gráfico que chega tarde

Monitoramento em produção mostra latência subindo quando o usuário já reclamou. Teste de carga bem feito inverte a ordem: você escolhe o cenário, aumenta pressão em ambiente controlado e observa onde o sistema deixa de cumprir o acordado — antes de colocar reputação em jogo.

O Google SRE Book trata capacity planning como engenharia, não adivinhação: saber o ponto de ruptura, margem de headroom e comportamento em degradação. Para eventos previsíveis — matrícula, campanha, abertura de inscrições, Black Friday — a checklist de pico do Google Cloud recomenda começar meses antes, com quota validada, capacity planner e rollback ensaiado. Não é paranoia; é o que separa “subiu” de “subiu e sabíamos até onde ia”.

Já vimos lançamento onde autoscaling adicionou nós até o limite de quota da região — e o gargalo real era pool de conexão no banco, não CPU. Escalar horizontalmente amplificou o problema. Teste de carga teria mostrado saturação em dez minutos de rampa, não em dez mil usuários reais.

Cenário de negócio, não número mágico

“Mil usuários simultâneos” sem mix de transação é decoração de slide. Cenário maduro traduz o pico real com quem conhece o negócio:

• Quantos logins por minuto no pico vs. baseline?
• Qual proporção de consultas pesadas (relatório, busca full-text) vs. leitura leve?
• Qual dependência externa no caminho crítico — gateway de pagamento, API de identidade, fila?
• Mobile vs. web altera payload e cache?

SLI entra aqui com número acordado: p95 de latência abaixo de X ms, taxa de erro abaixo de Y%, throughput mínimo Z req/s. E comportamento acima da capacidade: fila com backoff, circuit breaker, mensagem honesta ao usuário — ou colapso em cascata? Degradar com dignidade é requisito de produto, não detalhe de infra.

Ambiente de teste precisa ser representativo sem ser produção — cópia anonimizada de dados, mesma topologia de rede quando possível, feature flags alinhadas. Testar em miniatura que não reflete sharding ou replicação do real gera falsa confiança pior que não testar.

Fases de um engajamento sério

No Perfwise, conduzimos o ciclo em fases explícitas — projeto fechado, não assinatura genérica:

1. Diagnóstico. Arquitetura, observabilidade existente, histórico de incidentes em pico, SLAs contratuais.
2. Desenho de cenário. Workshop com produto e engenharia; script de carga com mix validado.
3. Preparação. Ambiente, janela, comunicação com operação, critérios de abort e rollback.
4. Execução. Ramp-up gradual, soak time, registro de métricas e traces correlacionados.
5. Laudo. Gargalos priorizados, evidência reproduzível, ordem de remediação com esforço estimado.
6. Reteste opcional. Após correções críticas, antes da data D.

Janela de execução, plantão de engenharia e plano de volta não são burocracia de CAB: são o que impede teste de virar incidente não planejado que o cliente descobre pelo monitoramento público.

Laudo, não export de métricas

Entregável útil não é dashboard bonito anexado a e-mail. É laudo que um diretor de engenharia e um gestor de produto leem sem tradutor:

• Resumo executivo — cumpriu ou não o SLI no cenário acordado; margem até o limite.
• Gargalo primário — com gráfico de saturação e trace que prova (ex.: 98% pool JDBC, fila Redis crescendo linearmente).
• Gargalos secundários — o que apareceria se o primeiro fosse corrigido.
• Recomendações ordenadas — quick win vs. mudança estrutural; risco operacional de cada uma.
• Baseline — para comparar após o próximo release ou mudança de infra.

Baseline fica no mapa do ambiente. Sem ela, cada discussão de performance recomeça do zero — especialmente quando o time que rodou o teste já mudou de projeto.