Das müssen Sie bei Cloud-SLAs beachten

Der Server antwortet stundenlang nicht, die Auftragsverwaltung gibt keinen Mucks von sich, Kundendaten stehen nicht zur Verfügung. Solche Störungen sind für Cloud-Kunden der Worst Case. Wenn sich Unternehmen auf Cloud Computing einlassen, müssen sie sicher sein, dass so etwas möglichst nicht vorkommt: Die Cloud-Services müssen reibungslos funktionieren und immer in einer bestimmten Qualität vorliegen. Schließlich wollen sich die Betriebe die IT-Qualitätsstandards, die sie sich in den letzten Jahren erarbeitet haben - Stichwort Compliance - mit dem Übergang zum Cloud Computing erhalten und auf das neue Modell übertragen.

Es ist deshalb wichtig, die Qualität der gelieferten Services rechtlich verbindlich festzulegen. Dies geschieht in Service Level Agreements, kurz SLAs. Rein formal ist ein Service Level Agreement ein Vertrag zwischen dem Service-Provider und dem Kunden - oft in Form eines Anhangs zum eigentlichen Vertrag. In diesem wird festgehalten, in welchem Umfang eine Dienstleistung erbracht wird und zu welcher Dienstgüte.

Ein SLA-Vertrag legt unter anderem genau fest, welche Dienstqualität ein Kunde vom Anbieter erwarten darf, wie schnell die Reaktion auf Probleme erfolgen muss und was der Provider an Wiedergutmachung leistet, wenn es zu SLA-Verletzungen kommt und der Kunde Geschäftsverluste erleidet.

SLAs sind im übrigen keine Besonderheit des Cloud Computing, sondern als gute IT-Praxis Teil jedes IT-Programms, bei dem es um die Bereitstellung von Produkten oder Dienstleistungen geht. So werden Service Level Vereinbarungen heute vielfach auch unternehmensintern genutzt. IT-Abteilungen in großen Unternehmen setzen beispielsweise oft Service Level Agreements auf, um die Dienstleistungen für die Nutzer in den Fachabteilungen des Unternehmens transparenter zu machen.

Muss-Elemente von SLAs

Im Bereich Cloud Computing bilden SLAs den zentralen Rahmen. Eine Besonderheit sind SLAs bei Public Cloud Anbietern wie Amazon, Microsoft oder Google. Normalerweise sind SLAs zwischen Kunde und Anbieter verhandelbar und werden einvernehmlich geregelt.

Bei den Public Cloud Anbietern ist dies in der Regel nicht möglich. Sie gehen nicht auf die individuellen Kundenbedürfnisse ein, sondern haben durchweg einheitliche, standardisierte SLAs, die nicht verhandelbar sind - manche Kritiker sprechen auch von "Low Level SLAs".

Die Nutzer von Public Cloud Services finden sich damit automatisch in einer schwachen Position. Das die Public Clouds SLAs immer im Interesse des Providers geschrieben und an dessen Bedürfnissen ausgerichtet sind, treten die Interessen des Kunden in den Hintergrund. Dies muss allerdings nicht immer, wie weiter unten diskutiert, ein Nachteil sein.

Unabhängig davon, ob standardisierte oder verhandelbare SLA: Es gibt einige grundlegende Elemente, die von einer SLA immer abgedeckt werden sollten. Allerdings gibt es auch einige Elemente, die in einer SLA inkludiert sein können - oder auch nicht.

Die folgenden Elemente sollten generell immer in einer SLA geregelt sein:

• Verfügbarkeit: Die generelle Zugänglichkeit der Cloud-Systeme für den Kunden

• Performance: Die Geschwindigkeit der Datenübertragung und die Antwortzeiten der Schnittstellen

• Reaktionszeit: Die Zeitspanne, innerhalb der ein Provider bei Problemen oder Fehlermeldungen reagieren muss

• Wiederherstellungszeit: Die Zeitspanne, innerhalb der ein Fehler behoben sein muss

