Welche Prozesse ein SLA benötigen und welche eine operative Erwartung

Wenn alle internen Prozesse als kritisch eingestuft werden, endet die Organisation mit ständigen Warnmeldungen, schwer dauerhaft tragbaren Rufbereitschaften und Verpflichtungen, die niemand erfüllen kann. Das Problem ist nicht nur technischer Natur: Die tatsächliche Priorität eines Ausfalls wird verwässert, und der Betrieb von Anwendungen, Integrationen und Daten wird teurer, obwohl diese möglicherweise Wartezeiten, eine Wiederverarbeitung oder eine manuelle Alternative zulassen.

Die sinnvolle Entscheidung besteht nicht darin, ein System als „wichtig“ zu kennzeichnen. Es geht darum, sich darauf zu verständigen, welche geschäftliche Folge unter welchen Bedingungen und für welchen Zeitraum nicht akzeptabel ist. Daraus ergibt sich, dass einige Prozesse eine Service-Level-Vereinbarung (SLA) benötigen; andere lassen sich besser über eine operative Erwartung, ein überprüfbares internes Ziel oder einfach über gute Supportpraktiken steuern.

Dieser Rahmen hilft, Prioritäten gegenüber Produkt, Fachbereich und Technologie zu begründen, ohne Kennzahlen aus dem Bauch heraus zu wählen oder jede Anforderung in eine Pflicht zur permanenten Verfügbarkeit zu verwandeln.

SLA, operatives Ziel und gute Praxis: unterschiedliche Verpflichtungen

Ein SLA ist eine ausdrückliche Verpflichtung für einen klar definierten Service. Üblicherweise legt es Umfang, Servicezeiten, Kennzahlen, Verantwortlichkeiten, Ausschlüsse sowie einen Mechanismus zur Überprüfung oder Eskalation fest. Es bedeutet nicht, dass es niemals Störungen geben wird: Es beschreibt, welches Funktionsniveau erwartet wird und wie mit einer Nichteinhaltung umgegangen wird.

Im internen Betrieb sollte es von zwei leichteren Instrumenten unterschieden werden:

• Service-Level-Ziel: ein messbares Ziel zur Steuerung des Betriebs, etwa eine Synchronisierung vor einer vereinbarten Uhrzeit abzuschließen. Es kann angepasst werden, ohne jede Abweichung als Vertragsverletzung zu behandeln.
• Operative Erwartung: eine klare Arbeitsregel, jedoch weniger starr. Zum Beispiel eine Warteschlange mit Anfragen an Werktagen zu prüfen oder einen Bericht zu Beginn des Arbeitstags bereitzustellen.
• Gute Praxis: ein wünschenswerter Ablauf, beispielsweise Fehler zu überwachen oder eine manuelle Wiederherstellung zu dokumentieren. Das ist wertvoll, sollte jedoch nicht als Garantie dargestellt werden, wenn Kapazität, Abdeckung und Verantwortliche fehlen, um es dauerhaft zu gewährleisten.

Der entscheidende Unterschied liegt in der Folge. Wenn eine Unterbrechung Umsätze, kritische betriebliche Verpflichtungen oder die Betreuung von Kunden blockiert und keine angemessene Ausweichmöglichkeit besteht, ist ein SLA in der Regel gerechtfertigt. Kann das Team die Aufgabe hingegen neu planen, Daten des Vortags verwenden oder die Arbeit manuell erledigen, ist eine operative Erwartung oft ehrlicher und effizienter.

Weisen Sie ein SLA nicht wegen der Sichtbarkeit des Anfordernden oder wegen des Alters eines Systems zu. Weisen Sie es auf Grundlage des nachweisbaren Schadens zu, der entsteht, wenn der Service in einem konkreten Zeitfenster nicht erbracht wird.

Die fünf Fragen zur Einordnung jedes Prozesses

