SLA-Richtliniendokument für Cloud Dienstleistungen. Veröffentlichung. Autonomic SLA Management as a Service (ASLAMaaS)

SLA-Richtliniendokument für Cloud Dienstleistungen Veröffentlichung Autonomic SLA Management as a Service (ASLAMaaS)

I Autonomic SLA Management as a Service. BMBF Fördernummer 03FH046PX2 Autoren Firma E-mail Stefan Frey Hochschule Furtwangen Stefan.Frey@hs-furtwangen.de Claudia Lüthje Hochschule Furtwangen Claudia.Luethje@hs-furtwangen.de Christoph Reich Hochschule Furtwangen Christoph.Reich@hs-furtwangen.de Michael Maier Advanced Unibyte GmbH Michael.Maier@advanced-unibyte.de> Tobias Zutavern Freicon AG TZutavern@freicon.de Markus Streif Gruner AG Markus.Streif@gruner.de Über Autonomic SLA Management as a Service Ziel dieses vom Bundesministeriums für Bildung und Forschung (BMBF) geförderten Projekts (Laufzeit: 01. Oktober 2012 30 September 2015 ) ist das selbständige, automatische Management von Dienstgütevereinbarungen in Cloud-Umgebungen. Dienstgütevereinbarungen (Service Level Agreements: SLAs) beschreiben dabei die Leistungsqualität (Quality of Service: QoS) der bezogenen Cloud Services welche zwischen Kunde und Dienstleister ausgehandelt werden. Die Nutzung von Cloud Services bietet gerade kleinen und mittelständischen Unternehmen große Vorteile, wie beispielsweise einen Kosteneinsparpotenzial durch den Zukauf von IT-Ressourcen nach Bedarf, niedrige Investitionskosten und der Möglichkeit der raschen Umsetzung von Innovationen. ASLAMaaS soll sowohl Cloud Kunden als auch Cloud Providern zur SLA-Verwaltung und Überwachung der in den SLAs definierten Servicequalitäten dienen und in die IT-Management- Infrastruktur des Kunden, als auch des Cloud Providers integriert werden. Basierend auf dem MAPE-K Konzept soll ASLAMaaS mithilfe von Policies und vordefinierten Aktionsplänen SLA-Verletzungen automatisch entgegenwirken, zum Beispiel durch die Bereitstellung zusätzlicher Ressourcen. Diese speziellen Cloud-spezifischen Mechanismen sollen untersucht werden, mit dem Ziel, in einem bestimmten Rahmen die Servicequalitäten besser einzuhalten. Durch die Dynamisierung des SLA-Managements mit ASLAMaaS sollen die IT-Kosten gesenkt, auf SLA-Verletzungen besser reagiert und die Sicherheit der Cloud-Services erhöht werden. Das ASLAMaaS-Projekt findet in Zusammenarbeit mit drei deutschen Industriepartnern statt: Advanced Unibyte GmbH (IT-Dienstleister, Cloud-Provider), Freicon AG (IT-Consulting, Monitoringsysteme) und der Gruner AG (Internationaler Hersteller von Relais, Magnetsystemen und Stellantrieben). ASLAMaaS ist ein gefördertes Projekt des Bundesministeriums für

1 Bildung und Forschung (BMBF) und läuft unter der Projektfördernummer 03FH046PX2. Dokumentenhistorie Version: 1.0-01.05.2013 - Erste Veröffentlichung Version: 1.1-17.07.2013 - Korrektur: Backup & Restore Abbildung und KPIs für SaaS Version: 1.2-08.04.2014 - Korrektur: KPI Taxonomie

Inhaltsverzeichnis 2 Inhaltsverzeichnis Glossar 4 1 Einführung 6 1.1 SLAs und Cloud Computing.......................... 6 1.2 Ziel des Richtliniendokuments......................... 7 1.3 Aufbau des Richtliniendokuments....................... 8 2 Service Level Agreement 8 2.1 SLA Lebenszyklus............................... 8 2.2 SLA Voraussetzungen.............................. 9 2.3 Aufbau von SLAs................................ 10 2.3.1 Vereinbarungsbezogene Elemente................... 11 2.3.2 Dienstleistungsbezogene Elemente................... 12 2.3.3 Managementbezogene Elemente.................... 14 2.3.4 Dokumentbezogene Elemente..................... 16 2.4 Standards.................................... 17 2.4.1 ITIL v3................................. 17 2.4.2 ISO 20000............................... 18 2.4.3 COBIT................................. 18 2.4.4 SOUSIS-Modell............................ 19 2.5 Rollen...................................... 19 2.6 Kennzahlen und KPIs.............................. 20 2.7 SLA Gliederung................................. 21 3 Service Level Objectives 21 3.1 Aufbau und Inhalt................................ 23 3.2 KPI Taxonomie................................. 23 4 Übergeordnete Cloud-KPIs 24 4.1 Basisleistungen................................. 24 4.2 Sicherheit.................................... 27 4.3 Service & Helpdesk............................... 29 4.4 Monitoring................................... 30 4.5 Weitere übergeordnete KPIs.......................... 31 5 SLOs für Cloud Computing 31 5.1 Netzwerk.................................... 31 5.2 Storage..................................... 33 5.3 Backup & Restore................................ 35 5.4 VM basierende KPIs.............................. 37 5.5 Infrastructure as a Service........................... 38 5.6 Platform as a Service.............................. 39

Inhaltsverzeichnis 3 5.7 Software as a Service.............................. 40 5.8 Cloud Basis Dienste............................... 41 5.8.1 Image Management Service...................... 41 5.8.2 Datenbank Service........................... 41 5.8.3 Load Balancer Service......................... 42 5.8.4 Scale Service.............................. 42 5.8.5 Message Queue Service........................ 42 6 Zusammenfassung 42 Literaturverzeichnis 42

