SLA Cloud und Hosting

§1 Einleitung

(1) Zweck des Dokuments

Das Dokument regelt und definiert Service Level für die Erbringung von Hosting- und Rechenzentrumsdienstleistungen durch die Thomas-Krenn.AG.

Das SLA wird im Rahmen der Bereitstellung von Dienstleistungen durch die Thomas-Krenn.AG mit abgeschlossen. Das Dokument legt die Service-Level der unterschiedlichen Dienstleistungen, der Infrastruktur-Parameter sowie aller bereitgestellter Funktionen fest.

(2) Gültigkeit

Das SLA ist nur in Verbindung mit einem gültigen Vertrag über Dienstleistungen der Thomas-Krenn.AG gültig. Der Umfang ergibt sich aus den jeweils in diesem Dokument aufgeführten Leistungsbeschreibungen bzw. den für einzelne Dienste ggf. ergänzenden Leistungsbeschreibungen. Neben dem SLA finden ausschließlich die Allgemeinen Geschäftsbedingungen (AGB) von Thomas-Krenn Anwendung.

(3) Geltungsbereich

Die in diesem Dokument aufgeführten Service Level kommen ausschließlich dann zur Anwendung, wenn sich der Kunde mit der Bezahlung seiner Leistungen nicht in Verzug befindet. Für die Dauer eines etwaigen Verzugs ruhen die Rechte und Pflichten aus diesem SLA beiderseitig.

Die in diesem Dokument aufgeführten SLA gelten nicht in Fällen, die zurückzuführen sind auf:

- Höhere Gewalt

- Rechtliche oder regulatorische Vorgaben (inklusive Anordnungen ordentlicher Gerichte des jeweiligen Landes in welchem der Betrieb erfolgt).

- Durch den Kunden herbeigeführte Überlastung und / oder fehlerhafte Bedienung der von Thomas-Krenn.AG bereitgestellten Dienste.

- Änderungen eines Dienstes oder einer Konfiguration, die vom Kunden durchgeführt worden ist oder in Auftrag gegeben worden ist.

- Wartungsarbeiten des Partners.

- Sperrung einzelner Dienste oder eines gesamten Accounts aufgrund missbräuchlicher Nutzung.

(4) Definitionen

(a) Geschäftszeiten sind Zeiten von 07:00 Uhr bis 22:30 Uhr an Werktagen, außer an bundeseinheitlichen und in Bayern geltenden Feiertagen, Heiligabend und Silvester.

(b) Nichtverfügbarkeit ist der Zeitraum, in dem ein von der Thomas-Krenn.AG bereitgestellter Dienst nicht verfügbar ist.

(c) Wiederherstellungszeit ist der Zeitraum, binnen dem ein von einer Störung betroffener Dienst wiederhergestellt worden ist. Die Wiederherstellung eines von einer Störung betroffenen Dienstes wird dem Kunden schriftlich angezeigt.

(d) Kalendermonat bezieht sich auf einen Monat mit rechnerisch 30,5 Tagen, unabhängig von der tatsächlichen Anzahl der Kalendertage.

(e) Wartungsfenster ist der Zeitraum, in dem geplante und angekündigte Arbeiten an einem Dienst durchgeführt werden.

(f) Reaktionszeit beschreibt das Zeitfenster zwischen der qualifizierten Störungsmeldung des Kunden per Telefon, E-Mail oder Ticket und der schriftlichen Bestätigung einer vorliegenden Störung durch die Thomas-Krenn.AG per E-Mail. Die Reaktionszeit innerhalb der Geschäftszeiten beträgt 30 Minuten und außerhalb der Geschäftszeiten 120 Minuten.

 

§2 Dienste von Thomas-Krenn.AG

(1) Infrastructure-as-a-Service (IaaS) Dienste

Die Thomas-Krenn.AG stellt eine Plattform an einem oder mehreren Standorten zur Verfügung, mit Hilfe der sich Compute- und Rechenressourcen (Netzwerk, Arbeitsspeicher, CPU, Datenspeicher) zusammenstellen und betreiben lassen. Bereitgestellte Ressourcen stehen dem Kunden exklusiv zur Verfügung und werden gemäß den jeweils gültigen Preisen minutengenau berechnet.

