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

Die Säule „Zuverlässigkeit“ im Google Cloud Well-Architected Framework enthält Prinzipien und Empfehlungen zum Entwerfen, Bereitstellen und Verwalten zuverlässiger Arbeitslasten in Google Cloud.

Dieses Dokument richtet sich an Cloud Architects, Entwickler, Plattformentwickler, Administratoren und Site Reliability Engineers.

Zuverlässigkeit ist die Fähigkeit eines Systems, die vorgesehenen Funktionen innerhalb der definierten Bedingungen konsistent auszuführen und einen unterbrechungsfreien Dienst aufrechtzuerhalten. Zu den Best Practices für die Zuverlässigkeit gehören Redundanz, fehlertolerantes Design, Monitoring und automatisierte Wiederherstellungsprozesse.

Als Teil der Zuverlässigkeit bezeichnet Robustheit die Fähigkeit des Systems, Ausfälle oder unerwarteten Störungen standzuhalten und diese bei gleichbleibender Leistung wiederherzustellen.Google Cloud Funktionen wie multiregionale Bereitstellungen, automatische Sicherungen und Lösungen zur Notfallwiederherstellung können Ihnen dabei helfen, die Ausfallsicherheit Ihres Systems zu verbessern.

Zuverlässigkeit ist aus vielen Gründen wichtig für Ihre Cloud-Strategie, darunter:

  • Minimale Ausfallzeiten: Ausfallzeiten können zu Umsatzeinbußen, Produktivitätsverlust und Rufschädigung führen. Stabile Architekturen können dazu beitragen, dass Systeme bei Ausfällen weiter funktionieren oder sich effizient nach Ausfällen wiederherstellen lassen.
  • Verbesserte Nutzererfahrung: Nutzer erwarten nahtlose Interaktionen mit der Technologie. Stabile Systeme können dazu beitragen, eine konsistente Leistung und Verfügbarkeit aufrechtzuerhalten. Sie bieten selbst bei hoher Nachfrage oder unerwarteten Problemen einen zuverlässigen Dienst.
  • Datenintegrität: Fehler können zu Datenverlust oder Datenbeschädigung führen. Stabile Systeme implementieren Mechanismen wie Sicherungen, Redundanz und Replikation, um Daten zu schützen und dafür zu sorgen, dass sie fehlerfrei und zugänglich bleiben.
  • Geschäftskontinuität: Ihr Unternehmen ist für kritische Abläufe auf Technologie angewiesen. Stabile Architekturen können die Kontinuität nach einem katastrophalen Ausfall gewährleisten, wodurch die Geschäftsfunktionen ohne nennenswerte Unterbrechungen weiterlaufen können und eine schnelle Wiederherstellung unterstützt wird.
  • Compliance: In vielen Branchen gibt es regulatorische Anforderungen in Bezug auf Systemverfügbarkeit und Datenschutz. Stabile Architekturen können Ihnen helfen, diese Standards zu erfüllen, da sie gewährleisten, dass die Systeme betriebsbereit und sicher bleiben.
  • Geringere langfristige Kosten: Stabile Architekturen erfordern Vorabinvestitionen. Durch Ausfallsicherheit können jedoch im Laufe der Zeit Kosten gesenkt werden, da teure Ausfallzeiten, reaktive Korrekturen und eine effizientere Ressourcennutzung vermieden werden.

Organisatorisches Denken

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

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

Jedes Team muss die Zuverlässigkeitsziele und Risiken seiner Anwendungen verstehen. Die Teams müssen diese Anforderungen erfüllen. Konflikte zwischen der Zuverlässigkeit und der regelmäßigen Entwicklung von Produktfeatures müssen priorisiert und entsprechend eskaliert werden.

Planen und verwalten Sie die Zuverlässigkeit ganzheitlich, über alle Funktionen und Teams hinweg. Erwägen Sie die Einrichtung eines Cloud Centre of Excellence (CCoE) mit einer Säule für Zuverlässigkeit. Weitere Informationen finden Sie unter Den Weg Ihrer Organisation in die Cloud mit einem Cloud Center of Excellence optimieren.

Schwerpunkte für Zuverlässigkeit

Die Aktivitäten, die Sie ausführen, um ein zuverlässiges System zu entwerfen, bereitzustellen und zu verwalten, können den folgenden Schwerpunktbereichen zugeordnet werden. Jedes der Zuverlässigkeitsprinzipien und Empfehlungen in dieser Säule ist für einen dieser Schwerpunktbereiche relevant.

  • Umfang festlegen: Um Ihr System besser zu verstehen, führen Sie eine detaillierte Analyse seiner Architektur durch. Sie müssen verstehen, wie die Komponenten funktionieren und interagieren, wie Daten und Aktionen durch das System fließen und was schiefgehen könnte. Identifizieren Sie potenzielle Fehler, Engpässe und Risiken, damit Sie Maßnahmen ergreifen können, um diese Probleme zu mindern.
  • Beobachtung: Implementieren Sie eine umfassende und kontinuierliche Beobachtung und Überwachung, um Systemausfälle zu vermeiden. Mithilfe dieser Beobachtung können Sie Trends verstehen und potenzielle Probleme proaktiv identifizieren.
  • Antwort: Um die Auswirkungen von Fehlern zu reduzieren, sollten Sie angemessen reagieren und eine effiziente Wiederherstellung durchführen. Automatisierte Antworten können auch dazu beitragen, die Auswirkungen von Ausfällen zu reduzieren. Auch mit Planung und Kontrolle können Fehler auftreten.
  • Lernen: Lernen Sie aus den einzelnen Erfahrungen und ergreifen Sie entsprechende Maßnahmen, um wiederkehrende Fehler zu vermeiden.