Inhaltsverzeichnis 4 Glossar Cloud-Anwender Cloud-Anwender ist jede natürliche oder juristische Person, die von Betroffenen personenbezogene Daten erhebt, verarbeitet oder nutzt und hierfür von anderen Stellen IT-Dienstleistungen für Cloud-Services in Anspruch nimmt. [Arb11] Cloud Host Physikalischer Computer, auf dem mittels Hypervisorsoftware virtuelle Maschinen betrieben werden können. CMS Cloud Management System ist für die Erstellung, Verwaltung und Löschung virtueller Ressourcen zuständig. CSP Cloud Service Provider, siehe Cloud Anbieter. Cloud-Anbieter Cloud-Anbieter ist jede natürliche oder juristische Person, die einem Cloud- Anwender IT-Dienstleistungen für Cloud-Services bereitstellt. Fehlen dem Cloud- Anbieter hierfür die Ressourcen, so kann dieser zur Erfüllung seiner Verpflichtungen gegenüber dem Cloud-Anwender u. U. weitere Unter-Anbieter einbeziehen. [Arb11] Datenschutz Personenbezogene Daten werden besonders geschützt und nur unter den Gesichtspunkten des Datenschutz verarbeitet (erzeugt, gespeichert, übermittelt, gelöscht). Die informationelle Selbstbestimmung der beteiligten natürlichen Personen wird gewahrt. Public Cloud IT-Dienstleistungen für Public Clouds werden am freien Markt und nicht innerhalb einer Institution oder im internen Unternehmensbereich einer verantwortlichen Stelle angeboten. Sie können folglich von einer beliebigen Zahl von Cloud-Anwendern in Anspruch genommen werden.[arb11] Private Cloud IT-Dienstleistungen werden hierbei innerhalb einer Institution oder im internen Unternehmensbereich einer verantwortlichen Stelle angeboten,[fra10] sodass der Cloud- Anwender und der Cloud-Anbieter (oder mehrere Cloud-Anbieter) dem Bereich dieser verantwortlichen Stelle zuzuordnen sind. [Arb11] Community Cloud In einer Community Cloud schließen sich zwei oder mehrere Cloud- Anbieter aus Private Clouds zusammen, um für einen definierten Kundenkreis IT-Dienstleistungen für Cloud-Services zu erbringen.[fra10] [Arb11] Hybrid Cloud Bei Hybrid Clouds werden Public-, Private- und/oder Community Clouds miteinander kombiniert. Dieses Modell kann im Rahmen der Erhöhung der Verfügbarkeit oder zur effizienten Lastverteilung zum Einsatz kommen. [Arb11] Infrastructure as a Service (IaaS) Cloud-Anwender erhalten Zugriff auf üblicherweise virtualisierte Komponenten zur Datenverarbeitung, zum Datentransport und zur Datenspeicherung. Sie können nahezu beliebige Anwendungsprogramme und Betriebssysteme einsetzen. [Arb11]

Inhaltsverzeichnis 5 Platform as a Service (PaaS) Platform as a Service ermöglicht dem Cloud-Anwender, auf der vom Cloud-Anbieter angebotenen Infrastruktur, eigene Programme zu entwickeln und auszuführen. Der Cloud-Anbieter macht hierbei Vorgaben zu den zu verwendenden Programmiersprachen und Schnittstellen zu Datenspeichern, Netzwerken und Datenverarbeitungssystemen. Wie bei der Dienstleistung Software as a Service auch, hat der Cloud-Anwender keine Möglichkeit auf die zur Bereitstellung des Dienstes genutzte Infrastruktur administrativ oder kontrollierend zuzugreifen. Die Kontrollmöglichkeiten beschränken sich auf die selbst eingebrachten Programme und Daten. [Arb11] Software as a Service (SaaS) Der Zugriff des Cloud-Anwenders auf die vom Cloud-Anbieter bereit gestellten Anwendungen erfolgt üblicherweise über einen Web-Browser, kann aber auch mit speziellen Programmen erfolgen, die hauptsächlich über Anzeigefunktionen verfügen ( Thin-Clients ). Die bereitgestellten Anwendungen können allenfalls in geringem Umfang auf spezielle Anforderungen der Cloud-Anwender angepasst werden. Auf die für das Bereitstellen der Anwendung genutzten Dienste und Systeme haben die Cloud-Anwender regelmäßig keinen direkten administrativen, operativen oder kontrollierenden Zugriff. [Arb11]

1 Einführung 6 1 Einführung Nach einem anfänglichen Hype, hat sich Cloud Computing als adäquates Mittel zur Bereitstellung von Ressourcen nach Bedarf etabliert. Für Unternehmen stellt Cloud Computing inzwischen eine praktische Alternative zu lokal gehosteten Ressourcen dar. Laut einer Marktanalyse der Gartner Group [Gro11] sind 2011 die IT Budgets der deutschen Firmen um 2,7% gekürzt worden. Die Studie sagt auch, dass viele Firmen zukünftig verstärkt auf die Auslagerung ihrer IT in die Cloud setzen wollen, um Kosten zu sparen. In Deutschland, dass durch einen sehr ausgeprägten und international erfolgreichen Mittelstand gekennzeichnet ist, hat die Bundesregierung in den High-Tech Strategien 2020 unter dem Bedarfsfeld Kommunikation, Cloud Computing als wichtiges Handlungsfeld beschrieben. Gerade für KMUs ist zukünftig die Nutzung von Cloud Computing zur Wettbewerbssicherung unabdingbar. Die Vorteile von Cloud Computing liegen dabei vor allem in einer Kostenersparnis durch pay-per-use, niedrige Investitionskosten und der Möglichkeit der raschen Umsetzung von Innovationen. Damit sich Unternehmen auf ihr Kerngeschäft konzentrieren können und Cloud Dienste effizient und verlässlich einsetzen können benötigen diese eine klare Zusicherung über deren Qualität. Diese zu erwartenden Service Qualitäten werden rechtlich verbindlich in sogenannten Service Level Agreements (SLAs) dokumentiert. SLAs sind wichtig, um die Erwartungen an einen Service eindeutig zwischen dem Cloud-Verbraucher (Kunde) und der Cloud-Provider (Verkäufer) festzulegen. Dabei werden sowohl die Service Eigenschaften mit den zu erwartenden Leistungen als auch die Verantwortlichkeiten und Aktionen definiert. Aktuell bieten Cloud Computing Provider ihre Dienste meist nur nach dem Best-Effort Prinzip an. Dabei werden keine oder nur allgemeingültige Garantien für QoS-Eigenschaften wie beispielsweise Bandbreite, Antwortzeiten, Datensicherung, etc. gegeben. Dies macht solche Angebote, um die eigene IT in die Cloud zu verlagern, wegen fehlender Dienstqualitätsgarantien und Sicherheiten, recht uninteressant für Unternehmen. Der Einsatz von Cloud Computing erfordert die konstante Überwachung und Kontrolle, um effizient im Unternehmen eingesetzt werden zu können,[for10]. Vereinzelt bieten Cloud Provider ein rudimentäres, starres Gerüst, welches gängige Service-Level-Agreements (SLAs), wie beispielsweise die Verfügbarkeit oder Helpdesk regelt. Dies erlaubt es dem Kunden zwar im Falle von Service-Problemen zu intervenieren, aber die Dienstgüte ist rechtlich nicht bindend zugesichert. Zudem ist dies nicht ausreichend, da individuelle Anforderungen nicht berücksichtigt werden. In den letzten Jahren gab es verschiedene Versuche, Cloud Computing von dem aktuellen Best-Effort-Prinzip zu differenzieren. Cloud Computing Anbieter die kundenspezifische SLAs anbieten ermöglichen es Unternehmen Cloud Computing effizient und mit geringem Risiko in ihre vorhandene IT-Infrastruktur einzubinden und können sich so klar zu ihren Wettbewerbern auf dem Markt unterscheiden wodurch ein Wettbewerbsvorteil entsteht. 1.1 SLAs und Cloud Computing 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, die Abrechnung und Laufzeit und was der Provider an Wiedergutmachung zu leisten hat, wenn es zu SLA- Verletzungen kommt und der Kunde Geschäftsverluste erleidet. SLAs stellen dabei die Eck-

