Was in einem sinnvollen SLA steht und warum Pönalen nicht dazu gehören
Der SLA - Service-Level-Agreement - ist ein gutes Werkzeug, um die Erwartungshaltung eines Kunden an den Service zu beschreiben. Damit das funktioniert, brauchst Du auch hier Werte, die der Kunde versteht. Diese dürfen für ihn wirklich relevant sein. Ansonsten ist der SLA das Papier nicht wert, auf dem er ausgedruckt wurde. Du erfährst auch, warum ich Pönalen, wie sie heute meist verwendet werden, für absolut sinnlos erachte.
In den letzten Wochen fragen mich Kunden immer wieder, was alles in einem SLA – Service-Level-Agreement – stehen soll. Das ist eine sehr gute Frage. Was würdest Du antworten?
Ich komme jedes Mal wieder ins Grübeln. Ich glaube, so einfach wie es auf den ersten Gedanken klingt, ist es nämlich in Wirklichkeit gar nicht. Deswegen gebe ich auf die Frage selten direkt eine Antwort. Ich möchte mit meinen Kunden ins Gespräch kommen und erfahren, was für sie ein sinnvoller SLA ist.
Verfügbarkeit – das Maß aller Dinge?
Eine der ersten Antworten ist immer: Verfügbarkeit. Verfügbarkeit wovon? Da gibt es dann zwei Lager: Lager Nummer eins will die Verfügbarkeit von technischen Equipment messen. Lager zwei ist da schon weiter, denen geht es um die Verfügbarkeit des Service an sich.
Habe ich Dir schon gesagt, dass ich das Gespräch mit IT-Abteilungen führe? Ich glaube nämlich nicht, dass der Großteil der Fachabteilungen gleich mit einer Verfügbarkeit um die Ecke kommt. Zumindest dann nicht, wenn wir sie nicht auf unser IT-Sprech getrimmt haben.
Was drückt denn eine Verfügbarkeit wirklich aus? Ich würde sagen, sie beschreibt die Wahrscheinlichkeit, dass ein Service funktioniert. Nehmen wir 98% Verfügbarkeit des Dienstes Onlineshop. Das heißt, dass 98 von 100 Versuchen, die Webseite aufzurufen erfolgreich sind. Das ist schon mal gar nicht so schlecht.
Wie überprüfst Du das? Eigentlich ganz einfach – Dein Monitoringsystem macht einen Aufruf der Webseite und zeichnet auf, ob es geht oder nicht. Wie oft prüfst Du das? In der Regel aller 5 Minuten. Und damit erreichst Du locker die 98% Verfügbarkeit.
Und dazwischen?
Ich nehme Dich jetzt mal auf ein Gedankenexperiment mit: Du prüfst das aller 5 Minuten – also genau 12-mal pro Stunde. Also müssen rein rechnerisch 11,76 Versuche erfolgreich sein.
Problem 1: Geteilte Versuche gibt es nicht.
Problem 2: Die Ergebnismenge ist ziemlich gering
Wie lange musst Du messen, damit Du wenigstens 100 Messergebnisse hast? Genau 8 Stunden und 20 Minuten.
Und da haben wir noch nicht darüber gesprochen, was mit den Zeiten zwischen der Messungen ist. Da sind ja ungefähr 4 Minuten und 59 Sekunden, in denen Du nicht misst. In der Zeit finden allerdings jede Menge Aufrufe der Webseite statt. Und wenn es da nicht funktioniert, dann zählt das nicht für den SLA. Schon komisch, oder?
Klar, jetzt kannst Du das Messintervall verkürzen. Führt letztlich immer wieder zum gleichen Ergebnis.
Wo?
Nächste Frage: Wo überprüfst Du das? Also wo ist der Messpunkt. Misst Du direkt im Rechenzentrum? Da ist die Wahrscheinlichkeit sehr hoch, dass die Messung erfolgreich ist. Sagt noch lange nichts darüber aus, wie es sich für den Kunden darstellt. Der Messaufbau ist auch falsch. Denn wenigstens die Internetanbindung Deines RZ und die öffentlichen DNS Server der Domäne gehören zu einer Ende-zu-Ende-Betrachtung des Service dazu.
Dann baust Du in einem anderen Rechenzentrum einen Messpunkt auf. Reicht das dann? Zumindest kommt es der Sache näher.
Egal was Du tust, am Ende kommt bei der Verfügbarkeit nicht wirklich was Sinnvolles für den Kunden raus! Denn dem Kunden ist das im Prinzip egal! Die schlechte Nachricht ist, wir leben in einer „allways-on“ Zeit. Jeder geht davon aus, dass alles immer verfügbar ist.
Du wirst nie mit einem Kunden auf einen grünen Zweig kommen, wenn Du über Verfügbarkeit diskutierst. Lass es einfach.
Konzentriere Dich bitte auf die, für Deinen Kunden wichtigen Punkte. Ich stelle häufig die Frage: „Woran merken Sie, dass der Service xyz eine hohe Qualität hat.“ Komm mit Deinem Kunden in die Diskussion, was für ihn Qualität bedeutet.
Lass uns bei dem Beispiel Webshop bleiben. Da kannst Du Dir sicher sein, dass Dein Kunde von 100% Verfügbarkeit ausgeht. Doch was bedeutet jetzt Qualität?
Denk mal bitte selber drüber nach: Wenn Du in einem Onlineshop einkaufen möchtest, was muss passieren, damit Du den Shop verlässt und Dir das Produkt in einem anderen kaufst?
Performance
Also bei mir reicht es schon, wenn Shop zu langsam ist. Also beispielsweise, wenn ich mehrere Artikel kaufen möchte und es dauert jedes Mal eine gefühlte Ewigkeit den Artikel aufzurufen und in den Warenkorb zu legen. Lange schau ich mir das nicht an, sondern schaue, wo ich die Produkte noch bekomme.
Nicht-Verfügbarkeit beginnt für den Nutzer eines Dienstes schon viel, viel eher. Schon wenn etwas langsam, zu langsam wird, nehmen es Nutzer als nicht verfügbar war. Da kann Deine Messung noch so erfolgreich sein – der Nutzer wird unzufrieden.
Aus diese Perspektive wäre eine sinnvolle Messgröße, die Zeitdauer folgenden Ablaufes:
Kunde ruft Webshop auf, sucht einen Artikel über die Suche, scrollt bis er ihn gefunden hat, ruft ihn auf, legt ihn in den Warenkorb, geht zu Kasse und bezahlt.
Das ist ein Ablauf, der messbar und vor allem für Deinen Kunden sinnvoll ist! Damit habt ihr eine Basis, über die beide Seiten gut sprechen können. Das bedeutet, dass Du zu sinnvollen Anforderungen an die Performance Deines Service kommst.
Mit Hilfe eines Skriptes oder Messrobotors kannst Du diese Klickfolge regelmäßig testen. Zusammen mit den technischen Detailmessungen kannst Du relativ schnell und einfach auch die Ursache des Performanceproblems erkennen.
Was noch viel schöner ist, wenn Dein Monitoring feststellt, dass der Messwert anhaltend eine gewisse Zeit die Warnungs-Grenze überschreitet, dann kann es automatisch das Deployment weiterer Webserverinstanzen oder Datenbankinstanzen anstoßen und so mehr Kapazität zur Verfügung stellen. Gleiches gilt auch, wenn zu wenig Last auf der Umgebung ist. Der Automat kann dann Web- oder Datenbankserver wieder deprovisionieren. Damit kannst Du von dynamischen Infrastrukturen super profitieren.
Natürlich gilt auch für diese Messung das Problem, dass es eine Momentaufnahme ist. Keine Frage. Jedoch ist diese Momentaufnahme für Deinen Kunden viel, viel nützlicher als die Verfügbarkeit. Damit lohnt es sich für Dich, darüber nachzudenken wie kurz sinnvollerweise die Zeit zwischen zwei Messungen sein soll.
Was ist Qualität?
Ich möchte Dich dazu anregen, sprich mit Deinen Kunden über Qualität und nicht Verfügbarkeit. Schaut gemeinsam, was relevant ist. Und dann schaut in der IT, wie ihr diese Messpunkte umsetzen könnt.
Wenn ihr einmal dabei seid miteinander über Qualität zu sprechen, dann sprecht bitte unbedingt darüber, dass der Moment, dass der Service nicht nutzbar ist, auf jeden Fall kommen wird. Irgendwann. 100% kann es aus meiner Sicht nicht geben. Services sind ein komplexes Zusammenspiel von Kunde, Nutzer, Technik, Betreiber und Prozessen. Da wird irgendwann etwas schief gehen.
Dein Kunde wird dem nicht wiedersprechen.
Worüber ihr in diesem Moment sprechen solltet, ist die Frage, welche Ausfallzeiten sind wie oft tolerierbar. Nehmen wir jetzt mal 99,3% Verfügbarkeit. 99,3% bedeuten bei 30 Tagen und 24 Stunden Betrieb 5 Stunden und 2 Minuten Ausfallzeit.
Das hört sich für einen Monat nicht viel an. Doch was ist, wenn das am Stück auftritt? Also der Webshop am Blackfriday 5 Stunden nicht verfügbar ist? Wie viel Millionen Euro verliere ich als Anbieter des Shops dabei?
Geh mal anders ran!
Du darfst mit Deinen Kunden darüber sprechen, wie lange einzelne Ausfälle dauern dürfen. Und wie oft diese vorkommen dürfen. Ihr seid euch ja einig, dass es zu den Ausfällen kommen kann.
Also beispielsweise dürfen:
- Ausfälle bis zu 2 Minuten 2 mal pro Stunde, aber maximal 5 mal am Tag und 10 mal pro Woche auftreten
- Ausfälle bis zu 30 Minuten dürfen 2 mal pro Woche und maximal 6 mal pro Quartal auftreten
- Ausfälle bis zu 4 Stunden einmal im Quartal und maximal 4 mal pro Jahr
Diese Diskussion gibt Dir viel mehr Informationen, wie Du Deinen Dienst gestalten musst, um die Anforderungen zu erfüllen. Da denkst Du dann nicht nur über Technik nach, sondern auch über Prozesse, Ressourcen, Supportverträge und externe Dienstleister.
Bei der Gelegenheit noch ein Grund, warum Verfügbarkeit kein so sinnvoller Wert ist: Je mehr Komponenten ein Service hat, umso geringer ist die rechnerisch mögliche Gesamtverfügbarkeit. Die Einzelverfügbarkeiten werden multipliziert. Wenn Dein Service nur aus 5 Komponenten besteht, die jeweils 99,9% verfügbar sind, kommt da eine mögliche Gesamtverfügbarkeit von 99,5% raus.
Jetzt schau mal, welcher Deiner Services nur als fünf Komponenten besteht …
Auswirkung
Eine weitere Möglichkeit ist, dass Du und Dein Kunde über die Auswirkung konkreter Fehler eines Services sprecht. Also die Relevanz oder wie viel Arbeitszeit dadurch verloren geht.
Ich versuche beim Webshop zu bleiben. Ist die Bezahlfunktion nicht verfügbar, macht der Webshop keinen Umsatz. Nahe an der Katastrophe. Funktioniert die integrierte FAQ-Datenbank für Bestandkunden nicht, hängt zumindest nicht unmittelbar Umsatz dran. Eine Störung beim Support-Chat ist dabei sicher kritischer.
Das Beispiel soll Dir zeigen, dass es sinnvoll sein kann, einen Service zu zerlegen und zu schauen, welche Auswirkung hat ein Ausfall der jeweiligen Funktion. Daraus kannst Du Dir wieder ableiten, wie der Service gebaut sein muss und Du hast auch eine Priorisierung, der einzelnen Vorfälle.
Wichtige Zeiten
Wenn Du jetzt immer noch mit Deinem Kunden sprichst, dann rede mit ihm doch bitte auch über folgende Punkte:
- Wartungsfenster – wann kannst Du Wartungsarbeiten am Service vornehmen; in einem deutschen Webshop wäre das vielleicht einmal im Monat irgendwann zwischen 2 und 5 Uhr in der Früh
- Hochlastzeiten – wann erwartet Dein Kunde besonders viel Nutzung des Service; im Webshop sind das Cyber-Monday, Black-Friday und die Weihnachtszeit – Zeiten, in denen der Service zusätzliche Ressourcen benötigt
- Frozen Zones – wann darfst Du auf keinen Fall etwas am Service ändern; in der Weihnachtszeit am Webshop etwas zu verändern ist sicher keine gute Idee
- Maximaler Datenverlust – auf Daten welches Zeitraums, kann im schlimmsten Fall verzichtet werden; bei einem Webshop sehr schwierig, wenn die Bestellungen der letzten Stunde weg sind – also brauchst Du dafür andere Strategien, um sicherzustellen, dass keine Bestellung abhandenkommt
Das sind vier Punkte, über die Du mit Deinem Kunden sprechen darfst. Die bringen Dich und Deinen Kunden weiter. Wenn Du jetzt weiterdenkst, dann findest Du noch viel mehr wirklich sinnvolle Punkte für einen SLA. Konzentriere Dich dabei bitte immer auf die Perspektive Deines Kunden und dessen Endkunden.
Die Krux mit den Pönalen
Zum Schluss möchte ich noch mit dem heiligen Gral des SLAs brechen: den Pönalen. Ich kenne fast kein Unternehmen, was nicht Wert auf die Pönalen legt, wenn es Leistungen nach Außen gibt. Und dabei sind die in vielen Fällen einfach nur sinnlos!
Pönale ist die Vertragsstrafe, die ein Provider zahlt, falls er einen Ausfall über einen gewissen Zeitraum zu vertreten hat. Ich habe gerade einfach mal im Internet gesucht und bei einem Provider folgendes gefunden:
In der höchsten SLA-Stufe, die bestimmt ordentlich teuer ist, würdest Du nach einer Stunde Ausfall 6% der Kosten für den Abrechnungszeitraum zurückbekommen. Die Stunde ist hier pro Ausfall zu verstehen und nicht kumuliert. Erst bei mehr als 18 Stunden pro Ausfall bekommst Du 100% der Kosten zurück.
Jetzt stelle ich mir vor, dass bei einem Automobilzulieferer das ERP für mehr als 18 Stunden steht. Genau.
Der kann sich für das Geld im wahrsten Sinne des Wortes nichts kaufen. Der hat seinerseits hohe Vertragsstrafen an die Autohersteller zu zahlen, weil er nicht liefern konnte.
Die Pönale ist ein wundervolles Instrument für Provider. Es ist ein wundervolles Instrument des Risikomanagements. Es dient dazu die Haftung zu begrenzen. Mehr wird Dir Dein Provider für die Ausfälle nicht bezahlen. Er kann damit sein Risiko sehr gut kalkulieren und immer abwägen, ob der Aufwand, den er treiben muss, eine Störung zu beheben, in Relation zum Risiko steht. Im Zweifel entscheidet er sich vielleicht nicht in Deinem Interesse.
Absicherung
In dem SLA des Anbieters heißt es weiter: „Sofern die oben genannten Service Level nicht erfüllt werden, ist eine Haftung der xyz gmbh nur dann gegeben, wenn die xyz gmbh die Nichteinhaltung allein zu vertreten hat. Darüber hinaus haftet die xyz ausschließlich für grob fahrlässig oder schuldhaft verursachten Schäden. Weitergehende Ansprüche gegen die xyz gmbh, insbesondere solche auf Ersatz von indirekten und Folgeschäden wie z. B. entgangener Gewinn, Betriebsunterbrechung, Verlust von Daten und Informationen etc., sind nur im Rahmen der Haftung nach den Allgemeinen Geschäftsbedingungen der xyz gmbh möglich.“
In den AGB ist dann wie üblich die Haftung auf Vorsatz und grobe Fahrlässigkeit begrenzt.
Was ist die Botschaft an den Kunden: Egal welchen Schaden du hast, mehr als die Monatsrate bekommst Du nicht.
Und genau deswegen prangere ich dieses Instrument an. Es ist so, wie ich es gerade dargestellt habe, für Dich als Kunde sinnlos. Wenn Du Pönalen vereinbaren möchtest, dann müssen die in einer Größenordnung sein, die dem in Deinem Unternehmen entstehenden Schaden entsprechen. Nur so können sie eine steuernde Wirkung entfalten und sind für Dein Unternehmen wirkungsvoll.
Es gibt andere Punkte, über die ich mit einem Provider sprechen möchte. Die sind für mich viel wichtiger als Pönalen. Dazu in einer späteren Folge mehr!
Du hast jetzt Anregungen bekommen, was sinnvolle Punkte in einem SLA sind. Schau einfach mal in die SLAs, die Du mit Deinen Kunden hast und überlege Dir, wie Du die für den Kunden besser gestalten kannst.
