Empfehlungen zur Definition von Zuverlässigkeitszielen

Hierfür gilt die Empfehlung der Power Platform Well-Architected Reliability-Checkliste:

AW:04

Definieren Sie Zuverlässigkeits- und Wiederherstellungsziele für die Komponenten, die Flows und die Gesamtlösung. Visualisieren Sie die Ziele, um zu verhandeln, einen Konsens zu erzielen, Erwartungen festzulegen und Maßnahmen einzuleiten, um den Idealzustand zu erreichen. Verwenden Sie die definierten Ziele, um das Integritätsmodell zu erstellen. Das Integritätmodell definiert, wie fehlerfreie, verschlechterte und fehlerhafte Zustände aussehen.

In dieser Anleitung werden die Empfehlungen zum Definieren von Zielmetriken für Verfügbarkeit und Wiederherstellung für kritische Workloads beschrieben. Zuverlässigkeitsziele werden durch Workshop-Übungen mit geschäftlichen Stakeholdern abgeleitet.

Die Ziele werden durch Überwachung und Tests verbessert. Arbeiten Sie mit Ihren internen Stakeholdern zusammen, um realistische Erwartungen hinsichtlich der Zuverlässigkeit festzulegen. Mit dieser Übung können die Stakeholder Ihre architektonischen Entwurfsentscheidungen auch unterstützen und verstehen, dass Sie Ihren Entwurf so gestalten, dass die vereinbarten Ziele bestmöglich erreicht werden.

Microsoft Power Platform kümmert sich für Sie um die meisten Fragen der Verfügbarkeit und Zuverlässigkeit auf Infrastrukturebene. Die Verfügbarkeit der von Ihnen erstellten Workloads liegt jedoch in Ihrer gemeinsamen Verantwortung. Es ist wichtig zu verstehen, dass das Risiko eines Systemausfalls trotz des Einsatzes von Microsoft für eine hohe Verfügbarkeit nie bei Null liegt.

Erwägen Sie die Verwendung der folgenden Metriken zur Quantifizierung der Geschäftsanforderungen.

Begriff	Definition
Service Level Objective (SLO)	Ein Prozentsatzziel, das die Integrität der Komponente und die Zuverlässigkeitsstufe darstellt. Je höher die Ebene, desto zuverlässiger ist die Komponente. Das zusammengesetzte SLO stellt das Gesamtziel der gesamten Arbeitslast dar und berücksichtigt die Komponenten-SLOs.
Service Level Indicator (SLI)	Eine von einem Dienst ausgegebene Metrik. SLI-Metriken werden aggregiert, um einen SLO-Wert zu quantifizieren.
Service Level Agreement (SLA)	Eine vertragliche Vereinbarung zwischen dem Dienstanbieter und dem Dienstkunden. Die Vereinbarung definiert die SLOs. Die Nichterfüllung der Vereinbarung kann für den Serviceanbieter finanzielle Konsequenzen haben.
Mean Time To Recover (MTTR)	Die zum Wiederherstellen einer Komponente benötigte Zeit wird nach der Erkennung eines Fehlers ermittelt.
Mean Time Between Failures (MTBF)	Die Dauer, während der die Workload die erwartete Funktion ohne Unterbrechung ausführen kann, bis sie ausfällt.
Recovery Time Objective (RTO)	Die maximal akzeptable Zeit, in der eine Anwendung nach einem Vorfall nicht verfügbar sein darf.
Recovery Time Objective (RPO)	Die maximal akzeptable Dauer des Datenverlusts während eines Vorfalls.

Definieren Sie die Zielwerte der Workload für diese Metriken im Kontext von Benutzer- und Systemflows. Identifizieren und bewerten Sie diese Flows nach ihrer Wichtigkeit für Ihre Anforderungen. Verwenden Sie die Werte, um die Gestaltung Ihrer Arbeitslast hinsichtlich Architektur, Überprüfung, Tests und Vorfallmanagementvorgängen voranzutreiben. Wenn die Ziele nicht erreicht werden, wird das Unternehmen über die Toleranzgrenze hinaus beeinträchtigt.

Wichtige Designstrategien