1 Einführung 7 pfeiler eines jeden IT-Dienstleisters dar, um seinen Kunden verlässliche Dienste anzubieten. Dies spiegelt sich auch in der 2010 von Vanson Bourne durchgeführten und von Compuware [Cor11] beauftragten Umfrage wieder. Dabei zeigte sich, dass 72% der befragten Unternehmen erklärten, dass der Einsatz von Cloud Diensten mangels der Eigenschaft Service-Level einzuhalten beeinträchtigt wird, was zu einen lähmenden Effekt auf den Umsatz des Unternehmens haben kann. Weiterhin ergab sich, dass deutsche Unternehmen hohe Schäden durch schlechte Performance bei Cloud-Anwendungen erleiden. Auf insgesamt mehr als eine halbe Million Euro bezifferte die Studie den durchschnittlichen jährlichen Verlust wegen fehlender SLAs. Die aktuell von den Providern angebotenen Service Levels werden von der zunehmenden Zahl der Nutzer als unzureichend und den Provider begünstigend gesehen. Cloud Provider gehen of nicht auf die individuellen Bedürfnisse ihrer Kunden ein, sonder fertigen diese mit vordefinierten allgemeinen Reglungen ab. Amazon, als einer der größten Cloud Anbieter, bietet beispielsweise für seinen Elastic Compute Cloud (Amazon EC2) Service nur eine generelle Verfügbarkeit von 99,95% pro 365 Tage an. Was einer Ausfallzeit von 4,38 Stunden entspricht. Alternative Reglungen sind nicht möglich. Ausfälle in der jüngsten Vergangenheit zeigten jedoch auch, dass die Formulierungen locker genug sind, dass der Provider nicht für die Verletzung des SLA trotz eines schweren Ausfalls aufkommen musste. Dies kann zu schweren Verlusten für einen Cloud Kunden führen. Für Unternehmen ist es somit unerlässlich, spezielle SLAs zu vereinbaren und deren Einhaltung zu überwachen. 1.2 Ziel des Richtliniendokuments Das Ziel dieses Richtliniendokuments ist es, eine praktische Referenz zu bieten, damit Unternehmen sowie Business-Entscheider, bei der Analyse und Erstellung von Cloud Service Level Agreements (SLA) zu helfen. Dabei werden Leitlinien vorgestellt, welche bei der Erstellung von SLAs helfen sowie wie existierende SLAs von Cloud Computing-Anbietern zu bewerten sind. Anhand einer präskriptiven Reihe von Schritten wird sowohl die Aushandlung von Konditionen als auch relevante Indikatoren vorgestellt. Besonderer Schwerpunkt liegt dabei neben den traditionellen Key Performance Indicators (KPIs: Leistungskennzahlen) auf der Beschreibung und Definition von Cloud-spezifischen Leistungskennzahlen. Bei spezifischen Cloud SLAs müssen die verschiedenen Provisionierungs-Modelle, Infrastructure as a Service (IaaS), Platform as a Service (PaaS) und Software as a Service (SaaS)), berücksichtigt werden, da jedes Modell individuelle Anforderungen besitzt. Dieses Dokument konzentriert sich vor allem auf die allgemeinen Anforderungen von SLAs zwischen Cloud- Anbieter und Cloud-Verbraucher. Spezielle Anforderungen und Metriken für spezifische Anwendungsgebiete des IaaS-Service-Modell werden ebenfalls erläutert.

