Zuverlässigkeits-Reifegradmodell

Legen Sie eine solide Grundlage für die Resilienz in der Workloadinfrastruktur und im Betrieb fest, anstatt Zeit für Optimierungsaufgaben zu verbringen.

Stufe 1 des Reifemodells wurde entwickelt, um Workloadteams dabei zu helfen, eine starke Grundlage für die Systemzulässigkeit zu schaffen. Der Fokus liegt auf dem Bootstrapping, bei dem es sich um die Einrichtung der Grundlagen für zukünftige Zuverlässigkeitsentscheidungen handelt. In dieser Phase werden hauptsächlich funktionale Implementierungen mit kleineren Erweiterungen für aktuelle Praktiken berücksichtigt.

Diese Phase umfasst Die Recherche, das Gewinnen von Erkenntnissen und das Erstellen eines Inventars Ihrer Systeme. Außerdem werden integrierte Zuverlässigkeitsfeatures in Azure verwendet, z. B. das Aktivieren von Zonenredundanz für sofortige Verbesserungen.

Durch die Festlegung dieser Grundlagen können Sie Ihr Team auf die Stufen des Zuverlässigkeitsreifemodells vorbereiten, um die Resilienz und Leistung Ihres Systems schrittweise zu verbessern.

Schlüsselstrategien

• Auswerten von Möglichkeiten zum Auslagern der operativen Verantwortung

Diese Strategie ist im Grunde eine bauen gegen ein kaufen oder vertrauen Ansatz. Die Entscheidung hängt davon ab, wie viel Verantwortung in dieser Phase verwaltbar ist und gleichzeitig die zukünftige Entwicklung unterstützt. Sie möchten Ressourcen verwenden, die für die Arbeitsauslastung relevant sind, aber Sie sollten immer Möglichkeiten zum Entladen ihrer Wartung erkunden. Im Folgenden finden Sie einige klassische Anwendungsfälle, in denen Sie diesen Ansatz anwenden möchten.

• Verlagern Sie die Verantwortung auf die Cloud-Plattform indem Sie sich für Platform-as-a-Service (PaaS)-Lösungen entscheiden. Sie bieten vorgefertigte Lösungen für allgemeine Resilienzanforderungen wie Replikation, Failover und Sicherungsspeicher. Bei diesem Ansatz übernimmt der Cloudanbieter Hosting-, Wartungs- und Resilienzverbesserungen.

  Beispielsweise repliziert der Cloudanbieter Daten über mehrere Computeknoten hinweg und verteilt die Replikate über Verfügbarkeitszonen. Wenn Sie Ihre eigene Lösung auf virtuellen Computern (VMs) erstellen, müssen Sie diese Aspekte selbst verwalten, was zeitaufwändig und komplex sein kann.

• Verantwortlichkeiten für Betriebsabläufe auslagern, die nicht direkt an die Geschäftsziele der Workload gebunden sind. Einige spezialisierte Vorgänge, z. B. Datenbankverwaltung und Sicherheit, können sich möglicherweise auf die Zuverlässigkeit Ihrer Workload auswirken. Erkunden Sie die Möglichkeit, erfahrene Teams, Technologien oder beides einzusetzen, um diese Aufgaben zu bewältigen.

  Wenn Ihr Team beispielsweise keine Datenbankkompetenz hat, verwenden Sie verwaltete Dienste, um die Verantwortung auf den Anbieter zu verschieben. Dieser Ansatz kann nützlich sein, wenn Sie mit dem Start beginnen, da es Ihrem Team ermöglicht, sich auf die Funktionalität der Workload zu konzentrieren. Viele Unternehmen haben gemeinsame, zentral verwaltete Dienste. Wenn Plattformteams verfügbar sind, verwenden Sie sie, um diese Vorgänge zu verarbeiten. Dieser Ansatz kann jedoch Abhängigkeiten und Organisationskomplexität hinzufügen.

  Alternativ können Sie, wenn Ihr Team über die richtige Expertise verfügt, eine explizite Entscheidung treffen, ihre Fähigkeiten zu verwenden und Dienste auszuwählen, die keine Verwaltungsfunktionen enthalten.

• Entlastung von Zuständigkeiten an Nicht-Microsoft-Anbieter. Wählen Sie Off-the-Shelf-Produkte als Ausgangspunkt aus. Erstellen Sie angepasste Lösungen nur, wenn sie zum Geschäftlichen Wert Ihrer Workload beitragen.

Risiko: Wenn die Option 'Kaufen' oder 'Vertrauen' Ihre Anforderungen nur teilweise erfüllt, müssen Sie möglicherweise benutzerdefinierte Erweiterungen implementieren. Diese Methode kann zu einer "Anpassungssperre" führen, in der Updates und Modernisierungen unpraktisch werden. Überprüfen Sie regelmäßig Ihre Anforderungen, und vergleichen Sie sie mit den Funktionen der Lösung. Entwickeln Sie eine Exit-Strategie für den Zeitpunkt, zu dem eine signifikante Abweichung zwischen den beiden besteht.

Das gegenteilige Szenario ist auch ein Risiko. Obwohl die Kauf- oder Verlassen-Option zunächst einfacher erscheinen könnte, kann es später eine erneute Auswertung und Neugestaltung erfordern, wenn die Einschränkungen des PaaS-Dienstes, der Anbieterlösung oder der plattformeigenen Ressourcen nicht die erforderliche Granularität oder das Maß an Autonomie erfüllen, die für die Workload erforderlich sind.

– Identifizieren der kritischen Benutzer- und Systemflüsse

Das Aufteilen der Arbeit in Abläufe ist in dieser Phase von entscheidender Bedeutung. Konzentrieren Sie sich auf Benutzer- und Systemflüsse . Benutzerabläufe bestimmen Benutzerinteraktionen, und Systemflüsse bestimmen die Kommunikation zwischen Workloadkomponenten, die nicht direkt mit Benutzeraufgaben verknüpft sind.

Beispielsweise führen Kunden in einer E-Commerce-Anwendung Front-End-Aktivitäten wie Browsen und Bestellen aus. In der Zwischenzeit erfüllen Back-End-Transaktionen und vom System ausgelöste Prozesse Benutzeranforderungen und verarbeiten andere Aufgaben. Diese unterschiedlichen Flüsse sind Teil desselben Systems, aber sie umfassen unterschiedliche Komponenten und dienen verschiedenen Zwecken.

Beginnen Sie in dieser Phase mit dem Erstellen eines Katalogs mit Flüssen. Beobachten Sie Benutzerinteraktionen und Komponentenkommunikation. Auflisten und Kategorisieren von Abläufen, ihre Anfangs- und Endpunkte definieren und Abhängigkeiten notieren. Dokumentieren Sie Ergebnisse und Ausnahmen mithilfe von Diagrammen zur Übersichtlichkeit. Dieser Katalog kann als wichtiges Tool für die erste Unterhaltung mit den Geschäftsbeteiligten dienen, um die wichtigsten Aspekte aus ihrer Perspektive zu identifizieren. Diese Unterhaltung kann die erste Ebene der Priorisierung informieren.

Klassifizieren Sie einen Fluss als kritisch, indem Sie das Risiko und die Auswirkungen auf primäre Geschäftsaktivitäten bewerten. Wenn Sie einen Ausfall erwarten, konzentriert sich Graceful Degradation auf die Aufrechterhaltung dieser kritischen Abläufe. Im E-Commerce-Beispiel umfassen kritische Abläufe Produktsuchen, das Hinzufügen von Artikeln zum Warenkorb und das Auschecken, da diese Aufgaben für das Unternehmen unerlässlich sind. Andere Prozesse wie das Aktualisieren von Produktdaten und die Pflege von Produktimages sind nicht so wichtig. Stellen Sie sicher, dass kritische Flüsse während eines Ausfalls betriebsbereit bleiben, um Umsatzverluste zu verhindern, indem Benutzer weiterhin nach Produkten suchen und Artikel zum Warenkorb hinzufügen können.

Weitere Informationen finden Sie unter Azure Well-Architected Framework: Optimieren des Workloaddesigns mithilfe von Flüssen.

– Wählen Sie das richtige Designmodell, Ressourcen und Features aus.

Sie sollten diese Strategie auf den folgenden Ebenen anwenden:

• Architektur: Der Workloadentwurf sollte die Zuverlässigkeitserwartungen auf verschiedenen Infrastrukturebenen berücksichtigen. Ihre anfänglichen Entscheidungen können die Wahl zwischen Containerisierung oder PaaS für das Hosten der Anwendung sein. Oder Sie können Netzwerksetups wie Hub und Speichen oder ein einzelnes virtuelles Netzwerk in Betracht ziehen.

  Sie sollten auch Abgrenzungen festlegen, die eine Segmentierung basierend auf der Funktionalität ermöglichen. Statt alle Funktionen auf einem einzigen virtuellen Computer mit einem virtuellen Datenträger in nur einer Zone zu hosten, sollten Sie Rechenkapazitäten und Datenspeicherung aufteilen und spezialisierte Dienste verwenden.

  Vorsicht

  In Migrationsszenarien kann die Einführung eines Lift-and-Shift-Ansatzes ohne Überprüfung neuer Möglichkeiten zu verpassten Vorteilen und Ineffizienzen führen. Es ist wichtig, Modernisierung frühzeitig in Betracht zu ziehen, um zu vermeiden, dass Sie mit schwer änderbaren Einrichtungen hängen bleiben, und um von besseren Optionen und Verbesserungen zu profitieren.

• Azure-Dienste: Verwenden Sie Entscheidungsstrukturen, um Ihnen bei der Auswahl der richtigen Dienste für Ihr Design zu helfen. Wählen Sie Komponenten aus, die Ihren aktuellen Anforderungen entsprechen, aber flexibel bleiben, damit Sie dienste wechseln können, während Sich Ihre Workload weiterentwickelt und mehr Features erfordert.

• SKUs oder Ebenen innerhalb von Azure-Diensten: Überprüfen Sie die Features jeder SKU, und verstehen Sie die Verfügbarkeitsgarantien der Plattform. Bewerten Sie die Service-Level-Vereinbarungen, um die Abdeckung zu verstehen, die um den veröffentlichten Prozentsatz bereitgestellt wird.

