Empfehlungen zum Definieren von Zuverlässigkeitszielen

  • Artikel

Gilt für die folgende Prüfliste für die Zuverlässigkeit von Azure Well-Architected Framework:

RE:04 Definieren Sie Zuverlässigkeits- und Wiederherstellungsziele für die Komponenten, die Flows und die Gesamtlösung. Visualisieren Sie die Ziele, um zu verhandeln, Konsens zu erzielen, Erwartungen festzulegen und Aktionen voranzutreiben, um den idealen Zustand zu erreichen. Verwenden Sie die definierten Ziele, um das Integritätsmodell zu erstellen. Das Integritätsmodell definiert, wie fehlerfreie, beeinträchtigte und fehlerhafte Zustände aussehen.

In diesem Leitfaden werden die Empfehlungen zum Definieren von Verfügbarkeits- und Wiederherstellungszielmetriken für kritische Workloads und Flows beschrieben. Zuverlässigkeitsziele werden durch Workshopübungen mit Unternehmensbeteiligten abgeleitet. Die Ziele werden durch Überwachung und Tests verfeinert.

Legen Sie mit Ihren internen Stakeholdern realistische Erwartungen an die Zuverlässigkeit der Workload fest, damit Die Stakeholder diese Erwartungen den Kunden durch vertragliche Vereinbarungen mitteilen können. Realistische Erwartungen helfen den Projektbeteiligten außerdem, Ihre Architekturplanungsentscheidungen zu verstehen und zu unterstützen und zu wissen, dass Sie entwerfen, um die Ziele, auf die Sie sich geeinigt haben, optimal zu erreichen.

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

Begriff Definition
Service Level Objective (SLO) Ein Prozentziel, das die Integrität der Komponente und die Zuverlässigkeitsebene darstellt. Je höher die Ebene, desto zuverlässiger ist die Komponente. Zusammengesetztes SLO stellt das aggregierte Ziel der gesamten Workload und konten für die Komponenten-SLOs dar.
Dienstebenenindikator (Service Level Indicator, SLI) Eine von einem Dienst ausgegebene Metrik. SLI-Metriken werden aggregiert, um einen SLO-Wert zu quantifizieren.
Vereinbarung zum Servicelevel (SLA) Eine vertragliche Vereinbarung zwischen dem Dienstanbieter und dem Servicekunden. Die Vereinbarung definiert die SLOs. Die Nichteinhaltung der Vereinbarung kann finanzielle Folgen für den Dienstanbieter haben.
Mittlere Wiederherstellungszeit (MTTR) Die Zeit, die zum Wiederherstellen einer Komponente nach der Erkennung eines Fehlers erforderlich ist.
Mittlere Zeit zwischen Fehler (MTBF) Die Dauer, für die die Workload die erwartete Funktion ohne Unterbrechung ausführen kann, bis sie fehlschlägt.
Recovery Time Objective (RTO) Gibt den maximal zulässigen Zeitraum an, den eine Anwendung nach einem Vorfall nicht verfügbar sein darf.
Recovery Point Objective (RPO) Die maximal zulässige Dauer des Datenverlusts während eines Incidents.

Definieren Sie die Zielwerte der Workload für diese Metriken im Kontext von Benutzer- und Systemflows. Identifizieren und ermitteln Sie diese Flows anhand ihrer Relevanz für Ihre Anforderungen. Verwenden Sie die Werte, um den Entwurf Ihrer Workload in Bezug auf Architektur-, Überprüfungs-, Test- und Incidentverwaltungsvorgänge zu steuern. Die Nichteinhaltung der Ziele wirkt sich auf das Unternehmen über die Toleranzebene hinaus aus.

Wichtige Entwurfsstrategien

Technische Diskussionen sollten nicht dazu führen, wie Sie Zuverlässigkeitsziele für Ihre kritischen Flows definieren. Stattdessen sollten sich die Geschäftsbeteiligten auf die Kunden konzentrieren, wenn sie die Anforderungen einer Workload definieren. Technische Experten helfen den Beteiligten dabei, 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. Interessengruppen schätzen, dass für einen kritischen Benutzerfluss eine Stunde Ausfallzeit während der regulären Geschäftszeiten zu einem Verlust von x Dollar beim monatlichen Umsatz führt. 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 darüber diskutieren, ob das Risiko dieses Umsatzverlustes die zusätzlichen Kosten und den Verwaltungsaufwand überwiegt, die zum Schutz davor erforderlich sind. Befolgen Sie dieses Muster, wenn Sie Flows untersuchen und eine vollständige Liste von Zielen 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.

Höchste Zuverlässigkeits- und Wiederherstellungsanforderungen und korrelierte Metriken können beispielsweise eine Anwendungsverfügbarkeit von 99,9 Prozent für alle Regionen oder eine Ziel-RTO von 5 Stunden für die Region Amerika umfassen. Durch das Definieren dieser Zieltypen können Sie ermitteln, welche kritischen Flows an diesen Zielen beteiligt sind. Anschließend können Sie Ziele auf Komponentenebene in Betracht ziehen.

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

