Zusammenfassung

  • Ein Verfügbarkeits-SLA ist kein allgemeines Versprechen, den wirtschaftlichen Schaden eines Ausfalls zu übernehmen. Es definiert eine Messgrenze, technische Voraussetzungen, eine Entgeltbasis und einen begrenzten Rechtsbehelf. Deshalb können zwei nominell ähnliche Verfügbarkeitswerte sehr unterschiedliche Risikotransfers darstellen.

  • Architektur und Nachweisführung gehören ökonomisch zum SLA. Bei AWS verändert die Verteilung über Availability Zones das anwendbare EC2-Versprechen; Google unterscheidet unter anderem nach Deployment, Region, Projekt, Instanz und Netzebene; IBM zeigt ausdrücklich, dass ein hohes Infrastruktur-SLO erst durch passende Workload-Architektur nutzbar wird. Der Käufer bezahlt also nicht nur Cloud-Ressourcen, sondern gegebenenfalls auch die Redundanz, die notwendig ist, um die höhere Zusage überhaupt zu erreichen. (Amazon Web Services, Inc.)

  • Anspruchsfristen, Logs, Ressourcenkennungen, Ausschlüsse, Obergrenzen und Kumulierungsverbote sind keine juristischen Nebensätze. Sie entscheiden darüber, ob aus einem technischen Vorfall überhaupt ein verwertbarer Anspruch entsteht und wie weit dieser reicht.

Die Prozentzahl ist nur das Etikett

In Beschaffungsunterlagen werden Cloud-SLAs häufig auf eine Zahl verdichtet: 99,9%, 99,99%, 100%. Das ist bequem, aber analytisch schwach. Die Zahl ist das nominale Etikett eines wesentlich größeren Mechanismus.

Für eine wirtschaftliche Bewertung müssen mindestens drei Dinge getrennt werden: das Etikett, die Abhängigkeit und der Rechtsbehelf. Das Etikett sagt, welchen Ziel- oder Mindestwert der Anbieter für einen definierten Gegenstand veröffentlicht. Die Abhängigkeit beschreibt, welche Architektur, Ressource und Messmethode erforderlich sind, damit dieser Wert überhaupt anwendbar ist. Der Rechtsbehelf bestimmt, was geschieht, wenn der gemessene Wert unterschritten wird.

Cloudflares 100%-Zusicherung illustriert diese Trennung besonders klar. Der veröffentlichte SLA definiert einen Service Credit als Anteil der monatlichen Serviceentgelte des Service. Die planmäßige Verfügbarkeit wird um kundengeplante Downtime und durch höhere Gewalt verursachte Ausfallzeit bereinigt. Ein ungeplanter Serviceausfall muss zudem dazu führen, dass die Anwendung für Kunden oder Nutzer nicht verfügbar ist. Das ist eine spezifische Vertragsgrenze, keine universelle Definition von Endnutzerverfügbarkeit. (Cloudflare)

Die Betroffenenquote verfeinert diese Grenze weiter. Sie setzt die Zahl der von einem ungeplanten Ausfall betroffenen eindeutigen Besucher ins Verhältnis zu sämtlichen eindeutigen Besuchern. Der Credit steigt folglich nicht nur mit der Ausfalldauer, sondern auch mit der gemessenen Reichweite des Ereignisses. Das ist ein plausibler Mechanismus zur Differenzierung zwischen lokalem und umfassendem Ausfall. Gleichzeitig macht er sichtbar, dass eine SLA-Zahl erst durch ihre Messvariablen wirtschaftlichen Inhalt erhält.

Messgrenzen sind Teil des Produkts

AWS zeigt denselben Grundsatz mit einer anderen Konstruktion. Das regionale EC2-SLA von 99,99% gilt nur, wenn alle laufenden Instanzen gleichzeitig auf mindestens zwei Availability Zones verteilt sind. Für eine einzelne EC2-Instanz gilt dagegen ein Instance-Level-SLA von 99,5%. Die Stufen der veröffentlichten Credits liegen bei 10%, 30% und 100%. (Amazon Web Services, Inc.)

Die Architektur ist damit keine nachgelagerte technische Empfehlung. Sie bestimmt, welcher Vertragsmechanismus anwendbar ist. Ein Käufer, der „99,99% EC2“ in eine Risikoübersicht einträgt, ohne zu prüfen, ob der tatsächliche Workload die Multi-AZ-Voraussetzung erfüllt, vermischt Anbieteretikett und eigene Deployment-Realität.