• Wartungsfenster und Downtimes: Die Zeit, wie lange das Cloud-System für Wartungsarbeiten abgeschaltet werden kann und wie oft und mit welchem Vorlauf Downtimes angekündigt werden müssen

Service-Verfügbarkeit

Der wichtigste SLA-Parameter ist die Verfügbarkeit. Am Beispiel dieses Parameters sollen die wichtigsten SLA-Elemente vorgestellt werden, bei den anderen verhält es sich ähnlich.

Die Verfügbarkeit eines Cloud Service ist der Zeitraum, in dem das System mindestens bereit steht. Als Zeiteinheiten werden typischerweise Minuten, Stunden, Tage, Monate, Quartale oder Jahre verwendet. Üblicherweise wird die Verfügbarkeit einer Cloud-Leistung als Prozentwert in Bezug auf den Betrachtungszeitraum angegeben, zum Beispiel "99,5 % im Monat"

Gemessen werden kann die Verfügbarkeit als Verhältnis von Uptime - also der Zeit, die der Service ordnungsgemäß bereit steht - zur Gesamtzeit, also Uptime plus Downtime (Ausfallzeit):

Verfügbarkeit = Uptime / (Uptime + Downtime).

Ist die Downtime = 0, ist die Verfügbarkeit 100 Prozent - der Idealwert. Als Mindestwert im Cloud Computing gelten Verfügbarkeiten von 99,9 Prozent. Das klingt beeindruckend, reicht aber in der Praxis oft nicht. Denn immerhin lassen 99,9 Prozent einen Zugriffsverlust von 8,7 Stunden pro Jahr zu - sind es acht Stunden in der Geschäftszeit, kann dies zu lang sein. Amazon bietet beispielsweise als einer der größten Cloud Anbieter für seinen Elastic Compute Cloud EC2-Service eine generelle Verfügbarkeit von 99,95 Prozent pro 365 Tage an, was einer Ausfallzeit von 4,38 Stunden entspricht.

Die nächst höhere übliche Stufe der Verfügbarkeit ist eine Ausfallsicherheit von 99,99 Prozent. Dies entspricht einem Systemausfall von etwa 50 Minuten pro Jahr. Auch dies ist für manche Einsatzgebiete zu wenig. Als magischer Wert gelten "Five-Nine": 99,999 Prozent Verfügbarkeit - das sind etwa fünf Minuten Ausfall pro Jahr.

Ungeplante Ausfälle

Ausfallsicherheit gibt es nicht umsonst, sie kostet Geld. Grob lässt sich sagen: Je mehr Neunen ein Provider anbietet (und damit: je höher die Verfügbarkeit) umso mehr steigen die Kosten für den Service. Bei kritischen Systemen empfiehlt es sich, hier nicht zu sparen. Weniger kritische Systeme können mit geringeren und kostengünstigeren Ausfalllevels betrieben werden.

Was aber zählt zur Downtime? Fällt ein Service ungeplant aus, ist die Verfügbarkeit ganz klar nicht gegeben. Wie aber verhält es sich mit geplanten Ausfällen aufgrund von Wartung oder Systemaktualisierungen? Für den Provider zählt letzteres nicht zur Ausfallzeit:

Verfügbarkeit = (Servicezeit + geplante - ungeplante Ausfallzeit) / Gesamtzeit

Der Kunde sieht dies naturgemäß anders. Er hat das Interesse, aus dem Plus hinter der Servicezeit ein Minus zu machen.

Wartungsfenster sollten deshalb in der SLA klar geregelt sein. Es muss ersichtlich sein, ob und wenn ja, welche Wartungszeiten zur Servicezeit zählen. Dort sollte auch festgelegt werden, ob Wartungsintervalle in regelmäßigen Abständen erfolgen, einer Genehmigung des Kunden bedürfen oder diese auch außerplanmäßig erfolgen können.

Verfügbarkeit ist eine klare Ja-Nein-Frage. Ein Service ist verfügbar oder nicht. Allerdings kann ein Service in seiner Qualität nicht den Erwartungen des Kunden entsprechen. Beispielsweise kann ein Cloud-System zwar antworten, aber die Antwort kann sehr lange auf sich warten lassen. Ist die Leistungserbringung damit erfüllt oder nicht?

