Well-Architected Framework: Säule „Zuverlässigkeit“

Last reviewed 2025-02-14 UTC

Die Säule „Zuverlässigkeit“ im Google Cloud Well-Architected Framework bietet Prinzipien und Empfehlungen, mit denen Sie zuverlässige Arbeitslasten in Google Cloudentwerfen, bereitstellen und verwalten können.

Dieses Dokument richtet sich an Cloud-Architekten, Entwickler, Plattformtechniker, Administratoren und Site Reliability Engineers.

Zuverlässigkeit ist die Fähigkeit eines Systems, seine beabsichtigten Funktionen unter den definierten Bedingungen konsistent auszuführen und einen unterbrechungsfreien Dienst aufrechtzuerhalten. Best Practices für die Zuverlässigkeit umfassen Redundanz, fehlertolerantes Design, Monitoring und automatisierte Wiederherstellungsprozesse.

Resilienz ist die Fähigkeit des Systems, Fehler oder unerwartete Störungen zu überstehen und sich davon zu erholen, während die Leistung aufrechterhalten wird.Google Cloud -Funktionen wie Bereitstellungen in mehreren Regionen, automatische Back-ups und Lösungen für die Notfallwiederherstellung können Ihnen helfen, die Resilienz Ihres Systems zu verbessern.

Zuverlässigkeit ist aus vielen Gründen wichtig für Ihre Cloud-Strategie, unter anderem aus den folgenden:

  • Minimale Ausfallzeiten: Ausfallzeiten können zu Umsatzeinbußen, geringerer Produktivität und Reputationsschäden führen. Robuste Architekturen können dazu beitragen, dass Systeme auch bei Ausfällen weiter funktionieren oder sich effizient von Ausfällen erholen können.
  • Verbesserte Nutzerfreundlichkeit: Nutzer erwarten nahtlose Interaktionen mit Technologie. Robuste Systeme können dazu beitragen, eine gleichbleibende Leistung und Verfügbarkeit aufrechtzuerhalten, und bieten auch bei hoher Nachfrage oder unerwarteten Problemen einen zuverlässigen Dienst.
  • Datenintegrität: Fehler können zu Datenverlust oder Datenbeschädigung führen. In resilienten Systemen werden Mechanismen wie Sicherungen, Redundanz und Replikation implementiert, um Daten zu schützen und dafür zu sorgen, dass sie korrekt und zugänglich bleiben.
  • Aufrechterhaltung des Geschäftsbetriebs: Ihr Unternehmen ist für kritische Vorgänge auf Technologie angewiesen. Robuste Architekturen können dazu beitragen, die Kontinuität nach einem katastrophalen Ausfall sicherzustellen. So können Geschäftsfunktionen ohne größere Unterbrechungen fortgesetzt werden und eine schnelle Wiederherstellung wird unterstützt.
  • Compliance: In vielen Branchen gibt es behördliche Anforderungen an die Systemverfügbarkeit und den Datenschutz. Resiliente Architekturen können Ihnen helfen, diese Standards einzuhalten, indem sie dafür sorgen, dass Systeme betriebsbereit und sicher bleiben.
  • Niedrigere langfristige Kosten: Robuste Architekturen erfordern Vorabinvestitionen. Die Robustheit kann jedoch dazu beitragen, die Kosten im Laufe der Zeit zu senken, indem teure Ausfallzeiten verhindert, reaktive Korrekturen vermieden und eine effizientere Ressourcennutzung ermöglicht wird.

Organisatorische Denkweise

Damit Ihre Systeme zuverlässig sind, benötigen Sie einen Plan und eine etablierte Strategie. Diese Strategie muss Schulungen und die Befugnis umfassen, Zuverlässigkeit neben anderen Initiativen zu priorisieren.

Machen Sie deutlich, dass die gesamte Organisation für die Zuverlässigkeit verantwortlich ist, einschließlich Entwicklung, Produktmanagement, Betrieb, Plattformentwicklung und Site Reliability Engineering (SRE). Sogar geschäftsorientierte Gruppen wie Marketing und Vertrieb können die Zuverlässigkeit beeinflussen.

Jedes Team muss die Zuverlässigkeitsziele und Risiken seiner Anwendungen kennen. Die Teams müssen für diese Anforderungen verantwortlich sein. Konflikte zwischen Zuverlässigkeit und regulärer Produktfeature-Entwicklung müssen priorisiert und entsprechend eskaliert werden.

Planen und verwalten Sie die Zuverlässigkeit ganzheitlich für alle Ihre Funktionen und Teams. Erwägen Sie die Einrichtung eines Cloud Center of Excellence (CCoE), das eine Säule für Zuverlässigkeit umfasst. Weitere Informationen finden Sie unter Cloud Center of Excellence zur Optimierung der Cloud-Migration Ihrer Organisation.

Schwerpunkte für Zuverlässigkeit

Die Aktivitäten, die Sie zum Entwerfen, Bereitstellen und Verwalten eines zuverlässigen Systems ausführen, lassen sich in die folgenden Schwerpunktbereiche einteilen. Jedes der Zuverlässigkeitsprinzipien und ‑empfehlungen in dieser Säule bezieht sich auf einen dieser Schwerpunktbereiche.

  • Umfang: Führen Sie eine detaillierte Analyse der Architektur Ihres Systems durch, um es zu verstehen. Sie müssen die Komponenten, ihre Funktionsweise und Interaktion, den Fluss von Daten und Aktionen durch das System und mögliche Fehlerquellen verstehen. Potenzielle Fehler, Engpässe und Risiken identifizieren, damit Sie Maßnahmen ergreifen können, um diese Probleme zu beheben.
  • Beobachtung: Um Systemausfälle zu vermeiden, sollten Sie eine umfassende und kontinuierliche Beobachtung und Überwachung implementieren. So können Sie Trends erkennen und potenzielle Probleme proaktiv identifizieren.
  • Reaktion: Um die Auswirkungen von Fehlern zu reduzieren, müssen Sie angemessen reagieren und sich effizient erholen. Automatisierte Antworten können auch dazu beitragen, die Auswirkungen von Fehlern zu verringern. Trotz Planung und Kontrollen können Fehler auftreten.
  • Lernen: Um zu verhindern, dass Fehler wieder auftreten, sollten Sie aus jeder Erfahrung lernen und entsprechende Maßnahmen ergreifen.