Auch die Entgeltbasis unterscheidet sich. Beim regionalen AWS-Anspruch ist die EC2-Monatsrechnung der betroffenen Region relevant, beim Instanzanspruch die betroffene Einzelinstanz; einmalige Zahlungen wie Reserved-Instance-Vorauszahlungen sind ausgenommen. Credits werden üblicherweise gegen künftige EC2-Zahlungen verrechnet. Regionaler und instanzbezogener Anspruch dürfen für dieselbe Einzelinstanz nicht gestapelt werden. (Amazon Web Services, Inc.)

Man kann deshalb nicht aus „100% Credit“ schließen, dass 100% des wirtschaftlichen Schadens ersetzt würden. Selbst die höchste Stufe bezieht sich auf einen vertraglich definierten Rechnungsbetrag. Wenn ein Compute-Baustein nur einen kleinen Anteil der Gesamtkosten eines geschäftskritischen Dienstes ausmacht, kann die maximale Gutschrift weit unter den Folgekosten eines längeren Ausfalls liegen.

Das ist keine Fehlfunktion des SLA. Es ist seine Konstruktion.

Eine Minute kann juristisch länger sein als technisch

Google Compute Engine setzt andere Grenzen. Die Berechnung erfolgt je nach Fall pro Projekt und Region oder für eine Einzelinstanz. Die veröffentlichte Zusage hängt außerdem vom Deployment und von der Netzebene ab. Für Multi-Zonen-Instanzen gelten je nach Region und Tier andere SLO-Werte als für Einzelinstanzen. (Google Cloud)

Bemerkenswert ist die Zeiteinheit: Eine Downtime Period besteht aus einer oder mehreren aufeinanderfolgenden vollen Minuten. Teilminuten oder intermittierende Downtime von weniger als einer Minute zählen nicht als Downtime Period. Für einen Latenz- oder Transaktionspfad kann eine Störung von 40 Sekunden geschäftlich durchaus bedeutsam sein. Innerhalb dieser Vertragsmetrik fällt sie jedoch unter eine andere Messlogik. (Google Cloud)

Die Financial-Credit-Stufen von Google liegen bei 10%, 25% und 100%. Die genaue Schwelle hängt vom erfassten Service und Deployment ab. Der Höchstbetrag der Credits eines Abrechnungsmonats ist auf das für die betroffenen Covered Services in den betroffenen Regionen geschuldete Entgelt begrenzt; der Credit wird auf künftige Nutzung angewendet. Für dieselbe virtuelle Maschine kann Downtime entweder als Single Instance oder als Teil von Instances in Multiple Zones berücksichtigt werden, nicht beides. (Google Cloud)

Wieder entsteht dieselbe Differenz: Die Messregel beantwortet nicht die Frage „War unser Dienst für Kunden gestört?“, sondern eine engere Frage: „Ist innerhalb der vertraglich definierten Ressource und Messperiode ein qualifizierendes Ereignis eingetreten?“

Die Entgeltbasis ist die eigentliche Haftungswährung

Cloudflares Beispielrechnung macht den nächsten Mechanismus sichtbar. Die Formel erzeugt eine Quote, aber die Quote wird nur auf die monatlich wiederkehrenden Entgelte des erfassten Service angewendet. Der Jahresbetrag der Service Credits ist zudem auf sechs Monate kumulierter monatlicher Serviceentgelte begrenzt; die Credits sind der ausschließliche SLA-Rechtsbehelf. (Cloudflare)

Oracle formuliert denselben Grundgedanken granularer. Ein Service Credit bezieht sich auf den konkreten Non-Compliant Service. Berechnet wird er als Prozentsatz der Nettoentgelte für die tatsächlich während der Messperiode genutzte Menge dieses Service. Je nach Dienst kann der Pillar Verfügbarkeits-, Manageability- oder Performance-SLAs vorsehen. (Oracle)

Damit wird die wirtschaftliche Grenze explizit: Nicht der Umsatz des ausgefallenen Onlineshops, nicht die Kosten einer manuellen Notfalloperation und nicht der Wert verpasster Transaktionen bilden den Nenner. Der Nenner ist Cloud-Entgelt.

Das verändert die Bedeutung des Begriffs „100% Credit“. Eine Gutschrift von 100% kann die vollständige Rückgabe des für einen definierten Service in einer definierten Periode relevanten Entgelts bedeuten und trotzdem nur einen kleinen Teil des End-to-End-Risikos eines Workloads übertragen.

