Architekturstrategien 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. Sie sollten Zuverlässigkeitsziele von Workshopübungen mit Geschäftsbeteiligten ableiten. Verfeinern Sie diese Ziele dann, indem Sie Ihre Workloads überwachen und testen.

Legen Sie realistische Erwartungen an Ihre internen Projektbeteiligten hinsichtlich der Arbeitsauslastungssicherheit fest. Dann können sie vertragliche Vereinbarungen verwenden, um diese Erwartungen den Kunden mitzuteilen. Realistische Erwartungen helfen den Projektbeteiligten auch, Ihre Architekturentwurfsentscheidungen zu verstehen und zu unterstützen und zu wissen, dass Sie entwerfen, um die Ziele, die Sie vereinbaren, optimal zu erfüllen.

Erwägen Sie die Verwendung der folgenden Metriken, um Ihre Geschäftlichen Anforderungen zu quantifizieren.

Zuverlässigkeitsziele stellen das gewünschte Qualitätsziel einer Arbeitsauslastung dar, wie den Benutzern und den Geschäftsbeteiligten versprochen. Dieses Ziel umfasst sowohl die Verfügbarkeit als auch die Wiederherstellbarkeit der Workload. Denken Sie daran, dass Zuverlässigkeitsziele von Leistungszielen abweichen, aber Sie sollten Leistungsziele in Zuverlässigkeitsziele einschließen. Berücksichtigen Sie die folgenden Zuverlässigkeitsziele:

• Verfügbarkeitsziele definieren die Qualitätsstandards für ein System, um barrierefrei und funktionsfähig zu bleiben. Wenn sie diese Standards nicht erfüllt, gilt das System als unzuverlässig. Verwenden Sie SLOs, um zu überprüfen, ob Ihr System diese Standards erfüllt. Geschäfts- und technische Projektbeteiligte arbeiten zusammen, um realistische SLOs festzulegen und Faktoren wie vergleichende Analyse, Benutzererfahrung und Workloadprofil zu berücksichtigen.

• Korrektheitsziele stellen sicher, dass die Arbeitsauslastung ihre Funktionen ordnungsgemäß mit konsistenter Qualität ausführt. Um die Korrektheit zu messen, quantifizieren Sie die Indikatoren der Arbeitsauslastung, damit Sie sie in einer einheitlichen, objektiven Bewertung kombinieren können.

• Wiederherstellungsziele beziehen sich auf die Kennzahlen RTO, RPO, MTTR und MTBF, die die Effektivität Ihrer Pläne und Tests für Geschäftskontinuität und Notfallwiederherstellung quantifizieren.

Um Zuverlässigkeitsziele festzulegen, definieren die Unternehmensbeteiligten allgemeine Anforderungen. Anschließend bewerten technische Experten den aktuellen Zustand der Arbeitsauslastung und arbeiten daran, Ziele durch Überwachung und Warnungen zu erreichen und aufrechtzuerhalten. Beide Parteien müssen sich auf realistische Ziele einigen.

Identifizieren und bewerten Sie Benutzer- und Systemflüsse basierend auf ihrer Bedeutung für Ihre Geschäftlichen Anforderungen. Verwenden Sie diese Bewertungen, um den Entwurf, die Überprüfung, das Testen und die Vorfallverwaltung Ihrer Workload zu unterstützen. Legen Sie Zuverlässigkeitsziele für diese Flüsse fest, und verstehen Sie, dass sich das Scheitern dieser Ziele erheblich auf Ihr Unternehmen auswirken kann.

Tradeoff: Möglicherweise besteht eine Lücke zwischen den technischen Grenzen Ihres Systems und seinen geschäftlichen Auswirkungen, z. B. Durchsatz und Transaktionen pro Sekunde. Das Überbrücken dieser Lücke kann schwierig sein. Setzen Sie auf eine praktische und kosteneffiziente Lösung statt auf Overengineering.

Festlegen von Verfügbarkeitszielen

Die gesamte SLO einer Arbeitsauslastung spiegelt die ganzheitliche Qualität wider, einschließlich aller Abhängigkeiten. Eine ausgereifte Deklaration des SLO sollte das allgemeine Geschäftsziel für diese Workload angeben, nicht nur eine Kombination dieser Abhängigkeiten. Wenn Kunden beispielsweise eine Verfügbarkeit von 99,99 % erwarten, sollte der Gesamt-SLO auf dieses Ziel abzielen, auch wenn ein Teil nur 99,80 % erreicht.

