Um sistema que processa, em média, mil requisições por minuto parece perfeitamente dimensionado para suportar essa carga com folga. Rolando Bonaccorsi, diretor de operações da Vert Analytics, observa que esse raciocínio, aparentemente lógico, é justamente o que leva tantas equipes a serem surpreendidas por uma indisponibilidade no momento em que menos esperavam.
O problema está escondido na própria palavra “média”: ela resume um comportamento variável em um único número, apagando exatamente a informação mais importante para quem precisa garantir que o sistema aguente o pior momento, não o momento típico e mais confortável de operação.
Por que a média some justamente quando você mais precisa dela?
Uma média de mil requisições por minuto pode esconder picos de três ou quatro mil requisições em janelas específicas do dia, seguidos de vales bem abaixo desse número em outros horários, um comportamento que se cancela matematicamente na hora de calcular a média final apresentada em qualquer relatório resumido.
Dimensionar infraestrutura para a média significa, na prática, dimensionar para um cenário que nunca corresponde exatamente ao momento real de maior demanda, o único momento em que a capacidade insuficiente efetivamente se manifesta como indisponibilidade visível para os usuários finais do sistema.
Segundo Rolando Bonaccorsi, esse descompasso costuma passar despercebido justamente porque relatórios executivos favorecem números únicos e resumidos, mais fáceis de apresentar em uma reunião do que uma distribuição completa de dados ao longo do tempo, mesmo que essa distribuição carregue a informação que realmente importa para decisões de dimensionamento.
O percentil que revela o que a média esconde
Em vez de olhar para a média, engenheiros de infraestrutura experientes preferem trabalhar com percentis, geralmente o percentil noventa e cinco ou noventa e nove, que mostram o valor abaixo do qual a grande maioria das observações se encontra, revelando diretamente o comportamento nos momentos mais exigentes.
Rolando Bonaccorsi destaca que essa diferença de abordagem muda completamente a decisão de dimensionamento: se o percentil noventa e nove de uso de processador está próximo do limite máximo disponível, existe risco real de saturação, mesmo que a média geral pareça tranquilamente dentro de qualquer faixa considerada segura pela maioria das equipes.
O erro de assumir que a capacidade cresce de forma linear
Outro erro recorrente é assumir que dobrar recursos automaticamente dobra a capacidade suportada, como se um servidor que aguenta cem usuários simultâneos significasse que dois servidores aguentariam duzentos sem qualquer perda proporcional de eficiência ao longo do caminho.
Sistemas reais raramente se comportam de forma tão previsível: gargalos em banco de dados, contenção de recursos compartilhados e overhead de coordenação entre múltiplas instâncias frequentemente fazem com que o ganho de capacidade, ao adicionar recursos, seja menor do que a soma simples sugeriria no papel antes de qualquer teste real de carga.
Testes de carga controlados, aplicados antes de assumir qualquer relação linear entre recurso adicionado e capacidade ganha, revelam esses obstáculos escondidos com muito mais precisão do que qualquer projeção teórica baseada apenas em aritmética simples de multiplicação de servidores.
Quanto de margem realmente faz sentido?
Definir margem de segurança acima do percentil mais exigente observado, geralmente entre vinte e trinta por cento adicionais, oferece espaço para picos ainda não observados no histórico disponível, sem incorrer no desperdício de superdimensionar recursos que ficarão ociosos na maior parte do tempo de operação normal.
Por fim, Rolando Bonaccorsi considera esse equilíbrio o verdadeiro objetivo de qualquer exercício sério de capacity planning: nem tão apertado que qualquer variação inesperada gere indisponibilidade, nem tão folgado que a empresa pague por capacidade que praticamente nunca chega a ser efetivamente utilizada ao longo do ano inteiro de operação.
Revisar essa margem periodicamente, à medida que o histórico de uso cresce e o comportamento real do sistema fica mais claro, evita que uma decisão tomada com poucos meses de dados permaneça fixa por anos, mesmo depois que o padrão de demanda real já mudou significativamente em relação ao momento em que aquele dimensionamento original foi calculado.
