Menü
Ein Beitrag von Adacor

Risiken und Begleiteffekte von SLAs

Risiken und Nebenwirkungen von SLAWieso technisch belastbare SLA besser für ihr Business sind, als rein kaufmännisch kalkuierte Service Level Agreements.

Wie stellt man als verantwortlicher Entscheider in der IT-Abteilung für die eigenen internen Kunden sicher, dass alle Serviceleistungen funktionieren? Mit jedem Dienstleister werden sogenannte SLAs (Service Level Agreements) vereinbart, in denen steht, was ein Service alles kann und welche Qualität er hat.
Mein eigenes Unternehmen verhandelt SLAs mit seinen Kunden genauso wie mit seinen Lieferanten (Rechenzenten, Carrier, Hardware, Software et cetera). Wir kennen das Thema also von beiden Seiten und aus der Praxis heraus zeigt sich: Es ist nicht alles so einfach, wie es auf den ersten Blick scheint.
Beim Thema SLA gilt es einige kritische Punkte zu umschiffen. Zwei besonders kritische Aspekte möchte ich näher beleuchten: rein kaufmännische SLAs und die konkrete Formulierung der Service Levels.

Die IT-Welt unterliegt einem ständigen Wandel. Der grundsätzliche Trend in der Corporate IT geht seit geraumer Zeit dahin, weniger selbst zu machen und stattdessen IT-Leistungen als Service einzukaufen. Die rasante Entwicklung der Cloud Services tut ihr übriges dazu: Infrastructure as a Service, Platform as a Service und Software as a Service. Wir bewegen uns in einer schönen neuen Servicewelt, in der das Management und die Orchestrierung sämtlicher eingekaufter Services eine der wichtigsten Aufgaben der IT-Abteilung geworden ist.

Was genau ist eigentlich ein Service Level Agreement?

In Deutschland wird der Begriff SLA häufig auf die Verfügbarkeit eines Service in einem Angebot reduziert. Diese Verwendung trifft es jedoch nicht ganz. Ein Service Level Agreement ist vielmehr ein Vertrag über Leistungen, die von einem Dienstleister erbracht werden. Darin werden sowohl die Inhalte als auch die Qualität dieser Leistungen festgelegt.

Die deutsche Entsprechung in der Enterprise IT ist der Leistungsschein, der ebenfalls einen Vertrag über die zu erbringenden Leistungen eines Service darstellt. Häufig ist dieser Vertrag in einen übergeordneten Rahmenvertrag eingebettet.

Ein Leistungsschein oder SLA beschreibt zunächst im Detail alle Leistungen, die in einem Business Service erbracht werden. Weiter geht er auf die sogenannten verfügbaren Service Levels ein.

Service Levels definieren verschiedene qualitative Ausprägungen der zu erbringenden Leistung, wie zum Beispiel die Verfügbarkeit, eine Reaktionszeit auf Supportanfragen, eine Lösungszeit oder eine Performance-Kennziffer. Es sind viele qualitative Ausprägungen denkbar. Dann sollten im Idealfall Vertragsstrafen, die bei Unterschreitung der zuvor definierten Service Levels fällig werden, aufgeführt werden. Abschließend wird das Abrechnungsmodell für den Service vereinbart.

Image

Whitepaper zu SLA downloaden

Belastbare Service-Level-Agreements also SLAs bilden die Grundlage für performante IT-Services. Wieso das so ist erfahren Sie in unserem Whitepaper von ADACOR CEO Thomas Wittbecker. Jetzt direkt downloaden!

Auswirkung von rein kaufmännischen SLA auf den Markt

Eine große Herausforderung im SLA-Management ist die Bewertung von SLAs. Einen Vertrag mit einem Dienstleister abzuschließen, garantiert leider nicht, dass dieser auch immer eingehalten wird. Wenn man selbst aber verschiedene Services einkauft, die man wiederum für die Erbringung eigener Services benötigt, ist es enorm wichtig einschätzen zu können, wie ernst man die Zusicherungen des Anbieters nehmen darf.

Am Beispiel meines eigenen Unternehmens wäre die Stromverfügbarkeit in unseren Rechenzentren ein sehr kritischer Service Level. Deshalb prüfen wir hier sehr genau, ob unsere Facility-Betreiber technisch und organisatorisch in der Lage sind, ihre vertraglich gemachten Zusicherungen einzuhalten.

Gerade bei den großen und im Marketing aggressiven amerikanischen Anbietern von IT-Services und Produkten werden häufig ambitionierte SLAs angeboten. Diese sind allerdings nur mit sehr geringen oder gar keinen Vertragsstrafen versehen und kalkulieren von Anfang an ein, dass sich die Service Levels bei einem nennenswerten Prozentsatz der Kunden nicht einhalten lassen. Über diese Problematik berichtet die ZEIT in einem Beitrag über die Abhängigkeit der zentralen Infrastruktur des Intenrets von einigen wenigen Cloud-Anbietern.

