Empfehlungen zum Definieren von Zuverlässigkeitszielen

Gilt für diese Empfehlung für die Zuverlässigkeitsprüfliste des Azure Well-Architected Framework:

In diesem Leitfaden werden die Empfehlungen zum Definieren von Verfügbarkeits- und Wiederherstellungszielmetriken für kritische Workloads und Flüsse beschrieben. Die Zuverlässigkeitsziele werden in Workshops mit den Interessengruppen des Unternehmens erarbeitet. Die Ziele werden durch Überwachung und Tests verfeinert.

Legen Sie gemeinsam mit Ihren internen Beteiligten realistische Erwartungen an die Zuverlässigkeit von Workloads fest, damit die Beteiligten diese Erwartungen über vertragliche Vereinbarungen an Kund(inn)en weitergeben können. Realistische Erwartungen helfen den Projektbeteiligten auch, Ihre Architekturgestaltungsentscheidungen zu verstehen und zu unterstützen und zu wissen, dass Sie entwerfen, um die von Ihnen vereinbarten Ziele optimal zu erfüllen.

Erwägen Sie die Verwendung der folgenden Metriken, um die Geschäftsanforderungen zu quantifizieren.

Definieren Sie die Zielwerte der Workload für diese Metriken im Kontext von Benutzerflüssen und Systemflüssen. Identifizieren und ermitteln Sie diese Flüsse , indem Sie feststellen, wie wichtig sie für Ihre Anforderungen sind. Verwenden Sie die Werte, um den Entwurf Ihrer Workload in Bezug auf Architektur, Überprüfung, Tests und Vorfallverwaltungsvorgänge zu fördern. Wenn die Ziele nicht erfüllt werden, wirkt sich das Unternehmen über die Toleranzstufe hinaus aus.

Wichtige Entwurfsstrategien

Technische Diskussionen sollten nicht dazu führen, wie Sie Zuverlässigkeitsziele für Ihre kritischen Abläufe definieren. Stattdessen sollten sich die Geschäftsbeteiligten auf Kunden konzentrieren, während sie die Anforderungen einer Workload definieren. Technische Experten helfen den Beteiligten, realistische numerische Werte zuzuweisen, die mit diesen Anforderungen korrelieren. Während sie Wissen teilen, ermöglichen technische Experten Verhandlungen und gegenseitigen Konsens über realistische SLOs.

Betrachten Sie ein Beispiel für die Zuordnung von Anforderungen zu messbaren numerischen Werten. Die Projektbeteiligten schätzen, dass für einen kritischen Benutzerfluss eine Stunde Ausfallzeiten während regulärer Geschäftszeiten zu einem Verlust von X-Dollar im monatlichen Umsatz führen. Dieser Dollarbetrag wird mit den geschätzten Kosten für die Entwicklung eines Flusses verglichen, der eine Verfügbarkeits-SLO von 99,95 Prozent anstelle von 99,9 Prozent aufweist. Entscheidungsträger müssen diskutieren, ob das Risiko dieses Umsatzverlusts den zusätzlichen Kosten- und Verwaltungsaufwand überwiegt, die zum Schutz vor ihnen erforderlich sind. Befolgen Sie dieses Muster, während Sie Flüsse untersuchen und eine vollständige Liste der Ziele erstellen.

Denken Sie daran, dass sich Zuverlässigkeitsziele von Leistungszielen unterscheiden. Zuverlässigkeitsziele konzentrieren sich auf Verfügbarkeit und Wiederherstellung. Um Zuverlässigkeitsziele festzulegen, definieren Sie zunächst die umfassendsten Anforderungen und definieren dann spezifischere Metriken, um die allgemeinen Anforderungen zu erfüllen.

Zuverlässigkeits- und Wiederherstellungsanforderungen auf höchster Ebene und korrelierte Metriken können beispielsweise eine Anwendungsverfügbarkeit von 99,9 Prozent für alle Regionen oder ein Ziel-RTO von 5 Stunden für die Region Amerika umfassen. Durch das Definieren dieser Zieltypen können Sie ermitteln, welche kritischen Flüsse an diesen Zielen beteiligt sind. Anschließend können Sie Ziele auf Komponentenebene berücksichtigen.

Kompromiss: Eine konzeptionelle Lücke kann zwischen den technischen Einschränkungen der Komponenten Ihrer Workload und dem, was für das Unternehmen bedeutet, z. B. Durchsatz in Megabits pro Sekunde im Vergleich zu Transaktionen pro Sekunde bestehen. Das Erstellen eines Modells zwischen diesen beiden Ansichten kann eine Herausforderung darstellen. Anstatt die Lösung zu überschreiben, versuchen Sie, sie wirtschaftlich, aber sinnvoll anzugehen.

