Bildquelle: Pexels / Hyundai Motor Group
SLOs im ITSM: Wie Service-Organisationen SLA, Monitoring und Change zusammenführen
Viele Service-Organisationen berichten Monat für Monat über SLA-Erfüllung und merken trotzdem zu spät, dass Nutzer unzufrieden sind, Betriebsteams Alarmmüdigkeit entwickeln und Changes in eine bereits fragile Produktionsumgebung laufen. Das Problem ist selten fehlendes Monitoring. Es liegt meist daran, dass klassische SLA-Berichte zu weit von der realen Nutzererfahrung entfernt sind und operative Entscheidungen nicht sauber steuern.
Genau deshalb rücken Service Level Objectives, kurz SLOs, auch im ITSM stärker in den Mittelpunkt. Sie sind keine akademische SRE-Übung, sondern ein praktisches Führungsinstrument für Service Owner, Plattformbetrieb, Service Desk und Change-Verantwortliche. Google trennt in seinem SRE-Grundlagenwerk klar zwischen SLI, SLO und SLA: Ein SLI misst einen relevanten Aspekt der Servicequalität, ein SLO setzt dafür den Zielwert, und ein SLA ergänzt erst die formalen oder vertraglichen Folgen. Für ITSM-Teams ist diese Trennung nützlich, weil sie hilft, interne Betriebssteuerung von externen Vertragslogiken zu lösen.
Entscheidend ist dabei, SLOs nicht als zusätzlichen KPI-Layer neben dem bestehenden Reporting einzuführen. Sie entfalten ihren Nutzen erst dann, wenn sie Incident-, Change- und Service-Steuerung direkt beeinflussen. Fünf Umstellungen sind dafür besonders wichtig.
1. Von Vertragskennzahlen zu nutzerrelevanten SLIs wechseln
Der erste Schritt ist begrifflich simpel, operativ aber oft unbequem. Ein SLA ist eine Vereinbarung. Ein SLO dagegen ist ein internes Ziel für eine klar definierte Servicekennzahl. Diese Kennzahl, der Service Level Indicator oder SLI, muss so gewählt sein, dass sie echte Nutzerwahrnehmung möglichst gut abbildet. Genau hier scheitern viele ITSM-Setups noch.
Ein Monatswert wie „99,5 Prozent Verfügbarkeit“ hilft wenig, wenn ein kritischer Service jeden Morgen für einige Minuten stockt. Für priorisierte Services sollten Organisationen deshalb nur wenige, aber belastbare SLIs definieren, typischerweise Verfügbarkeit, Antwortzeit und gegebenenfalls Fehlerrate. Wichtig ist, dass diese Indikatoren an realen Interaktionen hängen: erfolgreiche Anmeldungen, abgeschlossene Bestellungen, sauber verarbeitete API-Requests oder korrekt laufende Ticket-Schnittstellen. Wer nur Infrastrukturmetriken sammelt, misst oft an den Nutzern vorbei.
Google betont genau diesen Punkt, wenn dort zwischen direkter nutzerrelevanter Messung und bloßen Proxys unterschieden wird. Für ITSM ist das eine klare Ansage: Wenn ein Service Desk nur auf CPU, Speicher oder Ping schaut, aber nicht auf erfolgreiche Nutzertransaktionen, fehlt die eigentliche Steuerungsgröße.
2. SLOs als Betriebsgrenzen formulieren, nicht als Wunschbilder
Ein zweiter häufiger Fehler ist die Formulierung von SLOs als freundliche Zielbeschreibung. Ein SLO muss konkret sagen, was in welchem Zeitraum als gut gilt. Google Cloud beschreibt dafür sinnvoll zwei Grundmuster: request-basierte und windows-basierte SLOs. Beide Modelle sind auch für ITSM nützlich, weil sie unterschiedliche Betriebsrisiken sichtbar machen.
Praktisch heißt das zum Beispiel: „95 Prozent aller Requests bleiben in 30 Tagen unter 300 Millisekunden“ ist etwas anderes als „In 99 Prozent aller 10-Minuten-Fenster liegt die Latenz unter dem definierten Schwellenwert“. Das erste Modell eignet sich gut für stark transaktionale Services. Das zweite Modell macht längere Störungen oder degradierte Phasen besser sichtbar. Wer diese Logik nicht vorab festlegt, diskutiert im Incident-Fall über drei verschiedene Wahrheiten.
Ein gutes SLO ist deshalb keine Marketingzahl, sondern eine klare Betriebsgrenze mit messbarer Methodik, definiertem Zeitfenster und eindeutiger Berechnungslogik.
3. Error Budget mit Change-Risiko verknüpfen
Der eigentliche Durchbruch von SLOs entsteht nicht bei der Messung, sondern bei der Steuerung. Aus jedem SLO folgt ein Error Budget, also der Anteil an erlaubter schlechter Leistung innerhalb des Messzeitraums. Google Cloud beschreibt das ausdrücklich als Steuerungsgröße für riskante Änderungen. Wenn das Budget fast aufgebraucht ist, wird jeder zusätzliche Change teurer.
Genau darin liegt der praktische Nutzen für ITSM. Viele CABs und Change-Freigaben arbeiten noch mit pauschalen Risikoklassen, Wartungsfenstern und Bauchgefühl. Sinnvoller ist es, das verbleibende Error Budget eines betroffenen Services als Pflichtsignal in die Freigabe einzubauen. Hat ein Service sein Budget bereits weitgehend verbrannt, sollten Teams Releases, Plattformänderungen oder Konfigurationsanpassungen enger absichern, staffeln oder verschieben. Ist das Budget gesund, kann dieselbe Organisation kontrollierter, aber mutiger freigeben.
So wird aus SLO-Steuerung keine zusätzliche Bürokratie, sondern ein objektiver Mechanismus gegen blindes Weiterdeployen in einen ohnehin instabilen Service.
4. Incident, Problem und Service Review auf dieselben Signale ausrichten
In vielen ITSM-Organisationen sprechen Incident Management, Problem Management und Service Review noch unterschiedliche Sprachen. Das NOC schaut auf Alarme, der Service Desk auf Ticketvolumen, das Management auf Monatsberichte. SLOs schaffen hier nur dann Fortschritt, wenn sie als gemeinsame Referenz dienen.
Das beginnt im Incident Management. Ein Major Incident sollte nicht erst dann als kritisch gelten, wenn ein Eskalationsmeeting einberufen wird, sondern schon dann, wenn klar ist, dass ein geschäftskritischer SLO akut verletzt wird oder in kurzer Zeit kippt. Im Problem Management helfen SLO-Verletzungen, systemische Muster sichtbar zu machen, etwa wiederkehrende Latenzspitzen nach bestimmten Deployments oder periodische Einbrüche bei Drittanbindungen. Und im Service Review ersetzen SLO-Trends das übliche Schönrechnen mit Durchschnittswerten, die betriebliche Härten oft verdecken.
Grafana verweist in seiner SLO-Dokumentation ausdrücklich darauf, dass SLOs helfen, Alarmmüdigkeit zu reduzieren und den Blick auf die wirklich relevanten Zuverlässigkeitssignale zu lenken. Genau das ist auch für ITSM-Organisationen wertvoll, die heute zu viele Alarme, aber zu wenig steuerungsfähige Aussagen haben.
5. Ownership und Datenmodell standardisieren
Der fünfte Punkt wird oft unterschätzt. SLOs scheitern nicht nur an schlechter Metrik, sondern an unklarer Zuständigkeit. Service Owner definieren Ziele, Observability-Teams bauen Dashboards, Plattformteams liefern Telemetrie und der Service Desk soll das Ergebnis erklären. Ohne klares Datenmodell entstehen schnell Schattenlisten, Sonderdefinitionen und Toolbrüche.
Größere Organisationen sollten deshalb nicht nur einzelne SLO-Dashboards bauen, sondern ein standardisiertes Modell für Services, Indikatoren, Zeitfenster und Alarmregeln einführen. Genau hier wird der Gedanke offener Spezifikationen wie OpenSLO interessant. Die Initiative will einen vendor-agnostischen Rahmen für die Definition und Beschreibung von SLOs schaffen. Nicht jedes Team muss dieselbe Plattform nutzen, aber alle sollten dieselbe Grundlogik für Ziele, Messfenster und Alarmierung verstehen. Das reduziert Governance-Reibung und macht Servicequalität über Bereiche hinweg vergleichbarer.
Ebenso wichtig ist die Rollenklarheit. Für jeden kritischen Service sollte feststehen, wer Zielwerte freigibt, wer Messlogik verantwortet, wer bei Budgetverbrauch entscheidet und wer Maßnahmen aus Reviews nachhält. Ein SLO ohne benannten Owner ist im Betrieb nur Dekoration.
Fazit
SLOs ersetzen bestehende SLAs nicht automatisch, aber sie beheben ein altes ITSM-Problem: dass Servicequalität oft berichtet, aber zu selten wirksam gesteuert wird. Wer von abstrakten Monatswerten auf nutzernahe SLIs umstellt, SLOs methodisch sauber formuliert, Error Budgets mit Change-Risiko koppelt, Incident- und Problem-Management auf dieselben Signale ausrichtet und Ownership standardisiert, bekommt ein deutlich belastbareres Betriebsmodell. Dann werden SLA-Berichte nicht überflüssig, aber sie verlieren ihre Rolle als einziges Steuerungsinstrument. Und genau das ist für moderne Service-Organisationen ein spürbarer Fortschritt.