Interessengruppen bewerten die Kundenerfahrung und überlegen, wie sich Ausfallzeiten auf den Umsatz auswirken. Sie vergleichen diesen Verlust mit den Kosten für das Entwerfen und Betreiben des Geschäftsflusses. Entscheidungsträger entscheiden dann, ob sie mehr Geld für Zuverlässigkeit ausgeben sollten, um Umsatzverluste zu vermeiden und ihren Ruf aufrechtzuerhalten.

Verantwortliche für Workloads nutzen finanzielle Zielvorgaben, um Zielsetzungen festzulegen. Geschäftsanforderungen werden messbaren Kennzahlen zugeordnet. Ziel ist es, eine Reihe von Faktoren zu identifizieren, die die Qualität der Kundenerfahrung beeinflussen.

Workload-Architekten treffen viele technische Entscheidungen auf der Grundlage von SLOs. SLOs ermöglichen Folgendes:

• Nutzen Sie dies als wichtige Grundlage für architektonische Entscheidungen, wenn Sie andere Abhängigkeiten berücksichtigen.

• Sie bieten eine nahezu Echtzeit-Ansicht und ein gemeinsames Verständnis des Zustands eines Workloads, um objektive Diskussionen zu ermöglichen. Außerdem helfen sie dem Workload-Team, Anstrengungen zur Verbesserung der Zuverlässigkeit zu priorisieren und neue Features zu entwickeln.

• Dient als primäres Signal für Bereitstellungsvorgänge, die das automatisierte Rollback bei Auftreten von Problemen vorantreibt, und stellt eine Überprüfung bereit, dass die Änderungen die erwarteten Verbesserungen an der Kundenerfahrung erzielen.

• Beschleunigen Sie die Behebung und Wiederherstellung, indem Sie sich auf Ziele konzentrieren, automatische Benachrichtigungen an Kunden über Probleme veranlassen und Vertrauen zwischen Teams in Ihrer Organisation aufbauen.

Ziehen Sie allgemeine SLOs und Einflussfaktoren in Betracht

Jedes SLO zielt auf ein bestimmtes Qualitätskriterium ab. Betrachten Sie diese gängigen SLOs für Zuverlässigkeit. Die Liste ist nicht vollständig. Fügen Sie SLOs basierend auf Ihren geschäftlichen Anforderungen hinzu.

• Die Erfolgsquote misst den Erfolg von Anforderungen und Prozessen relativ zu denen, die einen Fehler zurückgeben oder ihre Aufgabe fehlschlagen.

• Die Latenz misst den Zeitraum zwischen dem Initiieren einer Anforderung für einen Vorgang und dem Zeitpunkt, zu dem das Ergebnis verfügbar ist oder der Prozess abgeschlossen ist.

• Kapazität misst die gleichzeitige Nutzung, z. B. die Anzahl drosselungsbedingter Antworten.

• Verfügbarkeit misst die Betriebszeit aus Sicht der Kunden.

• Der Durchsatz misst die minimale Datenübertragungsrate während einer bestimmten Zeitspanne. Der Durchsatz wird als Datenrateeinheit gemessen, z. B. Transaktionen pro Sekunde (TPS) oder Anforderungen pro Sekunde (RPS).

Verstehen Sie die Szenarien und Toleranzen für Ihre Workload in Azure. Sowohl Azure-Dienste als auch Anwendungskomponenten wirken sich auf die Arbeitsauslastung SLO aus. Kombinieren Sie die Antworten aus der folgenden Tabelle, um das gesamte SLO abzuleiten. Verwenden Sie diese Fragen als Beispiele, um den Nutzen der Workload-Komponente zu bewerten.

SLO-Umfang bestimmen

Sie können SLOs auf verschiedenen Ebenen festlegen, z. B. für jede Anwendung, Arbeitsauslastung oder einen bestimmten Fluss in Ihrem System. Legen Sie ebenenspezifische SLOs fest, damit Sie SLOs abhängig von der Wichtigkeit jeder Komponente anpassen können.