Verfügbarkeitsmetriken

SLOs und SLAs

Ein SLO ist ein Maß für die Leistung und Zuverlässigkeit einer Workload oder Anwendung. Ein SLO ist ein spezifisches messbares Ziel, das für bestimmte Kundeninteraktionen festgelegt ist. Es ist ein Ziel, das Sie für Ihre Workload oder Anwendung für die Qualität des Diensts festlegen, die Ihre Benutzer erwarten sollten.

Ein SLO kann in Bezug auf eine Vielzahl von Metriken definiert werden, z. B. Verfügbarkeit, Antwortzeit, Durchsatz, Erfolgsrate und andere. Ein SLO für einen Webdienst kann beispielsweise sein, dass er benutzern innerhalb von 500 Millisekunden 99,9 % der Zeit in einem bestimmten Monat zur Verfügung steht oder dass er auf 95 % der Anforderungen innerhalb von 500 Millisekunden antwortet.

Bevor Sie die SLOs für Ihre Anwendung oder Arbeitsauslastung definieren, überprüfen Sie die von Microsoft veröffentlichten SLAs für die zugrunde liegenden Dienste, auf denen Ihre Anwendung oder Workload gehostet wird.

Achten Sie beim Überprüfen der SLA für jeden Dienst darauf, wie viel Redundanz Sie benötigen, um hohe SLAs zu erfüllen. Microsoft garantiert z. B. höhere SLAs für Multi-Region-Bereitstellungen von Azure Cosmos DB, als sie für Bereitstellungen mit einer Region garantiert.

Nachdem Sie die SLAs für die einzelnen Workloadkomponenten gesammelt haben, berechnen Sie ein zusammengesetztes SLA. Die zusammengesetzte SLA sollte mit dem Ziel-SLO der Workload übereinstimmen. Die Berechnung eines zusammengesetzten SLA umfasst mehrere Faktoren, je nach Architekturdesign. Betrachten Sie die folgenden Beispiele.

Zusammengesetzte SLAs umfassen mehrere Dienste, die eine Anwendung unterstützen, mit unterschiedlichen Verfügbarkeitsstufen. Betrachten Sie beispielsweise eine Azure-App Service-Web-App, die in Azure SQL-Datenbank schreibt. Hypothetisch können diese SLAs folgendes sein:

• App Service Web Apps = 99,95 Prozent
• SQL-Datenbank = 99,99 Prozent

Was ist die maximale Ausfallzeit, die Sie für diese Anwendung erwarten können? Wenn einer der Dienste ausfällt, kommt es zu einem Ausfall der gesamten Anwendung. Die Wahrscheinlichkeit eines Dienstausfalls ist unabhängig, sodass die zusammengesetzte SLA für diese Anwendung 99,95 Prozent × 99,99 Prozent = 99,94 Prozent beträgt. Dieser Wert ist niedriger als die einzelnen SLAs. Diese Schlussfolgerung ist nicht überraschend, da eine Anwendung, die auf mehreren Diensten basiert, mehr potenzielle Fehlerpunkte aufweist.

Sie können die zusammengesetzte Vereinbarung zum Servicelevel verbessern, indem Sie unabhängige Fallbackpfade erstellen. Wenn SQL-Datenbank beispielsweise nicht verfügbar ist, können Transaktionen zur späteren Verarbeitung in eine Warteschlange eingereiht werden:

In diesem Design ist die Anwendung weiterhin verfügbar, auch wenn sie keine Verbindung mit der Datenbank herstellen kann. Es schlägt jedoch fehl, wenn die Datenbank und die Warteschlange gleichzeitig fehlschlagen. Der erwartete Prozentsatz der Zeit für einen gleichzeitigen Fehler beträgt 0,0001 × 0,001. Dies ist also die zusammengesetzte SLA für diesen kombinierten Pfad:

Datenbank oder Warteschlange = 1,0 − (0,0001 × 0,001) = 99,99999 Prozent

Die gesamt zusammengesetzte SLA:

Web-App und (Datenbank oder Warteschlange) = 99,95 Prozent × 99,99999 Prozent = ~99,95 Prozent

Dieser Ansatz stellt Gegensätze dar:

• Die Anwendungslogik ist komplexer.
• Sie bezahlen für die Warteschlange.
• Sie müssen Probleme mit der Datenkonsistenz berücksichtigen.