Grundprinzipien

Die Empfehlungen in der Säule „Zuverlässigkeit“ des Well-Architected Framework sind den folgenden Grundprinzipien zugeordnet:

Beitragende

Autoren:

Weitere Beitragende:

Zuverlässigkeit anhand von User-Experience-Zielen definieren

Dieses Prinzip im Zuverlässigkeitsbereich des Google Cloud Well-Architected Framework hilft Ihnen, die Nutzerfreundlichkeit zu bewerten und die Ergebnisse dann Zuverlässigkeitszielen und ‑messwerten zuzuordnen.

Dieser Grundsatz ist für den Fokusbereich Umfang der Zuverlässigkeit relevant.

Übersicht über die Grundsätze

Observability-Tools liefern große Mengen an Daten, aber nicht alle Daten beziehen sich direkt auf die Auswirkungen auf die Nutzer. Beispielsweise kann es zu einer hohen CPU-Auslastung, langsamen Servervorgängen oder sogar zu abgestürzten Aufgaben kommen. Wenn diese Probleme jedoch nicht die Nutzererfahrung beeinträchtigen, stellen sie keinen Ausfall dar.

Um die Nutzerfreundlichkeit zu messen, müssen Sie zwischen dem internen Systemverhalten und nutzerorientierten Problemen unterscheiden. Konzentrieren Sie sich auf Messwerte wie das Erfolgsverhältnis von Nutzeranfragen. Verlassen Sie sich nicht nur auf serverzentrierte Messwerte wie die CPU-Auslastung, da diese zu irreführenden Schlussfolgerungen über die Zuverlässigkeit Ihres Dienstes führen können. Echte Zuverlässigkeit bedeutet, dass Nutzer Ihre Anwendung oder Ihren Dienst konsistent und effektiv nutzen können.

Empfehlungen

Die folgenden Empfehlungen können Ihnen helfen, die Nutzerfreundlichkeit effektiv zu messen.

Nutzerfreundlichkeit messen

Um die Zuverlässigkeit Ihres Dienstes wirklich zu verstehen, sollten Sie Messwerte priorisieren, die die tatsächliche Nutzererfahrung widerspiegeln. Messen Sie beispielsweise das Erfolgsverhältnis von Nutzeranfragen, die Anwendungs-Latenz und die Fehlerraten.

Im Idealfall werden diese Daten direkt vom Gerät oder Browser des Nutzers erhoben. Wenn diese direkte Datenerhebung nicht möglich ist, verlagern Sie den Messpunkt im System schrittweise weiter weg vom Nutzer. Sie können beispielsweise den Load Balancer oder den Frontend-Dienst als Messpunkt verwenden. So können Sie Probleme erkennen und beheben, bevor sie sich erheblich auf Ihre Nutzer auswirken.

Kaufprozesse analysieren

Mithilfe von Tracing-Tools wie Cloud Trace können Sie nachvollziehen, wie Nutzer mit Ihrem System interagieren. Wenn Sie die User Journey durch Ihre Anwendung nachvollziehen, können Sie Engpässe und Latenzprobleme finden, die die Nutzerfreundlichkeit beeinträchtigen. Cloud Trace erfasst detaillierte Leistungsdaten für jeden Hop in Ihrer Dienstarchitektur. Anhand dieser Daten können Sie Leistungsprobleme effizienter erkennen und beheben, was zu einer zuverlässigeren und zufriedenstellenderen Nutzererfahrung führen kann.

Realistische Zuverlässigkeitsziele festlegen

Dieses Prinzip in der Säule „Zuverlässigkeit“ des Google Cloud Well-Architected Framework hilft Ihnen, Zuverlässigkeitsziele zu definieren, die für Ihre Arbeitslasten in Google Cloudtechnisch realisierbar sind.

Dieser Grundsatz ist für den Fokusbereich Umfang der Zuverlässigkeit relevant.

Übersicht über die Grundsätze

Gestalten Sie Ihre Systeme so, dass sie gerade zuverlässig genug sind, um die Nutzerzufriedenheit zu gewährleisten. Es mag kontraintuitiv erscheinen, aber ein Ziel von 100% Zuverlässigkeit ist oft nicht die effektivste Strategie. Eine höhere Zuverlässigkeit kann zu deutlich höheren Kosten führen, sowohl in Bezug auf finanzielle Investitionen als auch auf potenzielle Einschränkungen bei Innovationen. Wenn Nutzer bereits mit dem aktuellen Serviceniveau zufrieden sind, kann es sich lohnen, die Bemühungen zur Steigerung der Zufriedenheit zu reduzieren. Stattdessen können Sie Ressourcen besser an anderer Stelle einsetzen.

Sie müssen herausfinden, ab welchem Zuverlässigkeitsniveau Ihre Nutzer zufrieden sind, und den Punkt bestimmen, an dem die Kosten für inkrementelle Verbesserungen die Vorteile überwiegen. Wenn Sie dieses Niveau an ausreichender Zuverlässigkeit erreicht haben, können Sie Ressourcen strategisch zuweisen und sich auf Funktionen und Verbesserungen konzentrieren, die Ihren Nutzern einen größeren Mehrwert bieten.

Empfehlungen

Berücksichtigen Sie die Empfehlungen in den folgenden Unterabschnitten, um realistische Zuverlässigkeitsziele festzulegen.

Einige Fehler in Kauf nehmen und Komponenten priorisieren

Streben Sie eine hohe Verfügbarkeit wie 99,99% Betriebszeit an, aber setzen Sie kein Ziel von 100 % Betriebszeit. Erkennen Sie an, dass einige Fehler unvermeidlich sind.