Messen Sie in Software-as-a-Service-Lösungen (SaaS) die SLOs pro Kunde, um die Customer Experience jedes einzelnen Kunden zu optimieren. Kunden verfügen möglicherweise über unterschiedliche Infrastrukturressourcen in ihren Segmenten. Für solche Fälle ist ein systemweiter SLO, der alle Ressourcen in Kundensegmenten aggregiert, möglicherweise nicht sinnvoll. Messen Sie stattdessen SLOs, die an den spezifischen Kontext jedes Kunden ausgerichtet sind. Weitere Informationen finden Sie unter Mandantenmodelle für eine mandantenfähige Lösung.

Definieren zusammengesetzter SLO-Ziele

SLOs müssen messbar und innerhalb eines Beobachtungsfensters gemessen werden.

SLOs sind häufig Prozentsätze wie 99,90 %, können aber auch Aussagen sein. Verwenden Sie beide Methoden, um einen numerischen Wert abzurufen, der alle Faktoren enthält.

Ein SLO besteht aus messbaren SLIs, die akzeptable Faktoren definieren. SLIs sind Metriken mit einem festgelegten Schwellenwert, der benachrichtigt werden kann. Sie können sie von einer Plattform oder einer Anwendung sammeln. Verschiedene Komponenten geben relevante SLIs aus. Berücksichtigen Sie bei der Auswahl von SLIs Faktoren, die den SLO beeinflussen.

Um z. B. den SLO für einen Fluss zu berechnen, der eine Antwort- und Anforderungs-API verwendet, messen Sie die Serverlatenz und die Anforderungsverarbeitungszeit. Durchsatz und Fehlerraten gelten nicht für fortlaufende Computeumgebungen wie virtuelle Computer (VMs), Skalierungssätze oder Azure Batch.

Berücksichtigen Sie beim Zugriff auf die Steuerungsebene Fehlerraten und Latenzzeiten für API-Antworten sowie für lang andauernde Vorgänge wie die Ressourcenerstellung. Der Datenebenenzugriff hängt von den verwendeten APIs ab, die jeweils mit ihren eigenen SLO-Zielen verwendet werden.

Ein guter SLI zeigt, wann Sie einen SLO gefährden könnten. Üblicherweise wird es in Perzentilen gemessen. Hier sind einige häufig verwendete Perzentile und die geschätzte Dauer der Nichteinhaltung der erwarteten Verfügbarkeit.

Bewerten Sie die Auswirkungen von Microsoft-SLAs

Ein Microsoft SLA bietet Einblicke in die Verfügbarkeit von Bereichen, für die Microsoft sich verpflichtet. SLAs garantieren kein gesamtes Angebot. Wenn Sie SLAs auswerten, sollten Sie sich über die Abdeckung im Bereich des veröffentlichten Prozentsatzes im Klaren sein.

Betrachten Sie Web-Apps, ein Feature von Azure-App Dienst. Das Feature wird als verfügbar betrachtet, wenn in einem bestimmten Anwendungsfall ein Status "200 OK " zurückgegeben wird. Innerhalb dieses spezifischen Kontexts und zeitrahmens deckt es keine finanziell gesicherte Garantie für die Verfügbarkeit von Features wie Easy Auth oder Slot Switching ab. Sie sollten Bereiche, die nicht explizit in der Vereinbarung erwähnt sind, als nach bestem Bemühen der Plattform verfügbar betrachten.

Wenn Ihre Workload also auf Bereitstellungsplätze angewiesen ist, können Sie Ihr SLO nicht ausschließlich von der SLA des App-Diensts ableiten. Als Workload-Team müssen Sie sich absichern und die Verfügbarkeit planen. Diese Vorhersage kann jedoch unsicher sein, weshalb die enge Verknüpfung Ihres SLO mit der SLA der Plattform problematisch sein kann.