Für Bereitstellungen mit mehreren Regionen wird die zusammengesetzte SLA wie folgt berechnet:

• N ist die zusammengesetzte SLA für die Anwendung, die in einer Region bereitgestellt wird.

• R ist die Anzahl der Regionen, in denen die Anwendung bereitgestellt wird.

Die Wahrscheinlichkeit, dass die Anwendung in allen Regionen gleichzeitig fehlschlägt, beträgt ((1 – N) ^ R). Beispiel: Wenn die hypothetische Sla für einzelne Regionen 99,95 Prozent beträgt:

• Die kombinierte SLA für zwei Regionen = (1 − (1 − 0,9995) ^ 2) = 99,999975 %

• Die kombinierte SLA für vier Regionen = (1 − (1 − 0,9995) ^ 4) = 99,999999 Prozent

Das Definieren der richtigen SLOs erfordert Zeit und sorgfältige Überlegungen. Geschäftsbeteiligte sollten verstehen, wie wichtige Kunden die App verwenden. Sie sollten auch die Zuverlässigkeitstoleranz verstehen. Dieses Feedback sollte die Ziele informieren.

SLA-Werte

In der folgenden Tabelle werden allgemeine SLA-Werte definiert.

Wenn Sie über zusammengesetzte SLAs im Kontext von Flüssen nachdenken, denken Sie daran, dass verschiedene Flüsse unterschiedliche Kritischitätsdefinitionen aufweisen. Berücksichtigen Sie diese Unterschiede beim Erstellen ihrer zusammengesetzten SLAs. Nicht kritische Flüsse können Komponenten aufweisen, die Sie aus Ihren Berechnungen weglassen sollten, da sie sich nicht auf die Benutzererfahrung auswirken, wenn sie kurz nicht verfügbar sind.

SLIs

Stellen Sie sich SLIs als Metriken auf Komponentenebene vor, die zu einem SLO beitragen. Die wichtigsten SLIs sind diejenigen, die ihre kritischen Abläufe aus sicht Ihrer Kunden beeinflussen. Für viele Flüsse umfassen SLIs Latenz, Durchsatz, Fehlerrate und Verfügbarkeit. Eine gute SLI hilft Ihnen zu erkennen, wann ein SLO gefährdet ist, verletzt zu werden. Korrelieren Sie die SLI nach Möglichkeit mit bestimmten Kunden.

Um das Sammeln nutzloser Metriken zu vermeiden, beschränken Sie die Anzahl der SLIs für jeden Fluss. Ziel ist nach Möglichkeit drei SLIs pro Fluss.

Wiederherstellungsmetriken

Wiederherstellungsziele entsprechen den Metriken RTO, RPO, MTTR und MTF. Im Gegensatz zu Verfügbarkeitszielen sind Wiederherstellungsziele für diese Messungen nicht stark von Microsoft SLAs abhängig. Microsoft veröffentlicht RTO- und RPO-Garantien nur für einige Produkte wie SQL-Datenbank.

Definitionen für realistische Wiederherstellungsziele basieren auf ihrer Fehlermodusanalyse und Ihren Plänen und Tests für Geschäftskontinuität und Notfallwiederherstellung. Bevor Sie diese Arbeit abgeschlossen haben, besprechen Sie zielgerechte Ziele mit den Projektbeteiligten, und stellen Sie sicher, dass Ihr Architekturdesign die Wiederherstellungsziele am besten unterstützt. Weisen Sie den Projektbeteiligten klar zu, dass alle Flüsse oder gesamten Workloads, die nicht gründlich auf Wiederherstellungsmetriken getestet werden, keine garantierten SLAs aufweisen sollten. Stellen Sie sicher, dass die Projektbeteiligten verstehen, dass sich die Wiederherstellungsziele im Laufe der Zeit ändern können, wenn Arbeitslasten aktualisiert werden. Die Arbeitsauslastung kann komplexer werden, wenn Kunden hinzugefügt werden, oder wenn Sie neue Technologien einführen, um die Kundenerfahrung zu verbessern. Diese Änderungen können Ihre Wiederherstellungsmetriken erhöhen oder verringern.