2 Service Level Agreement 8 Ziele des Richtliniendokuments: Allgemeine Einführung in SLA Inhalte und Management. Unterstützung bei der Erstellung von SLAs für Cloud Dienste (z.b. VM, Storage, Skallierung, etc.) Beschreibung und Definition von Cloud-spezifischen Service Level Objectives/Leistungskennzahlen. 1.3 Aufbau des Richtliniendokuments Das vorliegende Dokument gliedert sich wie folgt. Kapitel 2 Service Level Agreement gibt neben der Erklärung der wichtigsten Standard Definitionen für SLAs auch eine Einführung der einzelnen Komponenten und Inhalte eines SLAs. In Kapitel 3 Service Level Objectives wird der Aufbau und Inhalt, sowohl wie eine Gruppierung dieser SLA Inhalte vorgestellt. Kapitel 4 gibt eine Übersicht der für die meisten SLAs anwendbaren allgemeingültigen KPI Metriken. In Kapitel 5 werden die wichtigsten Metriken für Cloud SLAs angegeben und beispielhafte Cloud Service SLAs gezeigt an denen der praktischen Einsatz dieser Richtlinien vorgestellt werden. 2 Service Level Agreement Service Level Agreements (SLAs) bzw. Dienstgütevereinbarungen legen die zugesicherten d.h. zu erwartenden Leistungseigenschaften zwischen Dienstleister und Kunden fest. Einen wesentlichen Bestandteil stellt dabei die genaue Beschreibung der Dienstgüte (Service Level) dar. Nachfolgend werden die wichtigsten Voraussetzungen, Inhalte und der Aufbau von Service Level Agreements beschrieben. 2.1 SLA Lebenszyklus Der Lebenszyklus eines Service Level Agreements umfasst mehrere Schritte welche zur erfolgreichen Nutzung von SLAs notwendig sind[sxl05]. Es gibt verschiedene Ansichten darüber, ob die Definition des SLAs zu dessen Lifecycle zählt oder nicht, da dieser auch zu den Vorbedingungen gezählt werden kann (vgl. [HKK + 07] und [GFD07]). Abbildung 1 zeigt den SLA Lifecycle. Nachfolgend werden die einzelnen Phasen kurz beschrieben: Definition: In der Definitionsphase muss sich der Kunde sich über alle relevanten Daten der zur regelnden Dienstleistung im klaren sein. Die Definition umfaßt die Erstellung der SLA-Vorlage und die Suche nach einem geeigneten Provider. Verhandlung: In der Verhandlungsphase wird dann anhand der SLA-Vorlage mit dem gewählten Provider die zu erbringenden Leistungen und Service Level ausgehandelt, sowie den dafür zu entrichteten Kosten festgelegt.

2 Service Level Agreement 9 SLA SLA Lebenszyklus - Abgrenzung und Beschreibung der Dienstleistung - Definition der Service Levels... - Aushandlung von Preisen - Vereinbarungen mit Provider... - Anpassung an Organisation - Kommunikation des SLA... - Ermitteln / Messen der Service Levels - Erzeugen von Berichten - Steuerung der Service Qualität... - Auswertung der Ergebnisse - Analyse von Abweichungen - Ermitteln des Zielerreichungsgrads... Abbildung 1: SLA Lebenszyklus Implementierung: Die Implementierungsphase stellt das Inkrafttreten der Vereinbarung durch die Unterschriften der beiden Partner dar. Hierbei werden die Vereinbarungen kommuniziert und die zu erbringenden Dienstleistung bereitgestellt und in die Organisationen eingepasst. Nutzung: In der Nutzungsphase werden die Laufzeitdaten durch das Monitoring gesammelt und die erbrachten Service Levels überprüft. Durch Berichte wird der Status der Dienstleistung unter den Partner kommuniziert und die Erfüllung der Service Levels dokumentiert. Kontrolle: In der Kontrollphase werden die erreichten Ergebnisse analysiert, der Zielerreichungsgrad gemessen und eventuelle Abweichungen ermittelt sowie daraus resultierende Maßnahmen abgeleitet. Die Ergebnisse dieser Analysen dienen zum einen wieder als Input für die Anpassungen des SLAs zum anderen erfolgen hier auch die Aktionen wie Terminierung oder Konsequenzen bei Nichteinhaltung. 2.2 SLA Voraussetzungen Der Entwurf von Service Level Agreements stellt gewisse Voraussetzungen an Kunden und Provider. Diese müssen in der Lage gewisse Anforderungen zu erfüllen um erfolgreich SLAs definieren zu können. Die im Vorfeld an den Kunden gestellten Anforderungen beim Entwurf von Service Level Agreements werden hier kurz aufgeführt. Ein Kunde muss die Rollen und Verantwortungen verstehen, die durch einen SLA geregelt werden. in der Lage sein, die zu regelnde Dienstleistung exakt und spezifisch beschreiben und abgrenzen zu können.

2 Service Level Agreement 10 die Anforderungen der zu regelnden Dienstleistung kennen, und die dazu passenden Kennzahlen definieren. die kritischen Leistungsmerkmale der Dienstleistung kennen, und basierend darauf Service Levels spezifizieren. den Prozess und Ablauf der geregelten Dienstleistung verstehen. Diese Anforderungen sind notwendig damit ein Kunde in der Lage ist bei der Erstellung des SLAs die Bedürfnisse richtig zu setzen und Tragweite seiner Entscheidungen zu verstehen. Ferner sollte ein SLA folgende Aufgaben erfüllen: Die Dienstleistung exakt beschreiben. Die zu erbringenden Leistungen ausführlich darstellen. Die Kennzahlen, Metriken und Service Levels ausführlich beschreiben. Die Kosten transparent aufschlüsseln. Die Konsequenzen bei Nichteinhaltung angeben. Das Berichtswesen und die Kommunikation definieren. Eskalationsverfahren und Konfliktlösungen beinhalten. Reglungen zur Kontrolle und Anpassung enthalten. Die Anforderungen an Lesbarkeit, Verständlichkeit, Vollständigkeit und Eindeutigkeit erfüllen (vgl. [Sch01]). Kunden-orientiert sein. 2.3 Aufbau von SLAs Der Aufbau von Service Level Agreements ist generell sehr Szenario spezifisch und kann somit nur sehr schlecht verallgemeinert werden. Jedoch gibt es einige grundlegende Elemente die in jedem SLA vorhanden sein sollten. Die nachfolgenden Ausführungen sollen nicht dazu dienen einen universellen Muster-SLA zu erstellen, sondern vielmehr eine Richtlinie für wichtige Inhalte eines SLAs geben. Die Elemente eines SLAs lassen sich laut [Ber05] in folgende vier Gruppen einordnen: Vereinbarungsbezogene Elemente (siehe Kapitel 2.3.1) regeln grundsätzliches, wie beispielsweise den Gerichtsstand, Haftung, etc. Dienstleistungsbezogene Elemente (siehe Kapitel 2.3.2) beschreiben die Dienstleistung näher, wie beispielsweise Inhalt, Qualität, Kosten, etc.

