SLA-Richtliniendokument Für Cloud Dienstleistungen PDF

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 Pro-
jekts (Laufzeit: 01. Oktober 2012 – 30 September 2015 ) ist das selbständige, automatische
Management von Dienstgütevereinbarungen in Cloud-Umgebungen. Dienstgütevereinbarun-
gen (Service Level Agreements: SLAs) beschreiben dabei die Leistungsqualität (Quality of
Service: QoS) der bezogenen Cloud Services welche zwischen Kunde und Dienstleister aus-
gehandelt werden. Die Nutzung von Cloud Services bietet gerade kleinen und mittelständi-
schen 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 zu-
sätzlicher Ressourcen. Diese speziellen Cloud-spezifischen Mechanismen sollen untersucht
werden, mit dem Ziel, in einem bestimmten Rahmen die Servicequalitäten besser einzuhal-
ten. 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, Magnetsyste-
men 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
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
Glossar
Cloud-Anwender Cloud-Anwender ist jede natürliche oder juristische Person, die von Be-
troffenen personenbezogene Daten erhebt, verarbeitet oder nutzt und hierfür von ande-
ren Stellen IT-Dienstleistungen für Cloud-Services in Anspruch nimmt. [Arb11]
Cloud Host Physikalischer Computer, auf dem mittels Hypervisorsoftware virtuelle Ma-
schinen 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- An-
bieter hierfür die Ressourcen, so kann dieser zur Erfüllung seiner Verpflichtungen ge-
genüber dem Cloud-Anwender u. U. weitere Unter-Anbieter einbeziehen. [Arb11]
Datenschutz Personenbezogene Daten werden besonders geschützt und nur unter den Ge-
sichtspunkten des Datenschutz verarbeitet (erzeugt, gespeichert, übermittelt, gelöscht).
Die informationelle Selbstbestimmung der beteiligten natürlichen Personen wird ge-
wahrt.
Public Cloud IT-Dienstleistungen für Public Clouds werden am freien Markt und nicht in-
nerhalb 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 inter-
nen 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-Dienst-
leistungen 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üg-
barkeit 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 Daten-
speicherung. Sie können nahezu beliebige Anwendungsprogramme und Betriebssyste-
me einsetzen. [Arb11]
Platform as a Service (PaaS) Platform as a Service ermöglicht dem Cloud-Anwender,

auf der vom Cloud-Anbieter angebotenen Infrastruktur, eigene Programme zu entwi-
ckeln und auszuführen. Der Cloud-Anbieter macht hierbei Vorgaben zu den zu verwen-
denden 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-An-
bieter bereit gestellten Anwendungen erfolgt üblicherweise über einen Web-Browser,
kann aber auch mit speziellen Programmen erfolgen, die hauptsächlich über Anzeige-
funktionen verfügen („Thin-Clients“). Die bereitgestellten Anwendungen können allen-
falls 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 Bereitstel-
lung von Ressourcen nach Bedarf etabliert. Für Unternehmen stellt Cloud Computing inzwi-
schen 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 Bundes-
regierung in den High-Tech Strategien 2020 unter dem Bedarfsfeld Kommunikation, Cloud
Computing als wichtiges Handlungsfeld beschrieben. Gerade für KMUs ist zukünftig die Nut-
zung von Cloud Computing zur Wettbewerbssicherung unabdingbar. Die Vorteile von Cloud
Computing liegen dabei vor allem in einer Kostenersparnis durch „pay-per-use“, niedrige In-
vestitionskosten 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 sogenann-
ten 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 erwar-
tenden Leistungen als auch die Verantwortlichkeiten und Aktionen definiert.
Aktuell bieten Cloud Computing Provider ihre Dienste meist nur nach dem Best-Effort Prin-
zip 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ätsgaran-
tien 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 Ge-
rüst, welches gängige Service-Level-Agreements (SLAs), wie beispielsweise die Verfügbar-
keit 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 An-
bieter 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 Compuwa-
re [Cor11] beauftragten Umfrage wieder. Dabei zeigte sich, dass 72% der befragten Unterneh-
men 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 Unter-
nehmens 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, bie-
tet 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 je-
doch auch, dass die Formulierungen locker genug sind, dass der Provider nicht für die Ver-
letzung 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 Unter-
nehmen 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 bewer-
ten 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, Infra-
structure 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 An-
wendungsgebiete des IaaS-Service-Modell werden ebenfalls erläutert.
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 Le-

vel 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 Le-
vel) 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 er-
folgreichen 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 be-
schrieben:
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 ge-
wählten Provider die zu erbringenden Leistungen und Service Level ausgehandelt, sowie
den dafür zu entrichteten Kosten festgelegt.
SLA
SLA Lebenszyklus
- Abgrenzung und - Aushandlung von - Anpassung an Organisation - Ermitteln / Messen der - Auswertung der
Beschreibung der Preisen Service Levels Ergebnisse
Dienstleistung - Kommunikation des SLA
- Vereinbarungen mit - Erzeugen von Berichten - Analyse von
- Deﬁnition der Provider Abweichungen
Service Levels ... - Steuerung der Service
... ... Qualität - 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 Organi-
sationen eingepasst.
Nutzung: In der Nutzungsphase werden die Laufzeitdaten durch das Monitoring gesam-
melt 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 Zielerrei-
chungsgrad gemessen und eventuelle Abweichungen ermittelt sowie daraus resultieren-
de 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.
• die Anforderungen der zu regelnden Dienstleistung kennen, und die dazu passenden
Kennzahlen definieren.
• die kritischen Leistungsmerkmale der Dienstleistung kennen, und basierend darauf Ser-
vice 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 so-
mit 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 wich-
tige 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 bei-

spielsweise den Gerichtsstand, Haftung, etc.
Dienstleistungsbezogene Elemente (siehe Kapitel 2.3.2) beschreiben die Dienstleis-

tung näher, wie beispielsweise Inhalt, Qualität, Kosten, etc.
Managementbezogene Elemente (siehe Kapitel 2.3.3) regeln SLA Verwaltung und Steue-
rung, wie beispielsweise Berichtswesen, Konsequenzen bei SLA-Abweichung, Kon-
fliktlösung, etc.
Dokumentbezogene Elemente (siehe Kapitel 2.3.4) beschreiben administrative und re-

daktionelle 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 ein-
zelne Inhalte.
Abbildung 2: SLA-Elemente laut [Ber05]
2.3.1 Vereinbarungsbezogene Elemente

Als vereinbarungsbezogene Elemente werden die Elemente bezeichnet die sich mit der grund-
sätzlichen Regelung der Vereinbarung befassen. Die Gruppe dieser Elemente wird dabei von
[Ber05] nochmals in Grundelemente und juristische Elemente untergliedert. Letztere kommen
nur bei externen SLAs zum Einsatz. Externe SLAs sind alle SLAs die zwischen zwei unab-
hängigen Personen, Unternehmen oder Institutionen geschlossen werden. Interne SLAs stel-
len 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 Ele-
mente 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 Gel-
tungsbereich, Inkrafttreten, Laufzeit und Beendigung des SLAs. Häufig werden diese Ele-
mente 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 Ab-
grenzung 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. Dienst-
leister 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 individuel-
le 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 auf-
einander.
Inhalt: Im Inhalt der Dienstleistung beschreibt eine Dienstleistungen mit all ihren Teilleis-
tungen und deren Ablauf. Dabei ist grundsätzlich zu beschreiben wer, wann, wo, und
welche Leistungen erbringt. Die Beschreibung der Dienstleistung sollte dabei allge-
mein Verständlich sein. Besonders bei IT-Dienstleistungen ist drauf zu achten techni-
sche 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 grundle-
gende Aspekte und Leistungen sowie die zu erwartenden Ergebnisse wiedergibt Inhalt
der Dienstleistungsbeschreibung. Kunden sollte es möglich sein aus diesen Beschrei-

bungen klar zu erkennen, ob die angegebene Reglung der von ihm erwarten Dienstleis-
tung 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 Dienstleistun-
gen auch den Ablauf bzw. Prozess der Diensterbringung enthalten um diesen besser
strukturiert darzustellen.
Rahmenbedingungen fließen zusätzlich in die inhaltliche Dienstbeschreibung ein. Die-
se umfassen beispielsweise eine Beschreibung der Systemumgebungen bei IT-Dienst-
leistungen, welche z.B. die Art der Infrastruktur oder die Auswahl der Anwender re-
gelt. Ebenso werden hier besondere Bedingungen geregelt die unter anderem die Mit-
wirkung des Kunden betreffen oder spezielle Anforderungen des Kunden. Ein weiterer
Punkt kann die Negativabgrenzung sein, welche dazu dient, den Inhalt der beschriebe-
nen 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 erwarte-
te Dienstgüte an und stellen somit den Soll-Wert bei der Erfolgsprüfung dar. Zusätz-
lich 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 die-
se 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 fi-
xen 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.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 Ab-
schnitt 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 Abweichun-
gen vom Service Level eintreten können, geregelt.
Berichtswesen: Berichte stellen den grundlegenden Informationsaustausch zwischen Kun-