Definieren Sie beim Definieren von Wiederherstellungszielen Schwellenwerte zum Initiieren einer Wiederherstellung. Wenn beispielsweise ein Webknoten länger als 5 Minuten nicht verfügbar ist, wird dem Pool automatisch ein neuer Knoten hinzugefügt. Definieren Sie Schwellenwerte für alle Komponenten, und berücksichtigen Sie, welche Wiederherstellung für eine bestimmte Komponente umfasst, einschließlich der Auswirkungen auf andere Komponenten und Abhängigkeiten. Ihre Schwellenwerte sollten auch vorübergehende Fehler berücksichtigen, um sicherzustellen, dass Sie keine Wiederherstellungsaktionen zu schnell starten. Dokumentieren und teilen Sie die Projektbeteiligten mit den potenziellen Risiken von Wiederherstellungsvorgängen, z. B. Datenverlust oder Sitzungsunterbrechungen für Kunden.

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 Flüsse zu erstellen. Ein Integritätsmodell definiert fehlerfreie, herabgestufte und fehlerhafte Zustände für die Flüsse und Workloads. Die Staaten stellen eine angemessene operative Priorisierung sicher. Dieses Modell wird auch als Ampelmodell bezeichnet. Das Modell weist grün für fehlerfreie, gelb für herabgestufte und rot für ungesunde Probleme zu. Ein Integritätsmodell stellt sicher, dass Sie wissen, wann sich der Zustand eines Flusses von "fehlerfrei" in "beeinträchtigt" oder "ungesund" ändert.

Wie Sie fehlerfreie, herabgestufte und ungesunde Zustände definieren, hängt von Ihren Zuverlässigkeitszielen ab. Im Folgenden finden Sie einige Beispiele für Möglichkeiten zum Definieren der Zustände:

• Ein grüner oder fehlerfreier Zustand gibt an, dass wichtige nicht funktionsfreie Anforderungen und Ziele vollständig erfüllt sind und ressourcen optimal verwendet werden. Beispielsweise werden 95 Prozent der Anforderungen in <=500 ms mit Azure Kubernetes Service (AKS)-Knoten bei X Prozent verarbeitet.

• Ein gelber oder herabgestufter Zustand weist darauf hin, dass mindestens eine Komponente des Flusses vor ihrem definierten Schwellenwert warnt, der Fluss ist jedoch betriebsbereit. So wurde beispielsweise die Speicherdrosselung erkannt.

• Ein roter oder ungesunder Zustand gibt an, dass die Beeinträchtigung länger als zulässig durch Ihre Zuverlässigkeitsziele beibehalten wurde oder dass der Fluss nicht mehr verfügbar ist.

Dieses Modell funktioniert mithilfe einer Überwachungs- und Warnstrategie, die entwickelt und auf den Grundsätzen einer kontinuierlichen Verbesserung basiert. Während sich Ihre Workloads entwickeln, müssen sich Ihre Integritätsmodelle mit ihnen weiterentwickeln.

Ausführliche Entwurfsüberlegungen und Empfehlungen für ein mehrschichtiges Anwendungsintegritätsmodell finden Sie in den Entwurfsbereichen für die Integritätsmodellierung in den Entwurfsbereichen für unternehmenskritische Arbeitsauslastungen. Ausführliche Anleitungen zu Überwachungs- und Warnungskonfigurationen finden Sie im Handbuch zur Integritätsüberwachung .

Visualisierung

Um Ihre Betriebsteams und Arbeitsauslastungsbeteiligten über den Echtzeitstatus und die allgemeinen Trends des Workload-Integritätsmodells auf dem Laufenden zu halten, sollten Sie dashboards in Ihrer Überwachungslösung erstellen. Besprechen Sie Visualisierungslösungen mit den Projektbeteiligten, um sicherzustellen, dass Sie die Informationen bereitstellen, die sie wert sind und das einfach zu nutzen ist. Möglicherweise möchten sie auch generierte Berichte wöchentlich, monatlich oder vierteljährlich anzeigen.

Azure-Erleichterung

Azure SLAs bieten die Microsoft-Verpflichtungen für Betriebszeit und Konnektivität. Unterschiedliche Dienste weisen unterschiedliche SLAs auf, und manchmal weisen SKUs innerhalb eines Diensts unterschiedliche SLAs auf. Weitere Informationen finden Sie unter Service level agreements for Onlinedienste.

Die Azure SLA enthält Verfahren zum Abrufen einer Dienstgutschrift, wenn die SLA nicht erfüllt ist, sowie Definitionen der Verfügbarkeit für jeden Dienst. Dieser Aspekt der Vereinbarung zum Servicelevel fungiert als Durchsetzungsrichtlinie.

Verwandte Links

• Gut konzipiertes Framework unternehmenskritische Anleitungen für die Gesundheitsmodellierung: Integritätsmodellierung und Observierbarkeit von unternehmenskritischen Workloads in Azure

Zuverlässigkeitsprüfliste

Lesen Sie den vollständigen Satz von Empfehlungen.