Wir haben in den vergangenen zehn Jahren mit den Marktführern im Storage-Markt in verschiedenen Kundenprojekten gearbeitet und keiner hat seine SLAs langfristig gehalten. Die SLAs sind bei diesen Unternehmen allerdings so formuliert, dass bei Nichteinhaltung nichts oder nicht viel passiert. Deshalb können diese Anbieter werblich aggressiv auftreten und gut damit leben, wenn einige Kunden am Ende unzufrieden zurückbleiben. Für einen Entscheider, der viele SLAs von verschiedenen Dienstleistern zu managen hat und selbst wieder gegenüber seinen internen oder externen Kunden in der Pflicht steht, ist die Bewertung der SLAs eine große Herausforderung.

Kaufmännisches SLA versus technisch belastbares SLA

Things To Say Episode #6: Der Unterschied zwischen kaufmännischen und technisch belastbaren SLA

Eigentlich müssen Entscheider sowohl technisch als auch organisatorisch prüfen, ob die vereinbarten Service Levels wirklich realistisch für alle relevanten Szenarien sind. Meiner persönlichen Erfahrung nach passiert das bei Großunternehmen in der Regel aber nicht. Meistens fehlt den Managern auch das technische Know-how für eine solche Überprüfung. Gerade gegenüber großen Dienstleistern ist die Skepsis eher gering. Wenn irgendwo schwarz auf weiß steht, dass ein Produkt eine Verfügbarkeit von 99,999 % p. a. hat, wird das als gegeben angesehen, und zwar umso mehr, je größer der IT-Dienstleister ist. Dabei ist es oft egal, ob im Vertrag sämtliche Schadensersatzansprüche ausgeschlossen sind und es auch keine vereinbarten Vertragsstrafen gibt. In den meisten Fällen geht es gut. Trotzdem gilt: Wenn ich viel einkaufe, werde ich mit Sicherheit einige SLA-Brüche erleben.

Meine Empfehlung gerade an größere Unternehmen ist daher: Baut Mitarbeiter auf, die sich in der Praxis der in den SLAs verhandelten Services auskennen, und die sie organisatorisch betreuen. Erst dann wird es möglich, die SLAs von Dienstleistern auf die technische Machbarkeit zu überprüfen.

Auch wir als Dienstleister sind von dem Thema betroffen, da viele Mitbewerber auf dem Cloud- und Hosting-Markt kaufmännisch kalkulierte SLAs formulieren. Vereinfacht bedeutet das, sie bieten eine ungewöhnlich hohe Verfügbarkeit an und wenn sie diese in Einzelfällen nicht einhalten, erstatten sie zum Beispiel 10 % der Gebühren für den betroffenen Monat (wie es ein großer Cloud-Anbieter macht). Für ein derartiges Kostenrisiko muss man keine teure höchstverfügbare Infrastruktur vorhalten. Und wenn es alle ein oder zwei Jahre zu einem Ausfall kommt und man als Dienstleister die SLAs nicht einhält, lassen sich 10 % für den betroffenen Monat gut verschmerzen.

Wir bieten Services mit dem Anspruch an unsere SLAs, diese über die Gesamtlaufzeit eines Projektes einzuhalten. Dafür müssen wir einen entsprechenden Aufwand betreiben und das bedeutet Ausgaben für die Leistung der Mitarbeiter und die Infrastruktur. Alternativ müssten wir genauso vorgehen wie einige Mitbewerber und kaufmännisch kalkulierte anstelle von technisch belastbaren SLAs anbieten.

Der Teufel steckt im Detail – oder in den Formulierungen

Im zweiten Teil des Artikels beschäftige ich mich mit einer weiteren Stolperfalle bei SLAs in Form von genauen Definitionen der einzelnen Leistungen. Hier steckt der Teufel im Detail.

Was wird beispielsweise wirklich als Ausfall gewertet und wie genau wird dieser gemessen? Diese Details zu durchschauen ist gar nicht so einfach. Der Kunde möchte eigentlich eine End-to-end-Verfügbarkeit des kompletten Service. Darunter versteht man die Verfügbarkeit bis auf das Gerät des Endkunden. Diese kann der Anbieter aber in der Regel weder leisten noch messen. Meistens verteilt sich die End-to-end-Verfügbarkeit deshalb über verschiedene Dienstleister und Parteien.