• Features, die Zuverlässigkeit unterstützen: Wählen Sie cloudeigene Dienste aus, um die Verfügbarkeit durch einfache Konfigurationen zu verbessern, ohne den Code zu ändern. Es ist wichtig, die Optionen zu verstehen und absichtlich Konfigurationen auszuwählen, z. B. die Erhöhung der Zonenredundanz oder das Replizieren von Daten in einen sekundären Bereich.

✓ Bereitstellen mit einem Grundmaß an Redundanz.

Vermeiden Sie in jedem Teil Ihrer Lösung einzelne Fehlerquellen, wie z. B. einzelne Instanzen. Erstellen Sie stattdessen mehrere Instanzen für Redundanz. Azure-Dienste übernehmen häufig die Handhabung der Redundanz für Sie, insbesondere bei PaaS-Diensten, die standardmäßig lokale Redundanz umfassen, sowie Optionen für ein Upgrade. Verwenden Sie vorzugsweise Zonenredundanz, um diese Instanzen über mehrere Azure-Rechenzentren hinweg zu verteilen. Wenn Dies nicht der Fall ist, stellen Sie zumindest lokale Redundanz sicher, aber diese Methode ist mit höherem Risiko verbunden. In zukünftigen Ebenen bewerten Sie, ob Ihre Zuverlässigkeitsanforderungen erfüllt werden können, indem Sie die Lösung mit georedundanten Komponenten erweitern.

Ausgleich: Ein erheblicher Kompromiss ist die erhöhte Redundanzkosten. Außerdem kann die zonenübergreifende Kommunikation Latenzen einführen. Bei Legacyanwendungen, die eine minimale Latenz erfordern, kann Redundanz die Leistung beeinträchtigen.

Risiko: Wenn eine Anwendung nicht für eine Umgebung mit mehreren Instanzen konzipiert ist, kann es mit mehreren aktiven Instanzen zu kämpfen haben, was zu inkonsistenten Daten führen kann. Wenn eine Anwendung auch für ein lokales Setup mit geringer Latenz erstellt wird, kann die Verwendung von Verfügbarkeitszonen die Leistung beeinträchtigen.

• Aktivieren von Metriken, Protokollen und Ablaufverfolgungen zum Überwachen von Flüssen

Wählen Sie plattformeigene Tools wie Azure Monitor aus, um die Sichtbarkeit von Metriken, Protokollen und Ablaufverfolgungen sicherzustellen. Verwenden Sie integrierte Features, um Warnungen für potenzielle Probleme festzulegen. Sie sollten über grundlegende Warnungen verfügen, um Benachrichtigungen zu senden und Warnungen zu erhalten. Nutzen Sie die Azure-Plattformfunktionen, die Änderungen am Integritätsstatus von Diensten angeben, z. B.:

• Azure Service Health um den Integritätsstatus der Plattform zu überprüfen.

• Azure Resource Health um den Gesundheitsstatus auf Ressourcenebene zu überprüfen.

Richten Sie Azure Monitor-Aktionsgruppen sowohl für die Infrastruktur als auch für die Anwendung ein.

Kompromiss: Während Sie weitere Protokolle sammeln, müssen Sie die zunehmende Menge verwalten, was sich auf die speicherbezogenen Kosten dieser Protokolle auswirkt. Verwenden Sie Aufbewahrungsrichtlinien, um das Volume zu verwalten. Verwenden Sie Azure Monitor, um eine tägliche Obergrenze für einen Arbeitsbereich festzulegen. Weitere Informationen finden Sie unter Konfigurationsempfehlungen für Zuverlässigkeit.

Beginnen Sie mit dem Aufbau der Überwachbarkeit auf den folgenden Ebenen.

Infrastruktur

Beginnen Sie, indem Sie Diagnoseprotokolle aktivieren und sicherstellen, dass Sie systemeigene Metriken aus Plattformkomponenten für die Analyse sammeln. Sammeln Sie Informationen zur Ressourcenauslastung, z. B. CPU, Arbeitsspeicher, Eingabe/Ausgabe und Netzwerkaktivität.

Anwendung

Sammeln Sie Metriken auf Anwendungsebene, wie z. B. Speicherverbrauch oder Anforderungslatenz, und protokollieren Sie Anwendungsaktivitäten. Führen Sie Protokollierungsvorgänge in einem Thread oder Prozess durch, der vom Hauptanwendungsthread getrennt ist. Dieser Ansatz führt nicht dazu, dass die Protokollierung die primären Aufgaben der Anwendung verlangsamt.

Überprüfen Sie auch die grundlegenden Verfügbarkeitstests in Application Insights.

Daten

Um Datenbanken auf einer grundlegenden Ebene zu überwachen, sammeln Sie wichtige Metriken, die die Datenbankressourcen ausgeben. Ähnlich wie Infrastrukturkomponenten können Sie die Ressourcennutzung im Kontext von Datenspeichern nachverfolgen, z. B. Netzwerkmetriken. Das Sammeln von Daten darüber, wie Verbindungen zusammengefasst werden, ist wichtig, um die Effizienz in späteren Phasen zu verbessern.

Zur Zuverlässigkeit ist es wichtig, Verbindungsmetriken zu verfolgen, z. B. die Überwachung aktiver und fehlgeschlagener Verbindungen. In Azure Cosmos DB wird beispielsweise ein 429-Statuscode zurückgegeben, wenn die Anzahl der Anforderungen die zugewiesenen Anforderungseinheiten überschreitet und Verbindungen fehlschlagen.

Beginnen Sie mit dem Erstellen eines Handbuchs zur Fehlerbehebung.

Fehler reichen von sporadischen und leicht verlängerten vorübergehenden Ausfällen bis hin zu katastrophalen Ausfällen.

Konzentrieren Sie sich in Ebene 1 auf Plattformfehler. Obwohl sie über Ihre Kontrolle hinausgehen, sollten Sie dennoch Strategien für die Behandlung haben. Adressieren Sie z. B. Zonenausfälle mithilfe von Verfügbarkeitszonen.For example, address zonal outages by using availability zones. Antizipieren Sie vorübergehende Fehler auf Plattformebene, und behandeln Sie sie in Ihrer Workload.

Der Prozess der Behandlung dieser Fehler variiert je nach Komplexität. Beginnen Sie mit der Dokumentation potenzieller Fehler auf Plattformebene, deren zugehörigen Risiken und Strategien zur Risikominderung. Diese Übung ist in erster Linie theoretisch und reift mit Automatisierung auf späteren Ebenen.

Sie sollten Fehler dokumentieren, einschließlich Faktoren wie Wahrscheinlichkeit, Auswirkung und Gegenmaßnahmen. Verwenden Sie einen Kritischen Maßstab, der den Zielen Ihrer Workload entspricht. Ihre Skalierung kann Folgendes umfassen:

• Hoch. Ein vollständiger Systemausfall, der zu erheblichen finanziellen Verlusten und einem Rückgang der Benutzervertrauensstellung führt.

• Mittel. Eine temporäre Unterbrechung, die sich auf einen Teil der Workload auswirkt und zu Unannehmlichkeiten führt.

• Niedrig. Ein kleineres Softwareproblem, das sich auf ein nicht wesentliches Feature der Anwendung auswirkt und für Benutzer minimale Ausfallzeiten verursacht.

Hier ist eine Beispielvorlage:

Achten Sie auf Ebene 1 nicht auf Vollständigkeit, da es immer unvorhergesehene Fehlerfälle gibt. Wenn unerwartete Ausfälle auftreten, dokumentieren Sie die Ursachen und Gegenmaßnahmen im Playbook. Behandeln Sie diese Ressource als lebendiges Dokument, das Sie im Laufe der Zeit aktualisieren.

Hinzufügen von Mechanismen zur Wiederherstellung bei vorübergehenden Fehlern

In einer Cloudumgebung sind vorübergehende Fehler üblich. Sie weisen auf kurzfristige Probleme hin, die durch erneute Versuche in der Regel innerhalb von Sekunden behoben werden können.

Verwenden Sie integrierte SDKs und Konfigurationen, um diese Fehler zu behandeln, um das System aktiv zu halten. Integrierte Konfigurationen sind häufig die Standardeinstellung, daher müssen Sie möglicherweise testen, um die Implementierung zu überprüfen. Implementieren Sie außerdem Muster, die für die Behandlung vorübergehender Fehler in Ihrer Architektur konzipiert sind. Weitere Informationen finden Sie unter Architekturentwurfsmuster, die Zuverlässigkeit unterstützen.

Persistante Probleme können auf einen Fehler hinweisen, der nicht vorübergehend oder der Beginn eines Ausfalls ist. Dieses Szenario erfordert mehr als nur das Beheben lokalisierter Probleme innerhalb der Anwendung. Es umfasst die Untersuchung der kritischen Benutzer- und Systemflüsse des Systems und das Hinzufügen von Selbsterhaltungstechniken und Wiederherstellungsmaßnahmen. Diese Methoden sind ausgereifte Methoden, die von Level 2 beschrieben werden.

• Ausführen grundlegender Tests

Integrieren Sie grundlegende Zuverlässigkeitstests in die frühen Phasen des Softwareentwicklungslebenszyklus. Suchen Sie nach Möglichkeiten zum Testen, beginnend mit Komponententests, um Funktionen und Konfigurationen zu überprüfen.

Entwickeln Sie auch einfache Testfälle für die Probleme, die Sie im Playbook zur Risikominderung identifizieren. Konzentrieren Sie sich auf höhere Auswirkungen, geringere Leistungsminderungen. Simulieren Sie beispielsweise Netzwerkausfälle oder zeitweilige Verbindungsprobleme, um zu sehen, wie Ihre Wiederholungslogik die Unterbrechungen löst.

Risiko: Tests führen häufig zu Reibungen im Entwicklungszyklus. Um dieses Risiko zu verringern, machen Sie zuverlässigkeitstests zusammen mit Entwicklungsaufgaben nachverfolgbar.