Betrachten Sie ein weiteres Beispiel. Wenn Azure Front Door über eine Verfügbarkeit von 99,99 % verfügt, muss Ihr Design bestimmte Kriterien erfüllen, die in der Vereinbarung veröffentlicht werden. Ihr Back-End muss beispielsweise Speicher enthalten, Sie benötigen einen GET Vorgang, der eine Datei mit mindestens 50 KB Größe abrufen kann, und Sie müssen Agents an mehreren Orten an mindestens fünf geografisch unterschiedlichen Standorten bereitstellen. Dieser schmale Anwendungsfall von Azure Front Door garantiert keine Features wie Zwischenspeichern, Routingregeln oder eine Webanwendungsfirewall. Diese Aspekte fallen außerhalb des Umfangs der SLA.

Implementieren von Multiregionszielen

Aus Zuverlässigkeitsperspektive ist die Multiregion-Bereitstellung eine Implementierung des Redundanzprinzips. Ziel ist es, das Risiko eines regionalen Ausfalls oder einer beeinträchtigten Leistung zu verringern. Diese Strategie kann, wenn sie ordnungsgemäß entworfen wurde, SLOs verbessern, da sie eine sekundäre Region für Failoverzwecke hinzufügt.

Es gibt zwei Hauptanwendungsfälle:

• Muster für hohe Verfügbarkeit, bei dem Sie eine Last über Regionen verteilen, um mehr Kapazität zu erzielen. Hohe Verfügbarkeit schränkt Arbeitsauslastungsbenutzer nicht auf eine Region ein, und die Leistung des gesamten Systems trägt zum SLO bei.

• Bulkhead-Muster, in dem Sie Kunden auf bestimmte Regionen beschränken, um sie zu segmentieren. Behandeln Sie in solchen Fällen Bereitstellungen in mehreren Regionen als separate Bereitstellungen oder Stempel in jeder Region. Messen Sie den Zustand jedes Stempels separat mit den SLIs, die für Ihren Workload angemessen sind. Berücksichtigen Sie den SLO Ihres gesamten Workloads auf der Grundlage des Zustands der einzelnen Stempel. Wenn Sie einen Failover zwischen den Stempeln durchführen können, ist der SLO des gesamten Workloads höher, da ein Ausfall in einem Stempel durch einen Failover zu einem anderen Stempel wiederhergestellt werden kann.

Tradeoff: Bestimmen Sie, ob die Risikoreduzierung die zusätzliche Komplexität wert ist. Multiregionsziele führen auch operative Komplexitäten ein, z. B. die Koordination von Bereitstellungen, die Sicherstellung der Datenkonsistenz und die Verarbeitung der Latenz. Diese Vorgänge sind während der Wiederherstellung wichtig. Ihr Team sollte diese Komplexitäten gegen die erhöhte Resilienz abwägen.

Achten Sie darauf, wie viel Redundanz Sie benötigen, um hohe SLOs zu erfüllen. Microsoft garantiert z. B. höhere SLAs für Multiregion-Bereitstellungen von Azure Cosmos DB, als sie für Bereitstellungen mit einer Region garantiert.

Definieren von Wiederherstellungsmetriken

Die Definition realistischer Wiederherstellungsziele, wie RTO-, RPO-, MTTR- und MTBF-Metriken, basiert auf Ihrer Fehlermodusanalyse sowie Ihren Plänen und Tests zur Geschäftskontinuität und Notfallwiederherstellung. Wenn Sie diese Ziele definieren, berücksichtigen Sie die von der Plattform bereitgestellten Wiederherstellungsgarantien. Microsoft veröffentlicht RTO- und RPO-Garantien nur für einige Produkte wie Azure SQL-Datenbank.

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. Kommunizieren Sie den Stakeholdern klar, dass Abläufe oder ganze Workloads, die nicht gründlich im Hinblick auf Wiederherstellungsmetriken getestet wurden, keine garantierten SLAs haben 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 Sie Kunden hinzufügen oder neue Technologien einführen, um die Kundenerfahrung zu verbessern. Diese Änderungen können Ihre Wiederherstellungsmetriken erhöhen oder verringern.

Wenn Sie Wiederherstellungsziele definieren, definieren Sie Schwellenwerte zum Initiieren einer Wiederherstellung. Wenn beispielsweise ein Webknoten länger als fünf Minuten nicht verfügbar ist, fügen Sie dem Pool automatisch einen neuen Knoten hinzu. Definieren Sie Schwellenwerte für alle Komponenten, und überlegen Sie, 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 keine Wiederherstellungsaktionen zu schnell starten. Dokumentieren Sie die potenziellen Risiken von Wiederherstellungsvorgängen, wie Datenverlust oder Sitzungsunterbrechungen für Kunden, und teilen Sie diese mit den Stakeholdern.

