Guida alla raccolta di prove di overselling del server cloud e alla scrittura dei ticket

Fissa le prove di overselling in 3 passi: ecco come scrivere un ticket efficace

Aggiornato 2026-09-05 · CloudWorth

oversellingraccolta provetickettest prestazioniCloudWorthSteal TimeOverselling VPSBenchmark VPS

Usa log di sistema + timestamp + certificazione di terze parti per fissare le prove e punta direttamente alla violazione della SLA nel ticket.

Come testare l'overselling

Non avere fretta di trarre conclusioni sul provider usando software di benchmark: se l'altra parte risponde solo con "metodologia di test non standard", anche i tuoi screenshot più belli saranno inutili. L'essenza dell'overselling è che le risorse fisiche vengono allocate in eccesso, ma i sintomi si nascondono in due punti poco appariscenti: lo Steal Time della CPU e il crollo della cache del disco.

Prima esegui una baseline in un periodo di basso carico: usa top -d 5 per registrare il valore di steal per 10 minuti; un server cloud normale dovrebbe essere al di sotto dell'1%; se supera il 5% per lungo tempo, significa che le macchine virtuali vicine stanno sottraendo i tuoi vCPU. Per l'IO del disco, non limitarti a guardare i picchi con fio: osserva la curva di throughput durante una scrittura continua di 10GB — quando la cache dell'host sovrallocato si esaurisce, gli IOPS precipitano, ed è un fatto che nessuna "metodologia di test" può cambiare.

Esegui lo stesso test in tre momenti diversi (ad esempio non di punta, punta serale, primo mattino) e conserva l'output originale. Se non capisci nemmeno lo Steal Time, puoi seguire i punti chiave che abbiamo preparato per l'intero flusso, oppure vedere l'esempio di diagnosi automatica in /app. Ricorda: non si testa "se è lento", ma "se le risorse vengono rubate dai vicini".

Come fissare le prove

L'obiettivo dell'acquisizione di prove non è dimostrare che le prestazioni sono "scarse", ma dimostrare che le "risorse promesse non corrispondono allo SLA". Ogni prova deve quindi includere quattro elementi: timestamp, nome del comando o strumento, output grezzo, ambiente di esecuzione.

Esegui date -u +%FT%TZ insieme al comando di test, così i log includono automaticamente l'ora UTC; usa poi script -a session.log per registrare l'intera sessione del terminale, evitando il sospetto di manomissioni a posteriori. Gli screenshot devono conservare la barra del titolo e l'ora di sistema; si consiglia di registrare lo schermo con il telefono e pronunciare l'ora corrente all'inizio della registrazione: questo è l'ancora temporale di terze parti più primordiale. Per gli screenshot del crollo della cache su disco, abbinali a iostat -dx 5 registrato in continuo e salvato come CSV; è più convincente di una singola immagine.

Non dimenticare la "validazione incrociata": i due cicli di test devono essere distanziati di almeno 6 ore, idealmente attraversando il "ciclo di rinnovo" o il "picco di attività dei tenant vicini". Se testi una sola volta, l'altra parte può negare; ma se ottieni risultati ripetuti in date diverse e con carichi diversi, la catena delle prove è chiusa.

Le persone più astute traggono dalle stesse prove una curva di rapporto qualità-prezzo: a parità di prezzo, la tua quota di CPU allocabile è inferiore del 30% rispetto al benchmark del cloud pubblico? Questo punto, pur non dimostrando direttamente l'overbooking, può elevare la "controversia tecnica" a "perdita da premio FinOps", trasformando il ticket da "stai mentendo" a "ci ho rimesso".

Come scrivere un ticket

La regola d'oro per i ticket è scrivere solo fatti, non giudizi. Non dire “state oversubscribed”, ma “osservato CPU steal medio al 12%, cache disco in calo netto 4 volte”; non dire “prestazioni non conformi”, ma “secondo l'impegno sulle prestazioni CPU del vostro SLA, l'attuale comportamento si discosta dalla baseline”.

Struttura consigliata:

1. Descrizione dell'ambiente: configurazione dell'istanza, sistema operativo, intervallo di tempo.
2. Metodo di test: includere i comandi per la riproduzione (usare comandi generici, non pannelli tipo BaoTa o strumenti di benchmark di terze parti).
3. Dati grezzi: tre serie di log steal, CSV del disco, screenshot con timestamp, impacchettati e allegati.
4. Spiegazione dell'impatto: indicare le conseguenze concrete sul business (es. risposta API passata da 80ms a 2s).
5. Richiesta: chiedere ufficialmente di verificare lo stato di carico dell'host fisico e fornire chiarimenti sull'allocazione delle risorse.

Il modello può iniziare così:

“La nostra istanza ha eseguito lo stesso test tre volte il 2025-06-01 alle 02:00, 08:00 e 20:00; i campioni sono in allegato. In tutte le esecuzioni il CPU steal ha superato l'8% e, dopo il crollo della cache disco, gli IOPS sono scesi a meno del 20% del valore nominale. Poiché il vostro SLA promette prestazioni di CPU e IO di base, chiediamo al team tecnico di verificare l'attuale rapporto di allocazione dell'host fisico e il carico dei vicini.”

Nota: non usare nel testo parole come “reclamo”, “oversubscription”, “frode” – lasciale per dopo, quando il ticket verrà escalato. Il valore del ticket sta nel fatto che l'altra parte non possa obiettare con “lo strumento non è accurato”, quindi ogni dato deve corrispondere a una riga di log completa. Se ti rispondono “usate il nostro strumento di test”, puoi dire: “Abbiamo già rieseguito il test seguendo il metodo documentato da voi; vedi il terzo set di dati in allegato.” Così rimandi la palla al mittente.

Cosa fare se il fornitore non riconosce il problema

Quando ti rispondono “il metodo di test è problematico” o “il carico dell'host è normale”, non avere fretta di discutere. Chiedi prima che ti forniscano i log di monitoraggio dell'host per lo stesso periodo di tempo — spesso non riescono a fornirli o possono solo fornire una versione ridotta. A questo punto hai già due serie di prove concrete: i log riga per riga con CPU steal superiore all'8% e la curva che mostra gli IOPS scesi al 20% del valore nominale dopo l'esaurimento della cache del disco. Trasformale in una tabella comparativa allineata temporalmente e sottolinea: se il crollo della cache del disco coincide con il picco di steal, significa che la CPU dell'host e le risorse di archiviazione sono state compresse contemporaneamente dai vicini; non è un semplice spike del test, ma la forma tipica di overselling del pool di risorse.

Se continuano a insistere che “lo strumento non è affidabile”, puoi rispondere: “Fornite lo script e i parametri di test ufficialmente raccomandati dalla vostra azienda; ripeterò il test secondo la vostra documentazione e farò registrare il processo da un notaio terzo.” Il valore di questo passaggio è trasferire l'onere della prova al fornitore. Inoltre, esegui altre due prove indipendenti in date diverse (ad esempio, la mattina presto e il picco serale), creando una validazione incrociata. Se tutti e tre i campioni puntano alla stessa conclusione, non potranno usare la scusa dell'“evento occasionale”. Conserva i log originali di ogni test, l'ora di sistema, i record di sincronizzazione NTP e i timestamp degli screenshot: sono materiali per eventuali ricorsi a canali di livello superiore.

Reclami per upgrade e rimborsi

Se il reparto di assistenza clienti diretto rifiuta l'upgrade, attiva l'escalation di canale: in primo luogo, invia un'email all'indirizzo abuse/reclami indicato sul sito ufficiale del fornitore, con oggetto "numero allegato prove violazione SLA"; in secondo luogo, presenta i materiali all'autorità di regolamentazione delle telecomunicazioni competente per il fornitore di servizi cloud o al centro di accoglimento segnalazioni per contenuti illeciti e spam 12321. Quando presenti la segnalazione, non ripetere le conclusioni dei test, ma elenca solo la lista dei fatti: in quale giorno, su quale istanza, quale test è stato eseguito, quale valore numerico è stato ottenuto e a quale clausola SLA corrisponde.

La richiesta di rimborso va eseguita in due passaggi. Prima, secondo le regole di rimborso del fornitore, richiedi il "rimborso per il periodo non utilizzato", specificando che la mancata conformità delle risorse ha causato perdite aziendali, e chiedi un risarcimento aggiuntivo. Qui puoi fare un calcolo in ottica FinOps: hai pagato un sovrapprezzo per una configurazione dichiarata da 8 core e 16 GB, ma la potenza di calcolo effettivamente disponibile equivale a solo 3 core, quindi il rapporto prezzo/prestazioni è già compromesso. Se l'altra parte è disposta a rimborsare solo in parte, insisti affinché emetta una "dichiarazione di allocazione delle risorse", indicando se l'istanza condivide l'host con VPS economici ad alta densità. La maggior parte dei fornitori, temendo che tu possa usare questa dichiarazione per denunciare l'overselling, offrirà una soluzione di compromesso.

Ultimo consiglio: tutte le comunicazioni devono passare attraverso ticket o email e conserva gli screenshot. Se richiedi un rimborso, ricordati di esportare prima i dati del disco e poi eliminare l'istanza. Dopo il rimborso, l'istanza verrà cancellata e i tuoi log di prova devono essere conservati per almeno 180 giorni, per poterli usare in caso di arbitrato o causa legale futuri. Anche se il rimborso va a buon fine, è consigliabile applicare lo stesso metodo di raccolta prove al prossimo fornitore, verificando prima di pagare per evitare di incappare di nuovo in una situazione simile.