Die Featureentwicklung ist die Priorität, und Tests können im Entwicklungszyklus Reibungspunkte bringen. Es ist einfacher, mit dem Testen zu beginnen, bevor die Featureentwicklung abgeschlossen ist. Wenn Sie nicht funktionsfreie Aspekte der Anwendung am Anfang entwerfen, können Sie diese erweitern, während Sie funktionale Funktionen hinzufügen, anstatt einen Backlog von Problemen zu erstellen, die später behoben werden können. Obwohl dieser Ansatz zunächst mehr Aufwand erfordert, ist er überschaubar und verhindert später größere Probleme.

Stellen Sie sicher, dass das System funktionsfähig und stabil bleibt, indem sie Selbsterhaltungsfunktionen integrieren und einen grundlegenden Wiederherstellungsplan zum Verwalten von Fehlern haben.

Fehler in der Cloud sind unvermeidlich. Ihre Resilienzstrategien sollten sich bemühen, das System unter allen Bedingungen funktionsfähig zu halten. Stufe 1 führt Methoden zur Behandlung vorübergehender Fehler ein. Stufe 2 konzentriert sich auf die Einbeziehung von Selbsterhaltungsstrategien zur Verhinderung, Erkennung und Wiederherstellung von länger andauernden Fehlern. Wenn sie nicht gelöst bleiben, können diese Probleme zu vollständigen Ausfällen werden.

Die kritischen Flüsse, die Sie in Ebene 1 identifizieren, haben Vorrang. Sie erfordern erhöhte Resilienz- und Wiederherstellungsbemühungen für alle Komponenten, einschließlich Anwendungen, Dienste und Datenbanken. Erwarten Sie, dass Sie Ihre anfänglichen Bereitstellungsgrößen, Instanzenanzahlen und Richtlinien für die automatische Skalierung anpassen, um Zuverlässigkeitsrisiken zu reduzieren.

Seien Sie in dieser Stufe bewusst in Ihren Überwachungs- und Testpraktiken. Verwenden Sie erweiterte Überwachungstechniken, die den technischen Anforderungen entsprechen und auf Entwicklungsteams zugeschnitten sind. Erweitern Sie das einfache Playbook, um Architekturkomponenten abzudecken, die Sie entwickeln und besitzen, z. B. Anwendungscode.

Schlüsselstrategien

• Bewerten des aktuellen Zustands der Resilienz zum Schutz vor Fehlern

• Ist die Redundanzstufe gut genug, um Fehlern standzuhalten? Definieren Sie eine Redundanzstrategie, die die Anzahl redundanter Ressourcen angibt, die verwaltet werden sollen. Bestimmen Sie, wo diese Ressourcen platziert werden sollen, ob lokal, über Zonen oder an geografisch verteilten Standorten. Bewerten Sie die Einstellungen der Cloudplattform, und wählen Sie eine Ebene aus, die den Geschäftlichen Anforderungen und akzeptablen Kompromissen entspricht.

• Sind die Workloadkomponenten ausreichend isoliert, um ihre Fehler zu begrenzen? Muster wie das Bulkhead-Muster helfen beim Aufbau von Resilienz und Fehlerisolation. Das Bulkhead-Muster partitioniert ein System in isolierte Komponenten, die als Bulkheads bezeichnet werden, um Zu verhindern, dass Fehler in andere Teile des Systems überlappen.

• Kommunizieren Komponenten auf dem kritischen Pfad asynchron? Wenn nicht, verwenden Sie Kommunikationsmethoden, z. B. Warteschlangen. Dieser Ansatz sorgt dafür, dass das System auch dann betriebsbereit bleibt, wenn eine nachgeschaltete Komponente fehlschlägt. Außerdem wird verhindert, dass das System einen unbestimmten Zustand eingibt. Erkunden Sie Azure-Optionen, einschließlich Azure Service Bus für Warteschlangen und Azure Event Hubs für Ereignisstreams.

  Ausgleich: Die asynchrone Kommunikation kann dazu beitragen, kaskadierende Fehler durch Entkoppeln von Prozessen zu verhindern. Es erhöht jedoch die Latenz im Kommunikationspfad, was ein Problem für kritische Komponenten darstellen kann. Bewerten Sie die Leistungseinbußen, bevor Sie Entwurfsmusteränderungen vornehmen.

• Sind die Vorgänge auf Konsistenz ausgelegt? Ressourcen wie Anwendungsgeheimnisse und Zertifikate können ablaufen und eine regelmäßige Aktualisierung erfordern. Inkonsistenzen in Routineupdates können zu Zuverlässigkeitsproblemen führen.

  Im Idealfall erkennen und beseitigen Sie laufende, vom Menschen betriebene Vorgänge, da sie fehleranfällig sind und zu Inkonsistenzen führen können, die Zuverlässigkeitsrisiken darstellen. Laden Sie so viele betriebliche Aufgaben wie möglich an den Cloudanbieter aus. Verwenden Sie beispielsweise verwaltete Identitäten, die Von Microsoft Entra ID bereitgestellt werden, und TLS-Zertifikate (Transport Layer Security), die Azure Front Door verwaltet.

  Die Überwachung ist für proaktive Maßnahmen erforderlich, z. B. das Nachverfolgen des Ablaufs von Zertifikaten und das Empfangen von Benachrichtigungen. Die Anwendung sollte wichtige Ereignisse protokollieren, z. B. ein TLS-Zertifikat, dessen Ablauf bald bevorsteht. Wenn Sie mehrere Methoden verwenden, um nach potenziellen Fehlern zu suchen, können Sie sicherstellen, dass erforderliche Maßnahmen ergriffen werden.

– Hinzufügen technischer Funktionen in Ihrem Überwachungssystem

Auf Stufe 1 haben Sie Überwachungsdaten aus den Workloadkomponenten gesammelt, wobei Sie sich auf die Infrastruktur konzentrieren. Die grundlegende Analyse ist abgeschlossen, und grundlegende Warnungen werden festgelegt. Diese Einrichtung ist wichtig, um die grundlegende Leistung von Workloadkomponenten zu verstehen und anomales Verhalten zu identifizieren.

Stufe 2 erweitert die Überwachung, indem erweiterte Beobachtbarkeitsfunktionen zu Ihren Arbeitslast-Ressourcen hinzugefügt werden und ein strukturierterer Ansatz zur Analyse von Überwachungsdaten eingeführt wird. Nutzen Sie analysetools, die Ihr Clouddienst bereitstellt. Beispielsweise bieten Azure Monitor Insight-Tools wie VM-Einblicke und Netzwerkeinblicke Visualisierungen von Integrität und Leistung über Abhängigkeiten hinweg.

Planen Sie die Beobachtbarkeitsfunktionen auf den folgenden Ebenen.

Anwendung

• Reagieren Sie auf die Abfrage des Gesundheitszustandes. Aktivieren Sie die Anwendung, um auf Health Check-Anforderungen von Probes zu reagieren. Die Anwendung sollte über spezielle Endpunkte für Gesundheitsprüfungen verfügen, die Statusinformationen liefern, wie z. B. gesund oder ungesundehinzufügen, mindestens. Mit diesem Ansatz können Überwachungssysteme beurteilen, ob die Anwendung ordnungsgemäß funktioniert und Anforderungen verarbeiten kann oder ob Probleme behoben werden müssen.

  Azure-Lastenausgleichsdienste wie Azure Front Door, Azure Traffic Manager, Azure Application Gateway und Azure Load Balancer unterstützen Gesundheitsprüfungen. Health Probes senden Anforderungen zur Gesundheitsprüfung an Anwendungen.

• Wechseln zur semantischen Protokollierung. Fügen Sie strukturierte Informationen zu Ereignissen und Aktionen in die Anwendung ein. Bei der strukturierten Protokollierung werden Protokolldaten in einem konsistenten Format mithilfe eines klar definierten Schemas aufgezeichnet. Dieses Schema erleichtert die Erstellung von Automatisierung, Suche und Analyse in späteren Phasen. Fügen Sie bestimmte Felder wie Zeitstempel und Fehlercodes ein, um Probleme schnell zu identifizieren und zu beheben.

• Implementieren Sie verteilte Ablaufverfolgung. Wenn eine Anforderung über verschiedene Komponenten des Systems fließt, ist es wichtig, Ablaufverfolgungsdaten über Grenzen hinweg zu erfassen. Diese Daten sind nützlich, um Einblicke in das Anwendungsverhalten zu erhalten und Leistungsengpässe, Fehler und Latenzprobleme zu identifizieren. Azure Monitor unterstützt die openTelemetry-basierte Datensammlung mit Application Insights.

Daten

• Nachverfolgen der Abfragedauer, fehlgeschlagener Abfragen und anderer relevanter Metriken. Lange ausgeführte Abfragen können Aufschluss über Ressourceneinschränkungen und möglicherweise eine Anpassung des Schemaentwurfs geben.

  In dieser Phase ist Ihre Datenbank seit einiger Zeit aktiv. Achten Sie auf die Datenwachstumsrate, insbesondere in Tabellen, die unerwartet schnell wachsen. Diese Informationen sind entscheidend für die Planung zukünftiger Speicheranforderungen und die frühzeitige Behandlung von Leistungsproblemen.

• Überwachen Sie den Status der Datenbankreplikation mithilfe der Tools und des Dashboards, die das Datenbankverwaltungssystem bereitstellt. Wenn Sie beispielsweise Azure Cosmos DB verwenden, verwenden Sie Azure Cosmos DB Insights. Für Azure SQL-Datenbank oder azure SQL Managed Instance sollten Sie die Datenbanküberwachung verwenden, um Diagnosedetails zu Ihren Datenbanken abzurufen.

  Wenn die Datenbank wächst, werden Schemaprobleme möglicherweise deutlicher, was sich auf die Leistung auswirkt. Um die Abfrageeffizienz zu optimieren, sollten Sie Indizes hinzufügen oder das Schema ändern, da sich diese Änderungen auf die Zuverlässigkeit auswirken können.

Operationen

Ebene 1 konzentriert sich auf die vorherigen Ebenen. Auf Ebene 2 beginnen Sie mit dem Aufbau von Vorgängen rund um das Überwachungssystem.