Die Lücke zwischen 100% Betriebszeit und einem Ziel von 99,99% ist die zulässige Ausfallzeit. Diese Lücke wird oft als Fehlerbudget bezeichnet. Mit dem Fehlerbudget können Sie Risiken eingehen und Innovationen vorantreiben. Das ist für jedes Unternehmen unerlässlich, um wettbewerbsfähig zu bleiben.

Priorisieren Sie die Zuverlässigkeit der wichtigsten Komponenten im System. Akzeptieren Sie, dass weniger kritische Komponenten eine höhere Fehlertoleranz haben können.

Zuverlässigkeit und Kosten in Einklang bringen

Um das optimale Zuverlässigkeitsniveau für Ihr System zu ermitteln, sollten Sie gründliche Kosten-Nutzen-Analysen durchführen.

Berücksichtigen Sie Faktoren wie Systemanforderungen, die Folgen von Fehlern und die Risikobereitschaft Ihrer Organisation für die jeweilige Anwendung. Berücksichtigen Sie dabei Ihre Messwerte für die Notfallwiederherstellung, z. B. das Recovery Time Objective (RTO) und das Recovery Point Objective (RPO). Legen Sie fest, welches Maß an Zuverlässigkeit innerhalb des Budgets und anderer Einschränkungen akzeptabel ist.

Suchen Sie nach Möglichkeiten, die Effizienz zu steigern und die Kosten zu senken, ohne die wesentlichen Zuverlässigkeitsfunktionen zu beeinträchtigen.

Hochverfügbare Systeme durch Ressourcenredundanz erstellen

Dieses Prinzip im Zuverlässigkeitsbereich des Google Cloud Well-Architected Framework enthält Empfehlungen zur Planung, Erstellung und Verwaltung von Ressourcenredundanz, die Ihnen helfen können, Ausfälle zu vermeiden.

Dieser Grundsatz ist für den Fokusbereich Umfang der Zuverlässigkeit relevant.

Übersicht über die Grundsätze

Nachdem Sie das erforderliche Zuverlässigkeitsniveau festgelegt haben, müssen Sie Ihre Systeme so konzipieren, dass Single Points of Failure vermieden werden. Jede kritische Komponente im System muss auf mehreren Maschinen, Zonen und Regionen repliziert werden. Eine kritische Datenbank kann beispielsweise nicht nur in einer Region vorhanden sein und ein Metadatenserver kann nicht nur in einer einzelnen Zone oder Region bereitgestellt werden. Wenn in diesen Beispielen die einzige Zone oder Region einen Ausfall hat, hat das System einen globalen Ausfall.

Empfehlungen

Beachten Sie die Empfehlungen in den folgenden Unterabschnitten, um redundante Systeme zu erstellen.

Ausfalldomänen identifizieren und Dienste replizieren

Erstellen Sie eine Übersicht der Fehlerdomains Ihres Systems, von einzelnen VMs bis hin zu Regionen, und planen Sie Redundanz in den Fehlerdomains ein.

Um eine hohe Verfügbarkeit zu gewährleisten, sollten Sie Ihre Dienste und Anwendungen auf mehrere Zonen und Regionen verteilen und replizieren. Konfigurieren Sie das System für automatisches Failover, damit die Dienste und Anwendungen bei Zonen- oder Regionsausfällen weiterhin verfügbar sind.

Beispiele für multizonale und multiregionale Architekturen finden Sie unter Zuverlässige Infrastruktur für Ihre Arbeitslasten in Google Cloud entwerfen.

Probleme schnell erkennen und beheben

Behalten Sie den Status Ihrer Fehlerbereiche im Blick, um Probleme rechtzeitig zu erkennen und zu beheben.

Sie können den aktuellen Status der Google Cloud -Dienste in allen Regionen über das Google Cloud Service Health-Dashboard überwachen. Sie können auch Vorfälle, die für Ihr Projekt relevant sind, mit Personalized Service Health anzeigen. Mit Load-Balancern können Sie den Zustand von Ressourcen erkennen und Traffic automatisch an fehlerfreie Backends weiterleiten. Weitere Informationen finden Sie unter Systemdiagnosen – Übersicht.

Failover-Szenarien testen

Simulieren Sie regelmäßig Fehler, um die Effektivität Ihrer Replikations- und Failover-Strategien zu prüfen.

Weitere Informationen finden Sie unter Ausfall einer Zone für eine regionale MIG simulieren und Ausfall einer Zone in regionalen GKE-Clustern simulieren.

Horizontale Skalierbarkeit nutzen

Dieses Prinzip in der Zuverlässigkeitssäule des Google Cloud Well-Architected Framework enthält Empfehlungen zur Verwendung horizontaler Skalierbarkeit. Durch die horizontale Skalierbarkeit können Sie dafür sorgen, dass Ihre Arbeitslasten inGoogle Cloud effizient skaliert werden und die Leistung beibehalten wird.

Dieser Grundsatz ist für den Fokusbereich Umfang der Zuverlässigkeit relevant.

Übersicht über die Grundsätze

Stellen Sie Ihr System auf eine horizontale Architektur um. Um dem Wachstum von Traffic oder Daten gerecht zu werden, können Sie weitere Ressourcen hinzufügen. Sie können auch Ressourcen entfernen, wenn sie nicht verwendet werden.

Um den Wert der horizontalen Skalierung zu verstehen, sollten Sie sich die Einschränkungen der vertikalen Skalierung ansehen.

Ein häufiges Szenario für die vertikale Skalierung ist die Verwendung einer MySQL-Datenbank als primäre Datenbank mit kritischen Daten. Mit zunehmender Datenbanknutzung sind mehr RAM und CPU erforderlich. Irgendwann erreicht die Datenbank das Speicherlimit auf dem Hostcomputer und muss aktualisiert werden. Möglicherweise müssen Sie diesen Vorgang mehrmals wiederholen. Das Problem ist, dass es feste Grenzen für das Wachstum einer Datenbank gibt. Die VM-Größen sind nicht unbegrenzt. Es kann ein Punkt erreicht werden, an dem der Datenbank keine weiteren Ressourcen mehr hinzugefügt werden können.