Überwachen und Visualisieren der Ziele

Verwenden Sie die Daten, die Sie für Ihre Zuverlässigkeitsziele erfassen, um Ihr Zustandsmodell für jede Workload und die zugehörigen kritischen Abläufe zu erstellen. Ein Zustandsmodell definiert die Zustände funktionsfähig, beeinträchtigt und nicht funktionsfähig für die Flüsse und Workloads. Wenn sich der Staat ändert, sollte das Modell die verantwortlichen Parteien benachrichtigen. Detaillierte Designüberlegungen und Empfehlungen finden Sie unter Leitfaden zur Zustandsmodellierung.

Um Ihre Operations-Teams und die Stakeholder der Workloads auf dem Laufenden zu halten, erstellen Sie eine Visualisierung, die den Echtzeitstatus und die allgemeinen Trends des Workload-Zustandsmodells widerspiegelt. Besprechen Sie Visualisierungslösungen mit den Stakeholdern, um sicherzustellen, dass Sie Informationen bereitstellen, die für sie wertvoll und leicht verständlich sind. Möglicherweise möchten sie auch generierte Berichte wöchentlich, monatlich oder vierteljährlich anzeigen.

Azure-Unterstützung

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

Die Azure SLA enthält Verfahren zum Abrufen einer Dienstgutschrift, wenn Ihre Workload die SLA nicht erfüllt, sowie Definitionen der Verfügbarkeit für jeden Dienst. Dieser Aspekt des Service-Level-Agreements dient als Durchsetzungsregelung.

Erkunden Sie die Azure Monitor-Dashboards für Ihr Visualisierungssystem.

Beispiel

Contoso, Ltd. entwickelt eine neue mobile Oberfläche für ihr Ereignisticketing-System. Hier ist die übergeordnete Architektur.

Das Grafana-Logo ist eine Marke des entsprechenden Unternehmens. Die Verwendung dieser Marke impliziert keine Empfehlung.

Komponenten

Hier sind einige Komponenten, die das Konzept der SLO-Definition veranschaulichen. In dieser Architektur gibt es Komponenten, die nicht in der folgenden Liste enthalten sind. Auch wenn Key Vault Teil des kritischen Anforderungsflusses ist, ist er nicht Teil des Antwortanwendungsfalles. Wenn Key Vault nicht verfügbar ist, funktioniert die Anwendung weiterhin mithilfe von geheimen Schlüsseln, die beim Start geladen werden. Wenn die Anwendung jedoch skalieren muss, wird die Verfügbarkeit von Key Vault kritisch, da neue Knoten mit geheimen Schlüsseln geladen werden müssen. In diesem Beispiel werden Skalierungsvorgänge nicht berücksichtigt. Andere Komponenten werden aus Platzgründen weggelassen.

• Azure Front Door ist der einzige Einstiegspunkt, der eine API verfügbar macht, die Kunden zum Senden von Anforderungen verwenden.

• Azure Container Apps ist die Umgebung, die das Workloadteam besitzt und verwendet, um Geschäftslogik für die Anwendung auszuführen.

• SQL Managed Instance befindet sich im Besitz eines anderen Teams und wird von diesem verwaltet und ist eine kritische Abhängigkeit des Workloads.

• Azure Private Link bietet private Konnektivität zwischen Azure Front Door- und Container-Apps-Bereitstellungen. Die verwaltete SQL-Instanz wird der Anwendung auch über einen privaten Endpunkt bereitgestellt.

In dieser Architektur definiert das API-Team ein anfängliches SLO-Ziel für kritische Flüsse in der Anwendung. Sie übernehmen die Strategie, die in Faktoren beschrieben wird, die SLOs beeinflussen. Sie zielen darauf ab, Ziele zu definieren, die die Kernfunktionalität abdecken, ohne zusätzliche Features zu betonen. Sie messen die Integrität von drei kritischen Benutzerflüssen, die alle kernbasierten Cloudfunktionen umfassen und Code für alle Bereitstellungen ausführen. Diese Abläufe decken jedoch nicht den gesamten Code oder den gesamten Datenzugriff ab. Hier sind die Einflussfaktoren.