Ein SLA ist daher näher an einer begrenzten Preisadjustierung als an einer vollständigen Betriebsunterbrechungsversicherung.

Der Anspruch ist ein operativer Prozess

Der Wert eines SLA hängt nicht nur von seiner Formel ab, sondern davon, ob der Käufer den Anspruch praktisch realisieren kann.

Cloudflare verlangt zunächst eine Meldung an den Support innerhalb von fünf Geschäftstagen nach dem Vorfall. Für den Claim sind unter anderem Beschreibung und Dauer des Vorfalls, Netzwerk-Traceroutes, betroffene URLs und eigene Lösungsversuche anzugeben. Ausreichende Belege für den Claim müssen bis zum Ende des auf den Vorfallmonat folgenden Abrechnungsmonats eingereicht sein. Cloudflare validiert den Anspruch anhand der vernünftigerweise verfügbaren Informationen. (Cloudflare)

Auch die Messverantwortung ist verteilt. Cloudflare erklärt, nicht für ein umfassendes Monitoring des Customer Content verantwortlich zu sein. Diese Aufgabe liegt beim Kunden. Zugleich berücksichtigt Cloudflare Daten aus einem wirtschaftlich angemessenen unabhängigen Messsystem des Kunden und verwendet verfügbare Informationen, um die Betroffenenquote zu berechnen. (Cloudflare)

AWS verlangt bei Credit-Anträgen unter anderem Datum und Uhrzeit, betroffene Region beziehungsweise Availability Zone, Ressourcen-IDs sowie Request-Logs oder andere Daten, mit denen sich der behauptete Ausfall validieren lässt. Ohne die verlangten Informationen kann der Anspruch entfallen. (Amazon Web Services, Inc.)

Google verlangt den Credit-Antrag innerhalb von 60 Tagen ab Anspruchsberechtigung und Logs, aus denen Downtime Periods mit Datum und Uhrzeit hervorgehen. Auch dort führt die Nichterfüllung der Anforderungen zum Verlust des Credit-Anspruchs. (Google Cloud)

Oracle verlangt für den betreffenden PaaS- oder IaaS-Service ebenfalls einen dokumentierten Claim. Dazu gehören unter anderem Dienstname, Beschreibung, Zeitpunkt und Dauer, Region, relevante OCIDs, eigene Lösungsversuche sowie geeignete Logs. Der Anspruch muss innerhalb von 60 Kalendertagen nach dem auslösenden Ereignis eingehen. (Oracle)

Diese Anforderungen verlagern einen Teil der Beweisproduktion auf den Käufer. Das ist ökonomisch folgerichtig, wenn der Käufer Teile der Fehlerfläche selbst kontrolliert: Workload-Konfiguration, Client-Sicht, Anwendungslogs und externe Messpunkte liegen häufig nicht vollständig beim Cloud-Anbieter. Es hat aber eine Konsequenz für die Beschaffung: Ein SLA ohne passende Telemetrie und internen Claim-Prozess kann formal vorhanden und praktisch wertlos sein.

Nicht-Kumulierung verhindert die Addition von Papieransprüchen

Cloud-Workloads bestehen aus Abhängigkeiten. Ein einzelnes Ereignis kann Compute, Storage, Netzwerk, Load Balancing oder Managementfunktionen gleichzeitig berühren. Würden alle nominellen Credits addiert, könnte dieselbe technische Ursache mehrfach monetarisiert werden.

Die untersuchten Bedingungen begrenzen das.

AWS erlaubt für eine bestimmte einzelne EC2-Instanz keinen kombinierten regionalen und instanzbezogenen Claim. Google erlaubt für eine konkrete VM entweder den Single-Instance- oder den Multi-Zonen-Credit. Oracle sieht bei mehreren einschlägigen SLA-Regeln für denselben Vorfall grundsätzlich den höchsten Credit vor, nicht die Summe; insgesamt kann der Credit das Entgelt für den tatsächlich genutzten betroffenen Non-Compliant Service nicht übersteigen. (Amazon Web Services, Inc.)

Diese Regeln sind für Käufer wichtig, weil sich der nominale Umfang eines SLA-Portfolios sonst leicht überschätzen lässt. Fünf einzelne Komponenten mit jeweils einer Credit-Regel ergeben nicht automatisch fünf unabhängige finanzielle Absicherungen gegen denselben Ausfall.