• Bewahren Sie Logdateien ausreichend lange auf, um wertvolle Einblicke zu gewinnen. Konfigurieren Sie aus Zuverlässigkeitsperspektive die Aufbewahrungsdauer so, dass Sie genügend Daten sammeln können, um Fehlermuster zu erkennen, Probleme zu beheben und Die Ursachenanalyse durchzuführen.

• Überwachen Sie Sicherungs- und Wiederherstellungsprozesse. Stellen Sie sicher, dass die Sicherungen erfolgreich an Standorten wie geplant gespeichert werden und dass Arbeitsauslastungsdaten innerhalb eines angemessenen Zeitrahmens wiederhergestellt werden. Die Überwachung dieser Prozesse ist wichtig, um Basispläne für Ihre RPO-Metriken (Recovery Point Objective) auf späteren Ebenen festzulegen.

– Erweitern Sie Ihr Playbook zur Fehlerbehebung

Ebene 1 konzentriert sich auf die erwarteten Plattformfehler. In Ebene 2 behandeln Sie Fehlerpunkte für Komponenten und Vorgänge innerhalb Ihrer eigenen Arbeitsauslastung. Wenn Ihr Code auf der Plattform ausgeführt wird, erhöhen sich die Interaktionspunkte zwischen der Plattform und der Anwendung. Erwarten Sie Ausfälle aufgrund von Bugs in Ihrem Code, gescheiterten Bereitstellungen und menschlichen Fehlern. Mindern Sie diese Probleme mithilfe von Selbsterhaltungs- oder Wiederherstellungstaktiken.

Erweitern Sie das Playbook zur Fehlerminderung, um Fehler und Bereitstellungsprobleme einzuschließen. Die folgende Tabelle basiert auf der Vorlage von Ebene 1:

Diese Übung kann überwältigend werden, wenn Sie versuchen, jeden möglichen Fehler zu berücksichtigen. Konzentrieren Sie sich auf die Komponenten, die Teil der kritischen Benutzerflüsse sind, um dies zu vereinfachen. Dieses lebendige Dokument wächst weiter, während die Arbeitsauslastung reift.

• Entwickeln eines grundlegenden Wiederherstellungsplans

Das Playbook zur Fehlerminderung ist die Grundlage für die Erstellung eines grundlegenden Wiederherstellungsplans. Abhilfemaßnahmen können Designmusterimplementierung, Plattformkonfigurationsanpassungen, Verwaltung von Live-Standortvorfällen, automatisierte Tests und Schulungspersonal umfassen, um Probleme während Codeüberprüfungen zu erkennen.

Beginnen Sie mit einer abgestuften Abbaustrategie, die temporäre Lösungen enthält, wenn Teile des Systems nicht einwandfrei funktionieren. Das Ziel besteht darin, Benutzern trotz Fehlern weiterhin zu dienen, indem sie arbeitsfreie Teile deaktivieren und die Benutzeroberfläche anpassen. Wenn beispielsweise eine Datenbank deaktiviert ist, kann die Anwendung das betroffene Feature deaktivieren und Clients darüber informieren, dass der Dienst vorübergehend nicht verfügbar ist, indem HTTP-Statuscodes verwendet werden.

Damit eine reibungslose Degradation funktioniert, isolieren Sie die Systemkomponenten, sodass nur die betroffenen Teile Probleme haben und die restlichen Komponenten weiterhin funktionieren. Verwenden Sie das Bulkhead-Muster, um fehlerisolieren zu können.

Nutzen Sie diese Gelegenheit, um Designentscheidungen zu überdenken, die möglicherweise die Wiederherstellung verlangsamen könnten. Beispielsweise kann das direkte Verweisen von DNS-Einträgen (Domain Name System) auf Ihre Anwendung in Azure App Service zu Verzögerungen während der Wiederherstellung aufgrund der DNS-Verteilung führen. Verwenden Sie einen dedizierten Dienst wie Azure Front Door als Ausgangspunkt für eine einfachere Neukonfiguration während der Wiederherstellungsschritte.

Erwarten Sie, dass sich dieser grundlegende Plan zu einem vollständigen Notfallwiederherstellungsplan auf reiferen Ebenen entwickelt.

• Erstellen von Testplänen

Erstellen Sie Testpläne, indem Sie Ausfälle und Probleme simulieren, die im Playbook zur Risikominderung identifiziert wurden. Ergänzen Sie diese Gegenmaßnahmen mit einfachen Testfällen, um sicherzustellen, dass sie erwartungsgemäß funktionieren und machbar sind. Überprüfen Sie, ob diese Features ordnungsgemäß funktionieren, und führen Sie Beeinträchtigungstests durch, um zu sehen, wie das System ausgeführt wird, wenn bestimmte Komponenten fehlschlagen. Halten Sie das Ergebnis einfach, indem Sie sicherstellen, dass der Test entweder fehlschlägt oder bestanden wird.

Verwenden Sie Testtools wie simulierte Frameworks, um Fehler in HTTP-Anforderungen einzufügen, wodurch Sie Wiederholungsrichtlinien expliziter testen können. Azure Chaos Studio bietet eine umfassende Testsuite zum Simulieren von Komponentenausfällen und anderen Problemen, was es zu einem wertvollen Dienst macht. Sie können Chaos Studio schrittweise einführen, während Sie mit seinen Features vertraut werden.

• Bewerten der Auswirkungen von Skalierungsvorgängen auf Zuverlässigkeit

Um mit Lastspitzen umgehen zu können, müssen kritische Komponenten in der Lage sein, effizient zu staffeln. Nutzen Sie die vorteile der automatischen Skalierung, die Azure bereitstellt. Diese Funktionen passen die Kapazitätsgrenzen eines Diensts basierend auf vordefinierten Konfigurationen an. Mit dieser Anpassung können Sie den Dienst nach Bedarf nach oben oder unten skalieren.

• Identifizieren Sie potenzielle Engpässe und verstehen Sie die Risiken, die sie darstellen könnten. Beispielsweise sollte der hohe Durchsatz nicht dazu führen, dass der Fluss zusammenbricht.

• Die Lademuster verstehen. Statische Nutzungsmuster können Engpässe weniger kritisch machen, aber Änderungen der Nutzungs- und Verbrauchsdynamik können die Risiken verschlechtern.

  Hinweis

  Möglicherweise gibt es Komponenten, die nicht skaliert werden können, z. B. monolithische Datenbanken und Legacyanwendungen. Überwachen Sie die Ladekurve proaktiv, um bei Bedarf die Neuarchitektur zu ermöglichen.

• Entscheiden Sie sich für Skalierungsgrenzwerte, die auf Leistungs- und Zuverlässigkeitsanforderungen basieren. Bei Leistungsbedenken ist die schrittweise Skalierung am häufigsten. Zuverlässigkeitsbedenken für kritische Flüsse erfordern jedoch möglicherweise eine schnellere Skalierung, um Ausfälle zu vermeiden. Vermeiden Sie in beiden Fällen unendliche Skalierung.

Risiko: Wenn Sie leistungsbezogene Probleme behandeln, kann die Skalierung eine nützliche Entschärfungsstrategie sein. Die Skalierung ist jedoch ein temporärer Fix und keine Lösung. Untersuchen und lösen Sie das zugrunde liegende Problem, z. B. einen Speicherverlust oder einen Auslaufprozess. Andernfalls riskieren Sie, dieselbe Abhilfemaßnahme erneut an einem anderen Kipppunkt anzuwenden und für Ressourcen zu bezahlen, die Sie nicht benötigen. Indem Sie die Ursache adressieren, können Sie langfristige Stabilität und Kosteneffizienz gewährleisten.

Legen Sie Zuverlässigkeitsziele und Ziele fest, um das Team für Wiederherstellungsverfahren verantwortlich zu halten.

Auf frühen Ebenen konzentrieren sich Ihre Teams auf einfache Gewinne und grundlegende Funktionen. Sie beginnen mit kleinen Verbesserungen, lösen einfache Probleme, um eine starke Grundlage zu schaffen, während sie sich hauptsächlich auf Azure-Zuverlässigkeitsfunktionen verlassen. Wenn Ihre Teams wachsen, bewältigen sie mehr technische Herausforderungen im Zusammenhang mit ihren eigenen Ressourcen und Prozessen.

Auf Stufe 3 sollten Ihre Teams Geschäftseinblicke und technische Fähigkeiten für die Wiederherstellungsplanung integrieren. Sie legen Ziele fest und planen Wiederherstellungsprozesse mithilfe erweiterter Überwachung. Dieser Ansatz hilft Website-Zuverlässigkeitsingenieuren (SREs), zuverlässigkeitsziele schnell zu erfüllen.

Schlüsselstrategien

– Formalisieren der Zuverlässigkeitsfunktionen als Ziele

Zuverlässigkeitsziele helfen, die Verantwortung für Aufgabenteams festzulegen. Es ist wichtig, ein kollaboratives Gespräch mit den Stakeholdern zu führen, um Wiederherstellungszeiten und -kosten zu diskutieren und Kompromisse zu treffen, die mit den Geschäftszielen übereinstimmen. Sammeln Sie die Beteiligten, und führen Sie diese Diskussion als Workshop durch. Berücksichtigen Sie die folgenden Punkte für die Workshop-Agenda:

• Erläutern sie die Metriken hinter den Zielen. Erläutern Sie zunächst die wichtigsten Metriken, die zum Definieren von Zielen wie Zielen auf Dienstebene, Wiederherstellungszeitziele (RTOs) und Wiederherstellungspunktziele (Recovery Point Objectives, RPOs) verwendet werden. Zeigen Sie, wie diese Metriken den Geschäftszielen entsprechen. Konzentrieren Sie sich auf die kritischen Benutzerflüsse. In einer E-Commerce-Anwendung ist beispielsweise die RTO für das Aktualisieren von E-Mail-Einstellungen weniger wichtig als das Auschecken von Benutzern aus Einkaufswagen.

• Kommunizieren Sie die Trade-Offs. Die Projektbeteiligten erwarten oft mehr als das, was erreicht werden kann. Erläutern, wie sich die Erweiterung des Umfangs auf das Budget, die betrieblichen Anforderungen und die Leistung auswirkt.