Auch wenn Ressourcen unbegrenzt wären, kann eine große VM zu einem Single Point of Failure werden. Jedes Problem mit der primären Datenbank-VM kann zu Fehlerantworten oder zu einem systemweiten Ausfall führen, der alle Nutzer betrifft. Vermeiden Sie Single Points of Failure, wie unter Hochverfügbare Systeme durch Ressourcenredundanz erstellen beschrieben.

Abgesehen von diesen Skalierungsgrenzen ist die vertikale Skalierung in der Regel teurer. Die Kosten können exponentiell steigen, wenn Maschinen mit mehr Rechenleistung und Arbeitsspeicher angeschafft werden.

Die horizontale Skalierung kann dagegen weniger kosten. Das Potenzial für die horizontale Skalierung ist in einem System, das für die Skalierung konzipiert ist, praktisch unbegrenzt.

Empfehlungen

Um von einer Architektur mit einer einzelnen VM zu einer horizontalen Architektur mit mehreren Maschinen zu wechseln, müssen Sie sorgfältig planen und die richtigen Tools verwenden. Die folgenden Unterabschnitte enthalten Empfehlungen, die Ihnen bei der horizontalen Skalierung helfen können.

Verwaltete Dienste verwenden

Bei verwalteten Diensten ist keine manuelle Verwaltung der horizontalen Skalierung erforderlich. Mit verwalteten Instanzgruppen (Managed Instance Groups, MIGs) in Compute Engine können Sie beispielsweise VMs hinzufügen oder entfernen, um Ihre Anwendung horizontal zu skalieren. Cloud Run ist eine serverlose Plattform für containerisierte Anwendungen, die Ihre zustandslosen Container automatisch auf Grundlage des eingehenden Traffics skaliert.

Modulares Design fördern

Modulare Komponenten und übersichtliche Schnittstellen ermöglichen es Ihnen, einzelne Komponenten nach Bedarf zu skalieren, anstatt die gesamte Anwendung. Weitere Informationen finden Sie unter Modulares Design fördern in der Spalte „Leistungsoptimierung“.

Zustandslose Architektur implementieren

Entwickeln Sie Anwendungen so, dass sie zustandslos sind, d. h., dass keine Daten lokal gespeichert werden. So können Sie Instanzen hinzufügen oder entfernen, ohne sich um die Datenkonsistenz sorgen zu müssen.

Mögliche Fehler mithilfe von Observability erkennen

Dieses Prinzip im Bereich „Zuverlässigkeit“ des Google Cloud Well-Architected Framework enthält Empfehlungen, mit denen Sie proaktiv Bereiche identifizieren können, in denen Fehler und Ausfälle auftreten können.

Dieses Prinzip ist für den Fokusbereich Beobachtung der Zuverlässigkeit relevant.

Übersicht über die Grundsätze

Um die Zuverlässigkeit Ihrer Arbeitslasten inGoogle Cloudaufrechtzuerhalten und zu verbessern, müssen Sie eine effektive Beobachtbarkeit mithilfe von Messwerten, Logs und Traces implementieren.

  • Messwerte sind numerische Messungen von Aktivitäten, die Sie für Ihre Anwendung in bestimmten Zeitintervallen erfassen möchten. Sie können beispielsweise technische Messwerte wie Anfragerate und Fehlerrate erfassen, die als Service Level Indicators (SLIs) verwendet werden können. Möglicherweise müssen Sie auch anwendungsspezifische Geschäftsmesswerte wie aufgegebene Bestellungen und eingegangene Zahlungen erfassen.
  • Logs sind Zeitstempeldatensätze von einzelnen Ereignissen, die in einer Anwendung oder einem System auftreten. Das Ereignis kann ein Fehler, ein Fehler oder eine Zustandsänderung sein. Logs können Messwerte enthalten und Sie können Logs auch für SLIs verwenden.
  • Ein Trace stellt den Weg eines einzelnen Nutzers oder einer einzelnen Transaktion durch mehrere separate Anwendungen oder die Komponenten einer Anwendung dar. Diese Komponenten können beispielsweise Mikrodienste sein. Mithilfe von Traces können Sie nachvollziehen, welche Komponenten in den Abläufen verwendet wurden, wo Engpässe bestehen und wie lange die Abläufe gedauert haben.

Messwerte, Logs und Traces helfen Ihnen, Ihr System kontinuierlich zu überwachen. Durch umfassende Überwachung können Sie herausfinden, wo und warum Fehler aufgetreten sind. Sie können auch potenzielle Fehler erkennen, bevor sie auftreten.

Empfehlungen

Beachten Sie die Empfehlungen in den folgenden Abschnitten, um potenzielle Fehler effizient zu erkennen.

Umfassende Statistiken erhalten

Verwenden Sie Cloud Monitoring und Cloud Logging, um wichtige Messwerte wie Antwortzeiten und Fehlerraten zu erfassen. Mit diesen Tools können Sie auch dafür sorgen, dass die Messwerte den Anforderungen Ihrer Arbeitslast entsprechen.

Um datengestützte Entscheidungen zu treffen, analysieren Sie die Standardmesswerte für Dienste, um die Abhängigkeiten von Komponenten und ihre Auswirkungen auf die Gesamtleistung der Arbeitslast zu verstehen.

Wenn Sie Ihre Monitoringstrategie anpassen möchten, können Sie mit dem Google Cloud SDK eigene Messwerte erstellen und veröffentlichen.

Proaktive Fehlerbehebung durchführen

Implementieren Sie eine robuste Fehlerbehandlung und aktivieren Sie die Protokollierung für alle Komponenten Ihrer Arbeitslasten in Google Cloud. Aktivieren Sie Logs wie Cloud Storage-Zugriffslogs und VPC-Flusslogs.

Berücksichtigen Sie beim Konfigurieren der Protokollierung die damit verbundenen Kosten. Um die Logging-Kosten zu senken, können Sie Ausschlussfilter für die Logsenken konfigurieren, um bestimmte Logs vom Speichern auszuschließen.

