Guia para coletar evidências de overselling e escrever chamados de suporte

3 passos para fixar evidências de overselling, e é assim que se escreve um chamado eficaz

Atualizado 2026-09-05 · CloudWorth

oversellingcoleta de evidênciaschamadoteste de desempenhoCloudWorthSteal TimeOverselling VPSBenchmark VPS

Use logs de nível de sistema + carimbo de tempo + notarização de terceiros para fixar evidências; no chamado, aponte diretamente a violação do SLA.

Como testar overselling

Não se apresse em tirar conclusões sobre o provedor com base em software de benchmark — se ele responder apenas com “metodologia de teste inadequada”, suas capturas de tela mais bonitas não valerão de nada. A essência do overselling é a alocação excessiva de recursos físicos, mas os sintomas se escondem em dois lugares discretos: o Steal Time da CPU e a queda abrupta do cache do disco.

Primeiro, faça uma medição de linha de base em horário de baixa carga: use top -d 5 para registrar o valor de steal por 10 minutos; um servidor em nuvem normal deve ficar abaixo de 1%. Se ficar acima de 5% por um longo período, isso indica que as VMs vizinhas estão ocupando seus vCPUs. Para o IO de disco, não olhe apenas para o pico com fio; observe a curva de throughput ao escrever 10 GB continuamente — quando o cache do host com overselling se esgota, o IOPS despenca como um precipício; isso é um fato que nenhuma “metodologia de teste” pode mudar.

Execute o mesmo teste em três horários diferentes (por exemplo, fora do pico, pico noturno e madrugada), uma rodada cada, e guarde as saídas originais. Se você não souber o que é Steal Time, siga primeiro o nosso guia prático com os pontos essenciais, ou veja exemplos de diagnóstico automático em /app. Lembre-se: o teste não é sobre “ser lento ou não”, mas sim sobre “se os recursos estão sendo roubados pelos vizinhos”.

Como fixar as evidências

O objetivo da coleta de evidências não é provar que o “desempenho é ruim”, mas sim que o “compromisso de recursos não está de acordo com o SLA”. Portanto, cada evidência deve conter quatro elementos: carimbo de data/hora, nome do comando ou ferramenta, saída original e ambiente de execução.

Execute date -u +%FT%TZ junto com o comando de teste para que os registros tragam o horário UTC; depois use script -a session.log para gravar toda a sessão do terminal, evitando suspeitas de fabricação posterior. As capturas de tela devem preservar a barra de título e o horário do sistema. Recomenda-se usar o celular para filmar a tela e, no início da gravação, ler em voz alta a hora atual — essa é a âncora temporal de terceiros mais primitiva. Para as capturas de tela da queda abrupta do cache de disco, utilize o registro contínuo do iostat -dx 5 e salve em CSV, o que é muito mais convincente do que uma única imagem.

Não se esqueça da “validação cruzada”: as duas rodadas de testes devem ter um intervalo de mais de 6 horas, idealmente atravessando o “ciclo de renovação” ou o “pico de uso dos locatários vizinhos”. Se você testar apenas uma vez, a outra parte pode negar; mas se você obtiver resultados repetidos em datas diferentes e sob cargas diferentes, a cadeia de evidências se fecha.

Quem é mais esperto também extrai dessas evidências uma curva de custo-benefício: na mesma faixa de preço, a sua parcela alocável de CPU está 30% abaixo da referência da nuvem pública? Esse ponto, embora não prove diretamente a sobrevenda, consegue elevar a “controvérsia técnica” ao patamar de “perda de prêmio FinOps”, transformando o chamado de “você está mentindo” para “estou no prejuízo”.

Como escrever um chamado

A regra de ouro para chamados é escrever apenas fatos, sem conclusões. Não diga “vocês estão fazendo overselling”; diga “observado CPU steal médio de 12% e 4 quedas abruptas do cache de disco”; não diga “desempenho insatisfatório”; diga “de acordo com a promessa de desempenho de CPU no SLA de vocês, o desempenho atual se desviou da linha de base”.

Estrutura recomendada:

1. Descrição do ambiente: configuração da instância, sistema operacional, intervalo de tempo.
2. Método de teste: inclua comandos de reprodução (use comandos genéricos, não use BaoTa nem ferramentas de benchmark de terceiros).
3. Dados brutos: três conjuntos de logs de steal, CSV de disco, capturas de tela com carimbo de data/hora, compactados em anexo.
4. Descrição do impacto: especifique como o negócio foi afetado (ex.: resposta da API aumentou de 80 ms para 2 s).
5. Solicitação: peça para a equipe oficial revisar a carga do host físico e fornecer esclarecimentos sobre a alocação de recursos.

Um modelo pode começar assim:

“Nossa instância executou o mesmo teste em 2025-06-01 às 02:00, 08:00 e 20:00; as amostras estão em anexo. O CPU steal excedeu 8% em todos os casos e, após o esgotamento do cache de disco, o IOPS caiu para menos de 20% do valor nominal. Como o SLA de vocês garante desempenho de CPU e I/O de linha de base, pedimos que a equipe técnica verifique a proporção atual de alocação do host físico e a carga dos vizinhos.”

Atenção: não use palavras como “reclamação”, “overselling” ou “fraude” no corpo do texto — deixe-as para depois, quando o suporte escalar o chamado. O valor do chamado está em impossibilitar que a outra parte contra-argumente com “a ferramenta não é precisa”; por isso, cada dado deve corresponder a linhas de log completas. Se a outra parte responder “usem nossa ferramenta de teste”, você pode dizer: “Já testamos novamente seguindo o método da documentação de vocês; veja o terceiro grupo de dados no anexo.” Assim, você devolve a bola com segurança para eles.

E se o provedor não reconhecer o problema?

Quando a outra parte responder “o método de teste tem problemas” ou “a carga do host está normal”, não se apresse em discutir. Primeiro, peça que forneçam os logs de monitoramento do host no mesmo período — muitas vezes eles não conseguem apresentar ou só fornecem uma versão censurada. Nesse momento você já tem dois conjuntos de evidências concretas: os logs linha por linha de CPU steal acima de 8% e a curva de IOPS caindo para 20% do valor nominal após o cache de disco se esgotar. Transforme esses dois conjuntos de dados em uma tabela comparativa alinhada por tempo e aponte: se a queda abrupta do cache de disco coincidir com o pico de steal, isso indica que a CPU e os recursos de armazenamento do host foram simultaneamente ocupados por vizinhos. Não se trata de uma oscilação isolada de teste, mas da forma típica de overcommit do pool de recursos.

Se a outra parte ainda insistir que “a ferramenta não é confiável”, você pode responder: “Por favor, forneçam o script e os parâmetros de teste oficialmente recomendados por sua empresa; vou refazer o teste seguindo seus documentos, com um terceiro notário registrando o processo.” O valor desse passo é transferir o ônus da prova de volta para o provedor. Ao mesmo tempo, realize duas outras rodadas de testes independentes em datas diferentes (por exemplo, de madrugada e no pico da noite), formando uma validação cruzada. Se as três amostras apontarem para a mesma conclusão, a outra parte não poderá se esquivar com “caso isolado”. Lembre-se de preservar os logs originais de cada teste, o horário do sistema, os registros de sincronização NTP e os carimbos de data/hora das capturas de tela — esses são materiais para recursos em canais de nível superior posteriormente.

Reclamações e reembolsos com escalonamento

Se o atendimento ao cliente direto se recusar a escalar a reclamação, inicie o escalonamento de canal: primeiro, envie um e-mail para o endereço de abuso/reclamações divulgado no site oficial do provedor, com o assunto “Número do anexo de evidência de violação de SLA”; segundo, envie os materiais para a agência reguladora de telecomunicações da jurisdição do provedor de nuvem ou para o Centro de Denúncias 12321 de Informações Ruins e Spam da Internet. Ao enviar, não repita as conclusões dos testes; apenas liste a lista de fatos: em qual data, em qual instância, qual teste foi executado, qual valor de resultado e qual cláusula de SLA corresponde.

O pedido de reembolso deve ser feito em duas etapas. Primeiro, solicite o “reembolso do tempo não utilizado” de acordo com as regras de reembolso do provedor e declare que houve prejuízo ao negócio devido a recursos abaixo do contratado, exigindo compensação adicional — use a perspectiva FinOps para calcular: você pagou um valor adicional por um plano nominal de 8 núcleos e 16 GB, mas o poder computacional disponível é equivalente a apenas 3 núcleos; a relação custo-benefício já está muito desequilibrada. Se o provedor só se dispuser a reembolsar parte do valor, insista para que ele forneça uma “declaração de alocação de recursos” e especifique se a instância compartilha o servidor físico com VPS baratos de alta densidade. A maioria dos provedores teme que você utilize essa declaração para denunciar overselling e apresentará uma solução intermediária.

Por fim, um lembrete: toda comunicação deve ser feita por ticket ou e-mail, e preserve capturas de tela. Ao solicitar reembolso, lembre-se de exportar os dados do disco antes de excluir a instância — após o reembolso, a instância é apagada, e seus logs de evidência precisam ser mantidos por pelo menos 180 dias para uso em arbitragem ou processo judicial posterior. Mesmo que o reembolso seja aprovado, é recomendado aplicar o mesmo método de coleta de evidências ao próximo provedor: verifique tudo antes de pagar, evitando cair novamente na mesma armadilha.