Berechnen Sie ein zusammengesetztes SLO.

• Azure-Verfügbarkeits-SLO: Das SLA zur finanziellen Zusage für Azure dient als Indikator zur Bewertung der Plattformzuverlässigkeit.

  Azure-Komponente	Anwendbare SLA-Abdeckung	Nicht von SLA abgedeckt	Angepasstes SLO
  Azure Front Door	99,99 % für erfolgreiche HTTP-Vorgänge GET	Zwischenspeichern, Regel-Engine	99.98%
  Containeranwendungen	99,95 % basierend auf den bereitgestellten Apps, die über den integrierten Ingress erreichbar sind	Automatische Skalierung, Tokenspeicherfunktionen	99,95 %
  SQL Managed Instance	99,99 % basierend auf der Verbindung mit der SQL Server-Instanz	Leistung, Datenaufbewahrung	99,80 %
  Private Link	99,99 % basierend auf ganzen Minuten, wenn das private Endpunktnetzwerk den Datenverkehr nicht akzeptiert hat oder wenn der Datenverkehr nicht zwischen dem Endpunkt und dem Privaten Link-Dienst fließt	Einzelne Fehler, die weniger als eine Minute dauern	99,99 %

  Die Anpassung basiert auf mehreren Faktoren, die von der Verpflichtung des Workload-Teams gegenüber seinen Zielen abhängen. Ein Faktor könnte das Vertrauen in die Funktion der Plattform sein, basierend auf früheren Erfahrungen. Das Team hält es beispielsweise bei Container Apps und Private Link für vertretbar, den SLA-Wert unverändert zu übernehmen.

  Es gibt auch nuancenreiche Faktoren. Beispielsweise senkt das Team den SLO-Wert für SQL-verwaltete Instanz auf 99,80 %, um potenzielle Fehler in ihren Datenvorgängen zu berücksichtigen, z. B. Schemaänderungen und Erstellen von Sicherungen.

  Das Team legt den zusammengesetzten SLO fest, indem die Auswirkungen einzelner, angepasster SLO-Werte berechnet werden. Dieser Wert ist 99,72 %.

  Es gibt weitere Faktoren, die dazu beitragen. Die Architektur basiert auf Azure-Netzwerkkomponenten wie virtuellen Netzwerken und Netzwerksicherheitsgruppen (NSGs), die nicht über eine veröffentlichte SLA verfügen. Das Workloadteam entscheidet, diese Faktoren mit einer Verfügbarkeit von 99,99 % für jede Komponente zu berücksichtigen.

  Ein zusammengesetztes SLO basierend auf der prognostizierten Plattformverfügbarkeit: 99,68 % pro Monat.

• Anwendungscode-SLO: Das Team erkennt an, dass Fehler in ihrem Anwendungscode oder gespeicherten Prozeduren die Systemverfügbarkeit beeinträchtigen können, und sie weisen eine Stunde monatliche Ausfallzeiten zu, um codebezogene Fehler zu berücksichtigen.

  Sie verwenden gängige Ausfallzeit-Perzentile, um den SLO für einzelne Faktoren wie Codefehler, Skalierungsprobleme und andere codebezogene Aspekte zu schätzen.

  Ein zusammengesetztes SLO basierend auf Code und Datenverfügbarkeit: 99,86 % pro Monat.

• SLO für Ressourcen- und Anwendungskonfiguration: Das Team ist sich bewusst, dass Cloud-Ressourcen und Anwendungscode ordnungsgemäß konfiguriert werden müssen. Dieses Ziel umfasst das Einrichten von Regeln für die automatische Skalierung, das Bereitstellen von NSG-Regeln und das Auswählen der richtigen Größe von SKUs. Um Konfigurationsfehler zu berücksichtigen, budgetieren sie 10 Minuten monatliche Ausfallzeiten, was etwa 99,98 % Verfügbarkeit ist.

  Ein zusammengesetztes SLO basierend auf der Konfigurationsverfügbarkeit: 99,95 % pro Monat.