Ressourcennutzung optimieren

Behalten Sie die CPU-Auslastung, die Netzwerk-E/A-Messwerte und die Laufwerk-E/A-Messwerte im Blick, um unter- und überdimensionierte Ressourcen in Diensten wie GKE, Compute Engine und Dataproc zu erkennen. Eine vollständige Liste der unterstützten Dienste finden Sie unter Cloud Monitoring-Übersicht.

Benachrichtigungen priorisieren

Konzentrieren Sie sich bei Benachrichtigungen auf wichtige Messwerte, legen Sie geeignete Grenzwerte fest, um die Anzahl der Benachrichtigungen zu minimieren, und sorgen Sie dafür, dass rechtzeitig auf wichtige Probleme reagiert wird. Mit diesem gezielten Ansatz können Sie die Zuverlässigkeit von Arbeitslasten proaktiv aufrechterhalten. Weitere Informationen finden Sie unter Benachrichtigungen – Übersicht.

Design für Graceful Degradation

Dieses Prinzip im Zuverlässigkeitsbereich des Google Cloud Well-Architected Framework bietet Empfehlungen, mit denen Sie Ihre Google Cloud Arbeitslasten so gestalten können, dass sie im Fehlerfall ordnungsgemäß beendet werden.

Dieses Prinzip ist für den Antwort-Fokusbereich der Zuverlässigkeit relevant.

Übersicht über die Grundsätze

Graceful Degradation ist ein Designansatz, bei dem ein System, das einer hohen Last ausgesetzt ist, weiterhin funktioniert, möglicherweise mit reduzierter Leistung oder Genauigkeit. Durch die sanfte Herabstufung wird die Verfügbarkeit des Systems aufrechterhalten und ein vollständiger Ausfall verhindert, auch wenn die Leistung des Systems nicht optimal ist. Wenn die Last wieder ein überschaubares Niveau erreicht, wird die volle Funktionalität des Systems wiederhergestellt.

Bei hoher Last priorisiert die Google Suche beispielsweise Ergebnisse von Webseiten mit einem höheren Ranking, was möglicherweise zu Lasten der Genauigkeit geht. Wenn die Last abnimmt, werden die Suchergebnisse in der Google Suche neu berechnet.

Empfehlungen

Beachten Sie die Empfehlungen in den folgenden Unterabschnitten, um Ihre Systeme für eine reibungslose Herabsetzung der Leistung zu konzipieren.

Drosselung implementieren

Achten Sie darauf, dass Ihre Replikate Überlastungen unabhängig voneinander bewältigen und eingehende Anfragen bei hohem Traffic drosseln können. Dieser Ansatz hilft Ihnen, kaskadierende Fehler zu vermeiden, die durch Verschiebungen von übermäßigem Traffic zwischen Zonen verursacht werden.

Verwenden Sie Tools wie Apigee, um die Rate von API-Anfragen bei hohem Traffic zu steuern. Sie können Richtlinienregeln so konfigurieren, dass sie widerspiegeln, wie Sie Anfragen reduzieren möchten.

Überflüssige Anfragen frühzeitig löschen

Konfigurieren Sie Ihre Systeme so, dass überschüssige Anfragen auf der Frontend-Ebene verworfen werden, um Backend-Komponenten zu schützen. Durch das Verwerfen einiger Anfragen werden globale Fehler verhindert und das System kann sich besser erholen.Bei diesem Ansatz kann es jedoch vorkommen, dass einige Nutzer Fehler sehen. Sie können die Auswirkungen von Ausfällen jedoch minimieren. Im Gegensatz zu einem Ansatz wie Circuit Breaking, bei dem bei einer Überlastung sämtlicher Traffic verworfen wird.

Partielle Fehler und Wiederholungsversuche behandeln

Entwickeln Sie Ihre Anwendungen so, dass sie partielle Fehler und Wiederholungsversuche nahtlos verarbeiten. Dieses Design trägt dazu bei, dass bei hoher Last so viel Traffic wie möglich verarbeitet wird.

Überlastungsszenarien testen

Um zu prüfen, ob die Drosselungs- und Anforderungsablehnungsmechanismen effektiv funktionieren, sollten Sie regelmäßig Überlastungsbedingungen in Ihrem System simulieren. Tests helfen Ihnen, Ihr System auf tatsächliche Trafficspitzen vorzubereiten.

Trafficspitzen beobachten

Mit Analyse- und Monitoringtools können Sie Trafficspitzen vorhersagen und darauf reagieren, bevor sie zu Überlastungen führen. Eine frühzeitige Erkennung und Reaktion kann dazu beitragen, die Verfügbarkeit von Diensten in Zeiten hoher Nachfrage aufrechtzuerhalten.

Wiederherstellung nach Fehlern testen

Dieses Prinzip im Zuverlässigkeitsbereich des Google Cloud Well-Architected Framework enthält Empfehlungen, die Ihnen helfen, Tests für die Wiederherstellung im Falle von Fehlern zu entwerfen und auszuführen.

Dieses Prinzip ist für den Lernbereich Zuverlässigkeit relevant.

Übersicht über die Grundsätze

Damit Ihr System nach Ausfällen wiederhergestellt werden kann, müssen Sie regelmäßig Tests durchführen, die regionale Failover, Release-Rollbacks und die Wiederherstellung von Daten aus Back-ups umfassen.

Mit diesen Tests können Sie Reaktionen auf Ereignisse üben, die ein großes Risiko für die Zuverlässigkeit darstellen, z. B. den Ausfall einer ganzen Region. Mit diesen Tests können Sie auch prüfen, ob sich Ihr System bei einer Störung wie vorgesehen verhält.