2 Service Level Agreement 11 Managementbezogene Elemente (siehe Kapitel 2.3.3) regeln SLA Verwaltung und Steuerung, wie beispielsweise Berichtswesen, Konsequenzen bei SLA-Abweichung, Konfliktlösung, etc. Dokumentbezogene Elemente (siehe Kapitel 2.3.4) beschreiben administrative und redaktionelle Inhalte, wie beispielsweise Handhabung, Lesbarkeit, Versionierung, etc. Nachfolgend wird kurz auf die Inhalte dieser Gruppen eingegangen und deren Elemente für SLAs ausführlich beschrieben. Abbildung 2 zeigt eine Übersicht der Gruppen und deren einzelne Inhalte. Abbildung 2: SLA-Elemente laut [Ber05] 2.3.1 Vereinbarungsbezogene Elemente Als vereinbarungsbezogene Elemente werden die Elemente bezeichnet die sich mit der grundsätzlichen Regelung der Vereinbarung befassen. Die Gruppe dieser Elemente wird dabei von [Ber05] nochmals in Grundelemente und juristische Elemente untergliedert. Letztere kommen

2 Service Level Agreement 12 nur bei externen SLAs zum Einsatz. Externe SLAs sind alle SLAs die zwischen zwei unabhängigen Personen, Unternehmen oder Institutionen geschlossen werden. Interne SLAs stellen dabei die Sonderform der innerbetrieblichen Vereinbarung dar die im Bereich des Cloud Computings eher selten anzutreffen sind. Die juristischen Elemente regeln den Gerichtsstand, das anwendbare Recht, Schutzrechte, Haftung und Gewährleistung, Schadensersatz, usw. und sind für die Beziehung zwischen Kunde und Provider wichtig. Da sich diese Juristischen Elemente nicht von denen herkömmlicher Verträge unterscheiden wird hier nicht tiefer auf diese eingegangen. Eine ausführliche Beschreibung kann in [Mei00] gefunden werden. Die Grundelemente umfassen den Gegenstand des SLAs, Ziele, Partner, sowie den Geltungsbereich, Inkrafttreten, Laufzeit und Beendigung des SLAs. Häufig werden diese Elemente in der Praxis in Form einer Präambel oder Einführung dargestellt. Der Gegenstand des SLAs beschreibt dabei einleitend den Inhalt und Kontext sowie eine Beschreibung und Abgrenzung der durch den SLA zu regelnden Dienstleistungen. Die Ziele des SLAs geben die spezifischen Ziele der beiden Parteien wieder und dienen, unter anderem, als Basis für eine spätere Erfolgskontrolle. Die Partner des SLAs spezifiziert den Leistungsgeber bzw. Dienstleister oder Provider und den Leistungsnehmer bzw. Kunde mit Namen, Unternehmen und Adresse. Es ist durchaus üblich in der Beschreibung der Partner diese für den Verlauf des SLAs als mit generischen Bezeichnungen wie Kunde und Provider zu betiteln. Der Geltungsbereich ermöglicht es die Gültigkeit bzw. Anwendbarkeit des SLAs auf z.b. geographische oder organisatorische Einheiten zu beschränken. Dies ermöglicht es individuelle Reglungen für verschiedenen Standorte vorzunehmen. Die Reglung zur Beendigung gibt an ob und wie am Ende der Laufzeit eines SLAs gekündigt werden muss oder ob beispielsweise eine automatische Verlängerung stattfindet. Ebenso werden hier die Rechte und Pflichten die bei der Beendigung des SLAs in Kraft treten und die Regelungen für eine außerordentliche Kündigung aufgeführt. 2.3.2 Dienstleistungsbezogene Elemente Die Dienstleistungsbezogenen Elemente stellen jene Elemente dar, welche die Regelung einer Dienstleistung beschreiben. Sie müssen für jede Dienstleistung einzeln spezifiziert werden. Nach [Ber05] werden diese in die Dimensionen Inhalt, Qualität und Kosten gruppiert. Diese drei Dimensionen stehen im direkten Zusammenhang und haben direkte Auswirkungen aufeinander. Inhalt: Im Inhalt der Dienstleistung beschreibt eine Dienstleistungen mit all ihren Teilleistungen und deren Ablauf. Dabei ist grundsätzlich zu beschreiben wer, wann, wo, und welche Leistungen erbringt. Die Beschreibung der Dienstleistung sollte dabei allgemein Verständlich sein. Besonders bei IT-Dienstleistungen ist drauf zu achten technische Fachbegriffe zu vermeiden oder zu erklären. Die Beschreibung der Dienstleistung sollte stets eine Bezeichnung enthalten, welche als eindeutige Referenz dient. Dabei sollte stets eine aussagekräftige Bezeichnung gewählt werden. Ebenso ist eine verbale Beschreibung der Dienstleistung, welche die grundlegende Aspekte und Leistungen sowie die zu erwartenden Ergebnisse wiedergibt Inhalt