Nehmen wir auf der Suche nach einem Beispiel für einen Ausfall etwas vermeintlich Einfaches wie die Verfügbarkeit der Internetanbindung bei einem Webhoster. Wie genau wird dabei die Verfügbarkeit der Internetanbindung gemessen? Größere Hosting Anbieter nutzen Internetanbindungen von verschiedenen Carriern, die in einem Mix gefahren werden. Am einfachsten ist der Fall, wenn die Haupt-Routing-Infrastruktur des Webhosters ausfällt: Dann ist alles tot und es muss definitiv als Ausfall gewertet werden. Aber wie stellt sich der Fall dar, wenn es Routingprobleme bei einem der angebundenen Carrier gibt und der Webhoster zum Beispiel aus dem Telekom-Netz nicht erreichbar ist, aber aus anderen Netzen schon? Dann ist mein Webangebot für viele Privatkunden nicht erreichbar, für viele andere aber schon. Hier kommt es dann auf die genauen Definitionen im SLA an.

Die folgenden zwei Beispiele zeigen, wie man Erreichbarkeit definieren kann. Eine aussagekräftige Methode besteht darin, möglichst viele Messpunkte aus den unterschiedlichsten Netzen verschiedener Carrier zu nutzen. Wenn diese Messpunkte mehrheitlich das Rechenzentrum erreichen können, gilt das Rechenzentrum als verfügbar.

Man kann es aber auch anders formulieren. Solange mein Monitoring innerhalb des Rechenzentrums fünf von zehn externen Zielen erreichen kann, ist Internetverfügbarkeit gegeben. Und so weiter… Also muss ich ganz genau verstehen, was für mein Projekt wichtig ist und was die Formulierungen im SLA genau für meinen Fall bedeuten.

Eine weitere Stolperfalle im SLA ist die Tatsache, dass die Verfügbarkeiten einzelner Services meistens getrennt angegeben werden. Das teilt sich bei einem Webhoster in folgende Unterteilung auf: Verfügbarkeit Internet, Verfügbarkeit internes Netz, Verfügbarkeit Firewall und Verfügbarkeit Webserver. Je detaillierter diese aufgeführt sind, umso schwieriger wird es, die Verfügbarkeit eines kompletten Services, wie einer Website zu berechnen.

Wie so häufig im Leben steckt auch bei den SLAs der Teufel im Detail. Manchmal ist ein auf den ersten Blick vorteilhaftes SLA in erster Linie Augenwischerei. Ein Vertrag ersetzt nicht eine gute Beziehung zwischen Dienstleister und Kunde und hilft auch nicht bei mangelndem Fachwissen.

Welche Fragen in Sachen SLA bei der ADACOR haben Sie noch?

Nehmen Sie direkt Kontakt zu mir oder dem Sales-Team auf.

Mehr Informationen zum Thema Verfügbarkeiten finden Sie in meinem Artikel über die Berechnung von Verfügbarkeit.

Dieser Text ist in ähnlicher Formulierung bereits als Gastbeitrag bei IP-Insider erschienen.

, , , , , , , , , ,


Weitere Artikel zum Thema lesen

Cloud, Hosting

Welche Verfügbarkeit braucht mein Web-Projekt?

Unser Fragenkatalog hilft zur Bestimmung der erforderlichen Verfügbarkeit weiter.

weiter lesen

Herausforderung Datenschutz aus Sicht von Managed Hosting

Hosting

Herausforderung Datenschutz aus Sicht von Managed Hosting

Wieso Datensicherheit und -schutz integrale Bestandteile unserer Dienstleistungen sind.

weiter lesen

Das Infrastrukturteam – Arbeit an der technischen Basis der ADACOR

Biz & Trends, Cloud, Domains, Hosting

Das Infrastrukturteam – Arbeit an der technischen Basis der ADACOR

Diesmal möchten wir ganz gezielt das Infrastrukturteam der ADACOR Hosting in den Fokus der Betrachtung rücken. Als eine Art „betriebsinterner Dienstleister“ legt es die...

weiter lesen


Neueste Nachrichten von Adacor

Datendschungel Big Data

Biz & Trends

Big Data – Mehr Durchblick im Datendschungel

Big Data wird häufig als Synonym für NoSQL-Datenbanken genutzt. Wir ordnen die Themen Big Data und Datenbanken korrekt ein.

weiter lesen

iks

IT Security

Compliance – Vertrauen ist gut, Kontrolle ist besser

Wir stellen wirksame Instrumente für die erfolgreiche Unternehmenskontrolle im Rahmen der von uns erbrachten IT-Services vor.

weiter lesen

Warum brauchen Sie Informationen über die Applikation?

Hosting

Warum brauchen Sie Informationen über die Applikation?

Die Verzahnung der Entwicklung mit dem Betrieb direkt bei der Konzeption löst die gewünschte Agilität aus, um „Continuous Operations“ zu gewährleisten.

weiter lesen

Diese Website verwendet Cookies. Mit der weiteren Nutzung der Website stimmen Sie unserer Datenschutzerklärung zu.
Für weitere Informationen klicken Sie bitte hier.