Service Level Management und SLA

Service Level Management (SLM) ist die ITIL-Disziplin, die dafür sorgt, dass IT-Dienstleistungen mit messbaren Versprechen versehen werden – und dass diese Versprechen auch gehalten werden. Das zentrale Artefakt heißt SLA – Service Level Agreement, der zwischen IT (Service Provider) und Kunde (Service Consumer) festlegt: „Wir liefern Service X mit Verfügbarkeit Y, Antwortzeiten Z und Support-Reaktion innerhalb von W Minuten." Ohne SLA gibt es keine objektive Grundlage zu sagen, ob der Service gut oder schlecht läuft – Diskussionen werden zu Bauchgefühl-Debatten. In dieser Lektion klärst du die Hierarchie SLA → OLA → UC, lernst die wichtigsten Metriken und übst, wie viel „99,9 % Verfügbarkeit" eigentlich bedeutet – nämlich nicht so wenig Downtime wie man denkt.

1) Die SLA-Hierarchie – SLA, OLA, UC

Drei Vertragsarten kommen vor, die du auseinanderhalten musst:

SLA / OLA / UC – die drei Vertragsarten im SLM

SLA

Service Level Agreement – Vereinbarung zwischen IT-Provider und Kunde. Schriftlich, mit messbaren Zielen. → Parteien: IT-Provider ↔ Endkunde / Fachbereich

OLA

Operational Level Agreement – interne Vereinbarung zwischen verschiedenen internen IT-Bereichen. Die OLAs müssen so gestaltet sein, dass der SLA insgesamt erfüllt werden kann. → Parteien: Service-Desk ↔ Netzwerk-Team ↔ DB-Team ↔ Storage-Team

Underpinning Contract (auch: Underpinning Agreement) – Vertrag mit externen Lieferanten. Muss strenger sein als der SLA, damit deren Verzögerungen den SLA nicht reißen. → Parteien: IT-Provider ↔ Cloud-Anbieter / ISP / Software-Hersteller

Die Stärke dieser drei muss kongruent sein: ein SLA verspricht 99,9 % Verfügbarkeit – dann muss die OLA mit dem Storage-Team mindestens 99,95 % zusagen und der UC mit dem ISP mindestens 99,99 %. Sonst kann der SLA gar nicht eingehalten werden, weil die Zulieferer „erlaubterweise" länger ausfallen dürfen.

2) Was in einem SLA steht

Ein SLA ist mehr als nur ein Verfügbarkeitsversprechen. Die typischen Bestandteile:

Abschnitt	Inhalt
Service-Beschreibung	Was genau ist der Service? Welche Komponenten gehören dazu, welche nicht?
Service-Zeiten	Geschäftszeiten (z. B. Mo-Fr 7-19 Uhr) oder 24/7? Was passiert außerhalb?
Verfügbarkeit	z. B. „99,5 % während Service-Zeiten" – Berechnungsformel und Ausnahmen
Performance / Antwortzeiten	z. B. „Page-Load p95 < 2 Sek." oder „DB-Antwort < 100ms"
Support-Reaktion	Prio 1: 15 Min., Prio 2: 1 Std., Prio 3: 4 Std. Wann wird reagiert, wann gelöst?
Eskalationswege	Wer wird angesprochen bei Problemen? Wer entscheidet?
Berichtszeitpunkte	Monatlicher SLM-Report mit Kennzahlen, Quartals-Review
Pönalen / Bonus	Was passiert bei Nichteinhaltung? Strafzahlungen? Gutschriften?
Ausnahmen	Wartungsfenster, geplante Downtimes, „höhere Gewalt"

3) Verfügbarkeit – was die Zahlen wirklich bedeuten

„99,9 %" klingt nach „fast immer". Aber wieviel Ausfall ist das tatsächlich pro Jahr? Klick die Service-Levels an, um zu sehen, wie sich die zulässige Downtime entwickelt – das ist die wichtigste Tabelle im SLM:

Verfügbarkeits-Level – die „Neun-Regel"

99 %

two nines

99,9 %

three nines

99,95 %

Cloud-Standard

99,99 %

four nines

99,999 %

five nines

Jede zusätzliche „9" multipliziert die Anforderungen drastisch. 99,99 % verlangt schon Hochverfügbarkeits-Setups (Cluster, Failover, redundante Verbindungen). 99,999 % ist ohne grundlegende Architektur-Maßnahmen praktisch unmöglich – und meist nicht wirtschaftlich zu rechtfertigen. Mehr in Verfügbarkeit berechnen und MTBF / MTTR.

4) Andere wichtige Metriken im SLA

MTBF

Mean Time Between Failures – Durchschnittsabstand zwischen Ausfällen. Höher = besser. Aussage über Zuverlässigkeit.

MTTR

Mean Time To Repair/Restore – Durchschnittliche Reparaturzeit. Niedriger = besser. Aussage über Reaktionsfähigkeit.

First Response Time

Wie lange dauert es bis zur ersten Reaktion (nicht Lösung) auf ein Ticket. Wichtig für die Anwender-Wahrnehmung.