2 Service Level Agreement 13 der Dienstleistungsbeschreibung. Kunden sollte es möglich sein aus diesen Beschreibungen klar zu erkennen, ob die angegebene Reglung der von ihm erwarten Dienstleistung und Ziele entspricht. Zusammen mit einer komplette und ausführliche Darstellung aller Einzelleistungen, die zur Erbringung der Dienstleistung gehören, bildet dies den Kern der inhaltlichen Elemente. Diese kann bei großen oder komplexen Dienstleistungen auch den Ablauf bzw. Prozess der Diensterbringung enthalten um diesen besser strukturiert darzustellen. Rahmenbedingungen fließen zusätzlich in die inhaltliche Dienstbeschreibung ein. Diese umfassen beispielsweise eine Beschreibung der Systemumgebungen bei IT-Dienstleistungen, welche z.b. die Art der Infrastruktur oder die Auswahl der Anwender regelt. Ebenso werden hier besondere Bedingungen geregelt die unter anderem die Mitwirkung des Kunden betreffen oder spezielle Anforderungen des Kunden. Ein weiterer Punkt kann die Negativabgrenzung sein, welche dazu dient, den Inhalt der beschriebenen Dienstleistung besser von anderen Dienstleistungen zu unterscheiden, in dem nicht enthaltene Leistungen aufgeführt werden. Qualität: Der Beschreibung Qualität einer Dienstleistung kommt in einem SLA eine zentrale Rolle zu, da hier der zu erbringende Zustand genau spezifiziert wird. In SLAs wird die Qualität der Dienstleistung durch Leistungskennzahlen definiert, welche die Basis für Service Level Objectives (SLOs) sind. Diese Kennzahlen enthalten neben einer Bezeichnung auch die Berechnungsweise oder Metrik, sowie einen Bezugsbereich und Messort. In Abschnitt 2.6 wird der grundlegende Aufbau und Inhalt von Kennzahlen explizit dargestellt und Cloud-spezifische Service Level Objectives (siehe Kapitel 3) sind der Schwerpunkt dieses Dokumentes. Neben der Beschreibung der Kennzahlen werden bei der Definition der Qualität einer Dienstleistung die Service Levels spezifiziert. Diese geben die vom Kunden erwartete Dienstgüte an und stellen somit den Soll-Wert bei der Erfolgsprüfung dar. Zusätzlich werden Restriktionen für die Einhaltung der Service Levels im Sinne der Erfüllung durch den Anbieter aufgeführt. Diese umfassen meist Regelungen für höhere Gewalt wie beispielsweise Naturkatastrophen oder ähnliches. Im Sinne des Kunden sollten diese Ausnahmen jedoch gering gehalten werden. Kosten: In der Dimension der Kosten werden die durch die Erbringung der Dienstleistung in der beschriebenen Dienstgüte entstehenden Kosten für den Kunden beschrieben. Dabei wird ein Preismodell für die zu beziehenden Leistungen angegeben, welches einen fixen oder variablen Preis enthalten für den jeweiligen Abrechnungszeitraum enthält. Bei einem fixen Modell wird der Preis unabhängig vom Umfang der bezogenen Leistungen definiert. Beim variablem Modell besteht eine Abhängigkeit zur konkreten Nutzung. Dabei wird anhand von Verrechnungseinheiten ein Preis festgelegt, welcher dann über eine Formel mit den anhand der echten Nutzungsdaten die Kosten ergibt.

2 Service Level Agreement 14 2.3.3 Managementbezogene Elemente Die managementbezogenen Elemente umfassen nach [Ber05] die Aspekte, welche mit der Verwaltung und Steuerung eines SLAs zu tun haben. Diese stellen einen sehr wichtigen Abschnitt im Inhalt eines SLAs dar, da hierbei sowohl die Benachrichtigung des Kunden und das Vorgehen bei Problemen oder der Nichteinhaltung der Service Levels geregelt werden. Ferner werden Sanktionen und Entschädigungen, welche im Falle eines Schadens durch Abweichungen vom Service Level eintreten können, geregelt. Berichtswesen: Berichte stellen den grundlegenden Informationsaustausch zwischen Kunde und Anbieter dar und sind somit essenziell. Ebenso dienen diese im Fall der Nichterbringen eines Service Levels zur Dokumentation und als Grundlage für Aktionen. Die Reglungen zum Berichtswesen erfassen alle Inhalte zur Dokumentation, Überprüfung, Benachrichtigung und Kommunikation. Für das Management und die Steuerung der vom SLA beschrieben Dienstleistungen is es notwendig kontinuierlich über den Erreichungsgrad, d.h. die tatsächlich erreichten Service Levels informiert zu werden. Hierfür sollten im SLA sog. Service Level Berichte definiert werden, welche den Erfüllungsgrad der Service Level für den betrachteten Zeitraum dokumentieren. Basierend auf diesen Berichten kann die Steuerung des SLAs durchgeführt werden. Ebenso können diese zur Bemessung der Konsequenzen bei Nichteinhaltung eines Service Levels herangezogen werden. Diese Berichte können aus verschiedenen Anlässen heraus generiert werden. So macht es zum Beispiel sinn einen gesonderten Bericht für Zwischenfälle (engl. Incidents) zu haben, welcher Kunden sofort über Probleme in der Einhaltung der Service Level informiert. Regelmäßige Berichte in einem zeitlich festgelegten Intervall stellen dabei sicher, dass ein Kunde zu jedem Zeitpunkt über den Stand und Erfüllungsgrad seiner Service Level informiert ist. Bei der Definition solcher Berichte muss der Auslöser bzw. die Frequenz oder Termin für Erstellung und Übermittlung des Berichts definiert werden. Des weiteren muss der Empfänger und Ersteller des Berichts festgelegt werden. Berichte können sowohl an die jeweiligen Partner als auch an einzelne Personengruppen gerichtet sein. Die genau Angabe des Auslösers, Berichtstermins bzw. der Frequenz in der die Berichte erstellt werden, hilft zum einen dabei eine Einteilung der Berichte für spezielle Aufgaben bzw. verschiedenen Informationsbedarf vorzunehmen. Zum anderen kann hier sehr fein reguliert werden wie viel Informationen dem Kunden zugestellt werden. Ein gutes Berichtswesen überflutet den Kunden nicht mit Informationen lässt zugleich jedoch auch keine Informationslücken aufkommen. Eine klare Definition der Berichtsinhalte, des Berichtsaufbaus, der Darstellung und des Layout ermöglichen es dem Kunden die Berichte genau nach seinen Vorstellungen zu gestalten. Hierbei werden unter anderem die relevanten Kennzahlen, die angefallenen Kosten, das Nutzungsvolumen etc. und deren Detaillierungsgrad angegeben. Als wichtige Grundinformation muss der Bezugszeitraum für den Bericht angegeben werden, da sich alle Berechnungen und Überprüfungen die angegeben werden immer auf diesen beziehen. Abschließend sollte die Übermittlungs-