Technische Diskussionen sollten nicht darüber entscheiden, wie Sie die Zuverlässigkeitsziele für Ihre kritischen Abläufe definieren. Stattdessen sollten sich die Stakeholder auf ihre eigenen Anforderungen und die Erwartungen der Endbenutzer der Workload konzentrieren. Technische Experten helfen den Stakeholdern bei der Zuweisung realistischer Zahlenwerte, die diesen Anforderungen entsprechen. Durch den Austausch von Informationen ermöglichen technische Experten die Diskussion und Einigung über realisierbare SLOs.

Sehen Sie sich ein Beispiel für die Zuordnung von Anforderungen zu messbaren Zahlenwerten an. Die Stakeholder gehen davon aus, dass bei einem kritischen Benutzerflow eine Stunde Ausfallzeit während der regulären Geschäftszeiten zu einem Verlust von X an monatlichen Einnahmen führt. Dieser Dollarbetrag wird mit den geschätzten Kosten für die Entwicklung eines Flows verglichen, der ein Verfügbarkeits-SLO von 99,95 Prozent statt 99,9 Prozent aufweist. Entscheidungsträger müssen darüber diskutieren, ob das Risiko eines Umsatzverlusts die zusätzlichen Kosten und den Verwaltungsaufwand überwiegt, die zum Schutz davor erforderlich sind.

Folgen Sie diesem Muster, während Sie Flows untersuchen und eine vollständige Liste von Zielen erstellen.

Bedenken Sie, dass sich Zuverlässigkeitsziele von Leistungszielen unterscheiden. Zuverlässigkeitsziele konzentrieren sich auf Verfügbarkeit und Wiederherstellung. Zum Festlegen von Zuverlässigkeitsziele beginnen Sie mit der Definition der weitreichendsten Anforderungen und legen dann spezifischere Metriken zur Erfüllung der übergeordneten Anforderungen fest.

Zu den höchsten Zuverlässigkeits- und Wiederherstellungsanforderungen und den damit verbundenen Metriken könnte beispielsweise eine Anwendungsverfügbarkeit von 99,9 Prozent für alle Regionen oder ein Ziel-RTO von 5 Stunden für die Region Amerika gehören. Durch die Definition dieser Zieltypen können Sie feststellen, welche kritischen Flows an diesen Zielen beteiligt sind. Anschließend können Sie Ziele auf Komponentenebene berücksichtigen.

Verfügbarkeitsmetriken

Verfügbarkeitsziele entsprechen SLO-, SLA- und SLI-Metriken.

SLOs und SLAs

Verfügbarkeitsmetriken korrelieren mit SLOs, die Sie zum Definieren von SLAs verwenden. Das Workload-SLO legt fest, wie viel Ausfallzeit in einem bestimmten Zeitraum tolerierbar ist, z. B. weniger als 1 Stunde pro Monat. Um sicherzustellen, dass Sie das SLO-Ziel erreichen können, überprüfen Sie die Microsoft-SLAs für jede Komponente.

Denken Sie beim Festlegen Ihrer SLOs an Folgendes:

• Nicht-funktionale Anforderungen Ihrer Workload (z. B. Spitzenanforderungsraten, gleichzeitige Benutzer) für die nächsten ein bis zwei Jahre.

• Verfügbare Metriken für das, was Sie über einen bestimmten Zeitraum messen können. Diese Daten geben Aufschluss darüber, welche SLIs angegeben werden müssen.

Nachdem Sie die SLAs für die einzelnen Workloadkomponenten erfasst haben, berechnen Sie ein zusammengesetztes SLA. Das zusammengesetzte SLA sollte mit dem Ziel-SLO der Workload übereinstimmen. Bei der Berechnung eines zusammengesetzten SLA sind, abhängig von Ihrem Architekturdesign, mehrere Faktoren zu berücksichtigen.

Das Definieren geeigneter SLOs erfordert Zeit und sorgfältige Überlegung. Geschäftliche Steakholder sollten die Zuverlässigkeitstoleranz verstehen. Dieses Feedback sollte in die Zielvorgaben einfließen.

SLA-Werte

In der folgenden Tabelle sind die allgemeinen SLA-Werte definiert.