Grundprinzipien

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

Beitragende

Autoren:

Weitere Beitragende:

Zuverlässigkeit basierend auf Zielen im Hinblick auf die User Experience definieren

Mit diesem Prinzip der Zuverlässigkeit des Google Cloud Well-Architected Framework können Sie die Erfahrung Ihrer Nutzer bewerten und die Ergebnisse dann Zuverlässigkeitszielen und Messwerten zuordnen.

Dieses Prinzip ist für den Bereich Schwerpunkt der Zuverlässigkeit relevant.

Prinzip – Übersicht

Beobachtbarkeitstools liefern große Datenmengen, aber nicht alle Daten stehen in direktem Zusammenhang mit den Auswirkungen auf die Nutzer. Sie können beispielsweise eine hohe CPU-Auslastung, langsame Servervorgänge oder sogar abgestürzte Aufgaben beobachten. Wenn diese Probleme die Nutzerfreundlichkeit jedoch nicht beeinträchtigen, sind sie nicht zu einem Ausfall führen.

Um die Nutzererfahrung zu messen, müssen Sie zwischen internem Systemverhalten und nutzerseitigen Problemen unterscheiden. Konzentrieren Sie sich auf Messwerte wie die Erfolgsquote von Nutzeranfragen. Verlassen Sie sich nicht ausschließlich auf serverbezogene Messwerte wie die CPU-Nutzung, da dies zu irreführenden Schlussfolgerungen über die Zuverlässigkeit Ihres Dienstes führen kann. Echte Zuverlässigkeit bedeutet, dass Nutzer Ihre Anwendung oder Ihren Dienst konsistent und effektiv verwenden können.

Empfehlungen

Beachten Sie die Empfehlungen in den folgenden Abschnitten, um die Nutzererfahrung effektiv zu messen.

Nutzererfahrung analysieren

Priorisieren Sie Messwerte, die die tatsächliche Erfahrung Ihrer Nutzer widerspiegeln, um die Zuverlässigkeit Ihres Dienstes wirklich zu verstehen. Messen Sie beispielsweise die Erfolgsquote bei Abfragen, die Anwendungslatenz und die Fehlerraten der Nutzer.

Idealerweise sollten diese Daten direkt über das Gerät oder den Browser des Nutzers erfasst werden. Wenn diese direkte Datenerhebung nicht möglich ist, verschieben Sie den Messpunkt im System schrittweise weiter vom Nutzer weg. Sie können beispielsweise den Load-Balancer oder den Front-End-Dienst als Messpunkt verwenden. So können Sie Probleme erkennen und beheben, bevor sie sich erheblich auf Ihre Nutzer auswirken.

Nutzerpfade analysieren

Sie können Tracing-Tools wie Cloud Trace verwenden, um nachzuvollziehen, wie Nutzer mit Ihrem System interagieren. Wenn Sie die Schritte eines Nutzers durch Ihre Anwendung durchlaufen, können Sie Engpässe und Latenzprobleme erkennen, die die Nutzererfahrung beeinträchtigen können. Cloud Trace erfasst detaillierte Leistungsdaten für jeden Hop in Ihrer Dienstarchitektur. Mit diesen Daten kannst du Leistungsprobleme effizienter erkennen und beheben, was zu einer zuverlässigeren und zufriedeneren Nutzererfahrung führen kann.

Realistische Ziele für die Zuverlässigkeit 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 machbar sind.

Dieses Prinzip ist für den Bereich Schwerpunkt der Zuverlässigkeit relevant.

Prinzip – Übersicht

Entwickeln Sie Ihre Systeme so, dass sie gerade zuverlässig genug für die Zufriedenheit der Nutzenden sind. Es mag widersprüchlich erscheinen, aber ein Ziel von 100% Zuverlässigkeit ist oft nicht die effektivste Strategie. Eine höhere Zuverlässigkeit kann zu erheblich höheren Kosten führen, sowohl für finanzielle Investitionen als auch für potenzielle Einschränkungen bei der Innovation. Wenn die Nutzer bereits mit dem aktuellen Serviceniveau zufrieden sind, können Bemühungen, die Zufriedenheit weiter zu steigern, zu einem niedrigen Return on Investment führen. Stattdessen können Sie die Ressourcen besser woanders einsetzen.

Sie müssen ermitteln, wie zuverlässig Ihre Nutzer sind, und feststellen, ab welchem Punkt die Kosten schrittweiser Verbesserungen die Vorteile überwiegen. Wenn Sie ein solches Maß an ausreichender Zuverlässigkeit feststellen, können Sie Ressourcen strategisch zuweisen und sich auf Funktionen und Verbesserungen konzentrieren, die für Ihre Nutzer einen größeren Mehrwert bieten.

Empfehlungen

Beachten Sie die Empfehlungen in den folgenden Unterabschnitten, um realistische Zuverlässigkeitsziele festzulegen.

Einige Fehler akzeptieren und Komponenten priorisieren

