Benchmark de servidores em nuvem: identificando especificações infladas com testes forenses
Use benchmarks forenses para expor especificações infladas e calcule o custo-benefício real
Benchmark não é só números; use Steal Time e taxa de sobrepreço para validação cruzada e recuse pagar por especificações falsas.
Benchmark forense: Steal Time e gerações de CPU
Ao comprar um servidor em nuvem, o maior medo não é uma pontuação baixa, mas sim uma 'pontuação inflada' — a ficha técnica indica EPYC 9006, mas na prática você recebe núcleos de gerações antigas; o cache de disco parece de 1,2 GB/s, mas em um teste de carga cai para 200 MB/s. Isso é especificação superdimensionada. Minha abordagem: primeiro, executo um benchmark forense por 30 minutos; depois, confronto os números com a fatura.
O primeiro corte é no Steal Time. No top, %steal acima de 5% já acende o alerta; acima de 15%, é praticamente certo que o vizinho está devorando sua CPU. Use vmstat 1 para amostragem contínua; se o steal oscila muito e vem acompanhado de load alto, o overselling é severo. Nesse tipo de máquina, mesmo com pontuação alta, o serviço engasga assim que o tráfego aumenta.
O segundo corte é na geração da CPU. Não confie apenas no lscpu; olhe os flags avx512 e sse4_2, e compare se o modelo real bate com o anunciado. Xeons antigos também têm 8 núcleos, mas o IPC é três gerações inferior; para a mesma configuração, o ágio deveria ser pelo menos 30% menor. Combinando com a taxa de sobrepreço do FinOps, monto uma tabela de 'pontuação nominal ÷ preço real de locação' — aí fica fácil saber quanto de overselling está embutido no preço unitário.
Os comandos específicos estão em Lista de benchmarks do CloudWorth, que gera um pacote de evidências pronto para abrir chamado.
Auditoria da taxa de prêmio: calcule o verdadeiro custo-benefício
A pontuação é apenas o começo; o que realmente importa é calcular a taxa de prêmio — ou seja, quanta capacidade de processamento efetiva você compra por cada real gasto. Não importa quão alta seja a pontuação do servidor em nuvem; se o Steal Time ficar consistentemente >10%, significa que os vizinhos estão disputando a CPU, e há uma forte suspeita de superprovisionamento. Esse tipo de especificação inflada é mais enganoso do que parâmetros falsos.
Minha fórmula de auditoria é simples:
- Capacidade de processamento efetiva = pontuação de núcleo único × proporção de tempo de CPU estável disponível (1 - proporção de steal)
- Taxa de prêmio = capacidade de processamento efetiva ÷ preço real de renovação, não o preço promocional da primeira compra
Nota: verifique o preço de renovação e compare com os provedores de nuvem pública. Para o mesmo EPYC, gerações mais antigas precisam ser 20% mais baratas que as novas; se o modelo novo ainda é vendido ao preço do antigo, há problema na taxa de prêmio.
Na prática, primeiro faça um teste de carga de 30 minutos para capturar o steal:
vmstat 1 300 | awk 'NR>1{sum+=$16;n++} END{print "avg steal %:", sum/n}'Se a média de steal ultrapassar 5%, empacote os resultados do teste e capturas de tela do ticket em um PDF — isso se tornará a cadeia de evidências para reclamações e reembolsos futuros. Só depois de calcular a taxa de prêmio é que você faz o pedido; aí sim estará pagando pelo verdadeiro custo-benefício, e não dando dinheiro para especificações falsas.
Ciclo de defesa de direitos via chamado: cadeia de evidências e compensação por downgrade
Se você encontrar problemas no benchmark, não se apresse em desinstalar e reinstalar. Primeiro, execute um conjunto de comandos forenses com timestamp, como vmstat 1 30 para capturar picos de Steal Time, depois dd contínuo para testar a queda abrupta do cache de disco e, finalmente, use lscpu para arquivar a geração real da CPU. Salve essas saídas em PDF, anote a data e o ID da instância — essa é a cadeia de evidências que pode ser jogada na cara do suporte.
Ao abrir o chamado, não diga "está lento", escreva diretamente "Steal Time acima de 30% continuamente, sobrepreço de mais de 40% em relação ao mercado para a mesma configuração, suspeita de superprovisionamento e downgrade de especificações". A maioria dos fornecedores primeiro fornece um script de teste para você testar novamente; nesse caso, execute-o como está e tire screenshots lado a lado dos dois resultados. Se a falsa especificação for confirmada, priorize negociar a compensação pelo downgrade: ou reembolse a diferença de preço com base no desempenho real, ou obtenha um upgrade gratuito para a mesma geração de CPU. O melhor caso que vi foi trocar dados de Steal Time por isenção de taxa de tráfego por três anos — desde que você também mostre o sobrepreço ao financeiro; a abordagem FinOps é mais útil do que jargões técnicos nesse momento.
Lembre-se de manter todos os números de chamado, teste novamente após o crédito da compensação e confirme se os números correspondem à fatura. Lutar por direitos não é discutir, é usar evidências para obter uma troca equivalente.
FAQ
Como identificar especificações infladas em servidores em nuvem?
Use Steal Time e a taxa de sobrepreço para validação cruzada; os números de benchmark não podem ser totalmente confiáveis, exigindo testes forenses.
O que fazer se o benchmark do servidor em nuvem for alto, mas o desempenho real for ruim?
Verifique se o Steal Time está muito alto e compare o preço com a média da mesma configuração; desconfie de especificações falsas se a taxa de sobrepreço ultrapassar 20%.