SLA steht für Service-Level-Agreement. Es handelt sich um einen formellen Vertrag zwischen einem Dienstleister und einem Kunden, der geschäftliche Anforderungen in messbare Servicezusagen übersetzt. Zu den üblichen Bestandteilen zählen Verfügbarkeits- bzw. Uptime-Ziele, Reaktions- und Lösungszeiten des Supports, Servicezeiten, Definitionen von Ausfällen, Wartungsfenster, Ausschlüsse sowie Berichts- oder Auditrechte. SLAs reduzieren Mehrdeutigkeiten, klären Verantwortlichkeiten und unterstützen die Planung sowie die Streitbeilegung. Mehr Kontext zu Kennzahlen, Downtime-Regeln und Durchsetzung erläutert, wie SLAs in der Praxis funktionieren.
Was ist ein SLA in der IT und bei Cloud-Diensten?
Klarheit in den Erwartungen definiert ein SLA in IT- und Cloud-Services. Ein SLA (Service-Level-Agreement) ist ein formaler Vertrag, der Geschäftsanforderungen in messbare Servicezusagen zwischen einem Anbieter und einem Kunden übersetzt. In IT-Betrieb und Cloud-Nutzung fungiert es als Governance-Instrument, das die technische Leistungserbringung mit kommerzieller Verantwortlichkeit in Einklang bringt, Unklarheiten reduziert und konsistente Entscheidungsfindung unterstützt.
Die Bedeutung eines SLA liegt in der Festlegung einer gemeinsamen Grundlage für Leistung und Verantwortlichkeit, wodurch Planung, Budgetierung und Risikokontrolle ermöglicht werden. Es bietet zudem einen Referenzrahmen für Streitbeilegung und Lieferantenmanagement, insbesondere wenn Services ausgelagert oder aus mehreren Quellen bezogen werden. Zu den gängigen SLA-Typen zählen kundenbasierte SLAs, die einen bestimmten Kunden abdecken, servicebasierte SLAs, die für ein definiertes Angebot gelten, sowie mehrstufige SLAs, die organisationsweite Bedingungen mit service- oder kundenspezifischen Ebenen kombinieren. In Cloud-Umgebungen können SLAs je nach Beschaffungsmodell und Kritikalität in den Anbieterbedingungen enthalten oder verhandelt sein.
Was sollte ein SLA enthalten (Verfügbarkeit, Support, Berichterstattung)?
Da ein SLA nur funktioniert, wenn die Leistung überprüfbar ist, sollte es messbare Serviceziele und die Mechanismen definieren, mit denen sie durchgesetzt werden. Zu den zentralen SLA-Bestandteilen gehören typischerweise Verfügbarkeitszusagen (z. B. 99,9 % monatliche Verfügbarkeit), klar definierte Servicezeiten sowie präzise Definitionen von Ausfällen, Wartungsfenstern, Ausschlüssen und Messmethoden (Monitoring-Quelle, Stichprobenverfahren und Berechnungsregeln).
Support-Bedingungen sollten Reaktions- und Lösungsziele nach Schweregrad, Eskalationswege und Kommunikationskanäle festlegen. Außerdem sollten sie Change-Management, Fristen für Incident-Benachrichtigungen und Verantwortlichkeiten auf beiden Seiten (Maßnahmen des Anbieters, Voraussetzungen des Kunden wie Konfiguration und Zugriff) abdecken.
Berichtsanforderungen sollten beschreiben, worüber berichtet wird (Verfügbarkeit, Incidents, Latenz, Ticket-Kennzahlen), die Häufigkeit der Berichte und Prüf- bzw. Auditrechte. Abhilfemaßnahmen müssen explizit sein: Servicegutschriften, Schwellenwerte und Verfahren zur Geltendmachung von Ansprüchen sowie Haftungsbeschränkungen. Die Dokumentation dieser Elemente unterstreicht die Bedeutung des SLA, indem sie Erwartungen abstimmt und Verstöße über Betriebs- und Governance-Prozesse hinweg durchsetzbar macht.
Wann benötigen Sie ein SLA – und wann nicht?
Ein SLA ist in der Regel erforderlich, wenn ein Service geschäftskritisch ist und Ausfallzeiten, langsame Reaktionszeiten oder schlechter Support erhebliche operative oder finanzielle Auswirkungen hätten. In Situationen mit geringem Risiko – etwa bei kleinen internen Tools oder vertrauenswürdigen, kurzfristigen Engagements – kann eine informelle Vereinbarung ausreichen. Externe Faktoren spielen ebenfalls eine Rolle, da regulatorische Verpflichtungen, Kundenzusagen oder Beschaffungsstandards von Anbietern ein SLA unabhängig vom wahrgenommenen Risiko vorschreiben können.
Support für hochkritische Dienste
Wenn ein Service Einnahmen, Sicherheit oder den Kernbetrieb untermauert, werden Ausfallzeiten und langsame Reaktionszeiten schnell zu Geschäftsrisiken statt bloßer Unannehmlichkeiten. In solchen Fällen formalisiert ein SLA die Erwartungen, nachdem eine Kritikalitätsbewertung die erforderliche Verfügbarkeit, Reaktionszeiten und Eskalationswege auf Basis der Serviceauswirkungen auf Prozesse, Kunden und Compliance-Pflichten geklärt hat. Support mit hoher Kritikalität spezifiziert typischerweise eine 24/7-Abdeckung, definierte Schweregrade, messbare Wiederherstellungsziele sowie proaktives Monitoring mit Alarmierung und Reporting. Er sollte außerdem Verantwortlichkeiten für Incident-Kommunikation, Change-Fenster, Sicherheitskontrollen und Disaster-Recovery-Ziele (RTO/RPO) enthalten, abgestimmt auf Business-Continuity-Pläne. Vertragsstrafen oder Servicegutschriften können die Verantwortlichkeit stärken, aber der primäre Wert liegt in einem vorhersehbaren Supportverhalten während Störungen. Regelmäßige Reviews halten die Ziele realistisch, wenn sich Nutzung und Abhängigkeiten im Laufe der Zeit weiterentwickeln.
Informelle Vereinbarungen mit geringem Risiko
Viele Services rechtfertigen keine formale SLA, insbesondere solche mit geringer geschäftlicher Auswirkung, begrenzten Abhängigkeitsketten und einfachen Ausweichmöglichkeiten, falls sie ausfallen. Typische Beispiele sind interne Wissensdatenbanken, nichtkritische Reporting-Dashboards oder Best-Effort-Kollaborationstools. In diesen Fällen bieten informelle Vereinbarungen oft ausreichende Klarheit: wen man kontaktieren soll, erwartete Reaktionszeitfenster und grundlegende Wartungsroutinen. Eine leichtgewichtige Risikobewertung sollte dennoch durchgeführt werden, um zu bestätigen, dass Ausfallzeiten keine kaskadierenden Störungen, keinen Kundenschaden oder keine wesentlichen Kosten auslösen. Wo das Risiko gering bleibt, können Teams sich auf dokumentierte Erwartungen in Tickets, Runbooks oder Team-Chartern verlassen, statt auf vertragliche Kennzahlen. Regelmäßige Überprüfungen helfen sicherzustellen, dass die Regelung im Laufe der Zeit weiterhin zu Nutzungsmustern, wachsender Abhängigkeitslandschaft und sich wandelnden Geschäftsprioritäten passt.
Regulatorische oder Anbieteranforderungen
Obwohl das operationelle Risiko gering sein kann, wird eine SLA notwendig, wenn Vorschriften, Audits oder Lieferantenverträge explizite Servicezusagen verlangen. In regulierten Umgebungen unterstützen dokumentierte Ziele, Monitoring und Eskalationswege die Einhaltung regulatorischer Anforderungen und belegen die Wirksamkeit von Kontrollen. Wenn Anbieter gehostete Systeme, Verarbeitung oder Support bereitstellen, formalisieren SLAs die Verpflichtungen des Lieferanten hinsichtlich Verfügbarkeit, Incident-Response, Datenschutz und Reporting und reduzieren Unklarheiten bei Streitfällen oder Prüfungen.
| Auslöser | Typische SLA-Klausel | Nachweis |
|---|---|---|
| Audit-Anforderung | Incident-Logging, Aufbewahrung | Audit-Trail-Reports |
| Finanzregulierung | Verfügbarkeit, RTO/RPO | Ergebnisse von DR-Tests |
| Datenschutz im Gesundheitswesen | Verschlüsselung, Meldung von Datenschutzverletzungen | Sicherheitsattestierungen |
| Öffentliche Beschaffung | Vertragsstrafen, Servicegutschriften | Vertragsanhänge |
Ohne solche externen Treiber können Teams sich auf informelle Erwartungen verlassen, doch die Verantwortlichkeit wird schwächer und der Nachweis wird schwierig.
SLA vs. SLO vs. SLI: Wie unterscheiden sie sich?
Ein gemeinsames Vokabular steht im Zentrum von zuverlässigem Service-Management, und SLA, SLO und SLI bilden diese Grundlage auf unterschiedliche Weise. SLA-Definitionen beschreiben ein externes Versprechen zwischen Anbieter und Kunde, einschließlich Umfang, Verantwortlichkeiten und Konsequenzen, wenn Ziele verfehlt werden. Sie übersetzen Erwartungen in durchsetzbare Bedingungen und verweisen häufig auf Reporting- sowie Eskalationsprozesse.
Ein SLO ist ein internes oder kundenorientiertes Leistungsziel, das Teams nutzen, um Engineering-Entscheidungen zu steuern; seine Rolle unterstreicht die Bedeutung von SLOs als praktisches Ziel, das Nutzererlebnis mit Kosten und Risiko ausbalanciert. Ein SLI ist der gemessene Indikator hinter dem Ziel; SLI-Metriken können die Erfolgsrate von Anfragen, Latenz-Perzentile oder Fehlerraten umfassen, die konsistent aus vereinbarten Datenquellen erfasst werden.
Zusammen eingesetzt quantifizieren SLIs die Realität, SLOs setzen objektive Ziele, und SLAs formalisieren Verpflichtungen. SLA-Best-Practices richten alle drei aus, definieren Messzeiträume, dokumentieren Ausschlüsse und halten Ziele realistisch, überprüfbar und an Nutzerergebnissen ausgerichtet.
Wie wird die SLA-Verfügbarkeit berechnet (und was gilt als Ausfallzeit)?
SLA-Verfügbarkeit wird typischerweise als Prozentsatz ausgedrückt, der berechnet wird, indem die gesamte Servicezeit minus Ausfallzeit durch die gesamte Servicezeit über ein definiertes Messfenster geteilt wird. Was jedoch als „Ausfallzeit“ gilt, kann variieren – abhängig von Faktoren wie geplanter Wartung, teilweisen Ausfällen, Abhängigkeiten von Drittanbietern und Ausschlüssen für vom Kunden verursachte Probleme. Die Klärung sowohl der Verfügbarkeitsformel als auch dieser Nuancen in der Definition von Ausfallzeit ist entscheidend, um Einhaltung und Abhilfemaßnahmen korrekt zu interpretieren.
Formel für die Verfügbarkeitsprozentzahl
In den meisten Service-Level-Agreements wird die Verfügbarkeit als der Anteil eines definierten Messzeitraums berechnet, in dem der Dienst verfügbar ist, ausgedrückt als Prozentsatz. Die Standardformel lautet: Verfügbarkeit % = (Gesamtzeit − Nichtverfügbarkeitszeit) ÷ Gesamtzeit × 100. Die Gesamtzeit ist das vereinbarte Zeitfenster (zum Beispiel ein Kalendermonat oder Geschäftszeiten), und die Nichtverfügbarkeitszeit ist die gemessene Ausfalldauer innerhalb dieses Zeitfensters. Diese Verfügbarkeitskennzahlen unterstützen konsistente Verfügbarkeitsberechnungen über Anbieter und Zeiträume hinweg.
| Messzeitraum | Gesamtminuten | Zielverfügbarkeit % |
|---|---|---|
| 30 Tage | 43.200 | 99,9 |
| 1 Jahr | 525.600 | 99,99 |
Um ein Ziel in zulässige Nichtverfügbarkeit zu übersetzen, stellt man um: Zulässiger Ausfall = Gesamtzeit × (1 − Zielwert). Dies ermöglicht einen unkomplizierten Vergleich zwischen vertraglichen Stufen.
Nuancen der Downtime-Definition
Uptime-Formeln sind nur so zuverlässig wie die vertragliche Definition von „Nichtverfügbarkeitszeit“, da nicht jede Serviceunterbrechung als Downtime gezählt wird. Viele SLAs schließen geplante Ausfallzeiten für Wartungsarbeiten aus, sofern Ankündigungsfristen, Wartungsfenster und Rollback-Verfahren eingehalten werden. Einige nehmen auch Ausfälle aus, die durch Fehlkonfigurationen auf Kundenseite, Drittanbieter-Carrier, höhere Gewalt oder Maßnahmen zur Missbrauchsabwehr verursacht werden. Im Gegensatz dazu umfasst unerwartete Downtime typischerweise ungeplante Serviceunterbrechungen, die vereinbarte Reaktions- und Wiederherstellungsziele verletzen. Definitionsdetails sind entscheidend: teilweise Beeinträchtigungen, API-Fehlerraten, Paketverlust und regionale Ausfälle können je nach Messpunkten und Schwellenwerten als Downtime gelten oder nicht. Das SLA sollte Monitoring-Quellen, Mittelungsintervalle sowie festlegen, ob Ausfallzeiten pro Instanz, pro Region oder global erfasst werden. Es sollte außerdem definieren, wann ein Vorfall beginnt und endet, einschließlich Erkennung, Bestätigung und Wiederherstellungskriterien.
Was bedeuten SLA-Reaktions- und Lösungszeiten?
Wie schnell sollte ein Anbieter eine Supportanfrage bestätigen und das zugrunde liegende Problem vollständig beheben? In einem SLA werden diese Zusagen in Reaktionszeit und Lösungszeit aufgeteilt, und sie messen unterschiedliche Phasen des Service-Supports.
Die Reaktionszeit definiert den maximalen Zeitraum, bis der Anbieter den Eingang bestätigt und mit der Bearbeitung des Tickets beginnt. Sie umfasst typischerweise die erste Triage, die Zuweisung und das erste aussagekräftige Update, nicht zwingend eine Umgehungslösung oder eine Behebung. Die Lösungszeit definiert den maximalen Zeitraum, bis der Vorfall vollständig gelöst ist und der Service auf das vereinbarte Niveau wiederhergestellt wurde, einschließlich der erforderlichen Verifikation und der abgeschlossenen Kundenkommunikation.
Beide Kennzahlen werden üblicherweise nach Prioritäts- oder Schweregraden ausgedrückt, die die geschäftlichen Auswirkungen widerspiegeln. Sie können in Kalenderstunden oder Geschäftszeiten gemessen werden und verwenden oft Zielwerte wie „P1: 15 Minuten Reaktionszeit, 4 Stunden Lösungszeit“. Klare Definitionen verhindern Streitigkeiten darüber, wann die Uhr startet, pausiert und stoppt.
Welche SLA-Ausschlüsse gelten (Wartung, Ausfälle, Umfang)?
Obwohl SLAs häufig bestimmte Verfügbarkeits- und Supportziele zusichern, sind diese Garantien typischerweise mit Ausschlüssen versehen, die festlegen, wann Gutschriften oder Abhilfen nicht gelten. Übliche Ausnahmeregelungen verdeutlichen betriebliche Realitäten und ziehen eine Grenze der Verantwortlichkeit des Anbieters, insbesondere bei geplanten Arbeiten, Abhängigkeiten von Dritten und kundenseitig verursachten Problemen.
| Ausschlussbereich | Typischer Auslöser | Hinweise |
|---|---|---|
| Wartungsfenster | geplante Patches/Upgrades | oft vorab angekündigt |
| ungeplante Ausfälle | Ereignisse höherer Gewalt | z. B. regionale Katastrophen |
| gemeinsame Infrastruktur | Ausfall von vorgelagertem ISP/Cloud-Anbieter | außerhalb der Kontrolle des Anbieters |
| Kundenumgebung | Fehlkonfiguration, Missbrauch | umfasst auch nicht unterstützte Änderungen |
| Umfangsgrenzen | nicht abgedeckte Leistungen | Add-ons und kundenspezifische Arbeiten |
Ausschlüsse behandeln auch die Methodik der Überwachung, etwa welche Endpunkte zählen, wie Ausfallzeiten gemessen werden und was als „Service“ gilt. Viele SLAs schließen Beta-Funktionen, kostenlose Tarife und Entwicklungsumgebungen aus. Andere beschränken die Abdeckung auf Kernkomponenten der Plattform und schließen Integrationen, Datenmigrationen oder Professional Services aus. Klare Definitionen verhindern Streitigkeiten darüber, was zugesagt wurde, versus dem, was lediglich erwartet wurde.
Was passiert, wenn ein SLA nicht eingehalten wird (Gutschriften und Durchsetzung)?
Wenn Ausfallzeiten oder die Support-Performance außerhalb der in der SLA festgelegten Ziele liegen – und keine der aufgeführten Ausschlüsse greift –, wechselt die Vereinbarung typischerweise von Definitionen zu Rechtsbehelfen. Am häufigsten schuldet der Anbieter Servicegutschriften, berechnet als Prozentsatz der monatlichen Gebühren und gekoppelt an Schweregrad und Dauer des Verstoßes. Gutschriften sind üblicherweise das ausschließliche finanzielle Rechtsmittel des Kunden, wodurch weitergehende Schäden begrenzt werden, während zugleich vorhersehbare SLA-Sanktionen entstehen. Um sie geltend zu machen, muss der Kunde möglicherweise innerhalb eines strengen Zeitfensters ein Ticket eröffnen und Protokolle, Zeitstempel sowie Nachweise über die Auswirkungen bereitstellen. Die Durchsetzung kann auch Eskalationswege, eine verpflichtende Ursachenanalyse (Root-Cause Analysis) und Maßnahmenpläne zur Behebung umfassen, die darauf abzielen, die SLA-Konformität wiederherzustellen. Wiederholte oder wesentliche Ausfälle können stärkere Rechte auslösen: erweitertes Reporting, Audit-Zugriff, vorübergehende Gebührenreduzierungen oder Kündigung aus wichtigem Grund nach einer Nachfrist. Einige Verträge fügen Leistungseinbehalte oder Vertragsstrafen bei chronischer Nichteinhaltung hinzu, diese sind jedoch oft gedeckelt und sorgfältig definiert, um Streitigkeiten zu vermeiden.