IaaS-Dienste unterteilen sich in steuernde, primäre und sekundäre Dienste. Nachfolgend nicht aufgeführte Dienste fallen in die Kategorie der sekundären Dienste.

(a) Steuernde Dienste

(I) API beschreibt vom Partner betriebene Schnittstellen, mit Hilfe der sämtliche Konfigurationen an Diensten durch den Kunden vorgenommen werden. Die API basiert auf einer standardisierten RESTful-HTTP-Schnittstelle.

(II) API CLI beschreibt ein von Thomas-Krenn bereitgestelltes Command Line Interface, das die Bedienung der API des Partners erlaubt.

(III) API GUI beschreibt ein von Thomas-Krenn bereitgestelltes und gehostetes Webinterface, dass die Bedienung der API des Partners erlaubt.

(IV) Automation Services sind vom Partner betriebene Dienste, die anhand vom Kunden definierter Kriterien automatisiert bestimmte Aktivitäten vornehmen. Beispielsweise können automatisiert Snapshot von einzelnen virtuellen Festplatten erstellt- und archiviert werden, oder bei bestimmten Workload Parametern ( z. B. Auslastung der CPU auf einem virtuellen Server ) automatisiert weitere CPU-Ressourcen bereitgestellt werden.

(b) Primäre IaaS-Dienste

(I) Compute- und Rechenressourcen definiert Ressourcen, aus denen ein virtueller Server zusammengestellt wird. Darunter:

- Prozessorkerne (CPU)

- Arbeitsspeicher (RAM)

- Netzwerkkarten (NIC)

- Primärer Blockstorage (Storage)

(II) Upstream beschreibt die Verbindung zwischen den einzelnen des Partners und dem Internet.

(III) Privates Netzwerk beschreibt die Verbindung zwischen mehreren virtuellen Servern eines Kunden über ein Software-Defined-Network (SDN).

(2) Managed Platform-as-a-Service (PaaS) Dienste

Die Thomas-Krenn.AG stellt eine Schnittstelle an einem oder mehreren Standorten zur Verfügung, mit Hilfe der sich hochwertige IT-Dienste und Programme (z.B. S3-Storage, Load Balance, Firewall, Nachrichten Gateway, Datenbanken, Kubernetes Orchestrierung etc.) durch den Kunden anfordern lassen. IT-Dienste, die als PaaS bereitgestellt werden, verstehen sich als standardisierte und gemanagte Dienstleistung.

 

§3 Überwachung und Verfügbarkeitsgarantie

(1) Predictive Failure Detection

Die durch Thomas-Krenn betriebenen Dienste unterliegen einer dauerhaften Überwachung. Dabei kommen eine Vielzahl an Sensoren und Überwachungstechnologien zum Einsatz, um eine etwaige Störung bereits vor Eintreten (sogenanntes Predictive Failure Detection - PFD) zu identifizieren und automatisiert geeignete Maßnahmen zu ergreifen, um vom Kunden genutzte Dienste in eine nicht von einer eintretenden Störung betroffene Zone zu verschieben. Weiterhin kommen reaktive Instrumente zum Einsatz, die bei Eintreten einer Störung automatisiert die Wiederherstellung des vom Kunden genutzten Dienstes durchführen und im Bedarfsfall automatisiert entsprechende IT-Experten des Partners alarmiert und in die Entstörung einbindet. Zur Sicherstellung der PFD ist es erforderlich, dass der Partner Sensorinformationen sammelt und automatisiert (sogenanntes Machine-Learning) verarbeitet (sogenanntes Profiling). Dabei werden insbesondere Workloads des Kunden erfasst, Verhalten bestimmter Workloads, automatisierte Vorgänge gegen die API des Partners durch Kunden, Reaktionsverhalten der Hard- und Software, Temperaturinformationen von Hardwarekomponenten und Sensoren, Spannungsversorgung und statistisch relevante Daten über das Verhalten der vom Partner betriebenen Plattform einschließlich genutzter PaaS Dienste. Im Rahmen dieser Datensammlung fallen zu keiner Zeit persönliche Daten gemäß DSGVO an.

(2) Netzwerküberwachung

