SLA (Service Level Agreement)

Ein Service Level Agreement (SLA) definiert verbindliche Leistungszusagen eines Dienstleisters, z. B. Verfügbarkeit, Reaktionszeiten und Verantwortlichkeiten im Störungsfall.

Was ist ein SLA (Service Level Agreement)?

Ein Service Level Agreement (SLA) ist ein vertraglich bindendes Abkommen zwischen einem Dienstleister und einem Kunden, das messbare Leistungskriterien (Service Levels), Verfügbarkeitsziele, Reaktionszeiten und Verantwortlichkeiten definiert. Im Kontext von IT- und Infrastrukturdiensten wie Cloudflare, CDNs oder Hosting-Anbietern legt ein SLA fest, welche Leistung der Kunde erwarten kann und welche Konsequenzen (meist finanzielle Gutschriften) eintreten, wenn der Anbieter diese vereinbarten Ziele nicht erreicht. Während große Cloudflare-Störungen die tatsächliche, internetweite Auswirkung eines Anbieterausfalls demonstrieren, zeigt das zugehörige SLA die formalen Grenzen der Haftung und Entschädigung auf. Es offenbart oft eine signifikante Lücke zwischen dem geschäftlichen Schaden für den Kunden und der vertraglich geregelten Kompensation, besonders wenn der Anbieter ein Single Point of Failure (SPOF) für das Geschäft darstellt.

Typische Bestandteile eines SLA

Ein gut strukturiertes SLA enthält mehrere Kernkomponenten:

1. Service Level Objectives (SLOs) – Die messbaren Ziele

SLOs sind die quantifizierbaren Metriken, anhand derer die Leistung gemessen wird. Die wichtigsten sind:

  • Verfügbarkeit (Uptime): Der prozentuale Anteil der Zeit, in der der Dienst betriebsbereit ist. Üblich sind Werte wie 99,9% („drei Neun“), 99,95% oder 99,99% („vier Neun“).
    • Beispiel: 99,9% Verfügbarkeit erlaubt max. 8h 46m Ausfallzeit pro Jahr.
  • Fehlerrate: Der Prozentsatz der Anfragen, die mit einem HTTP-Fehler (z.B. 5xx) oder Timeout antworten.
  • Performance/Latenz: Die maximale oder durchschnittliche Latenz für Anfragen, oft gemessen am 95. oder 99. Perzentil (p95/p99).
  • Support-Reaktions- und Lösungszeiten: Definiert, wie schnell der Anbieter auf ein Ticket reagieren und ein Problem lösen muss (z.B. „Reaktion innerhalb 1 Stunde bei Priorität High“).

2. Metriken und Messmethoden

Wie werden die SLOs gemessen? Dies ist entscheidend, da unterschiedliche Messpunkte zu unterschiedlichen Ergebnissen führen können.

  • Messpunkt: Misst Cloudflare die Verfügbarkeit aus seinem eigenen Netzwerk heraus oder von externen Prüfpunkten? Ersteres zeigt möglicherweise keine Probleme an, die nur bestimmte Internet-Provider betreffen.
  • Ausschlüsse (Exclusions): Fast jedes SLA enthält Ausnahmen, für die die Ziele nicht gelten. Typische Ausschlüsse sind:
    • Geplante Wartungsarbeiten.
    • Höhere Gewalt (Force Majeure).
    • Handlungen oder Fehler des Kunden.
    • Probleme bei zugrunde liegenden Diensten Dritter (z.B. Internet-Backbone-Ausfälle).

3. Berichterstattung und Eskalation

  • Wie und wie oft berichtet der Anbieter über die Erreichung der SLOs (z.B. monatliches Dashboard)?
  • Welche Eskalationspfade gibt es, wenn SLOs verfehlt werden oder der Support nicht reagiert?

4. Wiedergutmachung (Remedies/Service Credits)

Das ist der Kern der „Garantie“. Was passiert, wenn der Anbieter das SLA bricht?

  • Service Credits: Die typische Folge ist eine Gutschrift auf die nächste Rechnung. Die Höhe ist meist gestaffelt nach der Schwere des Verstoßes.
    • Beispiel: 99,9% Verfügbarkeit nicht erreicht → 10% Gutschrift. 99% nicht erreicht → 30% Gutschrift.
  • Kündigungsrecht: In seltenen Fällen und bei schwerwiegenden, wiederholten Verstößen erhält der Kunde das Recht, den Vertrag fristlos zu kündigen.

Die Realität von SLAs bei großen Infrastrukturanbietern wie Cloudflare