Streben Sie eine Hochverfügbarkeit wie eine Verfügbarkeit von 99,99% an, aber legen Sie kein Ziel von 100 % Verfügbarkeit fest. Erkennen Sie an, dass einige Fehler unvermeidlich sind.

Die Lücke zwischen 100% Verfügbarkeit und einem Ziel von 99,99% ist die Fehlertoleranz. Diese Lücke wird oft als Fehlerbudget bezeichnet. Das Fehlerbudget kann Ihnen helfen, Risiken einzugehen und Innovationen voranzutreiben. Dies ist für jedes Unternehmen von entscheidender Bedeutung, 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

Führen Sie gründliche Kosten-Nutzen-Analysen durch, um den optimalen Zuverlässigkeitsgrad für Ihr System zu ermitteln.

Berücksichtigen Sie Faktoren wie Systemanforderungen, die Folgen von Ausfällen und die Risikotoleranz Ihres Unternehmens für die jeweilige Anwendung. Berücksichtigen Sie dabei die Messwerte zur Notfallwiederherstellung, z. B. das Recovery Time Objective (RTO) und das Recovery Point Objective (RPO). Entscheiden Sie, welche Zuverlässigkeit im Rahmen des Budgets und anderer Einschränkungen akzeptabel ist.

Suchen Sie nach Möglichkeiten, die Effizienz zu verbessern und die Kosten zu senken, ohne wesentliche Zuverlässigkeitsfeatures zu beeinträchtigen.

Hochverfügbare Systeme durch Ressourcenredundanz aufbauen

Dieses Prinzip in der Säule „Zuverlässigkeit“ des Google Cloud Well-Architected Framework gibt Empfehlungen zum Planen, Erstellen und Verwalten von Ressourcenredundanz, mit denen Sie Ausfälle vermeiden können.

Dieses Prinzip ist für den Bereich Schwerpunkt der Zuverlässigkeit relevant.

Prinzip – Übersicht

Nachdem Sie das benötigte Zuverlässigkeitsniveau bestimmt haben, müssen Sie Ihre Systeme so konzipieren, dass keine Single Points of Failure auftreten. Jede kritische Komponente im System muss über mehrere Maschinen, Zonen und Regionen repliziert werden. Eine kritische Datenbank kann sich beispielsweise nicht in nur einer Region befinden und ein Metadatenserver kann nicht nur in einer einzelnen Zone oder Region bereitgestellt werden. Wenn in diesen Beispielen die einzige Zone oder Region ausfällt, kommt es zu einem globalen Ausfall des Systems.

Empfehlungen

Beachten Sie beim Erstellen redundanter Systeme die Empfehlungen in den folgenden Unterabschnitten.

Fehlerdomains identifizieren und Dienste replizieren

Ordnen Sie die Fehlerdomains Ihres Systems von einzelnen VMs bis Regionen zu und sorgen Sie für Redundanz in den gesamten fehlerhaften Domains.

Verteilen und replizieren Sie Ihre Dienste und Anwendungen über mehrere Zonen und Regionen hinweg, um Hochverfügbarkeit zu gewährleisten. Konfigurieren Sie das System für das automatische Failover, damit die Dienste und Anwendungen bei Ausfällen von Zonen oder Regionen weiterhin verfügbar sind.

Beispiele für Architekturen mit mehreren Zonen und mehreren Regionen finden Sie unter Zuverlässige Infrastruktur für Ihre Arbeitslasten in Google Cloudentwerfen.

Probleme schnell erkennen und beheben

Verfolgen Sie kontinuierlich den Status Ihrer fehlerhaften Domains, um Probleme schnell erkennen und beheben zu können.

Mit dem Google Cloud Service Health-Dashboard können Sie den aktuellen Status der Dienste Google Cloud in allen Regionen überwachen. Sie können für Ihr Projekt relevante Vorfälle auch mithilfe von Personalized Service Health aufrufen. Mit Load-Balancern können Sie den Ressourcenzustand erkennen und Traffic automatisch an fehlerfreie Back-Ends weiterleiten. Weitere Informationen finden Sie unter Systemdiagnosen – Übersicht.

Failover-Szenarien testen

Simulieren Sie wie bei einer Brandübung regelmäßig Fehler, um die Effektivität Ihrer Replikations- und Failover-Strategien zu validieren.

Weitere Informationen finden Sie unter Zonenausfall für eine regionale MIG simulieren und Zonenfehler in regionalen GKE-Clustern simulieren.

Horizontale Skalierbarkeit nutzen

Dieses Prinzip in der Säule „Zuverlässigkeit“ des Google Cloud Well-Architected Framework gibt Empfehlungen zur Nutzung horizontaler Skalierbarkeit. Durch horizontale Skalierbarkeit können Sie dafür sorgen, dass Ihre Arbeitslasten inGoogle Cloud effizient skaliert werden können und die Leistung aufrechterhalten wird.

Dieses Prinzip ist für den Bereich Schwerpunkt der Zuverlässigkeit relevant.

Prinzip – Übersicht

Stellen Sie Ihr System auf eine horizontale Architektur um. Sie können weitere Ressourcen hinzufügen, um einem Anstieg des Traffics oder der Daten Rechnung zu tragen. Sie können Ressourcen auch entfernen, wenn sie nicht verwendet werden.

