Glossaire
SGlossaire

SLA

Service Level Agreement: messbare vertragliche Verpflichtung zur Qualität eines IT-Service, definiert durch präzise Indikatoren (Verfügbarkeit, Reaktionszeit, RTO).

Ein SLA (Service Level Agreement, Service-Level-Vereinbarung) ist die messbare vertragliche Verpflichtung eines Anbieters — intern oder extern — zur Qualität eines IT-Service. Es legt im Voraus akzeptable Parameter fest (Verfügbarkeit, Reaktionszeit, RTO, Vorfall-Lösungszeit), die Messverfahren und die Konsequenzen bei Nichteinhaltung (Strafen, Gutschriften, Kündigungsrecht).

Das SLA ist das Vertragsstück, das eine Absicht in eine prüfbare Verpflichtung verwandelt.

Häufige SLA-Indikatoren

  • Verfügbarkeit (Uptime): Prozentsatz der Betriebszeit — oft in Nines ausgedrückt (99 %, 99,9 %, 99,99 %).
  • Reaktionszeit: durchschnittliche oder perzentilbasierte Latenz.
  • Übernahmezeit (Time to Respond): .
  • Lösungszeit (Time to Resolve / MTTR): .
  • [RPO](/de/glossary/rpo): und RTO.
  • Vorfall-Schweregrad: P1, P2, P3, P4.

Die «Nines» verstehen

  • 99 %: 3 Tage 15 Std. Ausfall pro Jahr.
  • 99,9 %: («three nines»): 8 Std. 45 Min. pro Jahr.
  • 99,99 %: («four nines»): 52 Min. pro Jahr.
  • 99,999 %: («five nines»): 5 Min. pro Jahr.

Der Wechsel von 99 % zu 99,99 % kostet typischerweise 100-mal mehr, nicht 10-mal.

SLA, OLA, UC: die Verpflichtungskette

  • SLA: Vertrag Anbieter ↔ Kunde.
  • OLA: (Operational Level Agreement): interne Verpflichtung zwischen Teams.
  • UC: (Underpinning Contract): Subunternehmer-Vertrag.

Goldene Regel: ein externes SLA kann niemals besser sein als das schlechteste OLA oder UC.

Ein SaaS-SLA richtig lesen

Häufige Fallen:

  • Umfang: betrifft die Verfügbarkeit die gesamte App oder nur den Basis-Service?
  • Ausschlüsse: geplante Wartung, höhere Gewalt, DDoS.
  • Berechnungsmethode: über welches Fenster?
  • Gedeckelte Strafen: meist auf 10-25 % der Monatsgebühr begrenzt.
  • Meldepflicht: die Strafe greift nur bei Meldung innerhalb eines kurzen Fensters.

SLA vs. SLO vs. SLI: das SRE-Vokabular

  • SLI: (Service Level Indicator): die rohe Messung.
  • SLO: (Service Level Objective): das interne Ziel.
  • SLA: die vertragliche Verpflichtung.

Ein SLO sollte immer anspruchsvoller sein als das entsprechende SLA.

Warum das SLA ein Governance-Thema ist

Für eine IT-Leitung gehört die SLA-Steuerung integral zur SI-Governance:

  • Anbieter-SLAs mit den intern versprochenen SLAs abstimmen.
  • Tatsächliche Kritikalität jeder Anwendung in den SLAs widerspiegeln.
  • Anbieter-Leistung in regelmäßigen Vertragsausschüssen messen.

Kabeen verbindet automatisch geschäftliche Kritikalität, Anwendungs-Abhängigkeiten und vertragliche SLAs für eine steuerbare Sicht.

Questions fréquentes

Was ist ein SLA?

Ein SLA (Service Level Agreement) ist die vertragliche Verpflichtung eines IT-Anbieters — intern oder extern — zur Qualität eines Service. Es definiert messbare Indikatoren (Verfügbarkeit, Reaktionszeit, RTO, RPO), Mess-Modalitäten und Konsequenzen bei Nichteinhaltung (Gutschriften, Strafen, Kündigung). Es ist das Stück, das eine Absicht in eine prüfbare Verpflichtung verwandelt.

Was bedeutet eine Verfügbarkeit von 99,9 %?

Eine Verfügbarkeit von 99,9 % («three nines») erlaubt 8 Stunden 45 Minuten Ausfall pro Jahr, also etwa 43 Minuten pro Monat. Der Wechsel zu 99,99 % reduziert dieses Budget auf 52 Minuten pro Jahr, und 99,999 % auf 5 Minuten pro Jahr. Jede zusätzliche «Nine» multipliziert die Infrastruktur-Kosten typischerweise um 5 bis 10. Das Ziel muss den realen Geschäftswert widerspiegeln.

Unterschied zwischen SLA, OLA und UC?

Das SLA ist eine externe Verpflichtung zwischen einem Anbieter und seinem Kunden. Das OLA (Operational Level Agreement) ist eine interne Verpflichtung zwischen Teams derselben Organisation (das Netzwerk-Team gegenüber dem Support-Team). Das UC (Underpinning Contract) ist ein Subunternehmer-Vertrag mit einem Dritten. Schlüsselregel: ein externes SLA kann niemals besser sein als die OLAs und UCs, die es intern stützen.

Welche Fallen in einem SaaS-SLA vermeiden?

Vier wiederkehrende Fallen: (1) der Umfang — prüfen, ob die Verfügbarkeit die gesamte App oder nur den Basis-Service abdeckt, (2) die Ausschlüsse — geplante Wartung, DDoS, höhere Gewalt, oft umfangreich, (3) die auf 10-25 % der Monatsgebühr gedeckelten Strafen, weit unter den realen Ausfall-Kosten, (4) die Meldepflicht in einem kurzen Fenster (oft 30 Tage), um die Strafe auszulösen.