2 Service Level Agreement 15 art, das Medium und Dateiformat für den Bericht festgelegt werden um eine effektive Kommunikation zwischen den Partner zu ermöglichen. Konsequenzen bei Abweichungen von Service Levels: Der Erbringungsgrad der geregelten Dienstleistung kann unter Umständen von den vereinbarten Servie Level abweichen. Aus diesem Grund werden die Konsequenzen für eine solche Nichterbringung im SLA festgelegt. Als Grundlage für die Bemessung dient der Soll-Ist-Vergleich der die erreichten Service Level der Kennzahlen mit den festgelegten Service Level vergleicht. Die Reglungen der Konsequenzen müssen dabei klar spezifizieren wann diese zu einer eindeutigen Anwendung kommen und welche Bedingung als Auslöser für die Konsequenz erfüllt sein muss. Zusätzlich sollten dabei klar definierte Stufen (Eskalationsstufen) angegeben werden, welche jeweils mit konkreten Beträgen unterfüttert sind. Die Art und Höhe dieser Stufen muss dabei immer in einem angemessenen Verhältnis zur Abweichung vom Service Level und dem Nutzen der Dienstleistung stehen. Die Konsequenzen lassen sich dabei in zwei Gruppen unterteilen. Zum einen die Sanktionen bzw. Malus die bei der Nichterbringung des Service Levels zum Einsatz kommen. Zum anderen Boni, die bei Übererfüllung der definierten Service Level dem Anbieter angerechnet werden können. In der Praxis gibt es zu Boni in SLAs sind geteilte Meinung. Bei [Ber05] werden diese als Teil des SLAs vorgestellt, während bei anderen wiederum darauf verzichtet wird. Inzwischen tauchen diese Boni Reglungen aber immer häufiger in SLAs auf, da viele Kunden dem Anbieter einen Anreiz für besonders gute Leistungen zu geben wollen. Diese Boni können sowohl in monetärer Form, d.h. als zusätzliche Zahlungen als auch nicht monetär Form sein, wie besondere Rechte oder Befugnisse. Dies kann beispielsweise das Recht zur Werbung mit dem Namen des Kunden darstellen. Sanktionen oder Malus gliedern sich genau wie die Boni in monetäre und nicht-monetäre Formen. Dabei wird jedoch zusätzlich nach dem verschulden unterschieden. Sind die Sanktionen verschuldensabhängig definiert so muss unter anderem nachgewiesen werden, dass die Nichterbringung des Service Levels durch ein Ereignis ausgelöst wurde, dass der Anbieter zu verursachen hat. Im Sinne eines Kunden ist es daher die definierten Sanktionen verschuldensunabhängig zu gestalten, da hier im Falle der Nichterbringung nicht erst noch der Nachweis über das Verschulden erbracht werden muss. Anbieter hingegen bevorzugen verschuldensabhängige Reglungen da hierbei nur für ihr eigenes Verschulden das Risiko getragen werden muss. Monetäre Sanktionen dienen hierbei immer Ausgleich für die entgangene Dienstgüte und werden für gewöhnlich als Minderung oder Ausgleichszahlung realisiert. In besonderen Fällen können auch Vertragsstrafen definiert werden welche für den entgangenen Nutzen des Kunden entschädigen. Die Bemessung solcher monetärer Sanktionen sollte dabei immer abhängig von der entgangenen Dienstgüte bzw. der Höhe des Schadens für den Kunden durch Nichterfüllung des Service Levels sein. Nicht-monetäre Sanktionen stellen besondere Aktionen und Rechte dar. Diese können so beispielsweise einen Sonderkündigungsrecht einräumen oder den Anbieter dazu verpflichten außerordentliche Treffen mit dem Kunden zur Behebung der Abweichung darstellen. Auch können dem Kunde Rechte zur Durchführung von Überprüfungen und Audits eingeräumt werden

2 Service Level Agreement 16 oder die Reglung über Ersatzvorname im Falle der Nichterbringung definiert werden. Diese Reglungen gestalten sich in der Praxis als äußerst heikel und bedürfen dem juristischen Verständnis. In der Regel lassen sich diese also nicht ohne Zuhilfenahme eines Anwalts regeln. Lösung von Konflikten: Bei der Nutzung von Dienstleistungen können Konflikte auftreten. Um diese in geregelter Art und Weise zu lösen bedarf es definierter Eskalationsverfahren bzw. Schlichtungsverfahren. Hierbei werden je nach Art des Konflikts die beteiligten Instanzen, Prozesse, sowie die Informations- und Benachrichtigungswege definiert. Hieraus lässt sich Weg bei einer Problemlösung ableiten. Kontrolle des SLAs: Die Kontrolle stellt einen wichtigen Prozess im Lebenszyklus des SLAs dar. Hierbei wird in gewissen Abständen die vorhandenen Reglungen auf sich die im Laufe der Zeit geänderten Anforderungen oder Änderungen im Umfeld überprüft. Dieser Prozess wird auch SLA Audit genannt. Ziel dabei ist es den SLA immer best möglich an die Zielsetzung bzw. Kundenerwartungen für die Dienstleistung angepasst zu haben. Dafür werden die Regelmäßigkeit, der Umfang und die Teilnehmer der Audits festgelegt. Die Dabei gewonnenen Erkentnisse fließen anschließend wieder in den revidierten SLA ein. Änderung des SLAs: Um einen SLA zur Laufzeit anpassen zu können, um z.b. auf die Ergebnisse eines SLA Audits einzugehen und den SLA wieder optimal an die geänderten Bedingungen anzupassen, ergibt sich die Notwendigkeit Änderungen vor zu nehmen. Damit diese Modifikationen geregelt Ablaufen können sollten die Möglichkeiten der Änderung, die Benachrichtigungen und der Informationsfluss im Fall einer Änderung spezifiziert werden. Verrechnung der erbrachten Dienstleistungen: Inhalte zur Verrechnung der erbrachten Dienstleistungen enthalten die Informationen zu Art und Gestaltung der Rechnungen, sowie deren Zahlungsmodalitäten. Hierbei werden die Zahlungswege, Fristen, Detailgrad der Angaben und Aufbau der Rechnung definiert. 2.3.4 Dokumentbezogene Elemente Dokumentbezogene Elemente können nach [Ber05] in administrative und redaktionelle Elemente gegliedert werden. Allgemein gilt für beide Gruppen, dass diese im SLA nur eine untergeordnete Rolle spielen und hauptsächlich der Handhabung, Verständnis und Lesbarkeit dienen. Administrative Elemente stellen so beispielsweise die Versionierung, das Datum der letzten Änderung oder die Versionshistorie dar. Unter redaktionellen Element verstehen sich Dinge wie das Inhaltsverzeichnis, der Index oder das Glossar. Diese Elemente erhöhen die Lesbarkeit indem sie den Kontext untermauern und Hintergrund erläutern.

