Das SLA garantiert eine Verfügbarkeit von 99,9 %. Im vergangenen Monat war das System während 99,92 % der gemessenen Zeit verfügbar und hat damit die vereinbarte Vorgabe technisch erfüllt. Während der verbleibenden 0,08 % konnte der Batch-Lauf für den Finanzabschluss allerdings nicht innerhalb des vereinbarten Zeitfensters abgeschlossen werden. Das SLA-Dashboard zeigte Grün. Der Finanzdirektor erhielt denselben Bericht zwei Stunden zu spät und verpasste damit die Deadline für die Vorstandssitzung. Das SLA wurde erfüllt. Das eigentliche Serviceversprechen nicht.
Genau diese Lücke zwischen dem, was das Monitoring meldet, und dem, was das Business tatsächlich erwartet, ist das operative Problem, das SLA Observability lösen soll.
Dafür muss auf der Ebene gemessen werden, auf der das Serviceversprechen definiert wurde, und nicht nur dort, wo sich Daten besonders einfach erfassen lassen.
Warum Uptime-Metriken die SLA-Erfüllung systematisch überschätzen
Verfügbarkeit als Prozentwert ist eine sinnvolle Ausgangsmetrik, aber keine ausreichende SLA-Messgröße. Die Zahl blendet zwei Faktoren aus, die in der Praxis entscheidend sind: wann die Downtime aufgetreten ist und welche Prozesse dadurch verhindert wurden.
Ein System, das während geplanter nächtlicher Wartungsfenster unter der Woche um 02:00 Uhr insgesamt 43 Minuten nicht verfügbar war, hat einen völlig anderen Business Impact als dieselben 43 Minuten Downtime um 07:30 Uhr am ersten Arbeitstag nach dem Monatsende, wenn Anwender auf Abschlussberichte zugreifen und die letzten Batch-Läufe abgeschlossen werden müssen.
Beide Situationen führen zum gleichen Verfügbarkeitswert. Die geschäftlichen Auswirkungen sind jedoch nicht vergleichbar.
Eine kalendergewichtete Verfügbarkeit, bei der Downtime während definierter kritischer Zeitfenster stärker gewichtet wird, bildet die Realität in SAP-Umgebungen besser ab. Denn die Kosten einer Nichtverfügbarkeit sind weder über den Tag noch über den Monat gleich verteilt.
Ein 15-minütiger Ausfall während des Jahresabschlusses kann operativ deutlich schwerwiegender sein als ein vierstündiger Ausfall an einem Sonntagmorgen.
SLA-Definitionen, die diese Unterschiede nicht berücksichtigen, können auf dem Papier sehr gute Werte produzieren und trotzdem an den Business-Prozessen vorbeimessen, die sie eigentlich schützen sollen.
Die drei Ebenen, auf denen SAP SLAs tatsächlich existieren
Infrastrukturverfügbarkeit: die Mindestanforderung, nicht das Endziel
Die Verfügbarkeit der Infrastruktur, also ob das SAP-System überhaupt erreichbar ist, bildet die Mindestvoraussetzung für die Erfüllung eines SLA. Ein System, zu dem keine Verbindung hergestellt werden kann, erfüllt kein Serviceversprechen, das seine Nutzbarkeit voraussetzt.
Umgekehrt bedeutet ein erreichbares System jedoch nicht automatisch, dass alle Serviceziele erfüllt sind.
Infrastrukturverfügbarkeit ist die notwendige Grundlage, aber nicht das vollständige Bild.
Für eine korrekte Messung muss zunächst definiert werden, was „verfügbar“ im Vertrag tatsächlich bedeutet. Nach einer Definition ist ein System verfügbar, wenn es auf einen Netzwerk-Ping antwortet. Eine strengere Definition verlangt, dass Dialogverbindungen möglich sind und Transaktionen innerhalb einer definierten Antwortzeit Ergebnisse liefern.
Viele Diskussionen über SLA-Verfügbarkeit entstehen schlicht dadurch, dass beide Parteien unterschiedliche Definitionen desselben Begriffs verwenden.
Applikationsperformance: die mittlere Ebene, die viele SLAs nur unvollständig abbilden
Die Dialog Response Time ist die Kennzahl auf Anwendungsebene, die sich am direktesten auf die User Experience übertragen lässt. Ein SAP-System, dessen Infrastruktur verfügbar ist, bei dem Dialogschritte aber durchschnittlich acht Sekunden benötigen, erfüllt kein vernünftiges Performance-Versprechen, selbst wenn die Uptime-Messung keinerlei Problem zeigt.
Die Herausforderung besteht darin, dass Antwortzeiten je nach Transaktion, Tageszeit, gleichzeitiger Systemlast und verarbeitetem Datenvolumen variieren.
Ein SLA mit der Aussage „durchschnittliche Dialog Response Time unter zwei Sekunden“ ist daher unklar. Durchschnitt über welche Transaktionen? Während welcher Zeiten? Bei welcher Benutzerzahl?
Solange diese Parameter nicht definiert sind, lässt sich das SLA nur messen, indem zunächst eine Interpretation gewählt wird. Dabei besteht die Gefahr, dass genau die Methode verwendet wird, die den günstigsten Wert erzeugt.
Das SLO, also das Service Level Objective hinter einem Response-Time-SLA, sollte deshalb den Messbereich eindeutig definieren.
Zum Beispiel: Das 95. Perzentil der Dialog Response Time aller Standardtransaktionen während der Geschäftszeiten, gemessen in Fünf-Minuten-Intervallen, muss unter zwei Sekunden bleiben.
Diese Definition lässt nur eine Interpretation zu und kann anhand von Monitoring-Daten konsistent gemessen werden.
Abschluss von Business-Prozessen: die Ebene, die fast kein SLA heute misst
Die Serviceversprechen, von denen das Business tatsächlich abhängt, befinden sich auf Prozessebene und nicht auf Infrastrukturebene.
Der Batch für den Finanzabschluss muss am zweiten Arbeitstag nach Monatsende bis 06:00 Uhr abgeschlossen sein. Kundenaufträge, die vor 16:00 Uhr eingehen, müssen innerhalb von 30 Minuten im Warehouse-Management-System erscheinen. Die nächtliche IDoc-Verarbeitung muss bis 07:00 Uhr eine Erfolgsquote von mehr als 99,5 % erreichen.
Das sind messbare Serviceversprechen.
Sie erfordern allerdings Monitoring auf Ebene der Batch-Job-Abschlüsse, der Interface-Erfolgsraten und der Erstellung von Business-Dokumenten statt ausschließlich auf Ebene der Serververfügbarkeit.
Nur wenige MSP-SLAs und ebenso wenige interne IT-Servicevereinbarungen enthalten heute solche Kennzahlen. Der Grund dafür ist, dass ihre Messung ein ausreichendes Verständnis der Geschäftsprozesse voraussetzt, um klare Erfolgskriterien zu definieren. Zusätzlich muss das Monitoring so instrumentiert werden, dass es erkennt, ob diese Kriterien tatsächlich erfüllt wurden.
Unternehmen, die prozessbezogene SLOs definieren und messen, schaffen eine gemeinsame Datenbasis zwischen IT und Business. Die Diskussion dreht sich dann um tatsächliche Ergebnisse und nicht um Infrastruktur-Dashboards, die keine der beiden Seiten vollständig mit dem Business Impact verbinden kann.
Diese Messung ist aufwendiger als die reine Erfassung von Uptime.
Sie beantwortet aber wesentlich ehrlicher die Frage, ob der vereinbarte Service tatsächlich erbracht wurde.
Das MTTR-Problem: vom Impact aus messen, nicht von der Detection
Mean Time to Recover, kurz MTTR, ist eine etablierte SLA-Kennzahl für Incident Response. Gemessen wird die Zeit zwischen der Erkennung eines Problems und seiner Behebung. Theoretisch bedeutet ein niedrigerer MTTR eine schnellere Incident Response.
In der Praxis wird damit häufig das falsche Zeitintervall gemessen.
Wenn sich ein Produktionssystem um 02:15 Uhr verschlechtert und das Problem erst um 04:30 Uhr erkannt wird, beginnt der gemessene MTTR erst um 04:30 Uhr. Wird der Incident um 05:00 Uhr gelöst, beträgt der MTTR 30 Minuten.
Der tatsächliche Service Impact dauerte jedoch 2 Stunden und 45 Minuten.
Ein MTTR von 30 Minuten ist damit technisch korrekt, operativ aber irreführend.
SLA Observability für Incident Response benötigt deshalb zwei getrennte Messgrößen: Time to Detect, vom Beginn des Impacts bis zur ersten Erkennung, und Time to Resolve, von der Erkennung bis zur Wiederherstellung.
Beide Werte sind relevant.
MTTR allein unterschätzt den tatsächlichen Service Impact systematisch, wenn Detection Gaps bestehen, was in den meisten Umgebungen der Fall ist.
Ein MSP, der einen durchschnittlichen MTTR von 22 Minuten meldet, aber nicht erwähnt, dass Incidents im Durchschnitt erst nach 90 Minuten erkannt werden, präsentiert korrekte Zahlen in einem Kontext, der einen wesentlichen Teil der Realität ausblendet.
Time to Detect ist außerdem die Kennzahl, die am unmittelbarsten die Qualität des Monitorings widerspiegelt.
Die Detection Time von 90 Minuten auf fünf Minuten zu reduzieren, hat in der Regel einen größeren Business Impact als die Resolution Time von 30 auf 15 Minuten zu reduzieren.
Time to Detect wird jedoch erst dann zu einer aktiv steuerbaren Kennzahl, wenn sie tatsächlich gemessen wird.
| Achtung: SLA-Definitionen, die ausschließlich die Resolution Time festlegen, können einen unbeabsichtigten Anreiz schaffen, einen Incident möglichst spät offiziell zu deklarieren. Beginnt die Messung erst mit der Erstellung des Incident-Tickets statt mit dem tatsächlichen Beginn des Impacts, hängt der gemessene MTTR davon ab, wie schnell ein Ticket eröffnet wird und nicht davon, wie lange der Service tatsächlich beeinträchtigt war. Dies muss nicht absichtlich geschehen, begünstigt bei SLA-Reviews aber systematisch den Provider gegenüber dem Kunden. Definieren Sie den Beginn des Business Impacts im SLA und nicht den Zeitpunkt der Ticket-Erstellung. |
|---|
Was MSPs anders messen müssen
Ein MSP, der SAP-Systeme für mehrere Kunden betreibt, erzeugt Monitoring-Daten über seine eigene Monitoring-Infrastruktur und berechnet auf dieser Grundlage die SLA-Erfüllung. Der Kunde hat gleichzeitig seine eigene Wahrnehmung davon, ob der vereinbarte Service tatsächlich erbracht wurde.
Wenn beide Perspektiven unterschiedliche Zahlen liefern, geht es im Konflikt nicht nur um die Servicequalität, sondern ebenso um die verwendete Messmethodik.
Die Frage nach der maßgeblichen Datenquelle ist daher praktisch relevant: Welche Monitoring-Daten gelten bei einem SLA-Streit als verbindlich?
Der Vertrag sollte diese Frage beantworten. In der Praxis tut er das nur selten.
Fehlt eine klare Definition, präsentieren beide Parteien ihre eigenen Daten und die Klärung wird langsam und konfliktbehaftet.
Ein MSP, der die SLA-Messung konsequent aus Sicht des Kunden gestaltet und dabei Daten verwendet, die die tatsächliche Kundenerfahrung abbilden statt nur den Zustand der Infrastruktur, reduziert diese Lücke zwischen beiden Perspektiven deutlich.
Das bedeutet, Process Completion Times auf Ebene der Geschäftsprozesse des Kunden zu messen und nicht nur die Systemverfügbarkeit auf Infrastrukturebene. Time to Detect sollte ab dem tatsächlichen Beginn des Business Impacts gemessen werden und nicht erst ab dem Zeitpunkt, an dem der Monitoring-Alert des MSP ausgelöst wurde. IDoc-Erfolgsraten und Batch-Job-Zeitfenster gehören ebenso in das SLA Reporting wie Server-Uptime.
Dieser Ansatz erfordert tiefere Monitoring-Abdeckung und eine intensivere Auseinandersetzung mit den Geschäftsprozessen des Kunden, um geeignete SLOs definieren zu können.
Gleichzeitig entsteht dadurch ein SLA Reporting, das tatsächlich informiert, statt lediglich defensiv die Vertragserfüllung nachzuweisen.
In einem Markt, in dem Kunden Verfügbarkeitswerten zunehmend skeptisch gegenüberstehen, wenn diese nicht erklären können, warum Geschäftsprozesse trotzdem ausgefallen sind, kann diese Transparenz zu einem echten kommerziellen Differenzierungsmerkmal werden.
Error Budgets als praktisches Werkzeug für das SLA Management
Ein Error Budget beschreibt die zulässige Abweichung von einem definierten SLA innerhalb eines bestimmten Zeitraums. Bei einem monatlichen Verfügbarkeits-SLA von 99,9 % beträgt das Error Budget ungefähr 43 Minuten pro Monat.
Dieses Budget wird jedes Mal verbraucht, wenn das System nicht verfügbar ist.
Die Echtzeitüberwachung des Error-Budget-Verbrauchs verändert die operative Steuerung grundlegend.
Zeigt das Monitoring am Mittwoch der dritten Woche, dass bereits 35 der verfügbaren 43 Minuten verbraucht wurden, verfügt das Team über konkrete Daten für eine Entscheidung: Eine für das Wochenende geplante Wartung sollte möglicherweise verschoben oder in einen Zeitraum mit neuem Error Budget gelegt werden. Würde sie jetzt durchgeführt, könnte sie den verbleibenden Puffer aufbrauchen und zu einem SLA Breach führen.
Error Budgets machen außerdem Diskussionen über Technical Debt und Reliability-Investitionen wesentlich konkreter.
Ein System, das regelmäßig 80 % seines monatlichen Error Budgets durch ungeplante Incidents verbraucht, hat ein messbares Reliability-Problem. Ein System, das sein Error Budget überwiegend für geplante Wartungsarbeiten nutzt, ist nachweislich zuverlässiger.
Der Unterschied wird in den langfristigen Error-Budget-Daten sichtbar und nicht nur in der Anzahl der Incidents.
Für MSPs schaffen Error Budgets zusätzlich einen gemeinsamen Rahmen mit dem Kunden. Beide Seiten sehen jederzeit, wie viel der monatlichen Toleranz bereits verbraucht wurde, wie viel noch verfügbar ist und ob geplante Änderungen durchgeführt werden können, ohne einen SLA Breach zu riskieren.
Diese gemeinsame Transparenz ersetzt Überraschungen beim SLA Review am Monatsende durch einen kontinuierlichen Austausch auf Basis realer Daten.
Die Monitoring-Infrastruktur für SLA Observability unterscheidet sich grundsätzlich nicht von der Infrastruktur für operatives Monitoring. Sie sammelt dieselben Daten.
Der Unterschied liegt im Blickwinkel.
Statt lediglich zu fragen, ob das System aktuell gesund ist, fragt SLA Observability, ob die für diesen Monat vereinbarten Service Commitments weiterhin erfüllt werden, ob das verfügbare Budget für Abweichungen bereits weitgehend aufgebraucht ist und ob die Business-Ergebnisse, von denen das Unternehmen abhängt, innerhalb der vereinbarten Zeitfenster geliefert werden.
Dafür müssen SLOs präzise genug definiert sein, um messbar zu werden. Das Monitoring muss die relevanten Daten auf der richtigen Ebene erfassen. Und das Reporting muss die tatsächliche Erfüllung der Service Commitments zeigen, statt lediglich den Gesundheitszustand der Infrastruktur.
Die meisten Monitoring-Implementierungen beherrschen bereits den dritten Punkt.
Die ersten beiden sind die Bereiche, in denen SLA Observability tatsächlich entsteht.
Redpeaks bietet SLA-Dashboards für SAP Managed Services und deckt Verfügbarkeitsfenster, Batch Completion SLOs, Interface-Erfolgsraten und Incident Detection Time ab. Die Informationen werden in einem Format dargestellt, das sowohl für Operations-Teams als auch für Business Stakeholder verständlich und zugänglich ist.
