SLA und SLO
In dieser Lerneinheit werden Vereinbarungen zum Servicelevel und Servicelevel-Zielpunkte beschrieben.
Vereinbarung zum Servicelevel (SLA)
Da SaaS nicht nur Software, sondern in erster Linie ein Dienst ist, ist ein Unterschied zwischen SaaS und herkömmlichen Softwareprodukten die Vereinbarung zum Servicelevel (Service-Level Agreement, SLA). Die SLA ist eine Vereinbarung zwischen einem SaaS-Anbieter und einem Kunden, die die Verpflichtungen des Anbieters hinsichtlich Uptime und Konnektivität beschreibt. Wenn der Softwareanbieter die Servicelevel für jeden Dienst nicht wie in dieser SLA beschrieben erreicht und aufrecht erhält, haben Kunden u. U. Anspruch auf Entschädigung.
Entschädigungen und Strafzahlungen in Verbindung mit der SLA für Softwareanbieter hängen von der Branche und der Art des Geschäfts ab. Die beiden häufigsten Fälle sind Geldstrafen und Servicegutschriften. Im Fall von Servicegutschriften können Kunden eine Gutschrift auf ihre monatlichen Servicegebühren erhalten.
Sie können zwar eine Uptime von 100 % für Ihren Dienst definieren, bei komplexen Systemen ist es aber schwierig, eine Verfügbarkeit von 100 % zu erreichen. Die meisten SLAs sind an die Verfügbarkeit gebunden, die sie bereitstellen können.
Eine SLA, die eine Uptime von 100 % angibt, garantiert möglicherweise keine Verfügbarkeit von 100 %. Eine Uptime von 100 % kann bedeuten, dass Kunden bei Ausfällen eine Entschädigung gemäß der Vereinbarung erhalten. Das Erstellen hochverfügbarer Systeme ist eine technische Aufgabe, während die SLA eine Möglichkeit ist, ein Unternehmen bei Ausfällen rechtlich zu schützen.
Beispiele für SLAs von Microsoft finden Sie unter Vereinbarungen zum Servicelevel (Service-Level Agreements, SLA) für Onlinedienste.
Servicelevel-Zielpunkte (Service-Level Objectives, SLO)
SLOs sind messbare Ziele, die auf zentralen, kundenorientierten Servicelevelindikatoren (Service-Level Indicators, SLIs) basieren. SLOs messen die Kundenerfahrung hinsichtlich einer Geschäfts- oder Infrastrukturworkload.
SLOs bestimmen, ob der SaaS-Anbieter die in einer formal ausgehandelten SLA eingegangenen Verpflichtungen erfüllt. SLOs und SLIs sollten frühzeitig beim Entwerfen eines Cloudgeschäfts oder einer Infrastrukturworkload definiert werden.
Der Schwerpunkt für Dienstbesitzer liegt auf der Ermittlung folgender Informationen:
- Szenarien, die kritische Indikatoren für die Integrität eines Diensts aus Sicht des Kunden sind
- Erfassen von SLIs, damit sie möglichst nah an der Kundenerfahrung liegen
- Vorgabe der SLOs für die SLIs
Es gibt zwei Arten von SLOs in der Softwarebranche:
Serviceorientierte SLOs sind taktische Ziele, die Teams definieren, um die Qualität ihres Diensts im Laufe der Zeit schrittweise zu verbessern.
Diese SLOs sind pragmatische Ziele, die in einem technischen Meilenstein erreichbar sind. Wenn z. B. ein Dienst derzeit eine Verfügbarkeit von 99,7 % erreicht, könnte das Team das Ziel festlegen, im nächsten Quartal eine Verfügbarkeit von 99,9 % zu erreichen.
Kundenorientierte SLOs definieren den idealen zukünftigen Zustand oder das Ziel, über das hinaus weitere Investitionen in Qualität unnötig sind, da Sie die Erwartungen der Kunden vollständig erfüllen.
SLOs sind bei der Entwicklung und beim Betrieb von Cloudworkloads wichtig und dienen verschiedenen Zwecken im Vergleich zu SLAs. Ein SLO gibt den Status und die Richtung für technische Teams an, während es sich bei einer SLA um einen Vertrag mit Kunden zu den Bedingungen für die erbrachten Dienstleistungen und die Entschädigung handelt.
In Azure ist die Servicelevelverwaltung einfach, da Microsoft die Schnittstellen, Funktionen und Metriken vordefiniert. Verbraucher müssen ihre Erwartungen an die Servicebereitstellung steuern, wenn sie Cloudworkloads verwenden.
Szenario für Contoso
Eine einfache SLA zwischen Contoso und den Benutzern definiert zuerst die garantierten Servicelevels und SLIs, z. B.:
- Benutzer können auf das System zugreifen und sich anmelden, Designs erstellen und andere verfügbare Funktionen im System verwenden
- Contoso bietet 99,99 % Verfügbarkeit für die Dienste und deckt die oben genannten Szenarien ab
- Anforderungen in den letzten fünf Minuten werden zu 99 % in unter 1.000 Millisekunden bedient.
Die SLIs sind Aggregationen von Zeitreihendaten. Wie die SLIs gesammelt werden, ist wichtig. Wenn der Kunde mit dem Dienst über eine API interagiert, sind die Messung der Systemwartezeit und der Zeit für die Verarbeitung von Anforderungen präzise SLIs. Wenn der Kunde jedoch mit dem Dienst über ein Webportal interagiert, sollte die Gesamtzeit zum Verarbeiten der Anforderung auch die JavaScript-Leistung der Webseite umfassen.
In der SLA müssen zudem Downtime und die Entschädigung für Kunden definiert werden, bei denen die Downtime auftritt. Es kann beispielsweise eine Vergütungsstruktur mit prozentualer Uptime korreliert mit dem Prozentsatz der erhaltenen monatlichen Gutschriften oder eine Pauschalvergütung für jede Minute Downtime verwendet werden.
In Bezug auf SLOs kann Contoso zunächst Folgendes definieren:
- QoS: Das KI-Modell sollte innerhalb von 3 Minuten nach einer Benutzeranforderung neue Designideen generieren.
- Verfügbarkeit: 99,99 % über einen monatlichen Zeitraum
- Kapazität: Zielprozentsatzauslastung für CPU, Speicher, Arbeitsspeicher, Wartezeit, Durchsatz und Skalierung.
- Produkteinführung: Die Einführung vorgeschlagener Designideen sollte über 20 % liegen