Service Level und Kennzahlen

Solche Fragen zur erwarteten Güte eines Service - dem Service Level - sind zentral für eine SLA und müssen dort geregelt werden. Ob eine Leistung in hinreichender Qualität erbracht wurde oder nicht legen Kennzahlen oder Key Performance Indicators (KPI) fest. Deren tatsächlicher Ist-Wert wird mit dem vertraglich geregelten Soll-Wert verglichen.

Werden die Grenzwerte eingehalten gilt der Service als funktionsfähig und erfüllt den Service Level. Wenn in dem eben erwähnten Beispiel die Antwortzeit eines Systems diese Kenngröße überschreitet, ist der Service Level nicht erbracht; andernfalls sind die Grenzwerte eingehalten und der Service Level gilt als erfüllt.

Die Kennzahl setzt sich aus der Bezeichnung für den zu berechnenden Wert, wie beispielsweise "Antwortzeit für Dienst X", dem Messverfahren zur Ermittlung der Werte und den Messpunkten bzw. Bezugsobjekten dar.

Die Antwortzeit lässt sich beispielsweise dadurch kontrollieren, dass man die Zeit vom Starten einer Anfrage an ein IT-System bis zum Wiedereintreffen der daraus resultierenden Antwort beim Absender misst. Als KPI:

Antwortzeit = tAntwort - tAnfrage

Kenngrößen werden natürlich nicht nur für das Antwortzeitverhalten festgelegt. Typische Kennzahlen , sondern auch für andere Parameter wie den Datendurchsatz ????(die übertragene Datenmenge pro Zeiteinheit), die Paketverzögerung (der Zeitbedarf, um ein IP-Paket von A nach B zu senden) oder die Paketverlustrate (die Zahl der IP-Pakete, die pro Zeiteinheit verloren gehen, weil sie nicht rechtzeitig an ihren Bestimmungsort gelangen).

In der Praxis wird meist eine über einen längeren Zeitraum durchgeführte Gruppe von Anfragen gemessen und dann der Durchschnittswert gebildet.

Kenngrößen lassen sich natürlich nicht nur für das Antwortzeitverhalten festlegen, sondern auch für andere Parameter wie den Datendurchsatz oder die Paketverzögerung. Besonders wichtig im Cloud Computing sind Kennziffern für die Sicherheit.

Welche KPIs zur Bestimmung der Leistungsqualität des Anbieters zu Grunde gelegt werden, sollte letztlich von den Anforderungen des Kunden abhängen. Viele Beispiele für die Definition von Kennzahlen finden Sie in dem vom Bundesamt für Sicherheit in der Informationstechnik (BSI) und der Hochschule Furtwangen herausgegebenen SLA-Richtliniendokument für Cloud Dienstleistungen, aus dem auch das Beispiel stammt.

Leistungsüberprüfung - Reporting

Damit der Kunde überprüfen kann, ob die Service Levels eingehalten wurden, sollte der Provider regelmäßig einen Report abliefern. Es sollte vereinbart werden, wie das Monitoring erfolgt, welche Parameter gemessen werden und unter welchen Bedingungen dies erfolgt. Auf Basis des Berichts sollte ersichtlich sein, ob und falls ja, wo eine Leistungsstörung aufgetreten ist. So kann der Kunde den Provider kontrollieren und im Falle der Nichterfüllung von Leistungen die Konsequenzen ziehen.

Im Idealfall liefert der Provider dem Kunden regelmäßig eine Übersicht über die Einhaltung der vereinbarten Verfügbarkeit und Qualität der Leistungen. Dies kann monatlich, vierteljährlich, halbjährlich oder jährlich erfolgen. Je kritischer die ausgelagerten Services sind, umso enger sollte das Reporting getaktet sein. Bewährt hat sich auch die Verpflichtung zu Berichten, wenn Zwischenfälle aufgetreten sind.