Im unwahrscheinlichen Fall, dass eine ganze Region ausfällt, müssen Sie den gesamten Traffic auf eine andere Region umleiten. Wenn Daten während des normalen Betriebs Ihrer Arbeitslast geändert werden, müssen sie von der primären Region in die Failover-Region synchronisiert werden. Sie müssen dafür sorgen, dass die replizierten Daten immer sehr aktuell sind, damit Nutzer keinen Datenverlust oder Sitzungsabbruch erleiden. Das Load-Balancing-System muss außerdem in der Lage sein, den Traffic jederzeit ohne Dienstunterbrechungen in die Failover-Region zu verlagern. Um Ausfallzeiten nach einem regionalen Ausfall zu minimieren, müssen Betriebsingenieure auch in der Lage sein, den Nutzer-Traffic manuell und effizient von einer Region wegzuleiten, und zwar in möglichst kurzer Zeit. Dieser Vorgang wird manchmal als Entleeren einer Region bezeichnet. Das bedeutet, dass Sie den eingehenden Traffic in die Region stoppen und den gesamten Traffic an einen anderen Ort verschieben.

Empfehlungen

Beachten Sie beim Entwerfen und Ausführen von Tests zur Fehlerbehebung die Empfehlungen in den folgenden Unterabschnitten.

Testziele und -umfang definieren

Definieren Sie klar, was Sie mit dem Test erreichen möchten. Ihre Ziele können beispielsweise Folgendes umfassen:

  • Validieren Sie das Recovery Time Objective (RTO) und das Recovery Point Objective (RPO). Weitere Informationen finden Sie unter Grundlagen der DR-Planung.
  • Bewerten Sie die Systemresilienz und Fehlertoleranz in verschiedenen Fehlerszenarien.
  • Effektivität automatisierter Failover-Mechanismen testen

Legen Sie fest, welche Komponenten, Dienste oder Regionen im Testumfang enthalten sind. Der Bereich kann bestimmte Anwendungsebenen wie das Frontend, das Backend und die Datenbank oder bestimmte Google Cloud Ressourcen wie Cloud SQL-Instanzen oder GKE-Cluster umfassen. Im Umfang müssen auch alle externen Abhängigkeiten angegeben werden, z. B. APIs von Drittanbietern oder Cloud-Verbindungen.

Umgebung für Tests vorbereiten

Wählen Sie eine geeignete Umgebung aus, vorzugsweise eine Staging- oder Sandbox-Umgebung, die Ihrer Produktionsumgebung entspricht. Wenn Sie den Test in der Produktion durchführen, müssen Sie Sicherheitsmaßnahmen wie automatisierte Überwachung und manuelle Rollback-Verfahren vorbereiten.

Erstellen Sie einen Sicherungsplan. Erstellen Sie Snapshots oder Sicherungen wichtiger Datenbanken und Dienste, um Datenverlust während des Tests zu verhindern. Sorgen Sie dafür, dass Ihr Team bereit ist, manuell einzugreifen, falls die automatisierten Failover-Mechanismen fehlschlagen.

Damit es nicht zu Unterbrechungen bei Tests kommt, müssen Ihre IAM-Rollen, Richtlinien und Failover-Konfigurationen richtig eingerichtet sein. Prüfen Sie, ob die erforderlichen Berechtigungen für die Testtools und ‑skripts vorhanden sind.

Stakeholder, einschließlich Betriebs-, DevOps- und Anwendungsverantwortliche, über den Testplan, den Umfang und die potenziellen Auswirkungen informieren. Informieren Sie die Stakeholder über den geschätzten Zeitplan und das erwartete Verhalten während des Tests.

Fehlerszenarien simulieren

Planen und führen Sie Ausfälle mit Tools wie Chaos Monkey aus. Sie können benutzerdefinierte Skripts verwenden, um Fehler kritischer Dienste zu simulieren, z. B. das Herunterfahren eines primären Knotens in einem GKE-Cluster mit mehreren Zonen oder eine deaktivierte Cloud SQL-Instanz. Sie können auch Skripts verwenden, um einen regionsweiten Netzwerkausfall zu simulieren. Dazu verwenden Sie Firewallregeln oder API-Einschränkungen, die auf dem Umfang Ihres Tests basieren. Eskalieren Sie die Fehlerszenarien schrittweise, um das Systemverhalten unter verschiedenen Bedingungen zu beobachten.

Führen Sie Lasttests zusammen mit Fehlerszenarien ein, um die reale Nutzung bei Ausfällen zu simulieren. Testen Sie die Auswirkungen von kaskadierenden Fehlern, z. B. wie sich Frontendsysteme verhalten, wenn Backend-Dienste nicht verfügbar sind.

Um Konfigurationsänderungen zu validieren und die Widerstandsfähigkeit des Systems gegen menschliche Fehler zu bewerten, sollten Sie Testszenarien mit Fehlkonfigurationen durchführen. Führen Sie beispielsweise Tests mit falschen DNS-Failover-Einstellungen oder falschen IAM-Berechtigungen aus.

Systemverhalten überwachen

Beobachten Sie, wie Load-Balancer, Systemdiagnosen und andere Mechanismen den Traffic umleiten. Verwenden Sie Google Cloud Tools wie Cloud Monitoring und Cloud Logging, um während des Tests Messwerte und Ereignisse zu erfassen.

Beobachten Sie während und nach der Fehlersimulation Änderungen bei Latenz, Fehlerraten und Durchsatz und überwachen Sie die Auswirkungen auf die Gesamtleistung. Stellen Sie fest, ob es zu einer Verschlechterung oder Inkonsistenzen bei der Nutzerfreundlichkeit kommt.

Achten Sie darauf, dass Logs generiert und Benachrichtigungen für wichtige Ereignisse wie Dienstausfälle oder Failover ausgelöst werden. Mit diesen Daten können Sie die Effektivität Ihrer Systeme für Benachrichtigungen und die Reaktion auf Vorfälle überprüfen.

Wiederherstellung anhand von RTO und RPO prüfen

Messen Sie, wie lange es dauert, bis das System nach einem Fehler wieder normal funktioniert, vergleichen Sie diese Daten mit dem definierten RTO und dokumentieren Sie alle Abweichungen.

Sorgen Sie dafür, dass Datenintegrität und ‑verfügbarkeit dem RPO entsprechen. Um die Datenbankkonsistenz zu testen, vergleichen Sie Snapshots oder Sicherungen der Datenbank vor und nach einem Fehler.