SLA	Downtime pro Woche	Downtime pro Monat	Downtime pro Jahr
99 %	1.68 Stunden	7.2 Stunden	3.65 Tage
99,9 %	10.1 Minuten	43.2 Minuten	8.76 Stunden
99,95 %	5 Minuten	21.6 Minuten	4.38 Stunden
99,99 %	1.01 Minuten	4.32 Minuten	52.56 Minuten
99.999 %	6 Sekunden	25.9 Sekunden	5.26 Minuten

Wenn Sie über zusammengesetzte SLAs im Kontext von Benutzer- und Systemflows nachdenken, bedenken Sie, dass unterschiedliche Benutzer- und Systemflows unterschiedliche Kritikalitätsdefinitionen aufweisen. Berücksichtigen Sie diese Unterschiede beim Erstellen Ihrer zusammengesetzten SLAs. Nicht kritische Flows enthalten möglicherweise Komponenten, die Sie bei Ihren Berechnungen auslassen sollten, da ihre kurze Nichtverfügbarkeit die Kundenerfahrung nicht beeinträchtigt.

SLIs

Stellen Sie sich SLIs als Metriken auf Komponentenebene vor, die zu einem SLO beitragen. Die wichtigsten SLIs sind diejenigen, die Ihre kritischen Flows aus der Sicht Ihrer Kunden betreffen. Für viele Flows umfassen SLIs Latenz, Durchsatz, Fehlerrate und Verfügbarkeit. Mithilfe eines guten SLI können Sie erkennen, wann die Gefahr einer Verletzung eines SLO besteht. Korrelieren Sie den SLI nach Möglichkeit mit bestimmten Kunden.

Um das Sammeln nutzloser Metriken zu vermeiden, begrenzen Sie die Anzahl der SLIs für jeden Flow. Streben Sie nach Möglichkeit drei SLIs pro Flow an.

Wiederherstellungsmetriken

Wiederherstellungsziele entsprechen RTO-, RPO-, MTTR- und MTBF-Metriken. Im Gegensatz zu den Verfügbarkeitszielen hängen die Wiederherstellungsziele für diese Messungen nicht so stark von den Microsoft SLAs ab. Microsoft veröffentlicht RTO- und RPO-Garantien nur für einige Produkte, wie etwa SQL Database.

Definitionen für realistische Wiederherstellungsziele basieren auf Ihrer Fehlermodusanalyse und Ihren Plänen und Tests zur Geschäftskontinuität und Notfallwiederherstellung. Bevor Sie diese Arbeit abschließen, besprechen Sie die angestrebten Ziele mit den Stakeholdern und stellen Sie sicher, dass Ihr Architekturentwurf die Wiederherstellungsziele nach bestem Wissen und Gewissen unterstützt. Teilen Sie den Stakeholdern klar mit, dass für Teile der Workload, die nicht gründlich auf Wiederherstellungsmetriken getestet wurden, keine SLAs garantiert werden sollten. Stellen Sie sicher, dass die Beteiligten verstehen, dass sich Wiederherstellungsziele im Laufe der Zeit ändern können, wenn die Workloads aktualisiert werden. Die Workload kann komplexer werden, wenn Sie neue Technologien zur Verbesserung der Benutzererfahrung einführen. Diese Änderungen können Ihre Wiederherstellungsmetriken verbessern oder verschlechtern.

Anmerkung

Das Definieren und Garantieren der MTBF kann eine Herausforderung sein. Bei Platforms-as-a-Service (PaaS) oder Software-as-a-Service (SaaS) kann es zu Ausfällen und Wiederherstellungen kommen, ohne dass der Cloudanbieter eine Benachrichtigung sendet. Der Vorgang kann für Sie vollkommen transparent sein. Wenn Sie Ziele für diese Metrik definieren, decken Sie nur die Komponenten ab, die unter Ihrer Kontrolle stehen.

Erstellen eines Integritätsmodells

Verwenden Sie die Daten, die Sie für Ihre Zuverlässigkeitsziele gesammelt haben, um Ihr Integritätsmodell für jede Workload und die zugehörigen kritischen Flows zu erstellen. Ein Integritätsmodell definiert die integrierten, beeinträchtigten und fehlerhaften* Zustände der Flows und Workloads. Die Länder sorgen für eine entsprechende betriebliche Priorisierung. Dieses Modell wird auch als Ampelmodell bezeichnet. Das Modell ordnet Grün für fehlerfrei, Gelb für beeinträchtigt und Rot für fehlerhaft zu. Ein Integritätsmodell stellt sicher, dass Sie wissen, wann sich der Zustand eines Flows von „fehlerfrei“ in „beeinträchtigt“ oder „fehlerhaft“ ändert.