2 Service Level Agreement 17 2.4 Standards Die folgenden Standards, dienen im wesentlichen zur Steuerung oder Definition der Prozesse, welche innerhalb des IT Service Management benötigt werden. Jedoch gibt es keinen klar definierten Standard für die Erstellung eines SLA. Um diesen aber gerecht zu werden sollten die vordefinierten Prozesse hierbei Beachtung finden. Um eine gute Integration und reibungslosen Ablauf im IT Service Management zu gewährleisten. 2.4.1 ITIL v3 Die IT Infrastructure Library (ITIL v3) ist ein weltweit anerkannter Best Practice Framework, welcher definierte Prozesse und deren Kontrollorgane vorgibt, um die IT innerhalb eines Unternehmens zu organisieren und zu steuern. Von der reinen Hardware Organisation bis zur stetigen Verbesserung und Optimierung werden innerhalb der ITIL v3 Möglichkeiten aufgezeigt dieses zu regeln. Auf diese Weise wird innerhalb eines Unternehmens die Transparenz geschaffen und eine klare Übersicht über die genauen Kosten gegeben. ITIL v3 gliedert sich in fünf Bereich, Service Strategy, Service Design, Service Transision, Service Operation und Continual Service Improvment. Im Service Design wird innerhalb des Service Level Management folgende Komponenten für den Inhalt einer SLA beschrieben. Die eindeutige Bezeichnung des Services. Eine genaue Freigabeinformationen mit Ort und Datum, dem zuständigen Service Manager und verantwortlicher Ansprechpartner auf Kundenseite. Die gesamt Laufzeit des Vertrages mit Beginn- und Enddatum, sowie Regularien für ein etwaige Verlängerung, Beendigung und vorzeitige Beendigung des Vertrages. Klare Beschreibung für das angestrebte Ergebnis des Kunden, mit dem Nutzen und Gewährleistung, welche der Kunde aus Geschäftssicht hat. Dazu gehören die Business- Prozessen und Aktivitäten, welche vom Service unterstützt werden sollen und eindeutige Ergebnisse wie z.b.: Zugriff von Außendienstmitarbeitern auf Unternehmensdaten oder die Verfügbarkeit zu Geschäftszeiten. Die geregelten Kommunikationswege zwischen Kunde und Service-Provider, mit Verantwortlichen, bzw. Kontaktpersonen und Business Relationship Manager. Wie Service- Berichte erstellt werden mit Inhalt und Intervallen. Ein Verfahren wie Ausnahmen und Beschwerden behandelt werden, mit genauen Angaben zu Antwortzeiten, Eskalationsprozess und die dazu bereitzustellende Information an den Kunden. Eine Kundenumfrage zur Ermittlung der Zufriedenheit und regelmäßige Service-Reviews mit dazugehörigem Prozess. Eine Liste kritischer Assets welche sich auf die Services auswirken und der damit verbundene geschätzte Schaden, wenn es zu einen Verlust des Asset oder Service kommt. Dieser ist in finanziellen Beträgen oder einen Klassifizierungsschema deutlich zu machen..

2 Service Level Agreement 18 Die Servicezeiten, welche genau angeben, wann der Service zur Verfügung stehen muss und die geregelten Ausnahmen, wie z.b. Wochenende oder Feiertage. Erforderliche Support-Typen und -Levels, welche vom Service Provider geleistet werden sollen, wie z.b. Vor-Ort-Service, Remote-Service und welche Bereich und evtl. Standorte diese betreffen. Mit Angabe von Reaktions- bzw. Lösungszeiten, welche nach Priorität und Definition der Priorität (zur Einordnung von Incidents ) gegliedert sind. Die Service-Level-Anforderungen/ -Ziele welche beschreiben ab wann ein Service z.b. als nicht verfügbar gilt. Hierzu werden klare Ziele die, die Basis zur Berechnung des Verfügbarkeits-Level angeben anhand von Ausfall- und Servicezeiten. Auch Wartung, Wartungszeiten, Zuverlässigkeit, Major Incidents, Notfall-Changes und Releases zur Behebung sowie die zugehörigen Prozesse für den Ablauf. Das Availabilitiy- Reporting, Businesszyklen, Anzahl User und Transaktionen, Skalierbarkeit, Antwortzeiten der Anwendung und die Maßnahmen und Zeiten bei einen Katastrophenfall, welche benötigt wird um den Service wieder vollständig im geforderten Umfang herzustellen. Auch gehören die genutzten technischen Schnittstellen und Spezifikationen noch dazu um Fehlerquoten auszuschalten. Den Schluss bilden hier die Verantwortlichkeiten und das Preismodell. Um das entstandene Dokument für alle Beteiligen eindeutig und nachvollziehbar zu machen, wird eine Change-History, Liste mit den Anhängen und Verweisen so wie ein Glossar geführt. 2.4.2 ISO 20000 Die Norm ISO/IEC 20000 beschreibt die Anforderungen, die für IT-Service-Management erbracht werden müssen. Es ist dort ein gemeinsamer Referenzstandard dokumentiert, wie die Prozesse in Unternehmen definiert zu sein haben, die IT-Services für interne und externe Kunden zur Verfügung stellen. Hierbei kommt auch der integrierte Prozessansatz aus dem Service Management Framework von ITIL zum Tragen. Dieser gilt als Richtlinie und wird auch teilweise ergänzt. Mit ITIL wird den Service Providern eine Sammlung von Best Practice and die Hand gegeben, um qualitativ hochwertige Leistungen zu garantieren zu können. Die Norm ISO 20000 beinhaltet also des Qualitätsmaß, welches für Service Provider erreicht werden muss. Für Organisationen und Organisationseinheiten kann eine Zertifizierung erworben werden. Dieses Zertifikat muss alle drei Jahre erneuert werden. 2.4.3 COBIT Mit COBIT (Control Objectives for Information and Related Technology) wird ein international anerkannter Framework für IT-Governance zur Verfügung gestellt. Dieser Leitfaden wird von dem IT Governance Institute, eine Schwesterorganisation der ISACA, gewartet und weiterentwickelt. Der Einsatz von COBIT sorgt für Gewährleistung der Sicherheit, Qualität und Ordnungsmäßigkeit in der IT. Es gliedert die Aufgaben in der IT in Prozesse und Kontrollziele. In COBIT wird beschrieben welche Anforderungen umgesetzt werden müssen, allerdings nicht wie dieses implementiert werden sollte. Dadurch ist es aus Unternehmenssicht ein