Verfügbarkeitsmetriken

SLOs und SLAs

Verfügbarkeitsmetriken korrelieren mit SLOs, die Sie zum Definieren von SLAs verwenden. Die Workload-SLO bestimmt, wie viele Ausfallzeiten in einem bestimmten Zeitraum tolerierbar sind, z. B. weniger als eine Stunde pro Monat. Um sicherzustellen, dass Sie das SLO-Ziel erreichen können, überprüfen Sie die Microsoft-SLAs für jede Komponente. Achten Sie darauf, wie viel Redundanz Sie benötigen, um hohe SLAs zu erfüllen. Microsoft garantiert beispielsweise höhere SLAs für Bereitstellungen von Azure Cosmos DB in mehreren Regionen als für Bereitstellungen in einer einzelnen Region.

Hinweis

Azure SLAs decken nicht immer alle Aspekte eines Diensts ab. Beispielsweise verfügt Azure Application Gateway über eine Verfügbarkeits-SLA, aber die Azure Web Application Firewall-Funktionalität bietet keine Garantie, um schädlichen Datenverkehr zu verhindern. Berücksichtigen Sie diese Einschränkung, wenn Sie Ihre SLAs und SLOs entwickeln.

Nachdem Sie die SLAs für die einzelnen Workloadkomponenten erfasst haben, berechnen Sie eine zusammengesetzte SLA. Die zusammengesetzte SLA sollte mit dem Ziel-SLO der Workload übereinstimmen. Die Berechnung einer zusammengesetzten SLA umfasst je nach Architekturentwurf mehrere Faktoren. Betrachten Sie die folgenden Beispiele.

Hinweis

Die SLA-Werte in den folgenden Beispielen sind hypothetisch und dienen nur zu Demonstrationszwecken. Sie sind nicht für die Darstellung der aktuellen Werte vorgesehen, die von Microsoft unterstützt werden.

Zusammengesetzte SLAs umfassen mehrere Dienste, die eine Anwendung mit unterschiedlichen Verfügbarkeitsgraden unterstützen. Betrachten Sie beispielsweise eine Azure App Service Web-App, die in Azure SQL Datenbank schreibt. Hypothetisch könnten diese SLAs wie folgt 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 Ausfalls jedes Diensts 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:

Diagramm, das Fallbackpfade zeigt. Im Feld Web-App werden Pfeile angezeigt, die nach SQL-Datenbank oder zu einer Warteschlange verzweigt werden.

In diesem Entwurf ist die Anwendung auch dann verfügbar, wenn keine Verbindung mit der Datenbank hergestellt werden 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. Hier ist die zusammengesetzte SLA für diesen kombinierten Pfad:

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

Die gesamte zusammengesetzte SLA:

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

Dieser Ansatz stellt Kompromisse dar:

  • Die Anwendungslogik ist komplexer.
  • Sie zahlen 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). Wenn die hypothetische SLA für eine Region beispielsweise 99,95 Prozent beträgt:

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

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

Das Definieren von richtigen SLOs erfordert Zeit und sorgfältige Abwägung. 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.

SLA Ausfallzeit pro Woche Ausfallzeit pro Monat Ausfallzeit 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 an zusammengesetzte SLAs im Kontext von Flows denken, denken Sie daran, dass verschiedene Flows unterschiedliche Kritikalitätsdefinitionen aufweisen. Berücksichtigen Sie diese Unterschiede, wenn Sie Ihre zusammengesetzten SLAs erstellen. Nicht kritische Flows enthalten möglicherweise Komponenten, die Sie aus Ihren Berechnungen weglassen sollten, da sie sich nicht auf die Kundenfreundlichkeit auswirken, wenn sie kurz nicht verfügbar sind.

Hinweis

Kundenorientierte Workloads und Workloads zur internen Verwendung weisen unterschiedliche SLOs auf. In der Regel können Workloads mit interner Verwendung viel weniger einschränkende Verfügbarkeits-SLOs als kundenorientierte Workloads aufweisen.

SLIs

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

Um das Sammeln nutzloser Metriken zu vermeiden, beschränken 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 Verfügbarkeitszielen hängen Wiederherstellungsziele für diese Messungen nicht stark von Microsoft-SLAs ab. Microsoft veröffentlicht RTO- und RPO-Garantien nur für einige Produkte, z. B. 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 mit dieser Arbeit fertig sind, besprechen Sie ehrgeizige Ziele mit den Beteiligten, und stellen Sie sicher, dass Ihr Architekturentwurf die Wiederherstellungsziele nach bestem Verständnis unterstützt. Teilen Sie den Beteiligten eindeutig mit, dass alle Flows oder gesamten Workloads, die nicht gründlich auf Wiederherstellungsmetriken getestet werden, keine garantierten SLAs aufweisen sollten. Stellen Sie sicher, dass die Beteiligten verstehen, dass sich die Wiederherstellungsziele im Laufe der Zeit ändern können, wenn Workloads aktualisiert werden. Die Workload kann komplexer werden, wenn Kunden hinzugefügt werden oder wenn Sie neue Technologien einführen, um die Kundenfreundlichkeit zu verbessern. Diese Änderungen können Ihre Wiederherstellungsmetriken erhöhen oder verringern.

