SLA, OLA, SLO: IT-Services realistisch steuern

Viele IT-Organisationen versprechen ambitionierte Reaktions- und Lösungszeiten gegenüber Fachbereichen oder Kunden. Doch intern fehlt häufig die Abstimmung darüber, wer was wann liefern soll. Die Folge: Eskalationen, Frust und ein IT-Betrieb, der schwer steuerbar ist.

Ein funktionierendes Service Management basiert auf dem Zusammenspiel von drei zentralen Komponenten: SLA, OLA und SLO. Nur wenn diese drei sauber definiert und aufeinander abgestimmt sind, lassen sich Versprechen nach außen zuverlässig einhalten und intern realistisch steuern.

Was steckt hinter SLA, OLA und SLO?

SLA (Service Level Agreement)
Das SLA ist das Versprechen nach außen. Es definiert, was ein Kunde oder Fachbereich erwarten darf: Reaktionszeiten, Lösungshorizonte, Kommunikationswege und Ausnahmen. Es ist das sichtbare Leistungsversprechen der IT.

OLA (Operational Level Agreement)
Das OLA regelt die internen Abläufe. Es beschreibt, wie verschiedene Teams zusammenarbeiten, welche Informationen bei Übergaben notwendig sind, wer welche Aufgaben übernimmt und welche Eskalationspfade gelten. Es ist die organisatorische Grundlage dafür, dass das SLA eingehalten werden kann.

SLO (Service Level Objective)
Das SLO bildet die technische Realität ab. Es umfasst messbare technische Ziele wie Verfügbarkeit, Fehlerbudgets und Wiederherstellungszeiten. SLOs dienen der internen Steuerung und geben vor, was technisch realistisch erreichbar ist.

Die Beziehung dieser drei Ebenen lässt sich einfach zusammenfassen:
SLA beschreibt das Außenversprechen
OLA ermöglicht die interne Umsetzung
SLO sichert die technische Basis

Ein Beispiel für das Zusammenspiel

Ein SLA verspricht bei einem P1-Vorfall eine Reaktion innerhalb von 15 Minuten und eine Lösung innerhalb von 4 Stunden.

Das passende OLA regelt, dass das First-Level-Team den P1 in 10 Minuten anlegt und weiterleitet, das Second-Level-Team in 20 Minuten mit der Analyse beginnt und das Netzwerk-Team innerhalb von 30 Minuten Rückmeldung gibt.

Das SLO sichert die technische Grundlage mit einer monatlichen Verfügbarkeit von 99,5 Prozent, einem Fehlerbudget von drei Stunden und einer Recovery-Zeit von 45 Minuten.

Dieses Zusammenspiel zeigt: Wenn das OLA nicht trägt, ist das SLA nicht haltbar. Wenn das SLO unrealistisch ist, wird das SLA unerreichbar.

Drei Schritte für realistische Ziele

1. Fakten statt Wunschdenken
   Analysiere die Daten der letzten drei bis sechs Monate. Wie hoch war die tatsächliche Verfügbarkeit? Wann traten Peaks auf? Wie viele Tickets gab es? Wenn keine Daten vorliegen, starte mit einem SLO-Piloten und messe vier Wochen lang.

2. Engpässe identifizieren
   Oft liegt der Schwachpunkt in der Übergabe zwischen Teams. Kläre genau, wann die Reaktionszeit beginnt, welche Informationen übergeben werden müssen und wer die Priorität vergibt.

3. Zielkorridore statt Punktlandungen
   Formuliere Zielzeiten als Korridore, zum Beispiel: Lösung von P1-Vorfällen zwischen drei und fünf Stunden, Ziel bei vier Stunden. So lässt sich besser steuern und du schaffst Raum für Ausreißer.

Häufige Fehler und wie du sie vermeidest

SLA ohne OLA
Ein externes Versprechen ohne interne Absicherung führt schnell zu Überlastung und Frust. Für jede SLA-Metrik sollte es eine passende OLA-Regel geben.

SLO als SLA verwenden
Technische Zielwerte nach außen zu kommunizieren kann zu unnötigen Vertragsrisiken führen. Besser: SLOs intern nutzen, SLAs mit realistischen Ausnahmefällen gestalten.

Unklare Zeitmessung
Wenn nicht klar ist, wann die Zeitmessung beginnt, entstehen Missverständnisse. Definiere präzise Start- und Endpunkte, etwa: Reaktionszeit startet, wenn ein P1 im System angelegt und die zuständige Rolle alarmiert wurde.

Alles rund um die Uhr absichern
24/7-Verfügbarkeit klingt gut, ist aber teuer und oft unnötig. Prüfe ehrlich, wo sie wirklich erforderlich ist, und wo ein klarer Major-Incident-Prozess genügt.

Zu viele Metriken
Ein überladenes Reporting führt zu Intransparenz. Drei Kennzahlen pro Service reichen meist aus: Reaktionszeit, Lösungszeit, Verfügbarkeit.

Ein pragmatischer 5-Tages-Plan zur OLA-Einführung

1. Wähle einen geschäftskritischen Service wie E-Mail oder Collaboration-Plattformen.

2. Skizziere das SLA mit Geschäftszeiten, Prioritäten, Reaktions- und Lösungszeiten sowie Kommunikationsregeln.

3. Erarbeite das passende OLA zwischen First- und Second-Level-Support mit klaren Pflichten, Übergaben und Eskalationspfaden.

4. Führe einen kurzen Drill durch, um die Abläufe zu testen.

5. Justiere nach, veröffentliche die Vereinbarung und beginne mit der Messung. Danach kannst du den nächsten Service angehen.

Fazit

Ein klar abgestimmtes Zusammenspiel aus SLA, OLA und SLO reduziert Konflikte, erhöht die Zuverlässigkeit und schafft Vertrauen. Versprich nach außen nur, was intern machbar ist, und steuere mit technischen Zielwerten, die zur Realität passen.

Starte klein, messe sauber und baue Schritt für Schritt ein tragfähiges Servicemodell auf. So wird dein IT-Betrieb nicht nur planbar, sondern auch belastbar.