de und Anbieter dar und sind somit essenziell. Ebenso dienen diese im Fall der Nichter-
bringen 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ül-
lungsgrad der Service Level für den betrachteten Zeitraum dokumentieren. Basierend
auf diesen Berichten kann die Steuerung des SLAs durchgeführt werden. Ebenso kön-
nen 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 infor-
miert. 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 regu-
liert werden wie viel Informationen dem Kunden zugestellt werden. Ein gutes Berichts-
wesen überflutet den Kunden nicht mit Informationen lässt zugleich jedoch auch kei-
ne Informationslücken aufkommen. Eine klare Definition der Berichtsinhalte, des Be-
richtsaufbaus, der Darstellung und des Layout ermöglichen es dem Kunden die Berichte
genau nach seinen Vorstellungen zu gestalten. Hierbei werden unter anderem die rele-
vanten Kennzahlen, die angefallenen Kosten, das Nutzungsvolumen etc. und deren De-
taillierungsgrad 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-
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 ge-
regelten Dienstleistung kann unter Umständen von den vereinbarten Servie Level ab-
weichen. 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 ver-
gleicht. 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 (Eskalati-
onsstufen) 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ält-
nis 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 ange-
rechnet 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 dar-
auf 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 Zah-
lungen 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 wer-
den, 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 beson-
deren 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 Son-
derkü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
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 juris-
tischen 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 auftre-
ten. Um diese in geregelter Art und Weise zu lösen bedarf es definierter Eskalations-
verfahren 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 Au-
dits 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 Er-
gebnisse 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 erbrach-

ten Dienstleistungen enthalten die Informationen zu Art und Gestaltung der Rechnun-
gen, sowie deren Zahlungsmodalitäten. Hierbei werden die Zahlungswege, Fristen, De-
tailgrad der Angaben und Aufbau der Rechnung definiert.
2.3.4 Dokumentbezogene Elemente

Dokumentbezogene Elemente können nach [Ber05] in administrative und redaktionelle Ele-
mente gegliedert werden. Allgemein gilt für beide Gruppen, dass diese im SLA nur eine un-
tergeordnete 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.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 de-
finierten 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 Un-
ternehmens zu organisieren und zu steuern. Von der reinen Hardware Organisation bis zur
stetigen Verbesserung und Optimierung werden innerhalb der ITIL v3 Möglichkeiten aufge-
zeigt 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 Manage-
ment 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 Ma-
nager 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 Ge-
wä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 eindeu-
tige 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 Ver-

antwortlichen, 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, Eskalations-
prozess und die dazu bereitzustellende Information an den Kunden. Eine Kundenumfra-
ge zur Ermittlung der Zufriedenheit und regelmäßige Service-Reviews mit dazugehöri-
gem Prozess.
• Eine Liste kritischer Assets welche sich auf die Services auswirken und der damit ver-
bundene geschätzte Schaden, wenn es zu einen Verlust des Asset oder Service kommt.
Dieser ist in finanziellen Beträgen oder einen Klassifizierungsschema deutlich zu ma-
chen..
• 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 wer-
den 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- Repor-
ting, 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 nachvoll-
ziehbar 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 er-
bracht 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 Kun-
den 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 teil-
weise 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 internatio-
nal anerkannter Framework für IT-Governance zur Verfügung gestellt. Dieser Leitfaden wird
von dem IT Governance Institute, eine Schwesterorganisation der ISACA, gewartet und wei-
terentwickelt. 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 Kontroll-
ziele. In COBIT wird beschrieben welche Anforderungen umgesetzt werden müssen, aller-
dings nicht wie dieses implementiert werden sollte. Dadurch ist es aus Unternehmenssicht ein
Werkzeug für die Steuerung der IT, welches auch als Modell zur Sicherstellung der Einhaltung
gesetzlicher Anforderungen angesehen werden kann.
Da COBIT stark an COSO (Committee of Sponsoring Organisations of Tradeway Commis-
sion), dem Rahmenwerk für interne Kontrollen im Unternehmen, angelehnt ist, gewährleistet
es die Integration der IT Governance in die Corporate Governance. Das dieses Konzept funk-
tioniert, zeigt sich an seiner weiten Verbreitung weltweit. Das Prozessmodell von COBIT
beinhaltet 34 Prozesse, die in der IT implementiert werden sollte. Diese unterteilen sich in
Planung, Entwicklung, Betrieb und Monitoring.
2.4.4 SOUSIS-Modell
Das SOUSIS-Modell ist eine Entwicklung von Robert Scholderer (Robert Scholderer/Management
von Service-Level-Agreements: Methodische Grundlagen und Praxislösungen mit COBIT,
ISO 20000 und ITIL/ISBN: 978-3-89864-702-1/dpunkt.Verlag/Erschienen Juni 2011), die in
über 15 Jahren in der Praxis entstanden ist. Dieses Modell unterstützt den Service-Level-
Manager bei seiner Tätigkeit, Vereinbarungen für ausgelagerte IT-Services zu erstellen.
Das Akronym des Modellnamens SOUSIS schlüsselt sich dabei wie folgt auf:
• S - SLA (Service Level Agreement)
• O - OLA (Operational-Level-Agreement) innerbetriebliche Vereinbarungen
• U - UC (Underpinning Contract) IT-Services von Drittanbieter
• S - Servicekatalog
• I - IT-Rahmenvertrag
• S - Service-Level-Kalkulator
Mithilfe von SOUSIS ist es möglich, einen SLA-Framework analog der Forderung von COBIT
aufzubauen.
2.5 Rollen
Damit in einem SLA Personen, Organisationen oder Einrichtungen genau spezifiziert werden
können bedarf es einer klaren Rolleneinteilung. Kunden müssen sich im Vorfeld einer SLA
Verhandlung ein klares Verständnis über die Rollen und Aufgaben der beteiligten Parteien
aneignen.
Beim Cloud Computing lassen siche unterschiedliche Rollen spezifizieren. Das National
Institute of Standards and Technology (NIST) Referenz Architecture[LTM+ 11] identifiziert 5
spezielle Cloud Akteure, welche nachfolgend kurz erläutert werden:
• Cloud-Consumer: Die Person oder Organisation, die eine Geschäftsbeziehung mit Cloud-
Anbietern pflegt und deren Dienste nutzt.
• Cloud-Provider: Die Person,Organisation oder Einrichtung die dafür verantwortlich ist,

einen Dienst dem Cloud-Consumer zur Verfügung zu stellen.
• Cloud-Carrier: Der Vermittler, welcher die Konnektivität und den Transport von Cloud-
Services von Cloud-Providern zu Cloud-Consumern bereitstellt.
• Cloud-Broker: Eine Organisation, die die Nutzung, Leistung und Lieferung von Cloud-
Services verwaltet und die Beziehungen zwischen Cloud-Provider und Cloud-Consumer
aushandelt.
• Cloud-Auditor: Eine Partei, die unabhängige Bewertungen von Cloud-Services, Leis-

tung, Informationssystem-Operationen und Sicherheit der Cloud Umsetzung durchfüh-
ren kann.
Die Verwendung des Begriffs "Cloud-Broker"variiert in der Praxis stark und sollte im Vor-
feld einer Cloud SLAs Aushandlung geklärt werden. Zum einen können Provider gleichzeitig
auch Broker sein, zum anderen können externe Parteien die Funktionen eines Brokers über-
nehmen ohne die Rolle des Broker einzunehmen. Welche Rollen in einem SLA eingenommen
und welcher Partei zugeordnet werden muss im Einzelfall spezifisch geklärt werden. Kunden
müssen sich über Aufgaben und Zuständigkeiten der einzelnen Cloud-Akteure bei der Bereit-
stellung ihrer Cloud Services im klaren sein und genau die spezifischen Anforderungen und
gewünschten Service-Levels für die jeweiligen Akteure definieren.
2.6 Kennzahlen und KPIs

