Wenn Sie ein Proxy-Netzwerk in eine Produktionspipeline einbinden, wird irgendwann jemand aus dem Einkauf oder der Plattform-Entwicklung fragen, wie das SLA aussieht. Das ist die richtige Frage, und die Antworten, die Sie bekommen, sind meist weniger aussagekräftig, als sie wirken, denn eine Zahl wie 99,9% bedeutet nichts, solange Sie nicht wissen, woran sie gemessen wird, über welchen Zeitraum, und was passiert, wenn sie verfehlt wird.
Es gibt in diesem Bereich zudem eine spezifische Falle. Ein Proxy-SLA verspricht, dass das Gateway erreichbar ist. Es verspricht nicht, dass die Websites, von denen Sie Daten sammeln, Ihre Anfragen durchlassen, und das sind zwei sehr unterschiedliche Dinge. Dieses Abgrenzung zu verstehen ist das Wichtigste, bevor Sie irgendetwas unterschreiben.
Was eine Uptime-Zahl tatsächlich bedeutet
Hinter jeder Prozentangabe stehen drei Variablen, und ein Anbieter, der Ihnen nur die Prozentzahl nennt, hat Ihnen den am wenigsten nützlichen Teil gegeben.
Die erste ist das Messfenster. Ein monatliches SLA von 99,9% erlaubt etwa 43 Minuten Ausfallzeit pro Monat. Dasselbe 99,9%, jährlich gemessen, erlaubt etwa 8 Stunden 45 Minuten, und diese Stunden dürfen zusammenhängend sein. Monatlich ist deutlich strenger, und ein Anbieter, der eine Jahreszahl nennt, gibt in identischer Formulierung ein schwächeres Versprechen ab.
Die zweite ist die Definition von Ausfallzeit. Gilt der Dienst als ausgefallen, wenn das Gateway Verbindungen ablehnt, oder auch dann, wenn es technisch antwortet, aber die Fehlerrate stark angestiegen ist oder die Latenz sich bis zur Unbrauchbarkeit verschlechtert hat? Viele SLAs zählen nur die vollständige Nichtverfügbarkeit, was bedeutet, dass ein Zeitraum, in dem jede Anfrage einen Fehler zurückgibt, der Endpunkt aber weiterhin Verbindungen annimmt, möglicherweise überhaupt nicht als Ausfallzeit erfasst wird.
Die dritte ist, wer misst. Wenn der Anbieter die einzige Quelle der Wahrheit ist und keine unabhängige Aufzeichnung veröffentlicht, ist die Zahl selbstberichtet. Eine öffentliche Statusseite mit Vorfallshistorie ist das, was die Angabe überprüfbar macht.
Die wichtigste Unterscheidung: Gateway-Uptime ist keine Erfolgsrate
Das ist der Punkt, an dem Teams stolpern, und es lohnt sich, hier deutlich zu sein.
Ein Uptime-SLA deckt die Infrastruktur des Anbieters ab: Das Gateway akzeptiert Ihre Verbindung, authentifiziert Sie und leitet Ihre Anfrage weiter. Das ist es, was der Anbieter kontrolliert, und das ist es, was er verspricht.
Was es nicht abdeckt, ist, ob die Zielseite die Anfrage akzeptiert. Wenn eine Website die Exit-Adresse blockiert, eine Challenge-Seite ausliefert oder ein leeres Ergebnis zurückgibt, ist das keine Ausfallzeit. Der Proxy hat seine Aufgabe erfüllt. Ihre Datenerhebung ist trotzdem gescheitert. Kein Proxy-Anbieter kann eine Erfolgsrate gegenüber Websites Dritter garantieren, denn die Websites entscheiden selbst, sie ändern ihre Abwehrmaßnahmen ohne Vorankündigung, und derselbe Pool, der ein Ziel am Montag problemlos passiert, kann am Freitag Schwierigkeiten haben. Jeder Anbieter, der tatsächlich eine Erfolgsrate für beliebige Ziele garantiert, verspricht etwas, das außerhalb seiner Kontrolle liegt.
Die praktische Konsequenz für den Einkauf ist also: Das SLA schützt Sie davor, dass der Anbieter kaputt ist, und Ihr eigenes Monitoring schützt Sie vor allem anderen. Sie brauchen beides, und wer beides vermischt, endet mit Teams, die vertraglich abgesichert, aber operativ blind sind. Dafür ist das Monitoring Ihrer Pipeline da, das die validierte Erfolgsrate pro Ziel und Region misst, anstatt anzunehmen, das SLA würde das abdecken, und deshalb ist das Erkennen blockierter oder gefälschter Inhalte wichtig: Eine mit Statuscode 200 zurückgegebene Challenge-Seite ist gleichzeitig eine SLA-konforme Antwort und ein Datenfehler.
Service-Credits und ihr tatsächlicher Wert
Wenn ein SLA verfehlt wird, besteht das übliche Mittel in einem Service-Credit, meist ein Prozentsatz der Monatsgebühr, skaliert danach, wie stark das Ziel verfehlt wurde, angewendet auf eine zukünftige Rechnung.
Man sollte sich über dessen Größenordnung im Klaren sein. Ein Credit wird auf Basis dessen berechnet, was Sie dem Anbieter gezahlt haben, nicht auf Basis dessen, was der Ausfall Sie gekostet hat. Wenn ein vierstündiger Gateway-Ausfall einen Preis-Feed lahmlegt, der Ihre eigenen geschäftlichen Entscheidungen antreibt, wird der Credit nur ein kleiner Bruchteil einer monatlichen Proxy-Rechnung sein, und der geschäftliche Schaden liegt bei Ihnen. Credits sind ein Verantwortlichkeitsmechanismus und ein Signal, dass der Anbieter die Verpflichtung ernst nimmt; sie sind keine Versicherung.
Zwei mechanische Details lohnen sich zu prüfen. Credits sind meist nicht automatisch: Viele Verträge verlangen, dass Sie sie innerhalb eines Fensters beantragen, oft 30 Tage, mit eigenen Nachweisen. Und Credits sind typischerweise auf einen bestimmten Prozentsatz der Monatsgebühr gedeckelt. Beides ist normal, aber Sie sollten es kennen, bevor Sie es brauchen.
Die Ausschlüsse, die man genau lesen sollte
Der Ausschlussabschnitt ist der Ort, an dem ein SLA tatsächlich definiert wird. Standardmäßige und vernünftige Ausschlüsse sind angekündigte geplante Wartungsarbeiten, höhere Gewalt und Ausfälle in Netzwerken, die der Anbieter nicht betreibt. Achten Sie auf Folgendes:
Geplante Wartungsarbeiten ohne Obergrenze oder ohne Ankündigungsfrist, was dem Anbieter faktisch erlaubt, jede im Voraus erklärte Ausfallzeit auszuschließen. Ausschlüsse für “Fehlkonfiguration durch den Kunden”, die so breit gefasst sind, dass sie normale Nutzung abdecken. Ausschlüsse für Dritte, die so weit gefasst sind, dass Probleme im vorgelagerten Netzwerk, die den größten Teil dessen ausmachen, was tatsächlich ausfällt, außerhalb des Versprechens liegen. Und Ausschlüsse für Verschlechterung im Unterschied zu Nichtverfügbarkeit, wodurch ein langsamer, aber lebender Dienst nicht mitgezählt wird.
Prüfen Sie außerdem, ob das SLA die Komponenten abdeckt, von denen Sie tatsächlich abhängen. Ein Proxy-Unternehmen hat mehrere: das Gateway, das Panel und die Authentifizierung, die Abrechnung und etwaige APIs. Ein SLA, das das Gateway abdeckt, während die Authentifizierung ausgeschlossen ist, bietet nicht viel Schutz, da Sie ein erreichbares Gateway, gegen das Sie sich nicht authentifizieren können, nicht nutzen können.
Wie man eine Angabe vor der Unterschrift überprüft
Ein SLA ist ein Versprechen für die Zukunft; überprüfbar sind die Gegenwart und die Vergangenheit.
Beginnen Sie mit der Statusseite. Echtzeit-Status und, noch wichtiger, eine öffentliche Vorfallshistorie sagen Ihnen, wie oft etwas kaputtgeht, wie schnell es erkannt wird und ob Postmortems ehrlich sind. Ein Anbieter ohne öffentliche Statusseite verlangt von Ihnen, der Uptime blind zu vertrauen. Shifter veröffentlicht eine solche unter status.shifter.io, wobei Gateway, ISP-IPs, die APIs, Panel und Authentifizierung sowie Abrechnung als separate Teilkomponenten erfasst werden, was genau die Granularität ist, die man sich wünscht, da man so sehen kann, welche Komponente ausgefallen ist.
Messen Sie es dann selbst während der Evaluierung. Führen Sie über einen Testzeitraum eine niedrigfrequente Verfügbarkeitsprüfung gegen das Gateway von Ihrer eigenen Infrastruktur aus durch, und Sie haben eine unabhängige Aufzeichnung statt einer Marketingzahl. Kombinieren Sie das mit einem ordentlichen Erfolgsraten-Test an Ihren echten Zielen, wie in Geschwindigkeit, Erfolgsrate und Standortgenauigkeit testen beschrieben, und Sie kennen beide Zahlen: ob der Dienst läuft und ob er für Sie funktioniert.
Schauen Sie sich schließlich die Support-Reaktionszeiten an, denn in der Praxis zählen sie mehr als der Credit. Wenn um 02:00 Uhr etwas ausfällt, bestimmt nicht der Prozentsatz auf der nächsten Rechnung Ihre Wiederherstellung, sondern wie schnell ein Mensch antwortet.
Was Shifter veröffentlicht
Zur Orientierung: Die veröffentlichten Stufen sind: Best Effort bei Starter bis Growth, typischerweise 99,5% oder besser; 99,9% monatliche Uptime bei Business bis Pro ohne formellen Credit-Mechanismus; und 99,9% bei Enterprise mit Service-Credits gemäß dem unterzeichneten Vertrag, berechnet auf Basis der monatlichen Ausgaben und als Guthaben auf der nächsten Rechnung gutgeschrieben. Die Support-Reaktionszeiten sind entsprechend gestaffelt, von Best-Effort-Chat bei Einstiegsplänen bis hin zu einem dedizierten Kanal und einem namentlich benannten Account Manager bei Enterprise. Details finden sich in der Support- und SLA-Dokumentation.
Der Grund, das klar zu benennen, ist, dass Staffelung in dieser Branche normal ist und es sich lohnt, sie zu verstehen: Ein formelles, credit-gestütztes SLA ist im Allgemeinen ein Merkmal von Enterprise-Verträgen, und wenn Ihr Beschaffungsprozess eines erfordert, ist das ein Gespräch, das man von vornherein führen sollte, statt anzunehmen, ein Self-Service-Plan würde es beinhalten.
Die Fragen, die man im Einkauf stellen sollte
Fragen Sie nach dem Messfenster und ob es monatlich oder jährlich ist. Fragen Sie nach der Definition von Ausfallzeit, insbesondere ob erhöhte Fehlerraten oder verschlechterte Latenz zählen. Fragen Sie, welche Komponenten das SLA abdeckt, Gateway, Authentifizierung, Panel, APIs, und ob sie separat gemessen werden. Fragen Sie, ob Credits automatisch oder auf Antrag erfolgen, wie lang das Antragsfenster ist und wo die Obergrenze liegt. Fragen Sie nach der Vorfallshistorie der letzten zwölf Monate. Fragen Sie, welche Support-Reaktionszusage für einen produktionskritischen Vorfall gilt und über welchen Kanal. Und fragen Sie, was ausdrücklich ausgeschlossen ist.
Ein Anbieter, der bereit ist, all das schriftlich zu beantworten, sagt Ihnen unabhängig von der Zahl selbst etwas Nützliches.
Fazit
Betrachten Sie die Prozentzahl als den am wenigsten aussagekräftigen Teil eines SLA. Das Messfenster, die Definition von Ausfallzeit, die abgedeckten Komponenten und die Ausschlüsse bestimmen, ob das Versprechen etwas bedeutet, und Service-Credits sind Verantwortlichkeit, keine Entschädigung für Ihre Verluste. Am wichtigsten: Denken Sie an die Grenze: Ein Uptime-SLA deckt die Verfügbarkeit des Gateways ab, niemals ob Drittziele Ihren Datenverkehr akzeptieren, weshalb Sie weiterhin ein eigenes Erfolgsraten-Monitoring benötigen, um zu wissen, ob Ihre Datenerhebung tatsächlich funktioniert. Verifizieren Sie mit einer öffentlichen Vorfallshistorie und eigenen Messungen während eines Testzeitraums, und gewichten Sie die Support-Reaktionsfähigkeit mindestens genauso hoch wie die Zahl selbst.
Wenn Sie auf dieser Grundlage evaluieren, finden sich die Entscheidungen auf Plan-Ebene in Auswahl des richtigen Residential-Proxy-Plans und die Kriterien auf Anbieter-Ebene in Wie man ein Proxy-Netzwerk auswählt. Der Dienst selbst sind Residential Proxies, mit Stufen und Preisen pro GB, die von Self-Service bis zu vertraglich vereinbarten Enterprise-Konditionen skalieren.