Hinweis

MTBF kann schwierig sein, zu definieren und zu garantieren. Platform-as-a-Service (PaaS) oder Software-as-a-Service (SaaS) können ohne Benachrichtigung des Cloudanbieters fehlschlagen und wiederhergestellt werden, und der Prozess kann für Sie oder Ihre Kunden vollständig transparent sein. Wenn Sie Ziele für diese Metrik definieren, decken Sie nur Komponenten ab, die unter Ihrer Kontrolle stehen.

Definieren Sie beim Definieren von Wiederherstellungszielen Schwellenwerte für das 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, wobei Sie berücksichtigen, was die 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 Wiederherstellungsaktionen nicht zu schnell starten. Dokumentieren und teilen Sie die potenziellen Risiken von Wiederherstellungsvorgängen wie Datenverlust oder Sitzungsunterbrechungen für Kunden mit den Beteiligten.

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 fehlerfreie, beeinträchtigte und fehlerhafte Zustände für die Flows und Workloads. Die Zustände stellen eine angemessene operative Priorisierung sicher. Dieses Modell wird auch als Ampelmodell bezeichnet. Das Modell weist grün für fehlerfrei, gelb für degradiert und rot für fehlerhaft zu. Ein Integritätsmodell stellt sicher, dass Sie wissen, wann sich der Zustand eines Flusses von fehlerfrei zu 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 Möglichkeiten, wie Sie die Zustände definieren können:

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

  • Ein gelber oder herabgestufter Zustand gibt an, dass eine oder mehrere Komponenten des Flusses für den definierten Schwellenwert warnungen, der Flow jedoch betriebsbereit ist. Beispielsweise wurde eine Speicherdrosselung erkannt.

  • Ein roter oder fehlerhafter Zustand gibt an, dass die Beeinträchtigung länger als von Ihren Zuverlässigkeitszielen zulässig ist oder dass der Flow nicht mehr verfügbar ist.

Hinweis

Das Integritätsmodell sollte nicht alle Fehler gleich behandeln. Das Integritätsmodell sollte zwischen vorübergehenden und nicht transparenten Fehlern unterscheiden. In jedem Fall muss es jedoch eine Unterscheidung zwischen erwarteten vorübergehenden, aber wiederherstellbaren Fehlern und einem echten Notfallzustand treffen können.

Dieses Modell funktioniert mithilfe einer Strategie zur Überwachung und Warnung, die nach den Prinzipien der kontinuierlichen Verbesserung entwickelt und betrieben wird. Wenn Sich Ihre Workloads weiterentwickeln, müssen Ihre Integritätsmodelle mit ihnen weiterentwickelt werden.

Ausführliche Entwurfsüberlegungen und Empfehlungen für ein mehrstufiges Anwendungsintegritätsmodell finden Sie in den Anleitungen zur Integritätsmodellierung in den Entwurfsbereichen unternehmenskritischer Workloads. Ausführliche Anleitungen zu Überwachungs- und Warnungskonfigurationen finden Sie im Leitfaden zur Integritätsüberwachung .

Visualisierung

Um Ihre Betriebsteams und Workloadbeteiligten über die Echtzeit-status und allgemeinen Trends des Workloadintegritätsmodells zu informieren, sollten Sie in Erwägung ziehen, Dashboards in Ihrer Überwachungslösung zu erstellen. Besprechen Sie Visualisierungslösungen mit den Beteiligten, um sicherzustellen, dass Sie die Informationen bereitstellen, die sie schätzen und die leicht zu nutzen sind. Es kann auch sein, dass die generierten Berichte wöchentlich, monatlich oder vierteljährlich angezeigt werden.

Azure-Erleichterung

Azure SLAs stellen die Microsoft-Verpflichtungen für Betriebszeit und Konnektivität bereit. Verschiedene Dienste weisen unterschiedliche SLAs auf, und manchmal weisen SKUs innerhalb eines Diensts unterschiedliche SLAs auf. Weitere Informationen finden Sie unter Vereinbarungen zum Servicelevel für Onlinedienste.

Die Azure-SLA umfasst 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.

Prüfliste für zuverlässigkeit

Weitere Informationen finden Sie im vollständigen Satz von Empfehlungen.

Prüfliste für zuverlässigkeit