Überverkauf bei Cloud-Servern: Beweise sichern und Ticket richtig schreiben

Sichern Sie in 3 Schritten Beweise für Überverkauf – So schreiben Sie ein Ticket, das wirkt

Aktualisiert 2026-09-05 · CloudWorth

ÜberverkaufBeweissicherungTicketPerformance-TestsCloudWorthSteal TimeVPS OversellingVPS Benchmark

Beweise mithilfe von Systemprotokollen, Zeitstempeln und externer Beglaubigung sichern und im Ticket direkt auf SLA-Verstöße verweisen.

So messen Sie Überverkauf

Ziehen Sie nicht vorschnell den Schluss, dass der Anbieter schlecht ist, nur weil ein Benchmark-Programm das nahelegt – wenn der Anbieter bloß antwortet, die „Testmethode sei nicht standardkonform“, sind Ihre schönsten Screenshots wertlos. Das Wesen des Überverkaufs liegt in der Überbelegung physischer Ressourcen; die Symptome verbergen sich jedoch an zwei unscheinbaren Stellen: bei der Steal Time der CPU und beim Cache-Einbruch der Festplatte.

Führen Sie zunächst eine Basismessung in einem lastschwachen Zeitraum durch: Notieren Sie mit top -d 5 zehn Minuten lang die Steal-Werte. Ein normaler Cloud-Server sollte unter 1 % bleiben; dauerhaft über 5 % deutet darauf hin, dass benachbarte virtuelle Maschinen Ihre vCPUs mitbeanspruchen. Betrachten Sie die Datenträger-IO nicht nur als Spitzenwert mit fio; achten Sie auf die Durchsatzkurve beim kontinuierlichen Schreiben von 10 GB – ist der Cache eines überverkauften Hosts erschöpft, brechen die IOPS regelrecht ein. Das ist eine Tatsache, die keine „Testmethode“ ändern kann.

Führen Sie denselben Test an drei unterschiedlichen Zeitpunkten durch (z. B. außerhalb der Spitzenlast, in der abendlichen Hauptlast und frühmorgens) und bewahren Sie die ursprüngliche Ausgabe auf. Falls Sie mit Steal Time nichts anfangen können, können Sie den Ablauf zunächst anhand unserer zusammengestellten Checkliste durchgehen oder sich unter /app das Beispiel für eine automatische Diagnose ansehen. Denken Sie daran: Gemessen wird nicht, ob es langsam ist, sondern ob Ressourcen von Nachbarn gestohlen werden.

Wie werden Beweise gesichert?

Das Ziel der Beweissicherung ist nicht der Nachweis von „schlechter Leistung“, sondern der Nachweis, dass „Ressourcenzusage und SLA nicht übereinstimmen“. Daher muss jeder Beweis vier Elemente enthalten: Zeitstempel, Befehls- oder Toolname, Rohausgabe und Laufzeitumgebung.

Führen Sie date -u +%FT%TZ zusammen mit dem Testbefehl aus, damit das Protokoll eine UTC-Zeit enthält; zeichnen Sie dann die gesamte Terminalsitzung mit script -a session.log auf, um den Verdacht einer nachträglichen Manipulation zu vermeiden. Screenshots sollten Titelleiste und Systemzeit enthalten. Es wird empfohlen, den Bildschirm mit dem Handy zu filmen und zu Beginn der Aufnahme die aktuelle Zeit vorzulesen – das ist der ursprünglichste Zeitanker eines Dritten. Für Screenshots des plötzlichen Abfalls des Datenträger-Caches verwenden Sie bitte iostat -dx 5 zur kontinuierlichen Aufzeichnung und speichern Sie die Daten als CSV – das ist überzeugender als ein einzelnes Bild.

Vergessen Sie nicht die „Kreuzvalidierung“: Zwischen den beiden Testrunden sollten mehr als 6 Stunden liegen, idealerweise über einen Verlängerungszyklus oder die Geschäftsspitze benachbarter Mandanten. Wenn Sie nur einmal testen, kann die Gegenseite es abstreiten. Wenn Sie jedoch an verschiedenen Tagen und unter verschiedenen Lasten wiederholte Ergebnisse erhalten, schließt sich die Beweiskette.