Kennzahlen bzw. Key Performance Indicators (KPI) stellen Indikatoren der Qualität einer
Dienstleistung dar, die mittels Metriken die Performance bzw. Dienstgüte messen. Diese spie-
len eine wichtige Rolle bei der Erstellung von SLAs, um die zu erwartenden Leistungen klar
zu definieren. Dabei werden wichtige bzw. kritische Performance-Informationen über einen
definierten Zeitraum verfolgt. Eine Kennzahl setzt sich dabei aus der Bezeichnung für den zu
berechnenden Wert, wie beispielsweise der Antwortzeit für Dienst ’X’, dem Messverfahren
zur Ermittlung der Werte und den Messpunkten bzw. Bezugsobjekten dar. Die hiebei gesam-
melten Ist-Werte werden zu Erfolgsprüfung in einem SLA mit dem vertraglich geregelten
Soll-Werten (Service Levels) verglichen. Eine Kennzahl bzw. KPI stellt dabei immer einen
speziellen Einzelaspekt der Qualität einer Dienstleistung dar und muss quantifizierbar sein.
Als Beispiel könnte man den KPI Körpertemperatur in Grad Celsius im Intervall von 10 Mi-
nuten als Indikator für unsere Gesundheit verwenden. In einem beispielhaften SLA welcher
dann die Gesundheit eines Menschen garantieren würde, wäre dann zum Beispiel festgelegt,
dass der Service Level des KPI-Körpertemperatur nicht von 36degC abweichen darf. KPIs
werden für verbreitete Dienstleistungen bereits in Form von KPI-Bibliotheken angeboten.
Diese eignen sich besonders für die Beschreibung der zu erwartenden Leistungen in SLAs,
da sie meist die aktuellen "best practices"der Systemüberwachung abbilden und so auch uner-
fahrenen Nutzer ermöglichen signifikante Messwerte für die Performance auszuwählen.
Ein wesentlicher Bestandteil eines KPIs ist die Definition der Messpunkte bzw. Bezugsob-
jekte, an denen die Metriken gemessen werden. Besonders im Bereich des Cloud Computings,
wo meist über große IP-Netzwerke (das Internet) zugegriffen wird, ist dies kritisch. In der
Praxis werden KPIs meist am sogenannten Eintritts-Punkt bzw. Austritts-Punkt des Provider-
Netzwerks gemessen, da dieser nur für sein eigenes Netzwerk verantwortlich gemacht werden
kann. Routen basierte und Endpunkt-Messungen kommen selten zum Einsatz da diese einen
höheren Aufwand mit sich bringen. In Kapitel 4 wird nochmals auf diese Problematik genauer
eingegangen. Generell sind Messpunkte neben den Metriken von entscheidender Bedeutung
für die Signifikanz eines SLAs und der Auswirkungen auf die Leistung eines Services.
2.7 SLA Gliederung

Um SLAs übersichtlich und Benutzerfreundlich zu gestalten ist es notwendig eine klar struktu-
rierte Gliederung vorzunehmen. Diese vereinfacht das Auffinden relevanter Inhalte und grup-
piert Informationen nach Kontext und Zugehörigkeit. In der Literatur gibt es keine einheitliche
Vorstellung über die Gliederung eines SLA. Zahlreiche Beispiel-Gliederungen können jedoch
aufgefunden werden. Die hier beschriebene Gliederung bezieht sich auf die bereits beschrie-
benen Elemente für den Inhalt SLAs. Abbildung 3 zeigt den beispielhaft den Aufbau eines
SLAs.
Die hier vorgestellte Gliederung beginnt mit den vorgestellten Grundelementen eines SLAs.
Die Präambel fasst dabei den Gegenstand und die Ziele zusammen und wird von der Partnerbe-
schreibung und dem Geltungsbereich gefolgt. Die Inhalte zum Inkrafttreten, der Laufzeit und
Beendigung schließen die Einleitung in den SLA ab. Der zentrale Teil des SLAs, die Dienst-
leistungsbeschreibung, gliedert alle zu erbringenden Dienstleistungen in einzelne Segmente,
welche deren Inhalte und die zu leistende Qualität definieren. Im Segment der Qualitätsbe-
schreibung werden die relevanten Kennzahlen und die dazugehörigen Service Levels angege-
ben. Durch die dazugehörigen Berichte und Konsequenzen bei Nichterbringung werden die
einzelnen Kennzahlen sinnvoll ergänzt.
Das Segment Vergütung und Rechnung fasst sowohl die Berechnung und Bezahlmodelle,
als auch die Rechnungsdetails zusammen. Die nachfolgenden Punkte fassen die Reglungen für
Berichtswesen, Kontrolle und Änderung, sowie allgemeine Reglungen zum SLA zusammen.
Die juristischen Segmente Regeln die Beziehungen bei externen SLAs. Die Gliederung wird
durch eine salvatorsiche Klausel, die Unterschriften und eventuelle Anhänge abgeschlossen.
3 Service Level Objectives

Service-Level-Objectives (SLOs) sind das zentrale Element eines jeden Service Level Agree-
ments (SLA) und beinhalten die verhandelten Servicequalitäten (Service Level), sowie die da-
für verwendeten Kennzahlen. SLOs sind dabei spezifische und messbare Eigenschaften des
SLA wie beispielsweise die Verfügbarkeit, der Durchsatz oder die Antwortzeit eines Ser-
vices. Service-Level-Objectives können dabei aus einem oder mehreren Quality-of-Service-
Atributen kombiniert bzw. zusammengesetzt werden.
SLOs müssen dabei laut [RW00] folgende Eigenschaften besitzen:
• erreichbar / erzielbar
!"#!$%!&'()*
!!!!!!!"#"!+),)-./&-0
!!!!!!!"#1!23)*)
!1#!$&%/-)%().45%)3(6-,
!7#!+)*/6-,.()%)345
!8#!9-:%&;//%)/)-<!=&6;>)3/!?!@))-03,6-,
!A#!B3)-./*)3./6-,.().45%)3(6-,
!!!!!!!A#"!B3)-./*)3./6-,!CDC
!!!!!!!!!!!!!!!!A#"#"!9-5&*/
!!!!!!!!!!!!!!!!!!!!!!!!!!!A#"#"#"!@)>)345-6-,<!@).45%)3(6-,!6-0!E(,%)->6-,
!!!!!!!!!!!!!!!!!!!!!!!!!!!A#"#"#1!F)3**)3./6-,)-
!!!!!!!!!!!!!!!!!!!!!!!!!!!A#"#"#7!E(*&6;!6-0!G&-0()03-,6-,)-
!!!!!!!!!!!!!!!!A#"#1!H6&*3/!/
!!!!!!!!!!!!!!!!!!!!!!!!!!!A#"#1#"!I)-->&5*!C"C
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!J!@)>)345-6-,!?!@).45%)3(6-,
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!J!K)/%3:!?!@)%)45-6-,.L)%;&5%)-
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!J!K)..M%/!?!@)>6,.M(N):/)
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!J!O)%L34)!=)L)*
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!J!@)%345/.P).)-
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!J!IM-.)Q6)->)-!()3!R345/)%(%3-,6-,
!!!!!!!!!!!!!!!!!!!!!!!!!!!!S
!!!!!!!!!!!!!!!!!S
!T#!U)%,V/6-,!6-0!G)45-6-,
!W#!@)%345/.P).)-
!X#!IM-.)Q6)->)-!()3!R345/)%(%3-,6-,
!Y#!G),*6-,)-!>6%!IM-/%M**)!0).!O=E.
"Z#!G),*6-,)-!>6%!"-0)%6-,!0).!O=E.
""#!G),*6-,)-!>6%!=#.6-,!LM-!IM-;*3:/)-
"1#!B&/)-.456/>!6-0!O)46%3/[
"7#!\&;/6-,!6-0!+)P!5%*)3./6-,
"8#!O45&0)-.)%.&/><!&-P)-0(&%).!G)45/<!+)%345/../&-0
"A#!U)%/%&6*345:)3/<!+)5)3'5&*/6-,!6-0!U)%#;;)-/*3456-,
"T#!O&*L&/M%3.45)!I*&6.)*
"W#!]-/)%.45%3;/)-
"X#!E-5!-,)
Abbildung 3: Gliederungsvorschlag für SLAs

• wiederholbar
• messbar
• verständlich / nachvollziehbar
• aussagekräftig
• kontrollierbar
• erschwinglich
• gegenseitig annehmbar
• beeinflussbar
SLOs werden immer so spezifiziert, dass sie einen Erfolgswert bzw. Service Level, eine
Kennzahl(Metrik) und Messperiode, sowie die Art und den Ort für die Messung enthalten. Ei-
ne gültige SLO Spezifikation wäre also beispielsweise: Das IT-System soll eine Verfügbarkeit
von 98% in einem Messzeitraum von 1 Monat betragen. Die Verfügbarkeit stellt dabei das
Verhältnis der Zeit in der der Service mit einer Responsetime von unter 100ms antwortet plus
der geplanten Ausfallzeit zur Gesamtservicezeit dar.
In ITIL V3 wird der Begriff SLO durch Service Level Ziel ersetzt.
3.1 Aufbau und Inhalt