• Zielziele vorschlagen. Basierend auf architektonischer Erfahrung und Workload-Design empfehlen wir Ziele wie 99,9 % Betriebszeit, wobei RPO und RTO auf vier Stunden aktiviert sind. Erleichtern Sie eine Diskussion für die Beteiligten, um Feedback zu geben und Anpassungen vorzunehmen. Stellen Sie sicher, dass sowohl geschäftliche als auch technische Stakeholder vor unrealistischen Erwartungen schützen. Gehen Sie mit einer kooperativen Haltung an Diskussionen heran.

• Erreichen sie einen Konsens oder eine Entscheidung. Zielen Sie auf einen Konsens ab, aber wenn dies nicht möglich ist, sollte ein Entscheidungsträger die Ziele festlegen, um den Fortschritt sicherzustellen.

Proaktives Überwachen mithilfe Ihres Gesundheitsmodells

Auf Ebene 1 werden Überwachungsdaten aus Workloadkomponenten, einschließlich Plattformdiensten und Anwendungen, gesammelt. Grundlegende Analysen und Warnungen werden festgelegt, um die grundlegende Leistung zu etablieren und Anomalien zu identifizieren. In Ebene 2 verlagert sich der Fokus auf das Abrufen von Observability-Daten aus Workloadkomponenten, z. B. Anwendungscode.

Stufe 3 verbessert die Überwachung, indem geschäftsbezogener Kontext zu kritischen Flüssen hinzugefügt und gesunde, ungesunde und beeinträchtigte Zustände durch die Integritätsmodellierung definiert werden. Die Zustimmung der Beteiligten ist erforderlich, um akzeptable Kompromisse bei der Benutzererfahrung zu ermitteln und als Grundlage für die Definition von Gesundheitszuständen zu verwenden.

Die Gesundheitsmodellierung erfordert betriebsbereite Reife und Know-how in Monitoring-Tools. Ihr Team überprüft Rohdaten, Leistungsstufen und Protokolle, um benutzerdefinierte Metriken und Schwellenwerte zu erstellen, die den Integritätsstatus des Flusses definieren. Sie müssen verstehen, wie sich diese Werte auf die allgemeine Integrität des Systems beziehen. Kommunizieren Sie klare Definitionen und Schwellenwerte für die Projektbeteiligten.

Visualisieren Sie das Gesundheitsmodell in Dashboards, um SREs dabei zu unterstützen, Probleme schnell zu lokalisieren, indem sie sich auf ungesunde oder herabgestufte Abläufe konzentrieren.

Das Gesundheitsmodell definiert den Status der Anwendung und kritische Abläufe. Grün gibt an, dass alle kritischen Flüsse erwartungsgemäß funktionieren. Rot gibt einen Fehler an. Gelb zeigt Trends zu Problemen. Das Durchlaufen von Gesundheitsmodellversionen sorgt für Zuverlässigkeit und Genauigkeit, erfordert jedoch beträchtliche Anstrengungen für große Anwendungen.

Eine Änderung des Gesundheitszustands sollte als Warnung konfiguriert werden. Um Warnungen gezielt zu gestalten, muss die Kritikalität der Komponente berücksichtigt werden.

Weitere Informationen finden Sie unter Well-Architected Framework: Gesundheitsmodellierung.

Warnungen einrichten, die Maßnahmen erfordern

Um die Reaktionseffizienz zu verbessern, definieren Sie Warnungen klar und liefern genügend Informationen für schnelle Maßnahmen. Detaillierte Warnungsnamen und Beschreibungen können bei der Problembehandlung Zeit und Aufwand sparen. Konfigurieren Sie den Schweregrad, den Namen und die Beschreibung sorgfältig, mit besonderem Augenmerk auf die Schweregrade. Nicht jedes Ereignis ist ein Notfall. Bewerten Sie die Schweregradstufen und legen Sie Kriterien für jede Stufe fest, z. B. ob eine CPU-Auslastungsspitze von 80% auf 90% als Notfall eingestuft wird. Legen Sie geeignete Schwellenwerte fest, um sicherzustellen, dass Warnungen effektiv definiert sind.

Durch eine effektive Warnungsverwaltung wird sichergestellt, dass Benachrichtigungen die richtigen Personen zur richtigen Zeit benachrichtigen. Häufige und störende Warnungen weisen auf eine Notwendigkeit der Anpassung hin und können kontraproduktiv werden, wenn sie ignoriert werden. Reduzieren Sie unnötige Benachrichtigungen, indem Sie geeignete Schwellenwerte festlegen, um falsche Alarme auszufiltern. Identifizieren Sie Möglichkeiten, bei denen Automatisierung betriebliche Verfahren auslösen kann.

Erstellen Sie eine einzelne Zielseite, die über die erforderlichen Informationen verfügt, um Warnungen effizient zu behandeln. Dieser Ansatz spart Zeit im Vergleich zur Anmeldung beim Azure-Portal und suchen nach Metriken. Wenn die integrierten Azure Monitor-Features Nicht vollständig Ihren Anforderungen entsprechen, sollten Sie ein benutzerdefiniertes Dashboard entwickeln.

• Durchführen der Fehlermodusanalyse

In den früheren Levels haben Sie ein einfaches Playbook zur Fehlerminderung für einzelne Komponenten erstellt. Entwickeln Sie dieses Playbook auf dieser Ebene zu einer formalen Fehlermodusanalyse (FMA). Zweck dieser Übung ist es, potenzielle Fehlermodi proaktiv zu identifizieren.

FMA erfordert, dass Sie potenzielle Fehlerpunkte innerhalb Ihrer Workload identifizieren und Maßnahmen zur Risikominderung planen, z. B. Self-Healing oder Disaster Recovery (DR). Überwachen Sie zunächst auf erhöhte Fehlerraten und erkennen Sie Die Auswirkungen auf kritische Flüsse. Verwenden Sie vergangene Erfahrungen und Testdaten, um potenzielle Fehler zu identifizieren und ihren Strahlradius zu bewerten. Priorisieren Sie wichtige Probleme, z. B. einen regionsweiten Ausfall.

Es ist wichtig, Aktionen als präventiv oder reaktiv zu klassifizieren. Präventivmaßnahmen identifizieren Risiken, bevor sie einen Ausfall verursachen, wodurch die Wahrscheinlichkeit oder der Schweregrad reduziert wird. Reaktive Maßnahmen behandeln Probleme, um einen verschlechterten Zustand oder einen Ausfall zu mindern.

In der E-Commerce-Beispielanwendung möchte das Workload-Team FMA durchführen, um sich auf ein großes Ereignis vorzubereiten. Einer der wichtigsten Benutzerflüsse ist das Hinzufügen von Elementen zum Warenkorb. Die Komponenten, die Teil des Flusses sind, sind das Front-End, CartAPI, ProductCatalogAPI, UserProfileAPI, PricingAPI, Azure Cosmos DB und Azure Event Hubs.

FMA ist komplex und kann zeitaufwändig sein, sodass Sie Ihre Analyse im Laufe der Zeit schrittweise erstellen. Dieser Prozess ist iterativ und entwickelt sich auch in späteren Phasen weiter.

Weitere Informationen finden Sie unter RE:03 Empfehlungen zur Durchführung von FMA.

– Vorbereiten eines DR-Plans

In Stufe 2 haben Sie einen Wiederherstellungsplan erstellt, der sich auf technische Steuerelemente konzentriert, um die Systemfunktionalität wiederherzustellen. Eine Katastrophe erfordert jedoch einen umfassenderen Ansatz wegen katastrophalen Verlusts oder Misserfolgs. DR-Pläne sind prozessbasiert. Sie umfassen Kommunikation, detaillierte Wiederherstellungsschritte und potenziell technische Artefakte wie Skripts.

Identifizieren Sie zunächst die Arten von Katastrophen, die geplant werden sollen, z. B. Regionenausfälle, Azure-weite Fehler, Infrastrukturunterbrechungen, Datenbankbeschädigungen und Ransomware-Angriffe. Entwickeln Sie dann Wiederherstellungsstrategien für jedes Szenario, und stellen Sie sicher, dass Mechanismen zum Wiederherstellen von Vorgängen vorhanden sind. Geschäftsanforderungen, RTOs und RPOs sollten die DR-Pläne leiten. Niedrige RTOs und RPOs erfordern explizite automatisierte Prozesse, während höhere RTOs und RPOs einfachere Wiederherstellungsmethoden und manuelle Analysen ermöglichen.

DR umfasst hauptsächlich die folgenden Aktionen:

• Benachrichtigen Sie die verantwortlichen Parteien. Es ist wichtig, Klarheit darüber zu haben, wer einbezogen werden soll und wann. Stellen Sie sicher, dass Ihr Team die richtigen Prozesse verwendet, über die richtigen Berechtigungen verfügt und ihre Rollen bei der Wiederherstellung versteht. Einige Verantwortlichkeiten, z. B. die Berichterstellung des CEO an den Markt oder die Behandlung gesetzlicher Vorschriften, sollten frühzeitig identifiziert werden.

  Im Idealfall sollten Sie über separate Wiederherstellungs- und Kommunikationsrollen verfügen und jeder Rolle unterschiedliche Personen zuweisen. Zunächst kann die IT-Betriebsperson, die das Problem erkennt, beide Rollen behandeln. Aber wenn die Situation eskaliert, könnten Führungskräfte die technische Wiederherstellung übernehmen, während eine Führungskraft aus dem geschäftlichen Bereich die Kommunikation verwaltet.