Der Upstream des Partners wird aus verschiedenen Regionen der Welt überwacht. Dabei kommen zum Teil externe Dienstleister zum Einsatz, die dem NOC des Partners erlauben eine Messung von Latenzen, Paketverlusten sowie Änderungen von Routing-Wegen zu protokollieren. Der Upstream gilt als nichtverfügbar, sobald zwei aufeinanderfolgende Überprüfungen aus mindestens zwei unterschiedlichen Regionen der Welt eine Nichterreichbarkeit ergeben haben.

(3) Verfügbarkeitsgarantie

(a) Folgende Messverfahren finden Anwendung:

(I) Aktivitätsbasierte Messungen

Die Anzahl von Aktivitäten pro Monat und Kunde und Dienst werden jeweils in Schritten von 10.000 Aktivitäten gezählt und jeweils auf die nächsten 10.000 Aktivitäten aufgerundet. Die Summe der Aktivitäten wird in das Verhältnis der fehlgeschlagenen Aktivitäten gesetzt. Aus der Berechnung ergibt sich die prozentuale Nichtverfügbarkeit im jeweiligen Monat.

(II) Zeitbasierte Messungen

Die Summe von Nichterreichbarkeit im jeweiligen Monat wird in das Verhältnis der theoretisch möglichen Verfügbarkeit pro Monat gesetzt. Aus der Berechnung ergibt sich die prozentuale Nichtverfügbarkeit im jeweiligen Monat.

(b) Folgende Verfügbarkeitsgarantien gelten als vereinbart:

Dienst (Typ)

Verfügbarkeit

Kriterium

Beispiele

Primär

100%

Eine Unterbrechung des Betriebs
primärer Dienste zählt unmittelbar
als Nichtverfügbarkeit, sofern
nichts Abweichendes vereinbart ist.


SLA verletzt: Der Upstream ist aus mindestens zwei unterschiedlichen Regionen der Welt für zwei aufeinanderfolgende Messpunkte nicht erreichbar.


SLA nicht verletzt: ein CPU-System des Partners friert unangekündigt ein. Die Sensorik des Partners erkennt diesen Zustand korrekt innerhalb einer Toleranz von 120 Sekunden und führt gemäß den Einstellungen des Kunden eine Autorecovery-Prozedur durch.

Steuernd

99,999%

Die Nichterreichbarkeit von API-Schnittstellen bzw. Nichtausführung von API-Kommandos oder nicht pünktlich ausgeführte Automation Services.


SLA verletzt: von 10.000 Anfragen eines Kunden an die API des Partners, kommt es zu mehr als einem Fehler.


SLA nicht verletzt: bei 100.000 API Anfragen kommt es zu einem fehlgeschlagenen API-Request

PaaS

99,99%

Unterbrechung des Betriebs oder der Erreichbarkeit des jeweiligen PaaS Dienstes.


SLA verletzt: Ein Load Balancer-Service ist für mehr als 264 Sekunden im jeweiligen Abrechnungsmonat nicht verfügbar bzw. die Funktion ist gestört.


SLA verletzt: Ein PaaS Datenbank-Cluster beantwortet für mehr als 264 Sekunden im jeweiligen Monat keine Anfragen.

Sekundär

99,9%

Sekundäre Services stehen nicht zur Verfügung oder erzeugen einen nicht betriebsrelevanten Fehler.


Ein Sekundärer Service steht für mehr als 44 Minuten im jeweiligen Monat nicht zur Verfügung.

§4 Wartungsmaßnahmen

Der Partner stellt dem Kunden eine Infrastructure-as-a-Service (IaaS) und Platform-as-a-Service (PaaS) Architektur bereit, die auf einer sogenannten Zero-Downtime Architektur basiert. Zero-Downtime bedeutet, dass die überwiegende Menge von Wartungsarbeiten an der Architektur, einzelner Komponenten, bereitgestellter Dienste oder der Infrastruktur ohne eine Beeinträchtigung der vom Partner bereitgestellten Dienste durchgeführt werden kann.