Noch klügere Personen werden mit denselben Beweisen eine Preis-Leistungs-Kurve erstellen: Ist Ihr CPU-Anteil zum gleichen Preis um 30 % niedriger als die öffentliche Cloud-Benchmark? Obwohl dies nicht direkt eine Überzeichnung beweist, hebt es den „technischen Streit“ auf die Stufe eines „FinOps-Prämienverlusts“ und verwandelt das Ticket von „Sie lügen“ in „Ich habe Verluste“.

Wie schreibt man ein Ticket?

Die eiserne Regel für Tickets lautet: Nur Fakten, keine Bewertungen. Sagen Sie nicht „Sie überverkaufen“, sondern „Durchschnittliche CPU-Steal-Zeit von 12% und 4 Cache-Einbrüche des Datenträgers beobachtet“; sagen Sie nicht „Leistung unzureichend“, sondern „Gemäß der CPU-Leistungszusage in Ihrer SLA weicht die aktuelle Leistung von der Baseline ab.“

Empfohlene Struktur:

1. Umgebungsbeschreibung: Instanzkonfiguration, Betriebssystem, Zeitraum.
2. Testmethode: Reproduktionsbefehle beifügen (Hinweis: allgemeine Befehle verwenden, keine BaoTa- oder Drittanbieter-Benchmark-Tools).
3. Rohdaten: Drei steal-Logs, Datenträger-CSV, mit Zeitstempel versehene Screenshots, als Anhang packen.
4. Auswirkungsbeschreibung: Konkrete Auswirkungen auf den Geschäftsbetrieb angeben (z. B. API-Antwortzeit von 80 ms auf 2 s erhöht).
5. Forderung: Bitte offiziell den Lastzustand des Hostsystems prüfen und eine Ressourcenzuteilungsübersicht bereitstellen.

Ein Ticket kann wie folgt beginnen:

„Unsere Instanz wurde am 2025-06-01 um 02:00, 08:00 und 20:00 Uhr dreimal mit demselben Test ausgeführt; Muster finden Sie im Anhang. Die CPU-Steal-Zeit überschritt jeweils 8%, und die IOPS fielen nach dem Erschöpfen des Datenträger-Caches auf weniger als 20% des Nennwerts. Da Ihre Service-Level-Vereinbarung eine Baseline für CPU- und IO-Leistung zusagt, bitten wir Ihr technisches Team, das aktuelle Verteilungsverhältnis und die Nachbarlast des physischen Hosts zu überprüfen.“

Hinweis: Verwenden Sie im Text keine Wörter wie „Beschwerde“, „Überverkauf“ oder „Betrug“ – diese bleiben für später, nach der Eskalation an den Kundenservice. Der Wert eines Tickets liegt darin, dem Anbieter keine Möglichkeit zu geben, mit „ungenauen Tools“ zu argumentieren. Daher muss jede Angabe einer vollständigen Protokollzeile entsprechen. Falls der Anbieter antwortet: „Bitte verwenden Sie unser Testwerkzeug“, können Sie antworten: „Wir haben nach der von Ihnen dokumentierten Methode erneut getestet; siehe dritter Datensatz im Anhang.“ Damit haben Sie den Ball wieder souverän zurückgespielt.

Was tun, wenn der Anbieter nicht anerkennt

Wenn die Gegenseite antwortet „Die Testmethode ist problematisch“ oder „Der Host ist normal ausgelastet“, geraten Sie nicht in Eile, zu streiten. Fordern Sie zuerst, dass sie Host-Überwachungsprotokolle für denselben Zeitraum vorlegen – meist können sie diese nicht liefern oder nur in abgespeckter Version. Zu diesem Zeitpunkt haben Sie bereits zwei Gruppen von harten Beweisen: die zeilenweisen Protokolle mit CPU-Steal über 8 % und die Kurve, in der die IOPS nach dem Verlust des Disk-Cache auf 20 % des Nennwerts fallen. Machen Sie aus diesen beiden Datengruppen eine zeitlich abgeglichene Vergleichstabelle und weisen Sie darauf hin: Wenn der Disk-Cache-Abfall genau mit dem Steal-Höhepunkt überlappt, bedeutet dies, dass die CPU- und Speicherressourcen des Hosts gleichzeitig von Nachbarn beansprucht werden. Dies ist kein einmaliges Testzittern, sondern die typische Form der Überbelegung des Ressourcenpools.