• Treffen Sie Geschäftsentscheidungen. Während einer Katastrophe können Stressniveaus hoch sein, was eine klare Entscheidungsfindung wesentlich macht. Ein gut strukturierter DR-Plan erfordert kontinuierliche Gespräche zwischen dem technischen Team und den Geschäftsbeteiligten, um Vorentscheidungsoptionen zu definieren. Überlegen Sie beispielsweise, ob Arbeitsauslastungsressourcen in einer Azure-Region mit Sicherungen in einer anderen Region ausgeführt werden sollen oder ob IaC-Ressourcen im Voraus vorbereitet werden sollten, um neue Ressourcen zu erstellen oder aus einer Sicherung während des Failovers wiederherzustellen.

  Maßnahmen, die gemäß DR-Plänen ergriffen werden, können destruktiv sein oder erhebliche Nebenwirkungen haben. Es ist wichtig, die Optionen zu verstehen, ihre Vor- und Nachteile abzuwägen und die richtige Zeit zu bestimmen, um sie anzuwenden. Bewerten Sie beispielsweise, ob die Wiederherstellung zu einer anderen Region erforderlich ist, wenn die primäre Region innerhalb eines akzeptablen Zeitrahmens betriebsbereit sein soll.

• Systemvorgänge wiederherstellen. Während einer Katastrophe sollte der Fokus auf dem Wiederherstellen von Vorgängen und nicht auf der Identifizierung der Ursache liegen. Entscheiden Sie sich bei der technischen Wiederherstellung, insbesondere beim regionalen Failover, im Voraus für Ansätze wie Aktiv-Aktiv, Aktiv-Passive, Warm Standby oder Cold Standby.

  Bereiten Sie bestimmte Wiederherstellungsschritte basierend auf dem gewählten Ansatz vor. Beginnen Sie mit einer konkreten Liste der Schritte zum Wiederherstellen von Vorgängen. Wenn der Prozess reift, soll der DR-Plan als Skript mit minimaler manueller Interaktion definiert werden. Verwenden Sie die Versionssteuerung, und speichern Sie das Skript sicher, um den Zugriff zu erleichtern. Dieser Ansatz erfordert mehr Vorleistung, minimiert aber Stress während eines tatsächlichen Vorfalls.

  Weitere Informationen finden Sie unter Bereitstellung im aktiv-passiven Modus für DR.

• Führen Sie eine Analyse nach dem Vorfall durch. Identifizieren Sie die Ursache des Vorfalls, und finden Sie Möglichkeiten, dies in Zukunft zu verhindern. Nehmen Sie Änderungen vor, um Wiederherstellungsprozesse zu verbessern. Diese Übung kann auch neue Strategien aufdecken. Wenn das System beispielsweise zur sekundären Umgebung gewechselt ist, ermitteln Sie, ob die primäre Umgebung noch benötigt wird und was der Failbackprozess sein soll.

Ein DR-Plan ist ein lebendiges Dokument, das sich an Änderungen ihrer Arbeitsauslastung anpasst. Aktualisieren Sie Ihren DR-Plan so, dass neue Komponenten und Risiken entstehen. Verfeinern Sie den Plan basierend auf Erkenntnissen aus Drills oder realen Katastrophen, indem Sie realistische Informationen von DR-Operatoren sammeln.

Risiken aus technischen und betrieblichen Änderungen kontrollieren und die Verwaltung von Zwischenfällen priorisieren.

In den vorherigen Ebenen konzentriert sich Ihr Workload-Team auf die Entwicklung von Funktionen und darauf, das System betriebsbereit zu machen. Auf Ebene 4 setzt sich der Fokus darauf, das System in der Produktion zuverlässig zu halten. Die Vorfallverwaltung wird so wichtig wie die Sicherstellung, dass alle eingeführten Änderungen gründlich getestet und sicher bereitgestellt werden, um zu vermeiden, dass das System instabil wird.

Dieser Prozess erfordert Verbesserungen bei betriebstechnischen Kontrollen, z. B. investitionen in dedizierte Teams, um Zuverlässigkeitsvorfälle zu verwalten. Außerdem sind technische Kontrollen erforderlich, um die Systemzulässigkeit über die in früheren Ebenen verstärkten kritischen Komponenten hinaus zu verbessern. Da das System weiterhin in der Produktion ausgeführt wird, kann das Datenwachstum Neugestaltungen erfordern, z. B. Partitionierung, um einen zuverlässigen Zugriff und eine zuverlässige Wartung sicherzustellen.

Schlüsselstrategien

• Zuverlässiges Change Management

Die größten Zuverlässigkeitsrisiken treten bei Änderungen auf, z. B. Softwareupdates, Konfigurationsanpassungen oder Prozessänderungen. Diese Ereignisse sind aus Zuverlässigkeitssicht kritisch. Ziel ist es, die Wahrscheinlichkeit von Problemen, Ausfällen, Ausfallzeiten oder Datenverlusten zu minimieren. Jede Art von Änderung erfordert spezifische Aktivitäten, um ihre eindeutigen Risiken effektiv zu verwalten.

Auf Ebene 4 schneiden sich Zuverlässigkeit mit sicheren Bereitstellungsmethoden, die in Operational Excellence beschrieben werden, bei der Aufrechterhaltung einer stabilen Umgebung beim Verwalten von Änderungen. Zuverlässiges Änderungsmanagement ist eine Voraussetzung für die Arbeitsauslastungsstabilität. Berücksichtigen Sie die folgenden wichtigen Aspekte:

• Reagieren Sie auf Plattformupdates. Azure-Dienste weisen unterschiedliche Mechanismen zum Aktualisieren von Diensten auf.

  • Machen Sie sich mit Wartungsprozessen vertraut, und aktualisieren Sie die Richtlinien der einzelnen dienste, die Sie verwenden. Verstehen Sie, ob der Dienst automatische oder manuelle Upgrades und den Zeitrahmen für manuelle Updates unterstützt.

  • Verwalten Sie geplante Updates für Dienste effektiv, indem Sie sie zu Zeiten mit geringer Auswirkung planen. Vermeiden Sie automatische Updates, und verzögern Sie sie, bis Sie das Risiko bewertet haben. Einige Dienste ermöglichen es Ihnen, die Anzeigedauer zu steuern, während andere Dienste eine Karenzzeit bieten. Bei Azure Kubernetes Service (AKS) haben Sie beispielsweise 90 Tage Zeit, sich zu entscheiden, bevor das Update automatisch wird. Testen Sie Updates in einem Nichtproduktionscluster, der Ihr Produktionssetup widerspiegelt, um Regressionen zu verhindern.

    Updates schrittweise anwenden. Selbst wenn tests zeigen, dass das Update sicher ist, kann die Gleichzeitige Anwendung auf alle Instanzen riskant sein. Aktualisieren Sie stattdessen einige Instanzen auf einmal und warten Sie zwischen den einzelnen Aktivierungen.

  • Überprüfen Sie regelmäßig nach Benachrichtigungen zu Updates, die in Aktivitätsprotokollen oder anderen dienstspezifischen Kanälen verfügbar sein können.

  • Überwachen Sie auf plötzliche oder graduelle Änderungen, nachdem ein Update angewendet wurde. Im Idealfall sollte Ihr Gesundheitsmodell Sie über diese Änderungen informieren.

• Gründliche Tests mit Automatisierung. Integrieren Sie mehr Tests in Ihre Build- und Bereitstellungspipelines, wenn Sie Änderungen einführen. Suchen Sie nach Möglichkeiten zum Konvertieren manueller Prozesse in automatisierte Teile Ihrer Pipelines.

  Führen Sie umfassende Tests mithilfe einer Kombination verschiedener Arten von Tests in verschiedenen Phasen durch, um zu bestätigen, dass Änderungen erwartungsgemäß funktionieren und sich nicht auf andere Teile der Anwendung auswirken. Beispielsweise können positive Tests überprüfen, ob das System erwartungsgemäß funktioniert. Es sollte überprüft werden, ob keine Fehler vorhanden sind und dass der Datenverkehr ordnungsgemäß fließt.

  Wenn Sie Updates planen, identifizieren Sie Testgates und die anzuwendenden Testtypen. Die meisten Tests sollten in den Phasen vor der Bereitstellung stattfinden, aber auch Smoke-Tests sollten in jeder Umgebung durchgeführt werden, wenn Sie sie aktualisieren.

• Folgen Sie sicheren Bereitstellungsmethoden. Verwenden Sie Bereitstellungstopologien, die Überprüfungsfenster und sichere Bereitstellungsmethoden enthalten. Implementieren Sie sichere Bereitstellungsmuster wie Canary- und blaugrüne Bereitstellungen, um Flexibilität und Zuverlässigkeit zu verbessern.

  In Canary-Bereitstellungen erhält beispielsweise zuerst eine kleine Benutzergruppe die neue Version. Dieser Prozess ermöglicht die Überwachung und Überprüfung vor der Bereitstellung für die gesamte Benutzerbasis. Techniken wie Feature Flags und Dark Launches erleichtern Tests in der Produktion, bevor Änderungen für alle Benutzer freigegeben werden.

• Aktualisieren Sie Ihren DR-Plan. Aktualisieren Sie Ihren DR-Plan regelmäßig, um sie relevant und effektiv zu halten. Vermeiden Sie veraltete Anweisungen. Mit diesem Ansatz wird sichergestellt, dass der Plan den aktuellen Zustand Ihres Systems widerspiegelt, das für die Produktion bereitgestellt und von Benutzern genutzt wird. Integrieren Sie Erkenntnisse aus Drills und tatsächlichen Vorfällen.

Weitere Informationen finden Sie unter Operational Excellence Level 4

• Investieren Sie in ein dediziertes Team, um Vorfälle zu behandeln

Anfänglich könnte das Entwicklungsteam bei Zwischenfällen einbezogen werden. Investieren Sie auf Ebene 4 in das Zuverlässigkeits-Engineering (Site Reliability Engineering, SRE) für die Vorfallverwaltung. SREs sind spezialisiert auf Produktionsprobleme und sind Experten für Effizienz, Change Management, Überwachung, Notfallreaktion und Kapazitätsmanagement. Ein kompetentes SRE-Team kann die Abhängigkeit vom Entwicklungsteam erheblich reduzieren.

Stellen Sie SREs mit den Tools, Informationen und Wissen bereit, die für die unabhängige Behandlung von Vorfällen erforderlich sind. Diese Vorbereitung reduziert die Abhängigkeit vom Entwicklungsteam. SREs sollten im Umgang mit den Playbooks und dem Gesundheitsmodell für Arbeitslasten geschult werden, die auf vorherigen Ebenen entwickelt worden sind, um häufige Muster schnell zu erkennen und den Abmilderungsprozess einzuleiten.