Wie Sie fehlerfreie, beeinträchtigte und fehlerhafte Zustände definieren, hängt von Ihren Zuverlässigkeitszielen ab. Hier sind einige Beispiele für die Definition der Zustände:

• Ein grüner oder fehlerfreier Zustand zeigt an, dass wichtige nichtfunktionale Anforderungen und Ziele vollständig erfüllt sind und die Ressourcen optimal genutzt werden.

• Ein gelber oder beeinträchtigter Zustand gibt an, dass eine oder mehrere Komponenten des Flows einen Alarm auslösen, wenn ihr definierter Schwellenwert erreicht wird, der Flow jedoch betriebsbereit ist. Beispielsweise wurde eine Speicherdrosselung erkannt.

• Ein roter oder fehlerhafter Zustand weist darauf hin, dass die Verschlechterung länger angehalten hat, als Ihre Zuverlässigkeitsziele zulassen, oder dass der Datenflow nicht mehr verfügbar ist.

Anmerkung

Das Integritätsmodell sollte nicht alle Fehler gleich behandeln. Das Integritätsmodell sollte zwischen vorübergehenden und nicht vorübergehenden Fehlern unterscheiden. Es sollte klar zwischen erwarteten vorübergehenden, aber behebbaren Fehlern und einem echten Notfallzustand unterschieden werden.

Dieses Modell funktioniert mithilfe einer Überwachungs- und Warnstrategie, die nach den Grundsätzen der kontinuierlichen Verbesserung entwickelt und umgesetzt wird. Wenn sich Ihre Workloads weiterentwickelt, müssen sich auch Ihre Integritätsmodelle weiterentwickeln.

Ausführliche Anleitungen zu Überwachungs- und Warnkonfigurationen finden Sie in der Anleitung Systemüberwachung.

Visualisierung

Um Ihre Betriebsteams und Workload-Stakeholder über den Echtzeitstatus und die allgemeinen Trends des Workload-Integritätsmodells auf dem Laufenden zu halten, sollten Sie die Erstellung eines Dashboards in Ihrer Überwachungslösung in Betracht ziehen. Besprechen Sie Visualisierungslösungen mit den Stakeholdern, um sicherzustellen, dass Sie ihnen die Informationen liefern, die für sie wichtig sind und die leicht zu verstehen sind. Sie möchten möglicherweise auch wöchentlich, monatlich oder vierteljährlich generierte Berichte sehen.

Power Platform: schnellere Durchführung

Power Platform-SLAs enthalten die Verpflichtungen von Microsoft hinsichtlich Verfügbarkeit und Konnektivität. Verschiedene Dienste haben unterschiedliche SLAs und manchmal haben SKUs innerhalb eines Dienstes unterschiedliche SLAs. Weitere Informationen finden Sie unter Vereinbarungen zum Servicelevel für Onlinedienste.

Das Power Platform-SLA umfasst Verfahren zum Erhalt einer Servicegutschrift bei Nichteinhaltung des SLA sowie Verfügbarkeitsdefinitionen für jeden Service. Dieser Aspekt des SLA dient als Durchsetzungsrichtlinie.

Microsoft Business Applications bietet Business Continuity & Disaster Recovery-Funktionen (BCDR) für alle Produktionstypumgebungen in Dynamics 365 und Power Platform-Saas-Anwendungen. Erfahren Sie, wie Microsoft die Ausfallsicherheit Ihrer Produktionsdaten bei regionalen Ausfällen sicherstellt.

Organisationsausrichtung

Das Cloud Adoption Framework bietet Anleitungen und Empfehlungen für SLOs und SLIs im Zusammenhang mit der Überwachung in der gesamten Organisation.

Weitere Informationen finden Sie unter SLOs für die Cloudüberwachung.

Zuverlässigkeitscheckliste

Lesen Sie die vollständigen Empfehlungen.

Zuverlässigkeits-Checkliste