• Operations SLO: Das Workload-Team entwickelt eine gute DevOps-Kultur, indem er den Grundsätzen des Well-Architected Framework for Operational Excellence folgt. Sie stellen Cloudressourcen, Konfiguration und Code für jeden Sprint bereit.

  Das Team hält Bereitstellungen für ein Risiko, da sie ein laufendes System destabilisieren können. Aufgrund von TLS-Zertifikatupdates, DNS-Änderungen oder Toolfehlern können Fehler auftreten. Das Team berücksichtigt auch potenzielle Ausfallzeiten, die durch Notfallfixes verursacht werden. Sie budgetieren insgesamt 20 Minuten monatliche Ausfallzeiten, was ungefähr 99,95 % Verfügbarkeit ist.

  Wartungsfenster sind festgelegte Zeiträume, in denen Systemwartungen oder -updates auftreten. Die API wird meist für ungefähr vier Stunden täglich nicht verwendet. Um das Risiko der Nichtverfügbarkeit zu verringern, kann das Team Wartungsaufgaben während dieser weniger aktiven Stunden planen. Dieser Ansatz führt zu einem höheren SLO, aber das Team entscheidet, das Wartungsfenster nicht als Teil der SLO einzuschließen.

  Ein zusammengesetztes SLO basierend auf der Betriebsverfügbarkeit: 99,95 % pro Monat.

• SLO für externe Abhängigkeiten: Das Team betrachtet SQL Managed Instance als primäre Abhängigkeit, deren Verfügbarkeit von 99,80 % bereits in die Gesamtverfügbarkeit der Plattform eingerechnet ist. Es werden keine anderen externen Abhängigkeiten berücksichtigt.

  Ein zusammengesetztes SLO basierend auf externen Abhängigkeiten: Nicht zutreffend.

Ermitteln Sie das zusammengesetzte SLO-Gesamtergebnis

Das gesamt zusammengesetzte SLO-Ziel wird auf 99,45 % festgelegt, was ungefähr vier Stunden Ausfallzeiten pro Monat entspricht.

Um das SLO-Ziel von nur vier Stunden Nichtverfügbarkeit pro Monat zu erreichen, richtet das Workload-Team eine Rufbereitschaftsrotation ein. Sowohl der Kundensupport als auch die Überwachung synthetischer Transaktionen können die SRE-Unterstützung (On-Call Site Reliability Engineering) aufrufen, um die Wiederherstellungsschritte zur Behebung von SLO-Problemen umgehend zu starten.

Festlegen der SLA für die Arbeitsauslastung

Die SLA für die Workload ist 99,90 % Verfügbarkeit pro Monat.

Die Rechts- und Finanzabteilungen des Workloadteams legen die SLA für die Arbeitsauslastung auf 99,90 % Verfügbarkeit pro Monat fest, was das SLO-Ziel von 99,45 % überschreitet. Sie treffen diese Entscheidung, nachdem sie finanzielle Auszahlungen im Vergleich zu projizierten Kundenwachstum basierend auf einer attraktiven SLA analysiert haben. Das SLA deckt zwei Kernbenutzerflüsse ab und umfasst Leistungsaspekte, nicht nur verfügbarkeit. Es handelt sich um ein berechnetes Risiko, das vom Geschäftsteam zum Nutzen des Unternehmens ergriffen wird, und das Entwicklungsteam ist sich der Verpflichtung bewusst.

Korrektheits-SLO festlegen

Die zentralen Nutzerabläufe der Anwendung müssen verfügbar sowie gut nutzbar und in ihrer Reaktionsgeschwindigkeit wettbewerbsfähig sein. Das Team legt eine Antwortzeit SLO speziell für die API fest, mit Ausnahme von Clientverarbeitungszeit und Internetnetzwerk-Traversal. Sie beurteilen dieses SLO nur in Zeiträumen der Verfügbarkeit. Sie wählen das 75. Perzentil sowohl als SLO-Ziel als auch als Leistungskennzahl, da es die typische Kundenerfahrung abbildet und Extremfälle ausschließt.

Verwandte Links

Integritätsmodellierung für Workloads

Zuverlässigkeitsprüfliste

Lesen Sie den vollständigen Satz von Empfehlungen.