Beachten Sie die Einschränkungen der vertikalen Skalierung, um den Wert der horizontalen Skalierung zu verstehen.

Ein gängiges Szenario für die vertikale Skalierung ist die Verwendung einer MySQL-Datenbank als primäre Datenbank mit kritischen Daten. Wenn die Datenbanknutzung zunimmt, werden mehr RAM und CPU benötigt. Schließlich erreicht die Datenbank das Arbeitsspeicherlimit auf dem Hostcomputer und muss aktualisiert werden. Dieser Vorgang muss möglicherweise mehrmals wiederholt werden. Das Problem besteht darin, dass es harte Beschränkungen für das Wachstum einer Datenbank gibt. VM-Größen sind nicht unbegrenzt. Die Datenbank kann einen Punkt erreichen, an dem keine weiteren Ressourcen hinzugefügt werden können.

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

Abgesehen von diesen Skalierungslimits ist die vertikale Skalierung tendenziell teurer. Die Kosten können exponentiell steigen, wenn Maschinen mit größerer Rechenleistung und größerem Arbeitsspeicher hinzukommen.

Horizontale Skalierung kann dagegen weniger kosten. Das Potenzial der horizontalen Skalierung ist in einem für die Skalierung konzipierten System nahezu unbegrenzt.

Empfehlungen

Für den Übergang von einer einzelnen VM-Architektur zu einer horizontalen Architektur mit mehreren Geräten müssen Sie sorgfältig planen und die richtigen Tools verwenden. Beachten Sie die Empfehlungen in den folgenden Unterabschnitten, um eine horizontale Skalierung zu erreichen.

Verwaltete Dienste verwenden

Mit verwalteten Diensten muss die horizontale Skalierung nicht manuell verwaltet werden. Mit von Compute Engine verwalteten Instanzgruppen (MIGs) können Sie beispielsweise VMs hinzufügen oder entfernen, um Ihre Anwendung horizontal zu skalieren. Für Containeranwendungen ist Cloud Run eine serverlose Plattform, die Ihre zustandslosen Container automatisch anhand des eingehenden Traffics skalieren kann.

Modulares Design fördern

Dank modularer Komponenten und klarer Schnittstellen können Sie einzelne Komponenten nach Bedarf skalieren, anstatt die gesamte Anwendung zu skalieren. Weitere Informationen finden Sie unter Modulares Design fördern in der Spalte zur Leistungsoptimierung.

Zustandsloses Design implementieren

Anwendungen so entwickeln, dass sie zustandslos sind, d. h. keine lokal gespeicherten Daten enthalten Auf diese Weise können Sie Instanzen hinzufügen oder entfernen, ohne sich Gedanken über die Datenkonsistenz machen zu müssen.

Potenzielle Fehler mithilfe von Beobachtbarkeit erkennen

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

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

Prinzip – Übersicht

Damit Ihre Arbeitslasten inGoogle Cloudzuverlässig und zuverlässig sind, müssen Sie mithilfe von Messwerten, Logs und Traces effektive Beobachtbarkeit implementieren.

  • Messwerte sind numerische Messungen von Aktivitäten, die Sie für Ihre Anwendung in bestimmten Zeitintervallen verfolgen möchten. Beispielsweise können Sie technische Messwerte wie die Anforderungsrate und Fehlerrate verfolgen, die als Service Level Indicators (SLIs) verwendet werden können. Möglicherweise müssen Sie auch anwendungsspezifische Geschäftsmesswerte wie aufgegebene Bestellungen und erhaltene Zahlungen verfolgen.
  • Logs sind Datensätze mit Zeitstempeln diskreter Ereignisse, die in einer Anwendung oder einem System auftreten. Das Ereignis kann ein Fehler, ein Fehler oder eine Statusänderung sein. Logs können Messwerte enthalten und Sie können auch Logs 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. Mit Traces können Sie verfolgen, welche Komponenten in den Fahrten verwendet wurden, wo es Engpässe gibt und wie lange die Fahrten gedauert haben.

Mit Messwerten, Logs und Traces können Sie Ihr System kontinuierlich überwachen. Ein umfassendes Monitoring hilft Ihnen herauszufinden, wo und warum Fehler aufgetreten sind. Sie können auch potenzielle Fehler erkennen, bevor Fehler auftreten.

Empfehlungen

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

Umfassende Einblicke erhalten

Mit Cloud Monitoring und Cloud Logging können Sie wichtige Messwerte wie Antwortzeiten und Fehlerraten verfolgen. Mit diesen Tools können Sie auch dafür sorgen, dass die Messwerte konsistent die Anforderungen Ihrer Arbeitslast erfüllen.

Für datengestützte Entscheidungen sollten Sie Standarddienstmesswerte analysieren, um die Abhängigkeiten von Komponenten und deren Auswirkungen auf die Gesamtleistung der Arbeitslast zu verstehen.

Erstellen und veröffentlichen Sie mit dem Google Cloud SDK eigene Messwerte, um Ihre Monitoringstrategie anzupassen.

Proaktive Fehlerbehebung durchführen

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

Berücksichtigen Sie beim Konfigurieren des Loggings die damit verbundenen Kosten. Zur Kontrolle der Logging-Kosten können Sie in den Logsenken Ausschlussfilter konfigurieren, um das Speichern bestimmter Logs auszuschließen.

Ressourcennutzung optimieren