Mean Time to Resolution

Wie lange von Ticket-Eröffnung bis komplette Lösung? Steht oft pro Prioritätsstufe im SLA.

p95 / p99 Latency

Antwortzeit unter der 95 % bzw. 99 % der Requests bleiben. Aussagekräftiger als Mittelwert.

CSAT / NPS

Customer Satisfaction / Net Promoter Score – qualitative Bewertung durch den Nutzer. Oft Ergänzung zu rein technischen Metriken.

5) SLI, SLO, SLA – das SRE-Modell

Im Cloud- und SRE-Umfeld (Site Reliability Engineering) wird das SLA-Konzept feiner aufgeteilt. Du solltest die drei Begriffe kennen:

SLI (Service Level Indicator) – die gemessene Größe. Z. B. „Verfügbarkeit (in %) basierend auf erfolgreichen HTTP-200-Antworten".
SLO (Service Level Objective) – das interne Ziel. Z. B. „SLI ≥ 99,95 % pro 30-Tage-Fenster". Strenger als SLA, gibt Puffer.
SLA (Service Level Agreement) – das Versprechen an den Kunden mit Konsequenzen. Z. B. „SLI ≥ 99,9 %, bei Nichteinhaltung Gutschrift X". Lockerer als SLO, weil Konsequenzen kosten.

Faustregel: SLO > SLA. Wenn dein internes Ziel 99,95 % ist, kannst du dem Kunden ehrlich 99,9 % versprechen – mit „Sicherheitspuffer". Wer SLA = SLO setzt, hat keine Reserve und reißt früher oder später den SLA.

6) Reporting und SLM-Reviews

Ein SLA ohne Reporting ist wertlos. Die ITIL-Practice Service Level Management sieht regelmäßige Termine vor:

SLM-Report (monatlich): Wie lief der Service? Wie viele Tickets, wie viele SLA-Verletzungen, welche Metriken? Datenquellen: Monitoring und Ticketsystem.
Service-Review (quartalsweise / jährlich): persönliches Treffen mit dem Kunden – passt das SLA noch zum Bedarf? Erfüllen wir die Erwartungen wirklich?
SLA-Anpassung bei strukturellen Änderungen – neuer Standort, neue Anwendung, geänderte Geschäftszeiten. Eng verbunden mit Change Management.

Wer beim Service-Review zum ersten Mal hört, dass der Kunde unzufrieden ist, hat das SLM falsch betrieben. Gutes SLM erkennt Probleme früh – über kontinuierliches Reporting und proaktive Kommunikation.

7) Typische Fallstricke

SLA ohne Messgrundlage. „99,9 % Verfügbarkeit" – wie wird das gemessen? Per Ping? HTTP-200? Ende-zu-Ende-Transaktion? Klar definieren, sonst gibt es Streit.
Geschäftszeiten ignoriert. 99,5 % über 24/7 ist etwas anderes als 99,5 % über Mo-Fr 8-18 Uhr. Erst entscheidet der Geschäftsbedarf.
Pönalen ohne Wert. Eine Strafzahlung von 5 % der Monatsgebühr motiviert keinen Anbieter, wenn der Schaden des Kunden eine Größenordnung höher liegt. SLA-Strafen sind nicht der Schadensersatz – das ist Sache des Vertragsrechts.
OLA und UC vergessen. Ein SLA mit dem Kunden, aber kein OLA mit dem Storage-Team? Bei Disk-Ausfall hängt der SLA in der Luft, weil das interne Team „kein Versprechen verletzt".
Wartungsfenster nicht definiert. Während des Wartungsfensters läuft die SLA-Uhr nicht. Wenn Wartung jede Nacht zwei Stunden dauert, ist die 99 %-Aussage mathematisch trivial – aber für den Kunden unzureichend.

Zusammenfassung

Service Level Management (SLM) ist die ITIL-Practice, die Service-Versprechen formal regelt und kontinuierlich überprüft. Drei Vertragsarten: SLA (mit dem Kunden), OLA (zwischen internen IT-Teams), UC (mit externen Lieferanten) – die müssen kongruent sein, sonst kann der SLA nicht eingehalten werden. Verfügbarkeits-Stufen folgen der „Neun-Regel": 99 % = 87 h Downtime/Jahr, 99,9 % = 8,7 h, 99,99 % = 52 Min., 99,999 % = 5 Min. Wichtige Metriken neben Verfügbarkeit: MTBF, MTTR, Response- und Resolution-Time, p95/p99-Latenzen, CSAT/NPS. Im SRE-Umfeld: SLI (Messgröße) < SLO (internes Ziel) < SLA (Versprechen). Reporting monatlich, Service-Reviews quartalsweise. Fallstricke: unklare Messgrundlagen, ignorierte Geschäftszeiten, OLAs vergessen, wertlose Pönalen.

Verwandte Lektionen: Verfügbarkeit berechnen · MTBF / MTTR · Incident Management · und mehrWeitere relevante LektionenService Value System Ticket-Priorisierung Schwellenwerte & Alerting Service Desk Continual Improvement CMDB RTO/RPO