Wartungsarbeiten an zentralen Komponenten, auf die zur selben Zeit mehr als ein Kunde zurückgreift (z. B. Storage-Systeme, Netzwerk-Systeme, zentrale Software-Komponenten) werden grundsätzlich im Vorfeld durch den Partner angekündigt. Die Ankündigung erfolgt mindestens mit drei Tagen Vorlauf über das eigens betriebene Serviceportal. Zusätzlich informiert der Partner auf Wunsch über diese Arbeiten im Einzelfall per E-Mail an die vom Kunden für diesen Zweck angegebene E-Mail Adresse. Das Abonnement dieser E-Mails kann direkt über das vom Partner betriebene Serviceportal abgeschlossen werden. Der Ankündigung ist jeweils zu entnehmen, mit welchen Folgen oder etwaigen Einschränkungen während einer Wartungsarbeit zu rechnen ist.

Wartungsarbeiten an einzelnen Komponenten, auf die nur ein Kunde Zugriff hat (z. B. dedizierte Hardware), werden im Einzelfall mit dem Kunden abgestimmt und nach Möglichkeit im beiderseitigen Einvernehmen zu einem für den Kunden günstigen Zeitpunkt durchgeführt.

Sowohl bei zentralen als auch bei einzelnen Komponenten werden Wartungsarbeiten unverzüglich (auch ohne vorherige Ankündigung) durchgeführt, wenn Ereignisse eintreten, die ein sofortiges Handeln (z. B. Gefahr im Verzug) erfordern.

 

§5 Gutschrift und Deckelung der Gutschrift bei Verletzung des SLA

(1) Erfassung von Verfügbarkeit und Nichtverfügbarkeit

Der Partner erfasst die Einhaltung von SLA eines jeden Dienstes automatisiert und selbstständig. Eine Unterschreitung der im SLA vereinbarten Verfügbarkeiten führt unmittelbar zu einer Gutschrift auf dem Kundenkonto, welches mit der jeweils nach Gutschrift folgenden Rechnung verrechnet wird. Eine Anzeigepflicht des Kunden besteht nicht. Maßgeblich für die Erreichung des SLA sind ausschließlich die vom Partner erfassten und automatisiert ausgewerteten Daten. Sollten etwaige Messungen des Kunden von den Messungen des Partners um mehr als 10 % zu Ungunsten des Kunden abweichen, so stimmen die Parteien bereits jetzt darin überein, eine gemeinsame Ursachenanalyse zu betreiben um für beide Parteien abweichende Messmethoden transparent zu machen und den Partner in die Lage zu versetzen, für zukünftige Messungen die Methode des Kunden anzunehmen und selber einzusetzen. Damit soll ein jederzeit optimales Messergebnis gewährleistet sein.

(2) Deckel von Gutschriften

Die Höhe kumulierter Gutschriften sind gedeckelt auf den durchschnittlichen monatlichen Umsatz des Kunden in den zurückliegenden drei Monaten, höchstens aber auf den im Kalenderjahr angefallenen Gesamtumsatz des Kunden.

(3) Gutschriftenprozess

Im Falle der Verletzung des SLA erfolgt automatisiert eine Gutschrift. Die Gutschrift setzt sich im Falle einer zeitbasierten Messung aus der auf 5 Minuten aufgerundete Dauer einer Nichtverfügbarkeit, multipliziert mit dem Faktor 10 auf die anfallenden Gebühren aller unmittelbar betroffener Dienste zusammen.

Im Falle der Verletzung eines SLA bezogen auf Aktivitätsbasierte Messungen, berechnen sich die Gutschriften aus dem Basispreis pro Aktivität, analog zu der zeitbasierten Messung mit dem Faktor 10.

 

§6 Sonstiges

(1) Mängelansprüche

Sollten die in diesem Dokument definierten Service Level nicht erfüllt werden, erstellt der Partner automatisiert eine nach diesem Dokument hergeleitete Gutschrift und wird diese spätestens im auf den der Störung folgenden Abrechnungszeitraum dem Kundenkonto gutschreiben.

(2) Preise, Änderungen, Kündigung

Das SLA wird ohne zusätzliche Kosten im Rahmen der von Thomas-Krenn bereitgestellten Services erbracht.

(3) Haftung

Bei der Nichteinhaltung von Service Leveln gelten die in diesem Vertrag definierten Regulierungen. Regelungen zu Vertragsstrafen bestehen ausdrücklich nicht. Für alle Ansprüche gegen die Thomas-Krenn.AG gelten ausschließlich die Regelungen in den AGB in ihrer aktuellen, mit dem Kunden vereinbarten Fassung.

 

Stand: 24.06.2021