Bevor Verfügbarkeitsprozentsätze oder Reaktionszeiten diskutiert werden, sollte jeder Prozess mit denselben Fragen eingeordnet werden. Dadurch wird das Gespräch von einer abstrakten Verhandlung zu einer Risikobewertung.

1. Welche Auswirkung hat es, wenn der Prozess nicht funktioniert? Beschreiben Sie die Folgen für Bestellungen, Betrieb, Compliance, Nutzer oder Entscheidungen. Vermeiden Sie allgemeine Aussagen wie „Das ist sehr wichtig“. Benennen Sie, welche Handlung nicht möglich ist und wer dadurch blockiert wird.
2. Wie sieht das tatsächliche Nutzungsfenster aus? Ein Portal, über das den ganzen Tag Bestellungen erfasst werden, hat nicht denselben Bedarf wie ein nächtlicher Datenimport. Definieren Sie Tage, Zeitfenster, Abschlusszeiten und bekannte Spitzen.
3. Wovon hängt der Prozess ab? Listen Sie Anwendungen, APIs, Anbieter, Zugangsdaten, Netzwerke, Quelldaten und verantwortliche Teams auf. Eine Verpflichtung kann nur das abdecken, was das Team beobachten und betreiben kann.
4. Gibt es eine manuelle oder eingeschränkte Alternative? Klären Sie, ob Informationen vorübergehend erfasst, Bestellungen über einen anderen Weg angenommen, eine frühere Kopie eingesehen oder eine Aufgabe erneut ausgeführt werden kann. Bewerten Sie auch die tatsächliche Kapazität dieser Alternative, nicht nur ihre theoretische Existenz.
5. Welcher Datenverlust oder welche Verzögerung ist tolerierbar? Unterscheiden Sie Verfügbarkeit von Integrität. Ein Prozess kann möglicherweise zwei Stunden Verzögerung tolerieren, jedoch keine doppelte Transaktion, unvollständige Daten oder den Verlust von Änderungen.

Dokumentieren Sie die Antworten gemeinsam mit einem fachlichen und einem technischen Verantwortlichen. Besteht keine Einigkeit über Auswirkung oder Toleranz, gibt es noch keine Grundlage für ein Service-Level; dann steht noch eine Geschäftsentscheidung aus.

Eine nützliche Kritikalitätsmatrix für Anwendungen und Integrationen

Eine einfache Matrix verhindert, dass die Einstufung davon abhängt, wer die Anforderung eskaliert. Bewerten Sie jede Dimension als niedrig, mittel oder hoch: Auswirkung, Empfindlichkeit gegenüber dem Nutzungsfenster, Fehlen einer Alternative, Datenrisiko und Komplexität der Abhängigkeiten.

• Hohe Kritikalität: direkte und unmittelbare Auswirkungen, ein enges oder durchgehendes Zeitfenster, keine tragfähige Alternative sowie ein erhebliches Risiko von Datenverlust oder Inkonsistenzen. Erfordert ein SLA, Monitoring, eine definierte Eskalation und Wiederherstellungstests.
• Mittlere Kritikalität: eine Verzögerung beeinträchtigt die Arbeit oder wichtige Entscheidungen, doch es gibt einen eingeschränkten Betriebsmodus oder einen Wiederherstellungsspielraum. Erfordert messbare operative Ziele, Fehlernachverfolgung und regelmäßige Überprüfung.
• Niedrige Kritikalität: der Prozess verbessert die Effizienz, kann aber warten, erneut verarbeitet oder vorübergehend ersetzt werden. Eine operative Erwartung, Priorisierung im Backlog und Support zu vereinbarten Zeiten reichen aus.

Die Kategorie sollte auf den konkreten Service angewandt werden, nicht auf die gesamte Anwendung. Dieselbe Plattform kann ein kritisches Transaktionsportal, einen aufschiebbaren Abfragebericht und einen monatlichen Export enthalten. Ein einziges globales SLA würde diese Unterschiede verbergen und unnötige Kosten verursachen.

Beispiel für eine Einordnung