In der Public Cloud werden die IT-Ressourcen allerdings nicht dediziert einem einzelnen Nutzer zur Verfügung gestellt. Um dieses Problem zu lösen, könnte sich der Kunde ein Recht auf Prüfung und Messung der SLA-Kennzahlen direkt beim Cloud-Computing-Anbieter vorbehalten. Dazu sind die wenigsten Provider bereit.

Laut BSI muss der Provider seinem Kunden allerdings die Möglichkeit geben, die SLA selbst zu überwachen und die Einhaltung der vereinbarten Werte zu überprüfen oder überprüfen zu lassen. Die entsprechenden Leistungsparameter könnte der Provider etwa über spezielle Schnittstellen zugänglich machen.

Störungsbeseitigung

Die Pflicht und Dauer der Beseitigung einer Störung sollte ebenfalls in einer SLA geregelt sein. Dazu legt der Anbieter - entweder in Rücksprache mit dem Kunden oder bei Public Cloud Anbietern alleine - Reaktions- und Wiederherstellungszeiten fest. Die Reaktionszeit ist die Zeitspanne, innerhalb der der Provider mit der Störungsbeseitigung beginnen muss, die Wiederherstellungszeit der Zeitraum, innerhalb dessen die Störungsbehebung abgeschlossen sein muss.

Reaktions- und Wiederherstellungszeiten sollten in der SLA klar geregelt werden. Das kling simpel, ist in der Praxis aber oft diffizil, etwa bei der Frage, wann der jeweilige Zeitpunkt beginnt. Auch wenn Hardware getauscht werden muss, kann sich die Reaktionszeit ungebührlich verlängern.

Um Leistungsmängel rechtlich zu erfassen, hat es sich in der Praxis bewährt, verschiedene Prioritätsklassen zu bilden. Für die einzelnen Prioritätsklassen wird dann in der SLA festgelegt, wie schnell der Diensteanbieter im Falle einer Störung reagieren und welche Leistungen er zur Beseitigung der Störung erbringen muss.

Für die Einstufung konkreter Störungen gilt die Faustregel, dass der Provider umso schneller reagieren muss, je kritischer die Leistungsstörung für den Auftraggeber ausfällt.

Konsequenzen bei Abweichungen - Entschädigung

Der Fall, dass ein vereinbarter Service Level auf Grundlage des Soll-Ist-Vergleich der Kennzahlen nicht erreicht wird, muss für den Dienstleister Konsequenzen haben. Die Konsequenzen lassen sich dabei in zwei Gruppen unterteilen.

Zum einen sind bei der Nichterbringung des Service Levels Sanktionen gegenüber dem Provider möglich. Zum anderen können bei Erfüllung oder Übererfüllung des definierten Service Levels dem Anbieter positive Konsequenzen angerechnet werden - wie etwa Bonuszahlungen bei Erreichen bestimmter Performance-KPIs.

Der Normalfall sind allerdings Sanktionen bei Nichterfüllung von Service Levels. Die Art und Höhe dieser Strafen sollte in einem angemessenen Verhältnis zur Abweichung vom Service Level und dem Nutzen der Dienstleistung stehen. Eine nicht-monetäre Sanktion wäre die Einräumung eines Sonderkündigungsrechts, wenn bestimmte Levels nicht erreicht werden.

Weit verbreitet sind monetäre Sanktionen in Form einer Reduzierung der laufenden Gebühren oder Geldrückzahlungen. In der SLA stehen dann Passagen wie: "Wenn der Service nicht verfügbar ist, erstatten wir Ihnen die Kosten für den Service für eine Anzahl X von Stunden."

Was in SLAs allerdings so gut wie nie thematisiert wird, sind die durch den Ausfall verpassten Geschäftstransaktionen, wie etwa nicht zustande gekommenen Verkäufe. Normalerweise möchten Kunden so etwas in die SLA integrieren, doch dem dürfte kein Cloud Provider zustimmen. Eine solche Verpflichtung wird kein Dienstleister eingehen.

SLAs bei Public Cloud Anbietern