Service Level Objectives setzen sich aus den Kennzahlen oder Key Performance Indicators
(KPIs) und den dazugehörigen Service Level, d.h. die zu erwartende Dienstgüte fest. Die
Kennzahlen enthalten dabei die Informationen über die Messverfahren und den -ort sowie
deren Einheit. Hieraus lassen sich zur Laufzeit die Ist-Werte der Dienstleistung errechnen.
Während die Service Levels den Bezugszeitraum und die gewünschten Soll-Werte beschrei-
ben. Durch Kenntnis beider Inhalte lässt sich so ein Soll-Ist-Vergleich durchführen und der
erreichte Zielerreichungsungsgrad errechnen.
Die in den Kennzahlen enthaltenen Messverfahren bzw. Metriken müssen exakt spezifiziert
sein um eine Aussagekraft für SLAs zu haben. Dabei gilt es die Datenerhebung, die Daten-
quellen, den Intervall, die Messtechnik und deren Präzision genau zu beschreiben. Ebenso
muss festgelegt werden welche Instanz die Messungen durchzuführen hat.
3.2 KPI Taxonomie

Die folgende KPI Taxonomie gibt eine Übersicht, wie die KPIs in diesem Dokument einge-
ordnet sind. Zum Einen werden diese in übergeordnete und Dienst-spezifische Cloud-KPIs
eingeteilt (siehe Abbildung 4).
Abbildung 4: KPI Taxonomie Übersicht
4 Übergeordnete Cloud-KPIs
Service Level Agreements und die darin enthaltenen Service Level Objectives müssen stets
individuell an die zu regelnde Dienstleistung angepasst werden. Dennoch gitb es sogenannte
übergeordnete KPIs, welche allgemeine Reglungen enthalten die sich durch übernehmen bzw.
verweisen einbinden lassen. Ergibt sich der Bedarf an Abweichungen zu diesen standardisier-
ten Regeln so müssen diese explizit in der jeweiligen SLO Beschreibung aufgeführt werden.
Übergeordnete KPIs dienen dabei als grobe Richtlinien für die Gestaltung von SLOs.
Für SLAs bedeutet dies, dass die verschiedenen im SLA geregelten Dienstleistungen die je-
weiligen SLO Beschreibungen enthalten, darin jedoch zum Beispiel auf die Kennzahl Verfüg-
barkeit verweisen. Zusätzlich muss jedoch immer das individuelle Service Level dazu angeben
werden. Hierdurch lassen sich Redundanzen vermeiden und der Umfang von SLAs gering hal-
ten, da beispielsweise die Verfügbarkeit von Netzwerkkomponenten, Storage und Infrastruk-
tur auf die gleichen Kennzahlen verweisen. Zugleich ermöglichen diese KPIs unerfahrenen
Anwendern auf die “best practices” zurück zu greifen. Solche standardisierten Kennzahlen
werden meist als KPI Bibliotheken angeboten und enthalten branchenspezifische Inhalte vgl.
[Mir13]. Im folgenden Abschnitt werden die gebräuchlichsten übergeordneten Cloud-KPIs,
wie in Abbildung 4 zu sehen, vorgestellt und erklärt. Diese wurden in die Kategorien Basis-
leistung, Sicherheit, Service und Helpdesk und Monitoring eingeteilt.
4.1 Basisleistungen
Die übergeordneten Basisleistungen sind Merkmale die für alle Cloud-Dienste gelten (siehe
Abbildung 5.
Verfügbarkeit Einheit: %
Die Verfügbarkeit von IT-Systemen oder Komponenten stellt ein wesentliches Qualitäts-
merkmal dar und lässt sich wie folgt definieren:
Abbildung 5: KPI Taxonomie (Ausschnitt): Basisleistung
Ünter der Verfügbarkeit eines IT-Systems wird die Eigenschaft der fehlerfreien
Nutzung der Funktionalität dieses Systems unter vorgegebenen Bedingungen in-
nerhalb eines definierten Zeitrahmens verstanden."[Ber05]
Die fehlerfreie Nutzung bezieht sich dabei auf die definierte Funktionalität eines Systems.
Das heißt ist die definierte Funktionalität beispielsweise das versenden von E-mail so ist der
Service bereits dann nicht mehr Verfügbar, wenn keine E-Mails mehr versendet werden kön-
nen, jedoch der Empfang von E-Mails noch möglich ist. In der Praxis kommt zusätzlich noch
die Überlegung dazu, dass Dienstleistungen zu bestimmten Zeiten abgeschaltet werden müs-
sen, um beispielsweise Wartungen oder Updates durchzuführen. Dafür ergibt sich die Berech-
nung der Verfügbarkeit wie folgt:
Servicezeit + geplante − ungeplanteAusf allzeit
V erf ügbarkeit = (1)
Gesamtzeit
Die Servicezeit bezeichnet hierbei die Zeit in der ein System fehlerfrei genutzt werden
konnte. Diese wird oft auch Betriebszeit genannt. Die Ausfallzeit gibt die Zeiten für die nicht
fehlerfreie Nutzen an. Hierbei wird zwischen geplanten und ungeplanten Ausfallzeiten unter-
schieden. Als geplant werden Wartungen, Updates, usw. bezeichnet die im Vorfeld mit dem
Kunden vereinbart wurden. Die Gesamtzeit gibt den Bezugszeitraum für die Erfassung an.
Der Nutzen solcher Vereinbarung ist stark Abhängig von der Definition des Bezugszeit-
raums. Garantiert ein SLA eine Verfügbarkeit von beispielsweise 98,5% ergibt sich für dies
bei einem Bezugszeitraum von einer Woche einen erlaubten Ausfall von 2,52 Stunden pro
Woche. Ist der Bezugszeitraum jedoch ein Jahr ist eine Ausfallzeit von ca. 5,5 Tage (131,4
Stunden) in Folge erlaubt. In der Praxis wird die Verfügbarkeit im Bezug auf ein Jahr angege-
ben.
Ein weiterer kritischer Faktor stellt die Definition der Messart dar. Hierbei gilt es zu beach-
ten, dass hier die fehlerfreie Nutzung, d.h. die definierte Funktionalität des Systems abgebildet
werden soll. So kann beispielsweise ein einfacher Ping oder eine Request-Response-Time un-
terhalb eines festgesetzten Limits als "verfügbar"gelten. Bei komplexen System ergibt sich
zudem die Anforderung, dass festgelegt werden muss ob die Verfügbarkeit einzelner Kompo-
nenten der gesamt Verfügbarkeit entspricht.
Leistungsfähigkeit/Antwortzeit Einheit: ms
Als Leistungsfähigkeit (engl. Performance) wird die Geschwindigkeit von IT-Systemen bei
der Bearbeitung von Aufgaben angesehen. Dabei gilt es die für die Funktion des Systems
relevanten Aufgabenmerkmale zu bestimmen. Eine formale Definition kann wie folgt gegeben
werden:
"Die Leistungsfähigkeit eines IT-Systems beurteilt die Dauer, die ein System zur
Ausführung spezifischer Aktionen unter definierten Randbedingungen benötigt."[Ber05]
Allgemein wird beim Bezug auf die Leistungsfähigkeit von IT-Systemen die Antwortzeit als
Kennzahl verwendet. Diese gibt an wie viel Zeit vom starten einer Anfrage an ein IT-System
bis zum wieder eintreffen der daraus resultierenden Antwort beim Absender vergeht. Für die
Berechnung der Antwortzeit ergibt sich folgende Formel:
Antwortzeit = tAntwort − tAnf rage (2)

Diese wird in der Praxis jedoch meist nicht auf eine einzelne Anfrage und Antwort bezogen,
sondern auf eine über einen längeren Zeitraum durchgeführte Gruppe an Anfragen. Dabei
lassen sich dann sowohl der Durchschnitt, als auch das Perzentil berechnen. Hierdurch wird
die Aussagekraft diser Kennzahl für das Verhalten des Systems erhöht.
Mittlere Lebensdauer (Mean Time Between Failure; MTBF) Einheit: %

Die im Bereich der IT-System weit verbreiteten Kennzahl ist Mean Time Between Failure
(kurz: MTBF). Bei MTBF handelt es sich um die mittlere Lebensdauer, d.h. es wird die er-
wartete Servicezeit vor dem Ausfall angegeben. Die Berechnung der MTTF basiert dabei auf
historischen Überwachungsdaten. Die Formel ergibt sich wie folgt:
Systemanzahl ∗ Lauf zeit
M T BF = (3)
Gesamtf ehlerzahl
Daraus ergibt sich die MTBF pro System. Beim Betrieb von mehreren System muss die
MTBF mit der Anzahl der System multipliziert werden.
Mittlere Reparaturzeit (Mean Time To Recover; MTTR) Einheit: %

Mean Time To Repair (kurz: MTTR) gibt die mittlere Reparaturzeit nach einem Ausfall an.
Diese besagt wie lange die Wiederherstellung eines Systems nach dem Ausfall im mittel dau-
ert. Berechnet wird diese durch die Formel:
Ausf allzeit
MT T R = (4)
Ausf allanzahl
In der Praxis wird die MTTF oft bereits vom Hersteller für seine Systeme oder Kompo-
nenten angeben. Dies ist vor allem bei Festplatten der Fall. Die MTTR kann in erster Linie
vom Provider angegeben werden da nur dieser über genügend historische Daten verfügt um
aussagekräftige Berechnungen durchzuführen.
Dienstbereitstellungszeit Einheit: ms
Zeit die der Provider braucht, bis der Dienst dem Kunden zur Verfügung steht.
Software Update Status Einheit: Status

Garantierte Software Versionszustände:
aktuell: Software ist auf dem neusten Stand
major: Es werden in der aktuellen Version die neusten Patches eingespielt.
frozen: Software bleibt auf dem vom Kunden definierten Stand.
4.2 Sicherheit
Kriterien für die Messbarkeit des Sicherheitsniveaus sind zu erarbeiten. Eine Möglichkeit
besteht darin, Audits durchzuführen und Sicherheitszertifikate zu erwerben, etwa nach ISO
27001 oder gemäß EuroCloud Star Audit SaaS, und diese Zertifizierungen zum Vertragsbe-
standteil zu machen. Dies stellt sicher, dass ein Cloud-Service-Provider bestimmte Anforde-
rungen in Bezug auf die Daten- und IT-Sicherheit erfüllt. Zusätzlich können folgende Security
SLOs im SLA festgeschrieben werden. In Abbildung 6 werden alle Cloud-spezifischen KPIs
zu Sicherheit aufgelistet.
Abbildung 6: KPI Taxonomie (Ausschnitt): Sicherheit
Rollout Time Release (RTR) Einheit: Zeit bzw. Dauer

RTR gibt die Zeit vom Release bis zum Einspielen eines Patches in das System an. Hierbei
wird festgelegt wie lange der Provider Zeit hat ein Update in das geregelte System einzuspie-
len. Wichtig dabei ist die Definition der Güte des Update z.B. critical fix. RTR is ein wichtiger
Sicherheitsaspekt da hierdurch geregelt werden kann wie schnell das System an neue Versio-
nen angeglichen wird.
Security Audits Einheit: Anzahl bzw. Intervall und Umfang

Security Audits testen das System auf bestimmte vordefinierte Kriterien. Durch festgelegte In-
tervalle kann sichergestellt werden, dass das System den definierten Anforderungen entspricht.
Die Definition des Umfangs stellt hierbei die größte Herausforderung dar, dieser sollte in re-
gelmäßigen Abständen dem Stand der Technik angepasst werden.
Aktualität der Virensoftware Einheit: Zeit bzw. Dauer

Aktualität der Antiviren-Software und der dazugehörigen Scan-Engine gitb an wie lange bzw.
zu welchen Zeitpunkten für diese ein Update eingespielt wird. Hierbei empfiehlt es sich nach
dem Update auch eine Überprüfung der Daten durchzuführen. Eine tägliche Aktualisierung ist
bei vielen Unternehmen bereits gängige Praxis.
Verschlüsselung Einheit: Verschlüsselungsart

Die Festlegung der Verschlüsselungsmethoden für das System ermöglicht die Einhaltung vor-
gegebener Sicherheitsstandards und erschwert den Missbrauch durch Dritte. Die definierten
Methoden sollten dem aktuellen Stand der Technik entsprechen.
Security Reaktionszeit Einheit: Zeit bzw. Dauer

Security Reaktionszeit gibt die maximale Zeit zwischen Meldung und Handlung bei Security
Incidents an. Je nach Nutzen des Systems und der Gefahr die durch eine Korrumpierung droht
sollte die Reaktionszeit kurz gewählt werden. Eine klare Definition und Abstufung für einzelne
Risiko- und Incident-Klassen sollte vorgenommen werde.
Zugriffsprotokollierung Einheit: Art, Bericht, Kommunikation

Die Festlegung der Zugriffsprotokollierung ermöglicht im Falle eines Security Incidents genau
nachzuvollziehen wie, von wo und wann auf das System zugegriffen wurde. Dazu muss die
Art der Protokollierung und das Verfahren zu dessen Handhabung definiert werden.
Zugriffsschutz Einheit: Art und Regelung

Beschreibung des Zugriffsschutzes für das System wie z.B. der Zugriff über eine Proxy-
Firewall. Hierbei muss sowohl die Art als die genauen Regelungen wie z.B. blockierte Ports
definiert werden.
Anzahl Sicherheitsvorfälle Einheit: Anzahl

Anzahl der Sicherheitsvorfälle pro Berechnungszeitraum.
Ressourcen Standort Einheit: Ort

Lokation der Ressource (z.B. Storage in Deutschland, EU). Dies ist besonders für rechtliche
Aspekte von Interesse. Dabei gilt es für Standorte innerhalb und ausserhalb der EU die jewei-
ligen Bestimmungen des Bundesdatenschutzgesetz (BDSG) einzuhalten.
Ressourcen Isolationsstufe Einheit: Stufe

In wie weit werden die Ressourcen voneinander isoliert.
räumlich getrennt getrennte Standorte
physikalisch getrennt getrennte Hardware
virtuell getrennt; HW shared gleicher Hypervisor
virtuell getrennt; SW shared Terminal Server
4.3 Service & Helpdesk

Für Cloud Kunden ist es wichtig im Fall eines Problem oder einer Störung die Hilfe des Pro-
viders in Anspruch zu nehmen. Der Umfang und die Güte dieser Services sollten klar definiert
sein. Service und Helpdesk Kennzahlen dienen dabei den zu erbringenden Leistungen klar zu
spezifizieren. Da sich einige der hier vorgestellten Kennzahlen nicht einheitlich messen lassen,
würden für diese ßubjektiven"Faktoren eigene Richtlinien, bzw. Bewertungskriterien festge-
legt werden. Diese müssen zwischen Provider und Kunde ausgehandelt werden. Nachfolgend
werden wichtige KPIs (siehe Abbildung 7) vorgestellt.
Abbildung 7: KPI Taxonomie (Ausschnitt): Service & Helpdesk
Anzahl der Anrufe Einheit: Anzahl bzw. Intervall

Die Anzahl der telefonischen Kontakte zur Hilfe des Providers pro Zeiteinheit. Hierbei wird
festgelegt wie viele Anfragen entgegen genommen werden müssen.
“First Call Resolution” Einheit: Güte der Hilfe

Definiert die Güte der entgegengebrachten Hilfe. Bestimmt ob Anfragen beim ersten Anruf
gelöst werden müssen oder an andere Abteilungen weitergereicht wird.
Anzahl Tickets Einheit: Anzahl

Die Anzahl der geöffneten Tickets zur Hilfe des Providers pro Zeiteinheit. Hierbei wird fest-
gelegt wie viele Anfragen entgegen genommen werden müssen.
Anzahl erfolgreich geschlossener Tickets Einheit: Anzahl bzw. Anteil

Die Anzahl erfolgreich geschlossener Tickets pro Zeiteinheit. Hierbei wird festgelegt wie viele
Probleme gelöst werden müssen bzw. wie hoch der Anteil der zu lösenden Anfragen ist.
Anzahl verworfener bzw. nicht gelöster Tickets Anzahl bzw. Anteil

Die Anzahl verworfenen bzw. nicht gelöster Tickets pro Zeiteinheit. Hierbei wird festgelegt
wie viele Probleme verworfen werden dürfen bzw. wie hoch der Anteil an der Gesamtzahl der
Anfragen ist.
Mittlere Lösungszeit Einheit: Dauer

Die durchschnittliche Zeit die vom Öffnen bis zum Schliessen einer Anfrage gebraucht wird.
Hierbei wird festgelegt wie schnell auf Probleme vom Provider zu antworten ist.
Maximale Lösungszeit Einheit: Dauer

Die maximale Zeit die vom Öffnen bis zum Schließen einer Anfrage gebraucht wird.
Verlässlichkeit der Lösung Einheit: Güte

Gibt an mit welcher Güte auf eine Anfrage geantwortet werden muss. Dies kann zum Beispiel
von einfach FAQs über Problem Management Databases, bis hin zum direkten Kontakt mit
Technikern reichen
Anrufzeiten Einheit: Uhrzeit

Die Geschäftszeiten zu denen direkter Kontakt mit der Hilfe des Providers aufgenommen
werden kann.
“Employee Proficiency” Einheit: Güte der Mitarbeiter

Level bzw. Qualifikation der bearbeitenden Person z.B. Techniker oder First Level Supporter.
Kundenzufriedenheit Einheit: Umfragewert

Bewertung des Providers im Bezug auf die Erfüllung der Anfragen.
4.4 Monitoring
Das Monitoring soll dem Cloud-Kunden die Möglichkeit gegeben werden, vom Provider ei-
ne gewisse Transparenz der Ressourcenüberwachung sicher zu stellen. Nachfolgend werden
wichtige KPIs (siehe Abbildung 8) vorgestellt.
Abbildung 8: KPI Taxonomie (Ausschnitt): Monitoring
Intervallzeit Einheit: s
Im welchem Zeitraum sollen Ressourcenmessungen durchgeführt werden.
Reportintervall Einheit: Stunden/Tage/Wochen/Monate

Im welchem Zeitraum sollen Reports an den Kunden verschickt werden.
4.5 Weitere übergeordnete KPIs

Zusätzlich zu den bereits vorgestellten KPIs gibt es noch weitere Kennzahlen die universelle
Verwendung finden können, die aber nicht Cloud-spezifisch sind und an dieser Stelle nicht
weiter dokumentiert werden.
5 SLOs für Cloud Computing

Nachfolgend werden Kennzahlen zur Dienstgüte-Überwachung bei verschiedenen Cloud Com-
puting Szenarien vorgestellt. Diese enthalten gängige Metriken und sollen als Hilfsmittel beim
erstellen von SLAs für Cloud Computing dienen. Jede Kennzahl wird mit ihrer Einheit und
Definition, sowie einer kurzen Erklärung bezüglich ihrer Aussagekraft und Relevanz für Cloud
Computing angegeben. Die SLOs sind in die 7 Kategorien Netzwerk, Storage, Backup und Re-
store, IaaS, PaaS, SaaS und Cloud Basis Dienste eingeteilt (siehe Abbildung 4).
5.1 Netzwerk
Dem Netzwerk kommt besonders beim Cloud Computing eine starke Bedeutung zu, da alle be-
zogenen Ressourcen bzw. Dienste über ein Netzwerk bezogen werden. Dabei ist das Netzwerk
sowohl Übertragungsmedium d.h. Bereitstellungsweg für andere Services als auch Service an
sich. Bei den hier beschriebenen Kennzahlen wird in der Praxis meist vom Eintrittspunkt in
das Providernetzwerk aus gemessen. Da sich die Garantien des Providers auch nur auf dieses
beziehen. Nachfolgend werden wichtige KPIs (siehe Abbildung 9) vorgestellt.
Round Trip Time Einheit: Dauer in ms

Umlaufzeit eines Pakets vom Sender zum Empfänger und zurück. Gibt an wie lange die Über-
mittlung innerhalb des Netzes benötigt.
Abbildung 9: KPI Taxonomie (Ausschnitt): Netzwerk
Response Time Einheit: Dauer in ms

Aufenthaltszeit einer Anfrage bis zum Eintreffen der Antwort bei der Ausgangsschnittstelle.
Hierbei wird im Gegensatz zur reinen Umlaufzeit noch die bearbeitung der Anfrage beim Ziel
mit einbezogen. Die Anfrage und das Verhalten des Ziels muss dabei konkret definiert sein.
Paketverlustrate Einheit: Anteil in %

Anteil der verlorengegangenen Pakte am Gesamtvolumen der Übertragung.
Formel:
Anzahl verlorener P akete
(5)
Anzahl Gesamtpakte ∗ 100
Verarbeitungsgüte Einheit: Anteil in %

Anteil der fehlerhaften Übertragungen.
Formel:
Anzahl F ehler
(6)
Gesamtübertragungen ∗ 100
Retransmissions Einheit: Anteil in %

Anzahl der pro Zeiteinheit wiederholten Übertragungen.
Formel:
Anzahl W iederholungen
(7)
Gesamtübertragungen ∗ 100
Bandbreite Einheit: Mbit/s / Gbit/s

Bruttokapazität der Datenmenge, die innerhalb einer Zeiteinheit übertragen wird.
Durchsatz Einheit: Mbit/s / Gbit/s

Anzahl der übertragenen Daten pro Zeiteinheit. Dabei werden nur die reinen Nutzdaten be-
rücksichtigt.
Auslastung Einheit: Anteil in %

Anteil der verwendeten Übertragungsrate an der Bandbreite.
Formel:
Durchsatz
(8)
Bandbreite ∗ 100
Warteschlangenlänge Einheit: Anzahl

Anzahl der Aufträge bzw. Transaktionen die auf die Ressource warten.
Latenzzeit Einheit: ms
Zeitintervall zwischen dem Eintritt eines Pakets im Netzwerk und dem Eintreffen beim Ziel-
system.
Jitter Einheit: ms
Differenz in der Latenzzeit eines Pakets und der durchschnittlichen / minimalen / maximalen
Laufzeit. Die Schwankung der Laufzeit sind besonders bei Echtzeit-Anwendungen störend,
da dadurch Pakete zu spät oder zu früh eintreffen können.
5.2 Storage
Die Bezeichnung Storage kann innerhalb des Cloud Computings in zwei grundlegende Arten
unterschieden werden. Zum einen kann Strorage als Service selbst, d.h. als Speicher für vor-
handene Strukturen bezogen werden. Zum anderen kann Storage als Teil eines Servicepaketes
z.B. als Backup oder Datenspeicher für Cloud Dienste mitverwendet werden. Nachfolgend
werden wichtige KPIs (siehe Abbildung 10) vorgestellt.
Antwortzeit Einheit: ms
Zeitintervall zwischen dem Absenden einer Anfrage an das Storagesystem und dem Eintreffen
der Antwort bei der Ausgansschnitstelle. Siehe auch Kapitel 4 Basisleistungen.
Durchsatz Einheit: MB/s / KB/s

Anzahl der übertragenen Daten pro Zeiteinheit. Dabei wird von einem vorgegebenen Punkt
eine spezifizierte Menge an Daten zum Storage übertragen und die benötige Zeit gemessen.
Die Größe der Datenmenge und Paketgröße sind wichtige Faktoren für die Aussagekraft dieser
Kennzahl. Des weiteren muss das Netzwerk und dessen Auslastung berücksichtigt werden.
Abbildung 10: KPI Taxonomie (Ausschnitt): Storage
Durchschnittliche Lesegeschwindigkeit Einheit: MB/s

Im Gegensatz zum Durchsatz bezieht sich die durchschnittliche Lesegeschwindigkeit meist
auf die einzelnen Festplatten. Dieser Wert gibt an wie schnell Daten von der Hardware gelesen
werden können. In RAID-Systemen oder Virtuellen Storagelösungen wird diese Kennzahl auf
den Verbund von Festplatten gerechnet.
Durchschnittliche Schreibgeschwindigkeit Einheit: MB/s

Genau wie die Lesegeschwindigkeit bezieht sich auch die Schreibgeschwindigkeit auf die
Festplatten. Dieser Wer gibt dabei an wie schnell Daten von einer Quelle auf die Hardware
geschrieben werden können.
Random Input/Outputs per Second (IOPS) Einheit: Anzahl pro Sekunde

Anzahl der möglichen zufälligen Ein/Ausgabe-Operationen pro Sekunde für verschiedene
Blockgrößen. Je größer der IOPS-Wert ist, desto schneller ist der Datenträger.
Sequential Input/Outputs per Second (IOPS) Einheit: Anzahl pro Sekunde

Anzahl der möglichen sequentiellen Ein/Ausgabe-Operationen pro Sekunde für verschiedene
Blockgrößen.
Kapazität Einheit: GB / TB
Gesamtvolumen des Storage in GB oder TB. Dabei wird die Bruttokapazität der Datenträger
bzw. des Datenträgerverbunds angegeben.
Tatsächliche Kapazität Einheit: GB / TB

Nettovolumen des Storage in GB oder TB. Hierbei wird nur der nutzbare Speicher angegeben
ohne Formatierungs-Overhead oder Verluste durch Verbundstrukturen wie z.B. RAID5.
Freier Speicherplatz Einheit: % oder GB / TB

Nutzbare freie Kapazität in % vom Gesamtvolumen bzw. verbleibende freie Kapazität in GB,
oder TB.
Garantierter Storage Zuwachs Datenmenge pro Zeit

Intervall in dem die bereitgestellte Datenmenge um einen definierten Wert erweitert wird. Dies
ermöglicht den konstanten Zuwachs an Speicherressourcen.
Provisionierungsart Einheit: Thin / Thick

Art der Provisionierung. Thin-Provisioning bezeichnet die „schlanke Speicherzuweisung“ bei
der dem Kunden nicht der gesamte zur Verfügung gestellten Speicher fest zugewiesen wird,
sondern dieser dynamisch zu Laufzeit allokiert wird. Bei Thick-Provisioning wird hingegen
gleich der gesamte Speicher fest an den Kunden gebunden.
Mittlere Bereitstellungszeit Einheit: Zeit in hh:mm:ss

Zeit die der Provider benötigt um eine definierte Datenmenge bzw. Datenmengenzuwachs
bereitzustellen.
Storage Typ Einheit: Art

Art der Storage Datenträger wie beispielsweise ATA, SATA, SCSI oder SSD Platten.
Storage Aufbau Einheit: Aufbau

Struktureller Aufbau des Storages wie z.B. RAID5 oder die Verwendung von Load Balancing.
5.3 Backup & Restore

Backup und Restore Kennzahlen (siehe Abbildung 10) beziehen sich sowohl auf den Storage,
d.h. die gespeicherten Daten, als auch auf Dienste an sich, wie beispielsweise VMs oder SaaS
Dienste. Nachfolgend werden wichtige KPIs (siehe Abbildung 11) vorgestellt.
Backup Intervall Einheit: Zeitintervall

Zeitintervall in dem ein Backup durchgeführt wird.
Abbildung 11: KPI Taxonomie (Ausschnitt): Backup
Backuptyp Art
Spezifikation des Backuptyps z.b. Vollbackup oder inkrementelles Backup.
Backup Archivierung Einheit: Art

Intervall und Anzahl der zu archivierenden Backups. Spezifikation ab wann Backups archiviert
werden und wie lange diese aufzubewahren sind.
Zeit zur Datenwiederherstellung Einheit: Zeit in Min. / Std.

Spezifikation der minimalen bzw. maximalen Zeit vom Ausfall eines Storage, bis zur Daten-
wiederherstellung aus einem vorhandenen Backup.
Zeit zur Systemwiederherstellung Einheit: Zeit in Min. / Std.

Minimale und maximale Dauer bis zur Wiederherstellung bei einem Systemausfall.
Zeit zur Dienstwiederherstellung Zeit in Min. / Std.

Minimale und maximale Dauer bis zur Wiederherstellung bei einem Dienstausfall. Im Gegen-
satz zur Systemwiederherstellung wird hierbei ein Dienst auch wieder beim Kunden direkt zu
verfügung gestellt.
Backup Test Einheit: Typ

Definition eines Backuptests auf Wiederherstellbarkeit. Dabei wird genau spezifiziert welchen
Umfang dieser Test hat und ob dieser automatisch oder manuell durchgeführt werden kann.
Backup Testintverall Einheit: Zeitintervall

Zeitintervall in dem die vorhandenen Backups getestet werden. Spezifikation muss den Backup
Test enthalten.
Backupmedien Einheit: Medium

Angabe der Medien auf dem die Backups gespeichert werden wie z.B. Magnetbänder. Angabe
von Medienbrüchen um auf verschiedenen Medien Backups zu speichern.
5.4 VM basierende KPIs

VM basierende KPIs (siehe Abbildung 12), werden im folgenden vorgestellt.
Abbildung 12: KPI Taxonomie (Ausschnitt): VM
CPU Einheit: Anzahl & Typ

Anzahl und Typ der zur verfügung gestellten CPUs.
CPU Überbuchung Einheit: Ja / Nein

Angabe über die Überbuchung der bereitgestellten CPU Ressourcen. Dabei wird den Instanzen
mehr Kapazität zugewiesen als physikalisch verfügbar ist. Somit findet keine physikalische
Allocation der Ressourcen statt. Die tatsächliche vorhandene Leistung ist vom Verbrauch der
jeweiligen Instanzen abhängig.
CPU Auslastung Einheit: %

Anteil der verwendeten CPU Ressourcen an der Gesamtzahl der zur Verfügung gestellten
CPUs pro Zeiteinheit.
CPU Warteschlange Einheit: Anzahl

Anzahl der offenen Anfragen an die CPU.
Memory Einheit: MB / GB
Menge des zur Verfügung gestellten Memory.
Memory Überbuchung Einheit: Ja / Nein

Angabe über die Überbuchung der bereitgestellten Memory Ressourcen. Siehe auch CPU
Überbuchung.
Memory Auslastung Einheit: %

Anteil der verwendeten Memory Ressourcen an der Gesamtzahl der zur Verfügung gestellten
Menge Memory pro Zeiteinheit.
Memory Art Einheit: Typ

Typ der zur Verfügung gestellten Memory Ressource. Diese kann sich auf physikalischer Spei-
cher z.B. DDR3-1333 RAM ECC oder virtuellen Speicher beziehen.
5.5 Infrastructure as a Service

Infrastructure as a Service (IaaS) hat zusätzlich KPIs (siehe Abbildung 13), die im folgenden
vorgestellt werden.
Anzahl VMs Einheit: Anzahl

Garantierte Anzahl der zur Verfügung gestellten VMs.
Migrationszeit Einheit: ms
Zeit, die gebraucht wird um eine VM von zwei vordefinierten HW-Ressourcen umzuziehen.
Unterbrechungszeit bei Migration Einheit: ms

Maximale Zeit, in der ein Kunde bei Migration kein Zugriff auf die Ressource hat.
Logging Einheit: Typ

Beschreibt welche Typen von Logs bzw. für welche Daten Logs erstellt werden sollen.
Loggingintervall Einheit: Stunden/Tage/Wochen/Monate

Gibt den Intervall an in dem Logs erstellt werden sollen und deren Aufbewahrungszeit.
Abbildung 13: KPI Taxonomie (Ausschnitt): IaaS
Log-Level Einheit: Level

Spezifikation von welchem Niveau aus mitgeloggt werden soll. (z.B. INFO, DEBUG, etc.)
5.6 Platform as a Service

Platform as a Service (PaaS) hat zusätzlich KPIs (siehe Abbildung 14), die im folgenden
vorgestellt werden.
Abbildung 14: KPI Taxonomie (Ausschnitt): PaaS

Response Time Einheit: Dauer in ms

Aufenthaltszeit einer Anfrage bis zum Eintreffen der Antwort bei der Ausgangsschnitstelle.
Die Anfrage und das Verhalten des Ziels muss dabei konkret definiert sein.
Deployment Time Einheit: Dauer in ms

Dauer bis die entwickelte Applikation in die Plattform, PaaS, hoch geladen ist und zur Verfü-
gung steht.
Upscaling Time Einheit: Dauer in ms

Zeit die die Plattform bei höherer Belastung für das Hoch-Skallieren benötigt.
Downscaling Time Einheit: Dauer in ms

Zeit die die Plattform bei niedriger Belastung für das Herunter-Skallieren benötigt.
5.7 Software as a Service

Software as a Service (SaaS) hat zusätzlich KPIs (siehe Abbildung 15), die im folgenden
vorgestellt werden.
Abbildung 15: KPI Taxonomie (Ausschnitt): SaaS
Lizenzen Einheit: Volumen & Typ

Typ der Lizenz (meist Mietlizenz) und Anzahl der erlaubten Nutzer.
Anzahl Nutzer Einheit: Anzahl

Maximale Anzahl der Nutzer, die den Service nutzen können. Sollte üblicherweise durch die
Lizenzen abgedeckt sein.
Anzahl gleichzeitiger Nutzer Einheit: Anzahl

Anzahl der Nutzer, die gleichzeitig den Service nutzen können.
5.8 Cloud Basis Dienste

Viel Cloud Provider bieten aus den Service Modellen IaaS, PaaS und SaaS noch spzielle
Cloud-Dienste, die Cloud-Kunden nützlich sein können. Nachfolgend werden einige der wich-
tigsten Basisdienste und deren KPIs vorgestellt (siehe Abbildung 16).
Abbildung 16: KPI Taxonomie (Ausschnitt): Base Services
5.8.1 Image Management Service

Upload Time Einheit: ms
Zeit um ein Kundenimage in das System einzuspielen.
Image Storage Size Einheit: GB

Maximaler Speicherplatz für Kundenimages.
5.8.2 Datenbank Service

Transaktionen Einheit: Transaktionen pro Zeiteinheit
Garantierte Anzahl der Transaktionen pro Sekunde die vom System bearbeitet werden.
Transaktionsfehlerrate Einheit: Fehler pro Anfrage gesamt

Anzahl der fehlerhaften oder wiederholten Transaktion pro Abfrageintervall. Der Verlust von
Transaktionen sollte einen vordefinierten Wert nicht übersteigen.
Datenbankgröße Einheit: GB
Maximale Speichergröße der Datenbank.
6 Zusammenfassung 42
5.8.3 Load Balancer Service

Fehlerrate Einheit: Fehler pro Anfragen insgesamt
Anzahl der fehlerhaften Anfragen im Verhältnis zur Gesamtzahl der Anfragen. Der Verlust
von Anfragen sollte einen vordefinierten Wert nicht überschreiten.
5.8.4 Scale Service

Min/Max Scale Limit Einheit: Anzahl
Garantierte Minimale/Maximale Anzahl von Ressourcen die vom System bereitgestellt wer-
den.
Upscale Time Einheit: ms

Zeit die benötigt wird, um eine Ressource hinzufügen.
Downscale Time Einheit: ms

Zeit die benötigt wird, um eine Ressource zu entfernen.
5.8.5 Message Queue Service

Message Queue Length Einheit: Anzahl
Maximale Länge der unbearbeiteten Anfragen in der Message Queue.
Maximale Anzahl paralleler Clients Einheit: Anzahl

Maximale Anzahl der parallelen Zugriffe auf das System
6 Zusammenfassung
Mit dem SLA-Richtliniendokument für Cloud Dienstleistungen soll ein Leitfaden geschaf-
fen werden, welcher es sowohl Cloud Providern, als auch Kunden ermöglicht, individuelle
und cloudspezifische SLAs zu gestalten. Um hier für beide Seiten eine effektivere Nutzung
der Cloud Dienstleistungen zu erhalten, welche sich bei den derzeitigen am Markt angeboten
SLAs nur schwer realisieren lassen. Es liefert einen allgemeinen Überblick über alle vertrags-
relevanten Punkte, welche in einem SLA festgehalten werden sollten, damit dieser für beide
Seiten tragbar ist. Speziell für die Cloud relevanten vertraglichen Regelungen, wird ein de-
taillierter Überblick geschaffen über die Anforderungen und deren Messbarkeit. So wird dem
Kunden und Provider ermöglicht zu jederzeit einen genauen Einblick in die aktuell vorhanden
Anforderungen zu nehmen. Auf diese Weise werden notwendige Anpassungen schnell sicht-
bar. Das Richtliniendokument ist einer der wichtigen Bausteine für das Projekt und dient dort
als Grundlage für die Gestaltung der SLAs.
Literatur 43
Literatur
[Arb11] A RBEITSKREISE T ECHNIK UNDM EDIEN DER KONFERENZ DER DATEN -
SCHUTZBEAUFTRAGTEN DES B UNDES UND DER L ÄNDER: Orientierungshilfe
- Cloud Computing. 2011. – Forschungsbericht
[Ber05] B ERGER, Thomas G.: Konzeption und Management von Service-Level-

Agreements für IT-Dienstleistungen, TU Darmstadt, Diss., June 2005
[Cor11] C ORPORATION, Compuware. Performance in the Cloud - Survey Report. 2011
[For10] F ORCE, Distributed Management T.: Architecture for Managing Clouds White
Paper / DMTF. 2010. – Forschungsbericht
[Fra10] F RAUNHOFER I NSTITUT FÜR O FFENE KOMMUNIKATIONSSYSTEME: Cloud

Computing für die öffentliche Verwaltung. In: ISPRAT-Studie (2010)
[GFD07] G ANGADHARAN, GR ; F RANKOVA, Ganna ; DA NDREA, Vincenzo: Service li-

cense life cycle. In: Collaborative Technologies and Systems, 2007. CTS 2007.
International Symposium on IEEE, 2007, S. 150–158
[Gro11] G ROUP, Gardner. Cio-Prioritäten und Budgets 2011. 2011
[HKK+ 07] H ASSELMEYER, Peer ; KOLLER, Bastian ; KOTSIOPOULOS, Ioannis ; K UO, De-
an ; PARKIN, Michael: Negotiating SLAs with dynamic pricing policies. In:
Proceedings of the SOC@ Inside’07 (2007)
[LTM+ 11] ANG L IU ; T ONG, Jin ; M AO, Jian ; B OHN, Robert B. ; M ESSINA, John V. ; BAD -
GER , Mark L. ; L EAF , Dawn M. NIST Cloud Computing Reference Architecture
- NIST SP - 500-292. 2011
[Mei00] M EINS, John: Die Vertragsverhandlung. Schäffer-Poeschel Verlag, 2000 ( ISBN:

978-382-020-874-0)
[Mir13] M IRROR -42. KPI Library. 2013
[RW00] R ICK, Sturm ; WAYNE, Morris: Foundations of Service Level Management. Sams
Publishing, 2000 ( ISBN: 978-0-6723-1743-9)
[Sch01] S CHMIDT, H.: Entwurf von Service Level Agreements auf der Basis von Dienst-
prozessen. Utz, 2001 ( ISBN: 978-383-160-455-5)
[SXL05] S UN, Wenhui ; X U, Yue ; L IU, Feng: The role of XML in service level agreements
management. In: Services Systems and Services Management, 2005. Proceedings
of ICSSSM’05. 2005 International Conference on Bd. 2 IEEE, 2005, S. 1118–
1120

SLA-Richtliniendokument Für Cloud Dienstleistungen PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

SLA-Richtliniendokument Für Cloud Dienstleistungen PDF

Hochgeladen von

Copyright:

Verfügbare Formate

SLA-Richtliniendokument für Cloud Dienstleistungen

Autonomic SLA Management as a Service (ASLAMaaS)

Autonomic SLA Management as a Service

Autoren Firma E-mail

Über Autonomic SLA Management as a Service

Das ASLAMaaS-Projekt findet in Zusammenarbeit mit drei deutschen Industriepartnern

2 Service Level Agreement 8

3 Service Level Objectives 21

5 SLOs für Cloud Computing 31

5.7 Software as a Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

CSP Cloud Service Provider, siehe Cloud Anbieter.

Infrastructure as a Service (IaaS) Cloud-Anwender erhalten Zugriff auf üblicherweise

Platform as a Service (PaaS) Platform as a Service ermöglicht dem Cloud-Anwender,

1.1 SLAs und Cloud Computing

1.2 Ziel des Richtliniendokuments

Ziele des Richtliniendokuments:

• Unterstützung bei der Erstellung von SLAs für Cloud Dienste

• Beschreibung und Definition von Cloud-spezifischen Service Le-

1.3 Aufbau des Richtliniendokuments

2 Service Level Agreement

2.1 SLA Lebenszyklus

Abbildung 1: SLA Lebenszyklus

Implementierung: Die Implementierungsphase stellt das Inkrafttreten der Vereinbarung

2.2 SLA Voraussetzungen

• den Prozess und Ablauf der geregelten Dienstleistung verstehen.

• 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

2.3 Aufbau von SLAs

Vereinbarungsbezogene Elemente (siehe Kapitel 2.3.1) regeln grundsätzliches, wie bei-

Dienstleistungsbezogene Elemente (siehe Kapitel 2.3.2) beschreiben die Dienstleis-

Dokumentbezogene Elemente (siehe Kapitel 2.3.4) beschreiben administrative und re-

Abbildung 2: SLA-Elemente laut [Ber05]

2.3.1 Vereinbarungsbezogene Elemente

2.3.2 Dienstleistungsbezogene Elemente

der Dienstleistungsbeschreibung. Kunden sollte es möglich sein aus diesen Beschrei-

2.3.3 Managementbezogene Elemente

Berichtswesen: Berichte stellen den grundlegenden Informationsaustausch zwischen Kun-

Verrechnung der erbrachten Dienstleistungen: Inhalte zur Verrechnung der erbrach-

2.3.4 Dokumentbezogene Elemente

• Die eindeutige Bezeichnung des Services.

• Die geregelten Kommunikationswege zwischen Kunde und Service-Provider, mit Ver-

• Die Service-Level-Anforderungen/ -Ziele welche beschreiben ab wann ein Service z.B.

2.4.2 ISO 20000

• S - SLA (Service Level Agreement)

• O - OLA (Operational-Level-Agreement) innerbetriebliche Vereinbarungen

• U - UC (Underpinning Contract) IT-Services von Drittanbieter

• Cloud-Provider: Die Person,Organisation oder Einrichtung die dafür verantwortlich ist,

• Cloud-Auditor: Eine Partei, die unabhängige Bewertungen von Cloud-Services, Leis-

2.6 Kennzahlen und KPIs

2.7 SLA Gliederung

3 Service Level Objectives

Abbildung 3: Gliederungsvorschlag für SLAs

3.1 Aufbau und Inhalt

3.2 KPI Taxonomie

Abbildung 4: KPI Taxonomie Übersicht

Abbildung 5: KPI Taxonomie (Ausschnitt): Basisleistung