Überwachen Sie die CPU-Nutzung, Netzwerk-E/A-Messwerte und Laufwerk-E/A-Messwerte, 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 in der Übersicht zu Cloud Monitoring.

Benachrichtigungen priorisieren

Konzentrieren Sie sich bei Benachrichtigungen auf kritische Messwerte, legen Sie geeignete Schwellenwerte fest, um die Ermüdung von Benachrichtigungen zu minimieren, und sorgen Sie für zeitnahe Reaktionen auf wichtige Probleme. Mit diesem gezielten Ansatz können Sie die Zuverlässigkeit von Arbeitslasten proaktiv aufrechterhalten. Weitere Informationen finden Sie unter Benachrichtigungen.

Graceful Degradation bei der Entwicklung berücksichtigen

Dieses Prinzip in der Säule „Zuverlässigkeit“ des Google Cloud Well-Architected Framework gibt Ihnen Empfehlungen, mit denen Sie Ihre Google Cloud Arbeitslasten auf einen fehlerfreien Fehler konzipieren können.

Dieses Prinzip ist für den Antwortbereich Schwerpunkt auf Zuverlässigkeit relevant.

Prinzip – Übersicht

Graceful Degradation ist ein Designansatz, bei dem ein System mit hoher Last weiterhin funktioniert, möglicherweise mit geringerer Leistung oder Genauigkeit. Graceful Degradation sorgt für eine kontinuierliche Verfügbarkeit des Systems und verhindert einen vollständigen Ausfall, auch wenn die Arbeit des Systems nicht optimal ist. Wenn die Auslastung auf ein überschaubares Niveau zurückkehrt, nimmt das System wieder die volle Funktionalität wieder auf.

In Zeiten hoher Auslastung priorisiert die Google-Suche beispielsweise Ergebnisse von höherrangigen Webseiten, was zu Abstrichen bei der Genauigkeit führen kann. Sinkt die Last, werden die Suchergebnisse von der Google Suche neu berechnet.

Empfehlungen

Beachten Sie beim Entwerfen Ihrer Systeme für Graceful Degradation die Empfehlungen in den folgenden Unterabschnitten.

Drosselung implementieren

Achten Sie darauf, dass Ihre Replikate Überlastungen unabhängig handhaben und eingehende Anfragen in Szenarien mit hohem Traffic drosseln können. Mit diesem Ansatz können Sie Fehlerkaskaden vermeiden, die durch Verschiebungen von übermäßigem Traffic zwischen Zonen verursacht werden.

Verwenden Sie Tools wie Apigee, um die Rate von API-Anfragen zu Zeiten mit hohem Traffic zu steuern. Sie können Richtlinienregeln so konfigurieren, dass Sie festlegen, wie Anfragen reduziert werden sollen.

Nicht erforderliche Anfragen frühzeitig löschen

Konfigurieren Sie Ihre Systeme so, dass überschüssige Anfragen auf der Front-End-Ebene gelöscht werden, um Back-End-Komponenten zu schützen. Durch das Löschen einiger Anfragen werden globale Fehler verhindert und das System kann effizienter wiederhergestellt werden.Bei diesem Ansatz können bei einigen Nutzern Fehler auftreten. Sie können die Auswirkungen von Ausfällen jedoch minimieren. Im Gegensatz zu einem Ansatz wie dem Verbindungsbruch, bei dem der gesamte Traffic während einer Überlastung unterbrochen wird.

Teilfehler und Wiederholungsversuche bearbeiten

Erstellen Sie Ihre Anwendungen so, dass sie Teilfehler und Wiederholungsversuche nahtlos verarbeiten können. Mit diesem Design wird sichergestellt, dass in Szenarien mit hoher Last so viel Traffic wie möglich bereitgestellt wird.

Überlastungsszenarien testen

Simulieren Sie regelmäßig Überlastbedingungen in Ihrem System, um zu prüfen, ob die Drosselungs- und Anfrage-Drop-Mechanismen effektiv funktionieren. Mithilfe von Tests können Sie dafür sorgen, dass Ihr System auf reale Verkehrsspitzen vorbereitet ist.

Trafficspitzen überwachen

Verwenden Sie Analyse- und Monitoringtools, um Trafficspitzen vorherzusagen und darauf zu reagieren, bevor sie zu Überlasten eskalieren. Eine frühzeitige Erkennung und Reaktion kann dazu beitragen, die Dienstverfügbarkeit während Zeiten großer Nachfrage aufrechtzuerhalten.

Wiederherstellung nach Fehlern testen

Dieses Prinzip in der Säule „Zuverlässigkeit“ des Google Cloud Well-Architected Framework enthält Empfehlungen, die Ihnen beim Entwerfen und Ausführen von Tests für die Wiederherstellung im Falle von Ausfällen helfen.

Dieses Prinzip ist für den Schwerpunkt der Zuverlässigkeit beim Lernen relevant.

Prinzip – Übersicht

Damit Ihr System nach Fehlern wiederhergestellt werden kann, müssen Sie regelmäßig Tests ausführen, die regionale Failovers, Release-Rollbacks und die Datenwiederherstellung aus Sicherungen beinhalten.

Mit diesen Tests können Sie Reaktionen auf Ereignisse üben, die ein erhebliches Zuverlässigkeitsrisiko darstellen, z. B. den Ausfall einer ganzen Region. Mit diesen Tests können Sie auch prüfen, ob sich Ihr System während einer Störung wie beabsichtigt verhält.