Ein Bestellportal kann eine hohe Kritikalität haben, wenn Nutzer Bestellungen nicht über einen anderen Kanal aufgeben können und eine Unterbrechung den Betrieb anhält. Die nächtliche Katalogsynchronisierung könnte mittel kritisch sein, wenn sie vor Öffnungsbeginn erneut ausgeführt werden kann oder der bisherige Katalog einen vorübergehenden Betrieb erlaubt. Ein interner Kontrollbericht kann niedrig kritisch sein, wenn er einmal täglich eingesehen wird und seine Daten verspätet bereitgestellt werden können.

Dieses Beispiel legt keine allgemeingültige Kategorie fest. Speist die Synchronisierung verpflichtende Preise oder löst der Bericht eine regulierte Entscheidung aus, ändert sich die Bewertung. Die Einstufung hängt von Folge und Zeitfenster ab, nicht von der Art der Technologie.

Was ein nachhaltiges internes SLA enthalten sollte

Ein nützliches SLA muss spezifisch und betreibbar sein. „Hohe Verfügbarkeit“ oder „schnelle Bearbeitung“ zu versprechen, schafft im Störungsfall Unklarheit. Ein kurzes Dokument kann dagegen präzise definieren, was erbracht und wie es gemessen wird.

• Umfang: Prozess, Schnittstellen, Nutzer und erwartetes Ergebnis. Geben Sie an, welche Komponenten ausgeschlossen sind.
• Servicezeit: das zugesagte Betriebsfenster, der anwendbare Kalender und Wartungsfenster.
• Kennzahlen: Verfügbarkeit des Prozesses, Zeit bis zur Erkennung, Zeit bis zur ersten Reaktion, Wiederherstellungszeit oder maximal zulässige Verzögerung. Messen Sie Ergebnisse, nicht nur die Aktivität des Teams.
• Verantwortliche: fachlicher Verantwortlicher, technischer Verantwortlicher, das Team zur Störungsbearbeitung und Verantwortliche für jede Abhängigkeit.
• Ausschlüsse: nicht eingegangene Quelldaten, Ausfälle Dritter, nicht genehmigte Änderungen oder eine Nutzung außerhalb der vorgesehenen Kapazität. Das sind keine Ausreden, sondern Grenzen der tatsächlichen Kontrolle.
• Eskalation: Meldekanal, Schweregrade, Personen, die über Notfallmaßnahmen entscheiden, sowie Kommunikation mit Betroffenen.

Vermeiden Sie es, Ziele von Anbietern oder anderen Produkten zu übernehmen. Ein Wert ist nur vertretbar, wenn er auf einen geschäftlichen Bedarf antwortet und Architektur, Beobachtbarkeit sowie Reaktionsfähigkeit seine Einhaltung erlauben. Die von Google verbreiteten Praktiken des Reliability Engineering unterscheiden gerade deshalb zwischen Indikatoren, Zielen und Vereinbarungen, damit ein Anspruch nicht zu einem unerfüllbaren Versprechen wird.

Kennzahlen festlegen, ohne willkürliche Zahlen zu wählen

Beginnen Sie beim Bedarf, nicht bei einem Prozentsatz. Fragen Sie: „Bis zu welchem spätesten Zeitpunkt muss dieses Ergebnis verfügbar sein, damit der festgestellte Schaden vermieden wird?“ Die Antwort definiert eine betriebliche Grenze. Gleichen Sie diese anschließend mit historischen Daten, Abhängigkeiten und Wiederherstellungskapazität ab.

Bei der Verfügbarkeit sollten Sie die Fähigkeit messen, die relevante Aktion abzuschließen, nicht nur, ob eine Seite antwortet. Für eine Integration können der Anteil erfolgreich abgeschlossener Ausführungen und die Verzögerung der Datensätze aussagekräftiger sein als der Status eines Servers. Bei der Wiederherstellung sind zwei Entscheidungen zu trennen:

• Wiederherstellungszeit-Ziel: wie lange die Unterbrechung dauern darf, bevor der Service wiederhergestellt oder eine Alternative aktiviert wird.
• Wiederherstellungspunkt-Ziel: wie viele Informationen nach der Störung verloren gehen oder bis zum Abgleich offen bleiben dürfen.

Definieren Sie außerdem ein operatives Fehlerbudget: den Spielraum für Nichteinhaltungen, der innerhalb eines Zeitraums toleriert werden kann, bevor Zuverlässigkeit gegenüber neuen Verbesserungen Vorrang erhält. Wird der Spielraum wiederholt aufgebraucht, genügt es nicht, das SLA zu verschärfen; vielmehr müssen Design, externe Abhängigkeit, Automatisierung, Supportkapazität oder sogar die Notwendigkeit des Prozesses überprüft werden.

Abhängigkeiten, Änderungen und Signale zur Überprüfung der Verpflichtung

Der häufigste Fehler besteht darin, ein Ende-zu-Ende-Ergebnis zuzusagen, wenn mehrere Teile nicht derselben Kontrolle unterliegen. Ist eine externe API, ein Datenteam oder ein Kommunikationsanbieter am Ablauf beteiligt, dokumentieren Sie die Abhängigkeit und vereinbaren Sie ein eigenes Ziel dafür. Gibt es keine solche Vereinbarung, formulieren Sie die Verpflichtung bedingt: was das Team tun wird, sobald gültige Daten eingehen oder der Dritte den Dienst wiederherstellt.

Überprüfen Sie jede Einstufung, wenn eines dieser Signale auftritt:

• Der Prozess wird zu neuen Zeiten oder von mehr Teams genutzt.
• Die manuelle Alternative entfällt oder ist wegen des Volumens nicht mehr tragfähig.
• Wiederkehrende Fehler, Wiederverarbeitungen oder manuelle Eingriffe nehmen zu.
• Es kommen Integrationen, Datenänderungen oder neue Ausfallpunkte hinzu.
• Eine Störung zeigt, dass die tatsächliche Auswirkung größer oder kleiner war als dokumentiert.

Führen Sie regelmäßige Überprüfungen und zusätzlich eine Nachbereitung nach relevanten Störungen durch. Das Ergebnis muss keine Verschärfung der Verpflichtung sein: Es kann darin bestehen, den Umfang zu verringern, einen eingeschränkten Betriebsmodus zu schaffen, eine Warnung zu verbessern, einen kritischen Service von einer aufschiebbaren Aufgabe zu trennen oder ein SLA abzusenken, das nicht mehr der tatsächlichen Nutzung entspricht.

Checkliste zum Treffen und Aufrechterhalten der Entscheidung

1. Beschreiben Sie das Geschäftsergebnis, das der Prozess liefert.
2. Definieren Sie Auswirkung, Nutzungsfenster, Alternative, Abhängigkeiten und Toleranz für Verlust oder Verzögerung.
3. Stufen Sie den Prozess nach Kritikalität ein, nicht die gesamte Anwendung.
4. Weisen Sie SLAs nur Ergebnissen zu, deren Nichteinhaltung einen nicht akzeptablen Schaden verursacht.
5. Definieren Sie für alle übrigen Prozesse ein operatives Ziel oder eine klare Supporterwartung.
6. Prüfen Sie, ob die Kennzahlen beobachtbar sind und Verantwortliche handeln können.
7. Dokumentieren Sie Ausschlüsse und Notfallmaßnahmen, bevor eine Störung eintritt.
8. Überprüfen Sie die Verpflichtung bei Änderungen der Nutzung, Abhängigkeit oder Auswirkung.

Reife bedeutet nicht, mehr SLAs zu haben. Sie bedeutet, dass jede Verpflichtung einen realen Bedarf widerspiegelt, messbar ist und eine tragfähige operative Reaktion hat. Diese Disziplin schützt sowohl diejenigen, die vom Service abhängig sind, als auch die Teams, die ihn aufrechterhalten müssen.