Bewerten Sie die Wiederherstellung des Dienstes und bestätigen Sie, dass alle Dienste in einen funktionsfähigen Zustand zurückversetzt wurden und die Nutzer nur minimal beeinträchtigt wurden.

Ergebnisse dokumentieren und analysieren

Dokumentieren Sie jeden Testschritt, jedes Ausfallszenario und das entsprechende Systemverhalten. Fügen Sie Zeitstempel, Protokolle und Messwerte für detaillierte Analysen hinzu.

Heben Sie Engpässe, Single Points of Failure oder unerwartetes Verhalten hervor, die während des Tests beobachtet wurden. Um die Priorisierung von Korrekturen zu erleichtern, sollten Sie Probleme nach Schweregrad und Auswirkungen kategorisieren.

Verbesserungen an der Systemarchitektur, den Failover-Mechanismen oder den Monitoring-Einrichtungen vorschlagen. Aktualisieren Sie anhand der Testergebnisse alle relevanten Failover-Richtlinien und Playbooks. Stakeholdern einen Postmortem-Bericht präsentieren Der Bericht sollte die Ergebnisse, gewonnenen Erkenntnisse und nächsten Schritte zusammenfassen. Weitere Informationen finden Sie unter Gründliche Postmortems durchführen.

Iterieren und verbessern

Um die anhaltende Zuverlässigkeit und Stabilität zu validieren, sollten Sie regelmäßige Tests (z. B. vierteljährlich) einplanen.

Führen Sie Tests in verschiedenen Szenarien durch, z. B. bei Infrastrukturänderungen, Softwareupdates und erhöhten Traffic-Lasten.

Automatisieren Sie Failover-Tests mit CI/CD-Pipelines, um Zuverlässigkeitstests in Ihren Entwicklungszyklus zu integrieren.

Nutzen Sie während der Post-Mortem-Analyse das Feedback von Stakeholdern und Endnutzern, um den Testprozess und die Systemstabilität zu verbessern.

Wiederherstellung nach Datenverlust testen

Dieses Prinzip im Bereich „Zuverlässigkeit“ des Google Cloud Well-Architected Framework enthält Empfehlungen, die Ihnen helfen, Tests für die Wiederherstellung nach Datenverlust zu entwickeln und auszuführen.

Dieses Prinzip ist für den Lernbereich Zuverlässigkeit relevant.

Übersicht über die Grundsätze

Damit Ihr System sich von Situationen erholen kann, in denen Daten verloren gehen oder beschädigt werden, müssen Sie Tests für diese Szenarien durchführen. Datenverlust kann durch einen Softwarefehler oder eine Naturkatastrophe verursacht werden. Nach solchen Ereignissen müssen Sie Daten aus Sicherungen wiederherstellen und alle Dienste mit den neu wiederhergestellten Daten wieder in Betrieb nehmen.

Wir empfehlen, den Erfolg oder Misserfolg dieser Art von Wiederherstellungstest anhand von drei Kriterien zu beurteilen: Datenintegrität, Recovery Time Objective (RTO) und Recovery Point Objective (RPO). Weitere Informationen zu den Messwerten RTO und RPO finden Sie unter Grundlagen der Planung der Notfallwiederherstellung.

Ziel von Tests zur Datenwiederherstellung ist es, regelmäßig zu überprüfen, ob Ihre Organisation weiterhin die Anforderungen an die Geschäftskontinuität erfüllen kann. Neben der Messung von RTO und RPO muss ein Test zur Datenwiederherstellung auch Tests des gesamten Anwendungsstacks und aller kritischen Infrastrukturdienste mit den wiederhergestellten Daten umfassen. Das ist erforderlich, um zu bestätigen, dass die gesamte bereitgestellte Anwendung in der Testumgebung richtig funktioniert.

Empfehlungen

Beachten Sie beim Entwerfen und Ausführen von Tests zur Wiederherstellung nach Datenverlust die Empfehlungen in den folgenden Unterabschnitten.

Sicherungskonsistenz prüfen und Wiederherstellungsprozesse testen

Sie müssen prüfen, ob Ihre Sicherungen konsistente und nutzbare Snapshots von Daten enthalten, die Sie wiederherstellen können, um Anwendungen sofort wieder in Betrieb zu nehmen. Um die Datenintegrität zu prüfen, richten Sie automatische Konsistenzprüfungen ein, die nach jeder Sicherung ausgeführt werden.

Wenn Sie Sicherungen testen möchten, stellen Sie sie in einer Nicht-Produktionsumgebung wieder her. Damit Ihre Sicherungen effizient wiederhergestellt werden können und die wiederhergestellten Daten den Anwendungsanforderungen entsprechen, sollten Sie regelmäßig Datenwiederherstellungsszenarien simulieren. Dokumentieren Sie die Schritte zur Datenwiederherstellung und schulen Sie Ihre Teams, damit sie die Schritte im Fehlerfall effektiv ausführen können.

Regelmäßige und häufige Sicherungen planen

Um Datenverluste während der Wiederherstellung zu minimieren und RPO-Ziele zu erreichen, sind regelmäßig geplante Sicherungen unerlässlich. Legen Sie eine Sicherungshäufigkeit fest, die Ihrem RPO entspricht. Wenn Ihr RPO beispielsweise 15 Minuten beträgt, planen Sie Sicherungen mindestens alle 15 Minuten. Sicherungsintervalle optimieren, um das Risiko von Datenverlust zu verringern.

Verwenden Sie Google Cloud Tools wie Cloud Storage, automatische Cloud SQL-Sicherungen oder Spanner-Sicherungen, um Sicherungen zu planen und zu verwalten. Verwenden Sie für kritische Anwendungen Lösungen für nahezu kontinuierliche Sicherungen wie die Wiederherstellung zu einem bestimmten Zeitpunkt (Point-in-Time Recovery, PITR) für Cloud SQL oder inkrementelle Sicherungen für große Datasets.