Im unwahrscheinlichen Fall, dass eine ganze Region ausfällt, muss der gesamte Traffic per Failover auf eine andere Region übertragen werden. Wenn Daten während des normalen Betriebs Ihrer Arbeitslast geändert werden, müssen diese von der primären Region mit der Failover-Region synchronisiert werden. Sie müssen sicherstellen, dass die replizierten Daten immer sehr aktuell sind, damit keine Datenverluste oder Sitzungsunterbrechungen auftreten. Das Load-Balancing-System muss außerdem in der Lage sein, den Traffic jederzeit ohne Dienstunterbrechung in die Failover-Region zu verlagern. Um die Ausfallzeit nach einem regionalen Ausfall zu minimieren, müssen Betriebstechniker auch in der Lage sein, den Nutzertraffic manuell und effizient aus einer Region in so weniger Zeit wie möglich zu verlagern. Dieser Vorgang wird auch als Draining einer Region bezeichnet. Dies bedeutet, dass Sie den eingehenden Traffic in die Region beenden und ihn an eine andere Stelle verschieben.

Empfehlungen

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

Testziele und -umfang definieren

Definieren Sie klar, was Sie mit den Tests 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 Ausfallsicherheit und Fehlertoleranz des Systems bei verschiedenen Fehlerszenarien.
  • Testen Sie die Wirksamkeit automatisierter Failover-Mechanismen.

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

Umgebung für Tests vorbereiten

Wählen Sie eine geeignete Umgebung aus, vorzugsweise eine Staging- oder Sandbox-Umgebung, die Ihre Produktionskonfiguration repliziert. Wenn Sie den Test in der Produktion durchführen, sollten Sie darauf achten, dass Sie Sicherheitsmaßnahmen wie automatisierte Überwachung und manuelle Rollbacks haben.

Erstellen Sie einen Sicherungsplan. Erstellen Sie Snapshots oder Sicherungen von kritischen Datenbanken und Diensten, um Datenverluste während des Tests zu verhindern. Sorgen Sie dafür, dass Ihr Team auf manuelle Eingriffe vorbereitet ist, wenn die automatisierten Failover-Mechanismen fehlschlagen.

Achten Sie darauf, dass Ihre IAM-Rollen, Richtlinien und Failover-Konfigurationen korrekt eingerichtet sind, um Testunterbrechungen zu vermeiden. Prüfen Sie, ob die erforderlichen Berechtigungen für die Testtools und -skripte vorhanden sind.

Informieren Sie die Beteiligten, einschließlich Betrieb, DevOps und Anwendungsinhaber, über den Testzeitplan, den Umfang und die möglichen Auswirkungen. Den Stakeholdern einen geschätzten Zeitplan und das erwartete Verhalten während des Tests bereitstellen.

Fehlerszenarien simulieren

Mithilfe von Tools wie Chaos Monkey können Sie Fehler planen und ausführen. Sie können benutzerdefinierte Skripts verwenden, um Fehler bei kritischen Diensten zu simulieren, z. B. das Herunterfahren eines primären Knotens in einem GKE-Cluster mit mehreren Zonen oder einer deaktivierten Cloud SQL-Instanz. Sie können auch Skripts verwenden, um einen regionalen Netzwerkausfall zu simulieren. Dazu werden Firewallregeln oder API-Einschränkungen verwendet, die auf Ihrem Testumfang basieren. Eskalieren Sie die Fehlerszenarien nach und nach, um das Systemverhalten unter verschiedenen Bedingungen zu beobachten.

Führen Sie Belastungstests und Fehlerszenarien durch, um die reale Nutzung bei Ausfällen zu replizieren. Testen Sie die Auswirkungen kaskadierender Fehler, z. B. wie sich Frontend-Systeme verhalten, wenn Backend-Dienste nicht verfügbar sind.

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

Systemverhalten überwachen

Überwachen 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 Änderungen der Latenz, Fehlerraten und des Durchsatzes während und nach der Fehlersimulation und überwachen Sie die Auswirkungen auf die Gesamtleistung. Ermittle alle Beeinträchtigungen oder Inkonsistenzen in der Nutzererfahrung.

Sorgen Sie dafür, dass Logs generiert und Benachrichtigungen für Schlüsselereignisse wie Dienstausfälle oder Failovers ausgelöst werden. Verwenden Sie diese Daten, um die Effektivität Ihrer Systeme für Benachrichtigungen und Vorfallreaktion zu überprüfen.

Wiederherstellung anhand von RTO und RPO prüfen

Messen Sie, wie lange es dauert, bis das System nach einem Ausfall den normalen Betrieb wiederaufnimmt, vergleichen Sie diese Daten mit dem definierten RTO und dokumentieren Sie etwaige Lücken.

Achten Sie darauf, dass Datenintegrität und -verfügbarkeit mit dem RPO übereinstimmen. Vergleichen Sie zum Testen der Datenbankkonsistenz Snapshots oder Sicherungen der Datenbank vor und nach einem Fehler.

Prüfen Sie die Wiederherstellung der Dienste und stellen Sie sicher, dass alle Dienste in einem funktionsfähigen Zustand mit minimaler Unterbrechung der Nutzer wiederhergestellt wurden.

Ergebnisse dokumentieren und analysieren