Falls der Anbieter weiterhin darauf besteht, dass „das Tool ungenau ist“, können Sie antworten: „Bitte geben Sie das offiziell empfohlene Testskript und die Parameter Ihres Unternehmens an. Ich werde gemäß Ihrer Dokumentation erneut testen und den Prozess von einem unabhängigen Zeugen protokollieren lassen.“ Der Wert dieses Schritts besteht darin, die Beweislast auf den Anbieter zurückzuverlagern. Führen Sie gleichzeitig an verschiedenen Tagen zwei weitere unabhängige Tests durch (z. B. in den frühen Morgenstunden und zur abendlichen Spitzenzeit), um eine Kreuzvalidierung zu erreichen. Wenn alle drei Stichproben auf dasselbe Ergebnis hinweisen, kann der Anbieter nicht mehr mit „gelegentlich“ ausweichen. Bewahren Sie unbedingt die Rohprotokolle, Systemzeiten, NTP-Synchronisierungsaufzeichnungen sowie die Zeitstempel der Screenshots jedes Tests auf – diese sind Material für spätere Beschwerden bei höheren Instanzen.

Upgrade-Beschwerden und Rückerstattungen

Wenn der direkte Kundendienst sich weigert, das Upgrade durchzuführen, starten Sie die Kanaleskalation: Erstens senden Sie eine E-Mail an die auf der offiziellen Website des Anbieters veröffentlichte Abuse-/Beschwerde-Adresse, mit dem Betreff „Anhangsnummer für SLA-Verletzungsnachweise“. Zweitens reichen Sie Materialien bei der Kommunikationsbehörde der Region, in der der Cloud-Anbieter seinen Sitz hat, oder beim 12321-Zentrum für die Meldung von unerwünschten und Spam-Informationen im Netz ein. Wiederholen Sie bei der Einreichung nicht die Testergebnisse, sondern listen Sie nur die Faktenliste auf: An welchem Tag, welche Instanz, welcher Test durchgeführt wurde, welcher Zahlenwert erzielt wurde und auf welche SLA-Klausel er sich bezieht.

Die Rückerstattungsforderung sollte in zwei Schritten erfolgen. Beantragen Sie zunächst gemäß den Rückerstattungsregeln des Anbieters eine „Rückerstattung für nicht genutzte Laufzeit“ und geben Sie an, dass durch die nicht erfüllten Ressourcen Geschäftsverluste entstanden sind, und fordern Sie eine zusätzliche Entschädigung – hier können Sie aus FinOps-Sicht eine Rechnung aufmachen: Sie haben einen Aufpreis für angeblich 8 Kerne und 16 GB gezahlt, aber die tatsächlich verfügbare Rechenleistung entspricht nur 3 Kernen, die Kosteneffizienz ist längst aus dem Gleichgewicht geraten. Wenn der Anbieter nur einen Teil der Kosten erstatten möchte, bestehen Sie darauf, dass er eine „Ressourcenzuweisungserklärung“ ausstellt, und vermerken Sie, ob diese Instanz sich einen Host mit hochdichten günstigen VPS teilt. Die meisten Anbieter befürchten, dass Sie mit dieser Erklärung Überbelegung melden könnten, und werden einen Kompromiss anbieten.

Letzte Erinnerung: Führen Sie die gesamte Kommunikation über Tickets oder E-Mails und bewahren Sie Screenshots auf. Wenn Sie eine Rückerstattung beantragen, denken Sie daran, zuerst die Daten der Festplatte zu exportieren und dann die Instanz zu löschen – nach der Rückerstattung wird die Instanz geleert, und Ihre Beweissicherungsprotokolle müssen mindestens 180 Tage aufbewahrt werden, um sie für ein späteres Schiedsverfahren oder eine Klage zu verwenden. Selbst wenn die Rückerstattung erfolgreich ist, wird empfohlen, diese Beweissicherungsmethode auch beim nächsten Anbieter anzuwenden, um alles zu verifizieren, bevor Sie zahlen, und so zu vermeiden, erneut in eine Falle zu tappen.