RPO definieren und überwachen

Legen Sie ein klares RPO basierend auf Ihren Geschäftsanforderungen fest und überwachen Sie die Einhaltung des RPO. Wenn die Sicherungsintervalle den definierten RPO überschreiten, können Sie mit Cloud Monitoring Benachrichtigungen einrichten.

Sicherungsstatus überwachen

Verwenden Sie den Google Cloud Backup- und DR-Dienst oder ähnliche Tools, um den Zustand Ihrer Back-ups zu verfolgen und zu bestätigen, dass sie an sicheren und zuverlässigen Orten gespeichert sind. Achten Sie darauf, dass die Sicherungen zur Erhöhung der Ausfallsicherheit in mehreren Regionen repliziert werden.

Szenarien über die Sicherung hinaus planen

Kombinieren Sie Sicherungen mit Strategien zur Notfallwiederherstellung wie Active-Active-Failover-Konfigurationen oder regionsübergreifender Replikation, um die Wiederherstellungszeit in Extremfällen zu verkürzen. Weitere Informationen finden Sie im Leitfaden zur Planung der Notfallwiederherstellung.

Gründliche Post-Mortem-Analysen durchführen

Dieses Prinzip im Bereich „Zuverlässigkeit“ des Google Cloud Well-Architected Framework enthält Empfehlungen, die Ihnen helfen, nach Ausfällen und Vorfällen effektive Postmortems durchzuführen.

Dieses Prinzip ist für den Lernbereich Zuverlässigkeit relevant.

Übersicht über die Grundsätze

Ein Postmortem ist ein schriftlicher Bericht über einen Vorfall, seine Auswirkungen, die Maßnahmen zur Eindämmung oder Behebung des Vorfalls, die Ursachen und die Folgemaßnahmen zur Verhinderung eines erneuten Auftretens des Vorfalls. Ziel einer Analyse ist es, aus Fehlern zu lernen und nicht, jemandem die Schuld zuzuweisen.

Das folgende Diagramm zeigt den Workflow einer Post-Mortem-Analyse:

Der Workflow eines Postmortems.

Der Workflow einer Post-Mortem-Analyse umfasst die folgenden Schritte:

  • Postmortem erstellen
  • Fakten erfassen
  • Grundursachen ermitteln und analysieren
  • Für die Zukunft planen
  • Plan ausführen

Führen Sie nach wichtigen und weniger wichtigen Ereignissen wie den folgenden Post-Mortem-Analysen durch:

  • Für Nutzer sichtbare Ausfallzeiten oder Leistungseinbußen, die einen bestimmten Schwellenwert überschreiten.
  • Datenverlust jeglicher Art.
  • Eingriffe von Bereitschaftsingenieuren, z. B. ein Release-Rollback oder das Umleiten von Traffic.
  • Lösungszeiten über einem definierten Schwellenwert.
  • Überwachung von Fehlern, die in der Regel eine manuelle Vorfallerkennung erfordern.

Empfehlungen

Legen Sie die Kriterien für die Analyse fest, bevor ein Vorfall eintritt, damit alle wissen, wann eine Analyse erforderlich ist.

Beachten Sie die Empfehlungen in den folgenden Unterabschnitten, um effektive Postmortems durchzuführen.

Nachbesprechungen ohne Schuldzuweisung durchführen

Bei effektiven Postmortems geht es um Prozesse, Tools und Technologien. Es wird nicht versucht, Einzelpersonen oder Teams die Schuld zu geben. Ziel einer Störungsanalyse ist es, Ihre Technologie und Zukunft zu verbessern, nicht, den Schuldigen zu finden. Jeder macht Fehler. Ziel sollte es sein, die Fehler zu analysieren und daraus zu lernen.

Die folgenden Beispiele zeigen den Unterschied zwischen Feedback, das Schuld zuweist, und Feedback ohne Schuldzuweisung:

  • Feedback, das Schuldzuweisungen enthält: „Wir müssen das gesamte komplizierte Backend-System neu schreiben! Es ist in den letzten drei Quartalen jede Woche kaputt gegangen und ich bin sicher, dass wir alle es leid sind, die Dinge stückweise zu reparieren. Wenn ich noch einmal benachrichtigt werde, schreibe ich es selbst…“
  • Schuldfreies Feedback: „Eine Maßnahme zur Überarbeitung des gesamten Backend-Systems könnte tatsächlich verhindern, dass diese Seiten weiterhin auftreten. Das Wartungshandbuch für diese Version ist sehr lang und es ist wirklich schwierig, sich darin einzuarbeiten. Ich bin sicher, dass unsere zukünftigen On-Call-Techniker uns dafür danken werden.“

Post-Mortem-Bericht für alle Zielgruppen lesbar machen

Bewerten Sie für jede Information, die Sie in den Bericht aufnehmen möchten, ob sie wichtig und notwendig ist, damit die Zielgruppe nachvollziehen kann, was passiert ist. Zusätzliche Daten und Erläuterungen können in einen Anhang des Berichts verschoben werden. Prüfer, die weitere Informationen benötigen, können diese anfordern.

Komplexe oder überentwickelte Lösungen vermeiden

Bevor Sie mit der Suche nach Lösungen für ein Problem beginnen, sollten Sie die Bedeutung des Problems und die Wahrscheinlichkeit eines erneuten Auftretens bewerten. Wenn Sie das System komplexer machen, um Probleme zu beheben, die wahrscheinlich nicht noch einmal auftreten, kann das zu einer erhöhten Instabilität führen.

Postmortem-Bericht so weit wie möglich verbreiten

Damit Probleme nicht ungelöst bleiben, sollten Sie die Ergebnisse der Post-Mortem-Analyse für ein breites Publikum veröffentlichen und Unterstützung vom Management einholen. Der Wert einer Post-Mortem-Analyse hängt davon ab, was nach der Analyse gelernt wird. Wenn mehr Personen aus Vorfällen lernen, sinkt die Wahrscheinlichkeit, dass ähnliche Fehler wieder auftreten.