Dokumentiere jeden Testschritt, das Fehlerszenario und das entsprechende Systemverhalten. Zeitstempel, Logs und Messwerte für detaillierte Analysen einbinden

Heben Sie Engpässe, Single Points of Failure oder unerwartetes Verhalten hervor, das während des Tests beobachtet wurde. Kategorisieren Sie Probleme nach Schweregrad und Auswirkung, um Korrekturen zu priorisieren.

Schlagen Sie Verbesserungen der Systemarchitektur, des Failover-Verfahrens oder der Überwachungseinrichtungen vor. Aktualisieren Sie auf der Grundlage der Testergebnisse alle relevanten Failover-Richtlinien und Playbooks. Sie präsentieren den Stakeholdern einen Postmortem-Bericht. 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

Planen Sie regelmäßige Tests (z. B. vierteljährlich), um die kontinuierliche Zuverlässigkeit und Robustheit zu validieren.

Führen Sie Tests in verschiedenen Szenarien durch, einschließlich Infrastrukturänderungen, Softwareupdates und erhöhter Traffic-Lasten.

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

Nutzen Sie während der Postmortem-Analyse das Feedback von Stakeholdern und Endnutzern, um den Testprozess und die Ausfallsicherheit des Systems zu verbessern.

Wiederherstellung nach Datenverlust testen

Dieses Prinzip in der Säule Zuverlässigkeit des Google Cloud Well-Architected Framework enthält Empfehlungen, die Ihnen beim Entwerfen und Ausführen von Tests zur Wiederherstellung nach Datenverlust helfen.

Dieses Prinzip ist für den Schwerpunkt der Zuverlässigkeit beim Lernen relevant.

Prinzip – Übersicht

Damit Ihr System sich nach einem Datenverlust oder einer Beschädigung wiederherstellen kann, müssen Sie für diese Szenarien Tests ausführen. Datenverluste können durch einen Softwarefehler oder eine Naturkatastrophe verursacht werden. Nach solchen Ereignissen müssen Sie Daten aus Sicherungen wiederherstellen und alle Dienste mithilfe der frisch wiederhergestellten Daten neu sichern.

Wir empfehlen, drei Kriterien zu verwenden, um den Erfolg oder Misserfolg dieser Art von Wiederherstellungstest zu bewerten: Datenintegrität, Wiederherstellungszeit (Recovery Time Objective, RTO) und Recovery Point Objective (RPO). Ausführliche Informationen zu den RTO- und RPO-Messwerten finden Sie unter Grundlagen der DR-Planung.

Ziel von Tests zur Datenwiederherstellung besteht darin, regelmäßig zu prüfen, ob Ihr Unternehmen die Anforderungen an die Geschäftskontinuität weiterhin erfüllen kann. Neben der Messung von RTO und RPO muss ein Datenwiederherstellungstest das Testen des gesamten Anwendungspakets und aller kritischen Infrastrukturdienste mit den wiederhergestellten Daten umfassen. Dies ist erforderlich, um zu prüfen, ob die gesamte bereitgestellte Anwendung in der Testumgebung ordnungsgemäß funktioniert.

Empfehlungen

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

Konsistenz von Sicherungen überprüfen und Wiederherstellungsprozesse testen

Sie müssen überprüfen, ob Ihre Sicherungen konsistente und nutzbare Snapshots von Daten enthalten, die Sie wiederherstellen können, um Anwendungen sofort wieder bereitzustellen. Richten Sie zur Validierung der Datenintegrität automatisierte 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. Simulieren Sie regelmäßig Szenarien der Datenwiederherstellung, damit Ihre Sicherungen effizient wiederhergestellt werden können und die wiederhergestellten Daten den Anwendungsanforderungen entsprechen. Dokumentieren Sie die Schritte für die Datenwiederherstellung und schulen Sie Ihre Teams, um die Schritte bei einem Ausfall effektiv auszuführen.

Regelmäßige und häufige Sicherungen planen

Um den Datenverlust während der Wiederherstellung zu minimieren und die RPO-Ziele zu erreichen, sind regelmäßige Sicherungen wichtig. Legen Sie eine Sicherungshäufigkeit fest, die Ihrem RPO entspricht. Wenn Ihr RPO beispielsweise 15 Minuten beträgt, planen Sie die Sicherungen so, dass sie mindestens alle 15 Minuten ausgeführt werden. Optimieren Sie die Sicherungsintervalle, um das Risiko eines Datenverlusts 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 Nahezu kontinuierliche Sicherungslösungen wie die Wiederherstellung zu einem bestimmten Zeitpunkt für Cloud SQL oder inkrementelle Sicherungen für große Datasets.

RPO definieren und überwachen

Legen Sie basierend auf Ihren Geschäftsanforderungen ein klares RPO fest und überwachen Sie die Einhaltung des RPO. Wenn die Sicherungsintervalle das definierte RPO überschreiten, verwenden Sie Cloud Monitoring, um Benachrichtigungen einzurichten.

Sicherungsstatus überwachen

Verwenden Sie den Google Cloud Sicherungs- und Notfallwiederherstellungsdienst oder ähnliche Tools, um den Zustand Ihrer Sicherungen zu verfolgen und zu bestätigen, dass sie an sicheren und zuverlässigen Orten gespeichert sind. Für zusätzliche Ausfallsicherheit sollten die Sicherungen über mehrere Regionen hinweg repliziert werden.