Oracle geht noch einen Schritt weiter, indem Nutzung und Verfall eines Credits vom Kaufmodell abhängen können. Bei bestimmten Credit-Modellen müssen Gutschriften innerhalb definierter Perioden genutzt werden; andere Modelle behandeln sie anders. Der Rechtsbehelf ist damit nicht nur in seiner Höhe, sondern auch in seiner Verwertbarkeit von der Einkaufsstruktur abhängig. (Oracle)

Architektur bleibt die große nicht übertragene Position

Die schärfste Trennung zwischen Anbieterzusage und Workload-Risiko findet sich in IBMs Resiliency-Leitfaden. IBM unterscheidet ein SLO als nichtvertragliches Ziel von einem SLA, dessen Unterschreitung einen Anspruch auf Service Credits auslösen kann. (IBM Cloud)

Für das Beispiel eines VPC-SLO von 99,999% erläutert IBM, dass ein Workload zur vollen Nutzung dieses Ziels mindestens drei virtuelle Server — jeweils einen in jeder der drei Zonen einer Multi-Zone-Region — sowie einen Load Balancer benötigt. Zwei Server in zwei Zonen reduzieren die Resilienz; ein einzelner Server ohne Load Balancer reduziert sie weiter. (IBM Cloud)

Das ist nicht nur eine technische Fußnote. Es zeigt, wer den Preis der Resilienz trägt.

Ein Anbieter kann seine Cloud-Infrastruktur resilient auslegen. Der Käufer muss trotzdem genügend Instanzen, Zonen, Load Balancing, Wiederherstellung und Betriebsprozesse finanzieren, um seinen eigenen Workload resilient zu machen. IBM formuliert diese Arbeitsteilung ausdrücklich: Der Anbieter verantwortet Resilienz und Wiederherstellung der Cloud; der Kunde Resilienz und Wiederherstellung seines Workloads. (IBM Cloud)

Damit verschiebt sich die Einkaufsfrage. Sie lautet nicht: „Welcher Anbieter hat die höchste SLA-Zahl?“ Sie lautet: „Welche Architektur müssen wir kaufen, betreiben und testen, damit unser tatsächliches Risiko dem gewünschten Niveau entspricht — und welcher Teil des verbleibenden Risikos wird vertraglich überhaupt übertragen?“

Der Preis der Lücke

Eine belastbare SLA-Analyse endet deshalb nicht beim Credit.

Die nicht übertragene Lücke muss separat behandelt werden. Ein Teil lässt sich durch Architektur reduzieren: Redundanz, mehrere Zonen, unabhängige Failure Domains und Wiederherstellungsmechanismen. Ein anderer Teil kann durch Beschaffungsbedingungen adressiert werden, soweit Verhandlungsspielraum vorhanden ist. Ein weiterer Teil gehört in Versicherungs- und Risikofinanzierungsentscheidungen. Und ein letzter Teil betrifft Exit-Fähigkeit: die Frage, wie schnell ein Workload, Datenbestand oder Geschäftsprozess aus einer nicht mehr akzeptablen Abhängigkeit herausgelöst werden kann.

Diese Instrumente sind keine Alternativen zum SLA. Sie decken andere Schichten desselben Risikos ab.

Für die operative Messung sollte der gemeinsame Datensatz möglichst schlank und rekonstruierbar sein: klarer Ereignisbeginn und -ende, eindeutig bezeichnete Ressourcen, unveränderliche Logs, definierte externe Messpunkte und dokumentierte Kundenmaßnahmen. Je weniger Interpretationsspielraum die Rekonstruktion eines Vorfalls benötigt, desto geringer ist das Risiko, dass ein formal berechtigter Claim an Beweisfragen scheitert.

Das ist auch der Grund, warum der Vergleich von Cloud-SLAs nicht als Zuverlässigkeitsrangliste gelesen werden sollte. Cloudflare, AWS, Google, Oracle und IBM zeigen unterschiedliche Mess- und Rechtsbehelfsdesigns. Aus den Vertragsbedingungen allein folgt nicht, welcher Anbieter im Betrieb häufiger oder seltener ausfällt.

Was sich vergleichen lässt, ist etwas anderes: welche Fehlerfläche gemessen wird, welche Architektur vorausgesetzt wird, welcher Rechnungsbetrag als Basis dient, wer Beweise liefern muss und welcher Rechtsbehelf nach allen Grenzen übrig bleibt.

Darin liegt die wirtschaftliche Bedeutung eines SLA.

Nicht in der Zahl, die oben steht, sondern in dem Risiko, das darunter tatsächlich den Besitzer wechselt.

Quellen