Das Entwicklungsteam sollte Zeit haben, sich über wiederkehrende Probleme zu reflektieren und langfristige Strategien zu entwickeln, anstatt sie jedes Mal einzeln zu behandeln.

• Automatisieren von Selbstheilungsprozessen

In den vorherigen Ebenen werden Selbstheilungsstrategien mithilfe von Redundanz- und Entwurfsmustern entworfen. Da Ihr Team nun Erfahrung mit der realen Nutzung hat, können Sie die Automatisierung integrieren, um häufige Fehlermuster zu mindern und die Abhängigkeit vom Entwicklungsteam zu verringern.

Ausgleich: Die Automatisierung kann zeitaufwendig und kostspielig sein, um sie einzurichten. Konzentrieren Sie sich zuerst auf die Automatisierung der wirkungsvollsten Aufgaben, wie beispielsweise Aufgaben, die häufig auftreten oder wahrscheinlich zu Ausfällen führen können.

Konfigurieren Sie Aktionen basierend auf Triggern und automatisieren Sie Antworten im Laufe der Zeit, um ein automatisiertes Playbook für SREs zu erstellen. Ein Ansatz besteht darin, das Playbook mit Skripts zu verbessern, die Gegenmaßnahmen implementieren. Erkunden Sie azure-native Optionen, z. B. die Verwendung von Azure Monitor-Aktionsgruppen, um Trigger einzurichten, die automatisch verschiedene Aufgaben initiieren.

• Erweitern der Resilienz auf Hintergrundaufgaben

Die meisten Workloads umfassen Komponenten, die benutzerabläufe nicht direkt unterstützen, sondern eine wichtige Rolle im gesamten Workflow einer Anwendung spielen. Beispielsweise fügt das System in einem E-Commerce-System, wenn ein Benutzer eine Bestellung platziert, eine Nachricht zu einer Warteschlange hinzu. Diese Aktion löst mehrere Hintergrundaufgaben aus, z. B. E-Mail-Bestätigung, Abschluss der Kreditkartengebühr und Lagerbenachrichtigung zur Versandvorbereitung. Diese Aufgaben funktionieren getrennt von den Funktionen, die Benutzeranforderungen auf der Website bedienen, wodurch die Auslastung reduziert und die Zuverlässigkeit verbessert wird. Systeme basieren auch auf Hintergrundaufgaben für die Datenbereinigung, regelmäßige Wartung und Sicherungen.

Berücksichtigen Sie nach der Auswertung und Verbesserung ihrer primären Benutzerflüsse die Hintergrundaufgaben. Verwenden Sie die bereits vorhandenen Techniken und Infrastruktur, und fügen Sie Verbesserungen für Hintergrundaufgaben hinzu.

• Wenden Sie Prüfpunkte an. Das Checkpointing ist eine Technik zum Speichern des Zustands eines Prozesses oder einer Aufgabe zu bestimmten Zeitpunkten. Checkpointing ist besonders nützlich für lang andauernde Aufgaben oder Prozesse, die durch unerwartete Probleme wie Netzwerkfehler oder Systemabstürze unterbrochen werden könnten. Wenn der Prozess neu gestartet wird, kann er vom letzten gespeicherten Prüfpunkt übernommen werden, wodurch die Auswirkungen von Unterbrechungen minimiert werden.

• Halten Sie die Prozesse idempotent. Stellen Sie die Idempotenz in Hintergrundprozessen sicher, damit eine andere Instanz die Verarbeitung ohne Probleme fortsetzen kann, wenn eine Aufgabe fehlschlägt.

• Sicherstellen der Konsistenz. Verhindern Sie, dass das System einen inkonsistenten Zustand eingibt, wenn eine Hintergrundaufgabe während der Verarbeitung beendet wird. Sowohl Checkpointing als auch Idempotenz auf Taskebene sind Techniken, die eine größere Konsistenz zwischen den Operationen der Hintergrundtasks ermöglichen. Führen Sie jede Aufgabe als atome Transaktion aus. Verwenden Sie für einen Vorgang, der mehrere Datenspeicher oder Dienste umfasst, Idempotenz auf Aufgabenebene oder Ausgleichstransaktionen, um sicherzustellen, dass er abgeschlossen ist.

• Integrieren Sie Hintergrundaufgaben in Ihr Überwachungssystem und Testpraktiken. Erkennen Sie Fehler und verhindern Sie unbemerkte Unterbrechungen, die zu funktionalen und nicht funktionsfreien Folgen führen können. Ihr Überwachungssystem sollte Daten aus diesen Komponenten erfassen, Warnungen für Unterbrechungen festlegen und Trigger verwenden, um den Prozess automatisch erneut zu wiederholen oder fortzusetzen. Behandeln Sie diese Ressourcen als Teil der Workload, und führen Sie automatisierte Tests auf die gleiche Weise wie bei kritischen Komponenten durch.

Azure bietet mehrere Dienste und Features für Hintergrundaufträge, z. B. Azure Functions und Azure App Service WebJobs. Überprüfen Sie ihre bewährten Methoden und Grenzwerte, wenn Sie Abläufe implementieren, die sich auf Zuverlässigkeit konzentrieren.

Bleibt stabil, da sich die Workloadarchitektur weiterentwickelt, wodurch das System neuen und unvorhergesehenen Risiken standhalten kann.

Auf Ebene 5 verlagert sich der Fokus auf die Verbesserung der Zuverlässigkeit Ihrer Lösung von der Implementierung technischer Steuerelemente. Ihre Infrastruktur, Anwendungen und Vorgänge sollten zuverlässig genug sein, um ausfallsicher zu sein und sie innerhalb der Zielwiederherstellungszeiten wiederherzustellen.

Verwenden Sie Daten und zukünftige Geschäftsziele, um zu bestätigen, dass architektonische Änderungen erforderlich sein können, wenn Ihr Unternehmen weitergehen muss. Wenn Sich Ihre Workload weiterentwickelt und neue Features hinzugefügt werden, sollten Sie Ausfälle im Zusammenhang mit diesen Features minimieren und gleichzeitig die Ausfälle für vorhandene Features weiter reduzieren.

Schlüsselstrategien

• Verwenden sie Zuverlässigkeitseinblicke, um die Architekturentwicklung zu leiten

Treffen Sie auf dieser Ebene Entscheidungen in Zusammenarbeit mit den Geschäftsbeteiligten. Berücksichtigen Sie die folgenden Faktoren:

• Analysieren Sie Metriken, die angeben, wie oft Ihr System Zuverlässigkeitsschwellenwerte innerhalb eines Zeitraums überschreitet und ob dies akzeptabel ist. Beispielsweise kann das Erleben von fünf großen Ausfallen in einem Jahr eine Neubewertung der Systementwurfs- und Betriebspraktiken auslösen.

• Bewerten Sie die Geschäftskritikalität des Systems. Beispielsweise kann ein Dienst, der unternehmenskritische Workflows unterstützt, eine Neugestaltung für Bereitstellungen ohne Ausfallzeiten und sofortiges Failover erfordern, auch wenn die Kosten oder Komplexität erhöht werden. Umgekehrt kann ein Dienst mit geringerer Nutzung von lockeren Service-Level-Zielen profitieren.

• Bewerten Sie, wie sich Änderungen in anderen Säulen auf die Zuverlässigkeit auswirken. So könnten beispielsweise verstärkte Sicherheitsvorkehrungen eine Abschwächung der Zuverlässigkeit für zusätzliche Sicherheitssprünge erfordern, was zu potenziellen Fehlerquellen führen könnte.

• Bewerten sie die Betriebskosten bei der Aufrechterhaltung der Zuverlässigkeit. Wenn diese Kosten Budgetbeschränkungen überschreiten, sollten Sie Architekturänderungen in Betracht ziehen, um Ausgaben zu optimieren und zu steuern.

Um Projektbeteiligten, Ingenieuren und Produktmanagern dabei zu helfen, fundierte Entscheidungen zu treffen, sollten Sie die vorherigen Datenpunkte zusammen mit zusätzlichen Erkenntnissen visualisieren. Dieser Ansatz bietet ein vollständiges Bild der Zuverlässigkeit.

• Kontrollierte Tests in der Produktion ausführen

Berücksichtigen Sie auf dieser Ebene kontrollierte Experimente in der Produktion nur, wenn die Arbeitsauslastung die höchsten Resilienzgarantien erfordert. Diese Prüfpraktiken werden als Chaostechnik bezeichnet. Die Tests überprüfen, ob das System ordnungsgemäß wiederhergestellt werden kann und unter ungünstigen Bedingungen weiterhin funktioniert.

Betrachten Sie die folgenden Beispielanwendungsfälle:

• Abhängigkeitsflussanalyse: Ein gängiger Anwendungsfall ist das Testen von Anwendungen, die als Microservices entwickelt wurden. Sie können zufällige Mikroserviceinstanzen deaktivieren, um sicherzustellen, dass Fehler nicht überlappen oder stören. Sie können diesen Ansatz auf Systemflüsse erweitern, indem Sie bestimmte Komponenten deaktivieren, um zu analysieren, wie nachgelagerte Systeme reagieren. Ziel ist es, enge Kopplungen oder ausgeblendete Abhängigkeiten zu identifizieren und zu testen, wie Systemredundanzpläne ausgeführt werden.

• Ausfalltests mit schrittweiser Herabstufung: Bewerten Sie, wie das System bei einem Ausfall mit eingeschränkter Funktionalität funktioniert. Sie können beispielsweise nicht kritische Features ausblenden, wenn ein Empfehlungsmodul fehlschlägt.

• Fehlersimulation von Drittanbietern: Deaktivieren oder drosseln Sie Aufrufe an externe APIs, um zu sehen, wie Ihr System funktioniert und ob Fallbacks oder Wiederholungen ordnungsgemäß implementiert sind.

Chaos Engineering ist ein Goldstandard zum Testen der Resilienz. Reservieren Sie diese Praxis jedoch für reife Systeme und für Teams, die sich mit der Arbeitsbelastung befassen. Stellen Sie sicher, dass Sicherheitsvorkehrungen vorhanden sind, um den Strahlradius zu begrenzen und die Auswirkungen der Benutzer zu verhindern.