Szenarien über die Sicherung hinaus planen

Kombinieren Sie Sicherungen mit Notfallwiederherstellungsstrategien wie Aktiv-Aktiv-Failover-Einrichtungen oder regionsübergreifende Replikation, um die Wiederherstellungszeit in extremen Fällen zu verkürzen. Weitere Informationen finden Sie im Leitfaden zur Planung der Notfallwiederherstellung.

Umfassende Postmortems durchführen

Dieses Prinzip in der Säule Zuverlässigkeit des Google Cloud Well-Architected Framework gibt Empfehlungen zur Durchführung effektiver Postmortems nach Ausfällen und Vorfällen.

Dieses Prinzip ist für den Schwerpunkt der Zuverlässigkeit beim Lernen relevant.

Prinzip – Übersicht

Eine Postmortem-Analyse ist eine schriftliche Aufzeichnung eines Vorfalls, seiner Auswirkungen, der Maßnahmen, die zur Minderung oder Behebung des Vorfalls ergriffen wurden, der Ursachen und der Folgemaßnahmen, die ein wiederkehrendes Ereignis des Vorfalls verhindern. Das Ziel einer Postmortem-Analyse ist es, aus Fehlern zu lernen und keine Schuld zuzuweisen.

Das folgende Diagramm zeigt den Workflow einer Postmortem-Analyse:

Der Arbeitsablauf einer Postmortem-Analyse.

Der Arbeitsablauf einer Postmortem-Analyse umfasst die folgenden Schritte:

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

Führen Sie Postmortem-Analysen nach größeren und weniger wichtigen Ereignissen wie den folgenden durch:

  • Für den Nutzer sichtbare Ausfallzeiten oder Verschlechterungen über einen bestimmten Grenzwert hinaus.
  • Datenverluste jeglicher Art.
  • Eingriffe von Bereitschaftsentwicklern, z. B. Release-Rollback oder Umleitung des Traffics.
  • Zeit bis zur Lösung über einem definierten Grenzwert.
  • Monitoringfehler, die normalerweise eine manuelle Vorfallerkennung erfordern.

Empfehlungen

Definieren Sie Postmortem-Kriterien, bevor es zu einem Vorfall kommt, damit alle wissen, wann eine Postmortem erforderlich ist.

Berücksichtigen Sie zur Durchführung effektiver Postmortems die Empfehlungen in den folgenden Unterabschnitten.

Postmortem-Analysen ohne Schuldzuweisungen durchführen

Effektive Postmortems konzentrieren sich auf Prozesse, Tools und Technologien und geben Einzelpersonen oder Teams keine Schuld. Der Zweck einer Postmortem-Analyse besteht darin, Ihre Technologie und Zukunft zu verbessern. Es geht nicht darum, herauszufinden, wer schuldig ist. Jeder macht Fehler. Das Ziel sollte darin bestehen, die Fehler zu analysieren und aus ihnen zu lernen.

Die folgenden Beispiele zeigen den Unterschied zwischen Feedback, bei dem Schuldzuweisungen zugeschrieben werden, und Feedback ohne Schuldzuweisungen:

  • Feedback, das Schuldzuweisungen zuweist: "Wir müssen das gesamte komplizierte Back-End-System neu schreiben. In den letzten drei Quartalen kam es jede Woche durcheinander und ich bin sicher, dass wir alle es satt haben, Dinge stückweise zu reparieren. Ernsthaft, wenn ich noch einmal Pager bekomme, schreibe ich ihn selbst um..."
  • Feedback ohne Schuldzuweisung: "Eine Maßnahme zum Umschreiben des gesamten Back-End-Systems könnte verhindern, dass diese Seiten weiterhin ausgeführt werden. Das Wartungshandbuch für diese Version ist ziemlich lang und sehr schwierig, sich umfassend damit vertraut zu machen. Ich bin mir sicher, dass unsere zukünftigen Bereitschaftsentwickler es uns danken werden.“

Die Postmortem-Analyse ist für alle Zielgruppen lesbar.

Bewerten Sie für jede Information, die Sie in den Bericht aufnehmen möchten, ob diese wichtig und notwendig sind, damit die Zielgruppe das Geschehen besser nachvollziehen kann. Sie können ergänzende Daten und Erläuterungen in einen Anhang des Berichts verschieben. Prüfer, die weitere Informationen benötigen, können diese anfordern.

Komplexe oder übermäßig entwickelte Lösungen vermeiden

Bevor Sie mit der Suche nach Lösungen für ein Problem beginnen, bewerten Sie die Bedeutung des Problems und die Wahrscheinlichkeit eines Wiederholungs. Wenn das System komplexer wird, um Probleme zu lösen, die wahrscheinlich nicht noch einmal auftreten, kann dies zu erhöhter Instabilität führen.

Postmortem so breit wie möglich teilen

Damit Probleme nicht gelöst werden, sollten Sie das Ergebnis der Postmortem-Analyse einem breiten Publikum zugänglich machen und Unterstützung vom Management erhalten. Der Wert einer Postmortem-Analyse ist proportional zu den Erkenntnissen, die danach erfolgen. Wenn mehr Personen aus Vorfällen lernen, sinkt die Wahrscheinlichkeit, dass ähnliche Fehler wieder auftreten.