Die SLAs globaler Plattformen wie Cloudflare sind oft so ausgelegt, dass sie trotz gelegentlicher, schwerwiegender Störungen formal eingehalten werden.

  • Hoch angesetzte Verfügbarkeitsziele: Cloudflare wirbt mit einer 100% Uptime-Garantie für seine CDN- und DDoS-Schutz-Dienste. Dies klingt absolut, ist aber an Bedingungen und Messmethoden geknüpft.
  • Messung aus Anbieterperspektive: Die Verfügbarkeit wird oft aus der Sicht von Cloudflares eigenem, globalem Netzwerk gemessen. Ein Problem, das nur einen Teil der Nutzer oder bestimmte Regionen betrifft (wie bei einigen historischen Ausfällen), kann unter Umständen die globale Verfügbarkeitsmetrik nicht unter den Schwellenwert drücken.
  • Gutschriften decken den Schaden nicht ab: Die finanziellen Service Credits sind in der Regel auf einen Bruchteil der monatlichen Dienstkosten begrenzt (oft 10-100%). Der tatsächliche geschäftliche Schaden eines mehrstündigen Ausfalls für einen E-Commerce-Shop – verlorene Umsätze, Kundenvertrauen, Supportaufwand – übersteigt diese Gutschrift um ein Vielfaches. Das SLA ist eine betriebliche, keine geschäftliche Versicherung.
  • Ausschlüsse schützen den Anbieter: Die umfangreichen Ausschlussklauseln können dazu führen, dass selbst ein mehrstündiger Ausfall nicht unter das SLA fällt, wenn er z.B. auf einen Konfigurationsfehler eines anderen Kunden oder ein nicht näher definiertes „Netzwerkproblem“ zurückzuführen ist.

Warum das Verständnis des SLA im Kontext von Störungen kritisch ist

Für ein Unternehmen, das von einem Dienst wie Cloudflare abhängt, ist das SLA mehr als ein Vertragsanhang – es ist ein zentraler Teil der Risikobewertung und Notfallplanung.

  1. Es definiert die reale „Garantie“: Das SLA zeigt nüchtern auf, was Ihnen im Schadensfall vertraglich zusteht. Es macht deutlich, dass Sie für Ihr Geschäftskontinuitätsrisiko im Wesentlichen selbst verantwortlich sind.
  2. Es treibt die Notwendigkeit eigener Resilienzmaßnahmen voran: Da die Kompensation durch den Anbieter unzureichend ist, müssen Sie selbst Vorsorge treffen. Das SLA ist das stärkste Argument für Investitionen in:
    • Redundanz-Architekturen: Ein Multi-CDN-Ansatz, um nicht von einem Anbieter abhängig zu sein.
    • DNS-Failover: Eine schnelle Umleitungsmöglichkeit bei Ausfall des primären Dienstes.
    • Umfassendes, externes Monitoring: Um Verstöße gegen das SLA überhaupt nachweisen und eigene Gegenmaßnahmen einleiten zu können.
  3. Es ist Verhandlungsgrundlage für Enterprise-Verträge: Für große Kunden sind SLAs verhandelbar. Sie können strengere SLOs, höhere Credits oder kritischere Metriken (z.B. Performance aus Nutzersicht) aushandeln.

Best Practices im Umgang mit SLAs

  • Lesen und verstehen Sie das SLA, bevor Sie sich binden: Besonders die Abschnitte zu Definitionen, Messmethoden und Ausschlüssen sind kritisch.
  • Überwachen Sie die SLA-Einhaltung selbst: Verlassen Sie sich nicht auf die Berichte des Anbieters. Implementieren Sie eigenes Monitoring von mehreren, externen Standorten aus, das genau die im SLA definierten Metriken (Verfügbarkeit, Latenz) misst. Diese Daten sind Ihre Beweisgrundlage.
  • Kalkulieren Sie Ihr eigenes Business-Risiko: Fragen Sie sich: Was kostet mich eine Stunde Ausfall? Vergleichen Sie diese Zahl mit der maximalen SLA-Gutschrift. Die Differenz ist das Risiko, das Sie durch eigene Architektur oder eine externe Versicherung absichern müssen.
  • Integrieren Sie SLA-Verstöße in Ihren Incident Response: Ihr Incident Response-Plan sollte einen Schritt enthalten, bei dem bei einem größeren Vorfall die SLA-relevanten Daten gesichert und die Meldung/Geltendmachung von Service Credits eingeleitet wird.
  • Planen Sie über das SLA hinaus: Die ultimative Absicherung ist nicht die Gutschrift, sondern die Vermeidung des Ausfalls. Investieren Sie in Architekturen, die Sie unabhängiger von den SLA-Zusagen eines einzelnen Anbieters machen.

Fazit

Ein Service Level Agreement ist ein notwendiger, aber unzureichender Schutz für geschäftskritische Online-Dienste. Es setzt einen formalen Rahmen für die Leistungserwartungen an einen Anbieter wie Cloudflare und bietet eine minimale finanzielle Kompensation bei Verstößen.

Die jüngsten, internetweiten Störungen haben jedoch die Grenzen dieses Instruments schmerzhaft deutlich gemacht: Das wahre Risiko liegt in der Abhängigkeit von einem zentralen Single Point of Failure, dessen Ausfall Ihr Geschäft lahmlegt – unabhängig davon, ob danach 10% oder 100% des Monatsbeitrags gutgeschrieben werden. Ein kluges Unternehmen behandelt das SLA daher nicht als Sicherheitsnetz, sondern als eine von vielen Kennzahlen in einer umfassenden Strategie für digitale Resilienz. Der Fokus sollte darauf liegen, die eigene Architektur so zu gestalten, dass die Einhaltung oder Verletzung eines einzelnen SLA nicht über Wohl und Wehe des Geschäfts entscheidet.