Im Allgemeinen ist es eine gute Strategie im Cloud Computing, eine eigene SLA zumindest in Grundzügen auszuarbeiten und diese mit der SLA des Providers zu vergleichen. Sie können dann selbst entscheiden, ob Sie die SLA des Providers übernehmen, auf die Durchsetzung Ihrer eigenen SLA drängen oder den Provider wechseln.

Bei Public Cloud Anbietern ist, wie eingangs erwähnt, eine individuelle SLA normalerweise nicht möglich. Hier muss sich der Kunde mit den vorgegebenen, allgemein gehaltenen Garantien für Parameter wie Bandbreite, Antwortzeiten oder Datensicherung begnügen - und hoffen, dass im Fall der Fälle Schadensersatz geleistet wird.

"Cloud-Dienstleister wie Amazon bieten überhaupt keine SLAs in dem Sinn, dass eine nicht erbrachte Leistung spürbare Konsequenzen für den Diensteanbieter hat", erklärt Ralph Treitz, CEO der VMS AG. Ausfälle in der jüngsten Vergangenheit zeigten tatsächlich, dass die Formulierungen locker genug sind, dass der Provider nicht für die Verletzung des SLA aufkommen musste - trotz eines schweren Ausfalls.

Sind standardisierte SLAs und Public Cloud Dienste also ein Risiko? "Kommt darauf an sagt", sagt Dr. Carlo Velten, ehemaliger IT-Analyst bei der Experton Group und jetzt bei Crisp Research. "Wenn es um unkritische Anwendungen geht, ums Testen und Entwickeln, kann man das bei den preisgünstigen Public Cloud-Providern mit ihren standardisierten SLAs wunderbar erledigen. Für simple Web-Applikation fürs Marketing, kurzfristiges High Performance Computing oder für Genom-Analysen, bei denen man nur Rechenpower braucht, sind Amazon Cloud, Salesforce oder Microsofts Azure hervorragend geeignet."

Ausschlusskriterium standardisierte SLAs

In bestimmten Business-Situationen können nicht verhandelbare SLAs allerdings ein Ausschlusskriterien sein. So entschädigt Microsoft bei Ausfall zwar für die entgangene Servicezeit. Nicht aber für den entgangenen Umsatz.

Für unternehmenskritische Anwendungen und sensible Daten sind die Public Clouds mit ihren Low Level SLAs deshalb kaum zu empfehlen, sagen die Analysten. "Betreibt man über längere Zeit Enterprise Anwendungen wie etwa ein SAP-System auf einer Cloud-Infrastruktur genügen standardisierte SLAs wie auch die ganze Infrastruktur der Public Cloud-Dienstleister nicht", warnt Crisp-Analyst Velten.

Stehen Sicherheit, mission critical Applikationen oder der langfristige Betrieb von Anwendungen im Vordergrund, sollte man sich bei Anbietern umsehen, die Enterprise Business Clouds mit individualisierbaren SLAs anbieten. Eine starke Rolle spielen hier Netzbetreiber, weil sie ihre Netz-Infrastruktur besser kontrollieren können. Alternativ kann man aber auch gleich den Aufbau einer Private Cloud in Betracht ziehen.

Fazit

Abschließend noch ein Hinweis auf zwei Dokumente mit weiterführenden Informationen. Das mehrfach erwähnte, vom BSI und der Hochschule Furtwangen herausgegebene SLA-Richtliniendokument für Cloud Dienstleistungen gibt einen detaillierten Überblick, auf was es bei SLAs ankommt und stellt die wichtigsten Kennziffern vor.

Der vom Bundeswirtschaftsministerium für Wirtschaft und Energie im Rahmen des Projekts Trusted Cloud herausgegebene Leitfaden zur Vertragsgestaltung im Cloud Computing gibt eine Orientierungshilfe zur rechtlichen Ausgestaltung von Cloud-Verträgen. Er richtet sich insbesondere an Entscheider in Unternehmen, die Cloud-Dienste anbieten oder nutzen möchten. (hal)