Empfehlungen zum Definieren von Zuverlässigkeitszielen
Gilt für diese Empfehlung für die Zuverlässigkeitsprüfliste des 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 gewinnen, Erwartungen festzulegen und Maßnahmen voranzutreiben, um den idealen Zustand zu erreichen. Verwenden Sie die definierten Ziele, um das Integritätsmodell zu erstellen. Das Integritätsmodell definiert, wie gesunde, herabgestufte und ungesunde Zustände aussehen. |
|---|
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.
| Begriff | Definition |
|---|---|
| Service-Level-Ziel (SLO) | Ein Maß für die Leistung und Zuverlässigkeit einer Workload oder Anwendung. Ein SLO ist ein spezifisches, messbares Ziel, das Sie für bestimmte Kundeninteraktionen festlegen. Es ist ein Ziel, das Sie für Ihre Workload oder Anwendung basierend auf der Qualität des Dienstes festlegen, die Ihre Kunden erwarten. |
| Indikator auf Dienstebene (SLI) | Eine quantitative Messung eines bestimmten Aspekts der Leistung eines Diensts. Sie können eine SLI verwenden, um die Compliance Ihrer Workload mit einem SLO zu messen. |
| Vereinbarung zum Servicelevel (SLA) | Eine vertragliche Vereinbarung zwischen dem Dienstleister und dem Servicekunden. Wenn die Vereinbarung nicht erfüllt wird, kann dies finanzielle Folgen für den Dienstanbieter haben. |
| Mittlere Wiederherstellungszeit (MTTR) | Die Zeit, die zum Wiederherstellen einer Komponente nach dem Erkennen eines Fehlers erforderlich ist. |
| Mittlere Zeit zwischen Ausfall (MOUNTAINBIKEF) | 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 maximale zulässige Dauer des Datenverlusts während eines Vorfalls. |
Wichtige Entwurfsstrategien
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 entsprechen den RTO-, RPO-, MTTR- und MTTR- und MTF-Metriken, 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. Ziel einer praktischen und kosteneffizienten Lösung anstelle von Over engineering.
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.
Workload-Besitzer verwenden finanzielle Ziele, um Ziele zu bestimmen. Geschäftsanforderungen ordnen messbare Metriken zu. Ziel ist es, eine Reihe von Faktoren zu identifizieren, die die Qualität der Kundenerfahrung beeinflussen.
Workload-Architekten treffen viele technische Entscheidungen basierend auf SLOs. SLOs können:
Dienen Sie als kritische Eingabe in Architekturentscheidungen, wenn Sie andere Abhängigkeiten berücksichtigen.
Stellen Sie eine nahezu echtzeitbasierte Ansicht und ein gemeinsames Verständnis der Integrität einer Arbeitsauslastung bereit, 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, automatisierte Benachrichtigungen über Probleme an Kunden fördern und vertrauen zwischen Teams in Ihrer Organisation.
Wichtig
Sie müssen den Unterschied zwischen SLAs und SLOs kennen. Obwohl SLAs und SLOs ähnliche Daten verwenden oder sogar darstellen, ist ihre Absicht unterschiedlich. Ein SLA ist ein formeller Vertrag zwischen einer Organisation und seinen Kunden und hat direkte finanzielle und rechtliche Auswirkungen, wenn die Organisation ihr Versprechen nicht erfüllen kann. Organisationen verwenden SLOs, um zu bewerten, ob die potenzielle Ausfallzeit innerhalb der zulässigen Grenzwerte liegt.
SLOs und SLAs teilen eine Geschäftsbeziehung und sollten unabhängig kontrolliert werden. Wenn die SLA als Geschäftstaktik dient, kann die Organisation sie absichtlich auf einen hohen Wert basierend auf den Zielen des Geschäftsbesitzers festlegen. Umgekehrt können SLOs höher sein. Betrachten Sie unternehmenskritische Workloads als Beispiel. Diese Workloadklasse kann sich keine langen Ausfallzeiten leisten, da die Auswirkungen, einschließlich finanzieller Verluste und sogar Bedrohungen für die menschliche Sicherheit, erheblich sind. Daher zielen SLOs in der Regel auf 99,999 % Uptime ab, die allgemein als die fünf Neuner bezeichnet werden. Wenn SLOs diese Ziele nicht erfüllen, müssen Organisationen schnell reagieren, um Fehler zu mindern und die Ergebnisse einer fehlgeschlagenen SLA zu verhindern.
Das Beispiel in diesem Artikel legt eine hohe SLA zur Unterstützung von Geschäftszielen fest.
Cloudplattform- und Technologieanbieter veröffentlichen SLAs in ihren Angeboten. Sie sollten die SLAs als Teil der SLO-Berechnung in Betracht ziehen, aber sie sollten nicht wie folgt verwenden, ohne den Umfang der SLA-Abdeckung zu verstehen. Weitere Informationen finden Sie unter Bewerten der Auswirkungen von Microsoft SLAs.
Ziehen Sie allgemeine SLOs und Einflussfaktoren in Betracht
Jedes SLO zielt auf ein bestimmtes Qualitätskriterium ab. Berücksichtigen 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 der Drosselungsbasierten 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 Antworten aus der folgenden Tabelle, um den gesamtlastigen SLO abzuleiten. Verwenden Sie diese Fragen als Beispiele, um das Dienstprogramm der Workloadkomponente zu bewerten.
| Komponentenmerkmale | Kundeninteraktion | Andere Faktoren |
|---|---|---|
| - Macht sie Anforderungs- oder Antwort-APIs verfügbar ? - Gibt es Abfrage-APIs? - Handelt es sich um eine Computekomponente ? - Handelt es sich um eine Auftragsverarbeitungskomponente ? |
- Steuern des Flugzeug- und Verwaltungsebenenzugriffs für öffentlich zugängliche Azure-Dienste. - Zugriff auf Datenebenen, z. B. Erstellen, Lesen, Aktualisieren und Löschen (CRUD)-Vorgänge. |
- Umfasst Ihr Veröffentlichungsprozess Ausfallzeiten? - Welche Wahrscheinlichkeit besteht in der Einführung von Fehlern? Wenn die Workload in andere Systeme integriert ist, müssen Sie möglicherweise Integrationsfehler in Betracht ziehen. – Wie wirken sich Routinevorgänge wie Patching auf das Verfügbarkeitsziel aus? Haben Sie sich in Partnerabhängigkeiten eingetan? - Reicht Ihr Personal aus, um eine ständige Notfall- und Notfallsicherung bei der Anrufdrehung zu unterstützen? - Hat die Anwendung laute Nachbarn außerhalb Ihres Kontrollbereichs, die potenziell Störungen verursachen können? |
Ermitteln des SLO-Bereichs
Sie können SLOs auf verschiedenen Ebenen festlegen, z. B. für jede Anwendung, Arbeitsauslastung oder einen bestimmten Fluss in Ihrem System. Legen Sie levelspezifische SLOs fest, damit Sie SLOs basierend auf der Wichtigkeit jeder Komponente anpassen können.
Messen Sie in SaaS-Lösungen (Software as a Service) SLOs pro Kunde, um die Benutzerfreundlichkeit 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 mehrinstanzenfähige Lösung.
Definieren zusammengesetzter SLO-Ziele
SLOs müssen innerhalb eines Observability-Fensters messbar und gemessen werden.
SLOs sind häufig Prozentsätze wie 99,90 %, können aber auch Anweisungen 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 bei der Steuerung des Flugzeugzugriffs Fehlerraten und Latenz für API-Antworten und lange ausgeführte Vorgänge wie die Ressourcenerstellung. Der Datenebenenzugriff hängt von den verwendeten APIs ab, die jeweils mit ihren eigenen SLO-Zielen verwendet werden.
Eine gute SLI zeigt, wann Sie eine SLO verletzen können. Es wird in der Regel in Quantilen gemessen. Hier sind einige häufig verwendete Quantile und die geschätzte Zeit der Nichtkompatibilität mit der erwarteten Verfügbarkeit.
| Ziel | Nichtkompatibilität pro Woche | Nichtcompliance pro Monat | Nichtcompliance pro Jahr |
|---|---|---|---|
| 99 % | 1,68 Stunden | 7.20 Stunden | 3,65 Tage |
| 99,90 % | 10,10 Minuten | 43,20 Minuten | 8,76 Stunden |
| 99,95 % | 5 Minuten | 21,60 Minuten | 4,38 Stunden |
| 99,99 % | 1,01 Minuten | 4,32 Minuten | 52,56 Minuten |
| 99,999% | 6 Sekunden | 25,90 Sekunden | 5,26 Minuten |
Wichtig
Ein zusammengesetzter SLO-Wert ist eine Produktverteilung der beitragenden Faktoren.
Ein Beispiel für einen zusammengesetzten SLO ist 99,95 % × 99,99999 % = ~99,95 %.
Wenn Sie zusammengesetzte SLOs für unterschiedliche Flüsse erstellen, sollten Sie deren unterschiedliche Kritischität und Relevanz berücksichtigen. Flüsse weisen möglicherweise Komponenten auf, die Sie als nicht kritisch erachen und von Ihren Berechnungen weglassen. Sie können ihre Auslassung rechtfertigen, je nachdem, ob sich ihre kurze Nichtverfügbarkeit auf die Erfahrung des Kunden auswirkt. In einigen Fällen ist eine Komponente möglicherweise nicht für den Anwendungsfall relevant, den Sie für das SLO in Betracht ziehen. Sie können diese Komponenten auch aus der Berechnung weglassen.
Das gleiche Prinzip gilt für Vorgänge. Bestimmte Vorgänge können Risiken oder Auswirkungen auf die SLO haben, andere sind unbedeutend. Die Entscheidung sollte explizit und auf Konsens basieren.
Ein illustratives Beispiel zum Definieren und Messen von SLOs und SLIs finden Sie im Beispielabschnitt .
Bewerten der 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 bewerten, haben Sie ein gutes Verständnis für die Abdeckung, die rund um das veröffentlichte Quantil bereitgestellt wird.
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 berücksichtigen, die nicht explizit in der Vereinbarung als beste Leistung der Plattform zur Verfügung stehen.
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 die Verfügbarkeit der Betriebszeit sichern und vorhersagen. 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 Multiregion-Bereitstellungen als separate Bereitstellungen oder Stempel in den einzelnen Regionen. Messen Sie die Integrität der einzelnen Stempel separat, wobei die SLIs, die für Ihre Arbeitsauslastung geeignet sind. Berücksichtigen Sie die SLO Ihrer gesamten Arbeitsauslastung basierend auf der Integrität jedes Stempels. Wenn Sie zwischen Stempeln fehlschlagen können, ist die gesamtlastige SLO höher, da ein Fehler in einem Stempel durch ein Failover zu einem anderen Stempel wiederhergestellt werden kann.
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
Definitionen für realistische Wiederherstellungsziele, z. B. RTO-, RPO-, MTTR- und MOUNTAINBIKEF-Metriken, basieren auf Ihrer Fehlermodusanalyse und Ihren Plänen und Tests für 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. 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 Sie Kunden hinzufügen oder neue Technologien einführen, um die Kundenerfahrung zu verbessern. Diese Änderungen können Ihre Wiederherstellungsmetriken erhöhen oder verringern.
Hinweis
BIKEF kann schwierig sein, zu definieren und zu garantieren. Plattform as a Service (PaaS) oder SaaS-Modelle können ohne Benachrichtigung vom Cloudanbieter fehlschlagen und wiederherstellen, 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 sich unter Ihrem Steuerelement befinden.
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 und teilen Sie die Projektbeteiligten mit den potenziellen Risiken wie Datenverlust oder Sitzungsunterbrechungen für Kunden von Wiederherstellungsvorgängen.
Überwachen und Visualisieren der Ziele
Verwenden Sie die Daten, die Sie für Ihre Zuverlässigkeitsziele sammeln, 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. Wenn sich der Staat ändert, sollte das Modell die verantwortlichen Parteien benachrichtigen. Ausführliche Entwurfsüberlegungen und Empfehlungen finden Sie in den Richtlinien zur Integritätsmodellierung.
Um Ihre Betriebsteams und Arbeitsauslastungsbeteiligten auf dem Laufenden zu halten, erstellen Sie eine Visualisierung, die den Echtzeitstatus und die allgemeinen Trends des Workload-Integritätsmodells widerspiegelt. Besprechen Sie Visualisierungslösungen mit den Projektbeteiligten, um sicherzustellen, dass Sie Informationen bereitstellen, die sie wertbringen und das einfach zu nutzen ist. Möglicherweise möchten sie auch generierte Berichte wöchentlich, monatlich oder vierteljährlich anzeigen.
Umsetzung in Azure
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 der Vereinbarung zum Servicelevel fungiert als Durchsetzungsrichtlinie.
Erkunden Sie die Azure Monitor-Dashboards für Ihr Visualisierungssystem.
Beispiel
Contoso, Ltd. entwickelt eine neue mobile Oberfläche für ihr Ereignisticketing-System. Dies ist die allgemeine 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 verwaltete Instanz gehört und wird von einem anderen Team verwaltet und ist eine wichtige Abhängigkeit der Arbeitsauslastung.
Azure Private Link bietet private Konnektivität zwischen Azure Front Door- und Container-Apps-Bereitstellungen. SQL-verwaltete Instanz wird auch über einen privaten Endpunkt für die Anwendung verfügbar gemacht.
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 Flüsse decken jedoch nicht alle Code- oder Datenzugriffe ab. Hier sind die Einflussfaktoren.
Berechnen eines zusammengesetzten SLO
Azure-Verfügbarkeits-SLO: Die SLA für die finanzielle Verpflichtung für Azure dient als Proxy zur Bewertung der Plattformzulässigkeit.
Azure-Komponente Anwendbare SLA-Abdeckung Nicht von SLA abgedeckt Angepasstes SLO Azure Front Door 99,99 % für erfolgreiche HTTP-Vorgänge GETZwischenspeichern, Regelmodul 99.98% Container-Apps 99,95 % basierend auf bereitgestellten Apps, die vom 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 Zusage des Workloadteams an ihre Ziele abhängen. Ein Faktor könnte das Vertrauen in die Funktion der Plattform sein, basierend auf früheren Erfahrungen. Für Container-Apps und private Links fühlt sich das Team beispielsweise wohl, den SLA-Wert wie folgt 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 häufige Ausfallzeiten quantile , um den SLO für einzelne Faktoren wie Codefehler, Skalierungsprobleme und andere codebezogene Überlegungen zu schätzen.
Ein zusammengesetztes SLO basierend auf Code und Datenverfügbarkeit: 99,86 % pro Monat.
Ressourcen- und AnwendungskonfigurationS-SLO: Das Team erkennt, dass Cloudressourcen 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.
Externe Abhängigkeiten SLO: Das Team berücksichtigt SQL-verwaltete Instanz als primäre Abhängigkeit, die bereits eine Verfügbarkeit von 99,80 % in die Gesamtverfügbarkeit der Plattform hat. Es werden keine anderen externen Abhängigkeiten berücksichtigt.
Ein zusammengesetztes SLO basierend auf externen Abhängigkeiten: Nicht zutreffend.
Ermitteln des gesamt zusammengesetzten SLO-Ergebnisses
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 erfüllen, richtet das Workloadteam eine Drehung im Anruf 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.
Festlegen der Korrektheit von SLO
Die Wichtigsten Benutzerflüsse der Anwendung müssen verfügbar sein und selbst wettbewerbsfähig und reaktionsfähig sein. Das Team legt eine Antwortzeit SLO speziell für die API fest, mit Ausnahme von Clientverarbeitungszeit und Internetnetzwerk-Traversal. Sie bewerten diesen SLO nur während der Verfügbarkeit. Sie wählen das 75. Quantil sowohl als SLO-Ziel als auch als Leistungsmessung aus, das die typische Kundenerfahrung erfasst und Worst-Case-Szenarien ausschließt.
Verwandte Links
Integritätsmodellierung und Beobachtbarkeit von unternehmenskritischen Workloads in Azure
Zuverlässigkeitsprüfliste
Lesen Sie den vollständigen Satz von Empfehlungen.