• Bereiten Sie sich vor, indem Sie Simulationstage ausführen. Beginnen Sie in Nichtproduktionsumgebungen, die reale Bedingungen simulieren, indem Sie Setups mit niedrigeren Risiken mit synthetischen Transaktionen verwenden. Dieser Ansatz hilft dabei, Prozesslücken, menschliche Fehlerpfade und Architekturfehler zu erkennen.

  Wenn nichtproduktionstests nicht mehr wertvolle Erkenntnisse liefern, kann es an der Zeit sein, zur Produktion zu wechseln, wenn Sie sicher sind. Stellen Sie sicher, dass Sie alle Bedenken auflisten, Resilienz bewerten und alle Probleme beheben, bevor Sie den Übergang durchführen.

• Beschränken Sie den Umfang der Experimente. Sie könnten zum Beispiel nur eine Instanz herunterfahren. Definieren Sie eindeutig den Zweck des Tests. Verstehen Sie, was Sie testen und warum.

Diese Tests müssen Vereinbarungen auf Serviceebene einhalten, indem sie innerhalb vordefinierter Grenzwerte und Fehlerbudgets arbeiten. Wählen Sie geeignete Zeitrahmen für diese Experimente aus. In der Regel stellt die Durchführung während eines Arbeitstags sicher, dass das Team voll besetzt ist und über ausreichend Ressourcen verfügt, um auf Vorfälle zu reagieren, die auftreten können.

• Durchführung von Notfallwiederherstellungsübungen

Chaos Engineering testet die Resilienz technischer Kontrollen. Notfallwiederherstellungs-Übungen bewerten die Robustheit von Prozesssteuerungen. Das Ziel von DR-Drills besteht darin, die Effektivität von Verfahren, Koordination und menschlichen Aktionen zu überprüfen, wenn Ihr System von schwerwiegenden Fehlern oder Katastrophen wiederhergestellt wird.

Bei gesetzlichen Workloads können Compliance-Anforderungen die Häufigkeit von DR-Drills vorschreiben, um eine Aufzeichnung des Aufwands zu gewährleisten. Für andere Workloads wird die regelmäßige Durchführung dieser Drills empfohlen. Ein sechsmonatiges Intervall bietet eine gute Möglichkeit, Workloadänderungen zu erfassen und DR-Verfahren entsprechend zu aktualisieren.

DR-Drills sollten mehr als Routineübungen sein. Bei der ordnungsgemäßen Durchführung helfen DR-Drills dabei, neue Teammitglieder zu trainieren und Lücken bei Tools, Kommunikation und anderen Drill-bezogenen Aufgaben zu identifizieren. Sie können auch frische Perspektiven hervorheben, die andernfalls übersehen werden könnten.

Berücksichtigen Sie die folgenden wichtigsten Methoden für die Durchführung von DR-Drills, die jeweils in Risiko und Praxis variieren:

• Vollständig simuliert: Diese Übungen sind vollständig whiteboardbasiert und umfassen exemplarische Vorgehensweisen ohne Auswirkungen auf Systeme. Sie eignen sich für Schulungen und erste Validierungen. Sie bieten jedoch keine Einblicke in echte Vorfälle.

• Reale Übungen in Nichtproduktionsumgebungen: Mit diesen Übungen können Sie Automatisierung, Skripts und Prozesse ohne Geschäftsrisiko validieren.

• Echte Bohrer in der Produktion: Diese Drills bieten den höchsten Grad an Vertrauen und Realismus. Führen Sie diese Drills erst nach dem Testen der beiden vorherigen Methoden durch. Eine gründliche Planung und Rollbackstrategien sind unerlässlich, um Risiken zu minimieren. Fahren Sie nicht fort, wenn die Möglichkeit besteht, Ausfälle zu verursachen.

Unabhängig von der Art des DR-Drills müssen Sie die Workload-Wiederherstellungsszenarien klar definieren. Führen Sie Drills aus, als wären sie echte Vorfälle. Mit diesem Ansatz wird sichergestellt, dass das Team gut verstandene Checklisten befolgt. Dokumentieren und klassifizieren Sie Ergebnisse, um eine kontinuierliche Verbesserung zu fördern. Ihre DR-Vorbereitung kann die folgenden Prozesse umfassen:

• Verstehen Sie Vorfallverwaltungssysteme, und stellen Sie sicher, dass das Team auf Eskalationspfaden trainiert wird.

• Kommunikationstools für Die Zusammenarbeit und Statusaktualisierungen auflisten, einschließlich Alternativen, falls primäre Systeme betroffen sind.

• Bereitstellung von Qualifikationsmaterialien zu relevanten Testszenarien für die Arbeitslast.

• Verfolgen Sie Diskrepanzen, um Probleme zu erfassen, die während der Implementierung aufgetreten sind.

Kompromiss: Diese Übungen sind in der Regel nicht störend, nehmen jedoch Zeit in Anspruch. Konzentrieren Sie sich auf die wichtigsten Aspekte, um ihre Effektivität zu maximieren und unnötige Aufgaben zu vermeiden. Stellen Sie sicher, dass Sie in Ihrem Backlog Zeit für diese Übung einplanen.

Wenn Sie DR-Pläne erstellen oder DR-Drills durchführen, insbesondere für die ersten Drills, sollten Sie spezielle Kenntnisse einbeziehen. Ihr Beitrag zum Multiregionen-Design, zu Failover- und Failback-Strategien sowie zu Diensten und Werkzeugen kann von unschätzbarem Wert sein. Wenn Ihre Organisation über ein Cloud Center of Excellence-Team verfügt, müssen Sie sie unbedingt in den Planungsprozess einbeziehen.

– Bewerten Sie ihr Datenmodell und Segment bei Bedarf.

Daten sind dynamisch und entwickeln sich ständig weiter. Im Gegensatz zu anderen Komponenten in Ihrer Architektur wächst die Daten normalerweise, wenn Benutzer mit Ihrem System interagieren. Das Überwachen von Datenmustern im Laufe der Zeit und die Bewertung ihrer Auswirkungen auf andere Teile Ihrer Architektur ist unerlässlich. Berücksichtigen Sie auf dieser Ebene Techniken, die die Datenverwaltung vereinfachen und die Leistung verbessern, um die Gesamtzulässigkeit zu verbessern. Partitionierung ist eine Schlüsselstrategie für die Erreichung dieser Ergebnisse.

Erkunden Sie Techniken wie Hot-Cold Partitioning, die Daten basierend auf Zugriffsmustern aufteilen und separat speichert. Verwenden Sie Kriterien wie die Häufigkeit des Zugriffs oder der Relevanz, um zu entscheiden, was partitioniert werden soll.

Hot-Cold Partitioning kann mit Sharding kombiniert werden, bei dem es sich um einen Prozess handelt, der eine große Datenbank in kleinere Einheiten unterteilt, die als Shards bezeichnet werden. Jeder Shard enthält einen Teil der Daten, und zusammen bilden sie das vollständige Dataset. Dieser Ansatz ermöglicht eine unabhängige Datenverwaltung.

Kompromiss: Die gleichmäßige Verteilung von Shards erfordert operative Prozesse, um ihre Verteilung zu bewerten und zu bestätigen. Dieser Ansatz hilft dabei, Hot Partitionen zu vermeiden, bei denen eine Partition überlastet ist. Es erfordert jedoch auch laufende Anstrengungen und Ressourcen, um das Gleichgewicht aufrechtzuerhalten.

Berücksichtigen Sie beim Auswählen einer Partitionierungsmethode die folgenden Zuverlässigkeitsvorteile:

• Verbesserte Leistung: Durch die Verteilung von Anforderungen über mehrere Partitionen können Sie die Auslastung einzelner Speicher reduzieren. Wenn sie effektiv implementiert wird, ermöglicht Sharding es einem System, Millionen von Schreibanforderungen pro Tag zu verarbeiten. Diese Strategie verbessert die Leistung und minimiert die Latenz.

  Die Partitionierung kann die horizontale Skalierung vereinfachen. Durch Sharding können beispielsweise Benutzer oder Kunden in ungefähr gleich große Buckets aufgeteilt werden.

• Verbesserte Datenverwaltung: Hot-Cold Partitioning ermöglicht es, verschiedene Ebenen der Datenverwaltung auf jede Speicherebene anzuwenden. Das Verschieben von Archivierungsdaten in einen separaten Speicher hilft beispielsweise, Verlangsamungen bei Vorgängen und Sicherungen zu verhindern. Ebenso müssen nicht alle Protokolldaten in einer relationalen Datenbank gespeichert werden. Sie kann in einem anderen Datenspeicher gespeichert werden, während aktive Workloaddaten relational bleiben.

• Maßgeschneiderte Zuverlässigkeitsrichtlinien: Verschiedene Zuverlässigkeitsrichtlinien können angewendet werden, um sicherzustellen, dass jede Partition über die richtige Resilienz verfügt und verhindert, dass ein einzelner Speicher zu einem Engpass wird. Heiße Partitionen können vollständig redundant sein, einschließlich Zonenredundanz und Georedundanz, während kalte Partitionen sich auf Sicherungen verlassen. Ein zusätzlicher Vorteil für die Zuverlässigkeit besteht darin, dass Sie auch den Auswirkungsbereich einiger Fehlertypen reduzieren können. Wenn sich ein Fehler beispielsweise auf einen Shard auswirkt, wirkt es sich möglicherweise nicht auf die anderen Shards aus.

Ausgleich: Es kann schwierig sein, Partitionen aufgrund der starken Interabhängigkeiten zwischen verschiedenen Datenpartitionen zu verwalten oder zu ändern. Diese Änderungen können sich auf die Möglichkeit auswirken, die Datenkonsistenz und Integrität zu überprüfen, insbesondere im Vergleich zu einem einzelnen Datenspeicher. Da sich die Anzahl der Partitionen erhöht, wird die Notwendigkeit robuster Prozesse zur Aufrechterhaltung der Datenintegrität wichtiger. Ohne diese Maßnahmen kann die Zuverlässigkeit beeinträchtigt werden.