Well-Architected Framework für Google Cloud: Zuverlässigkeit

Last reviewed 2025-02-14 UTC

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

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

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

Die Ausfallsicherheit ist ein Teil der Zuverlässigkeit und beschreibt die Fähigkeit des Systems, Ausfälle oder unerwartete Unterbrechungen zu überstehen und sich davon zu erholen, während die Leistung aufrechterhalten wird. MitGoogle Cloud Funktionen wie mehrregionalen Bereitstellungen, automatisierten Sicherungen und Notfallwiederherstellungslösungen können Sie die Ausfallsicherheit Ihres Systems verbessern.

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

  • Minimale Ausfallzeiten: Ausfallzeiten können zu Umsatzeinbußen, geringerer Produktivität und Reputationsschäden führen. Mit resilienten Architekturen lässt sich dafür sorgen, dass Systeme bei Ausfällen weiter funktionieren oder sich effizient von Ausfällen erholen.
  • Verbesserte Nutzererfahrung: Nutzer erwarten nahtlose Interaktionen mit der Technologie. Resiliente Systeme können dazu beitragen, eine gleichbleibende Leistung und Verfügbarkeit zu gewährleisten und einen zuverlässigen Dienst auch bei hoher Nachfrage oder unerwarteten Problemen zu bieten.
  • Datenintegrität: Fehler können zu Datenverlusten oder Datenbeschädigungen 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.
  • Geschäftskontinuität: Ihr Unternehmen ist für wichtige Abläufe auf Technologie angewiesen. Resiliente Architekturen können dazu beitragen, die Kontinuität nach einem katastrophalen Ausfall zu gewährleisten. So können Geschäftsfunktionen ohne größere Unterbrechungen fortgesetzt und eine schnelle Wiederherstellung unterstützt werden.
  • Compliance: In vielen Branchen gelten rechtliche Anforderungen an die Systemverfügbarkeit und den Datenschutz. Mit resilienten Architekturen können Sie diese Standards erfüllen, da die Systeme betriebsbereit und sicher bleiben.
  • Niedrigere langfristige Kosten: Resiliente Architekturen erfordern eine Vorabinvestition. Resilienz kann jedoch dazu beitragen, die Kosten im Laufe der Zeit zu senken, indem teure Ausfallzeiten vermieden, reaktive Fehlerbehebungen verhindert und eine effizientere Ressourcennutzung ermöglicht werden.

Organisatorische Denkweise

Damit Ihre Systeme zuverlässig sind, benötigen Sie einen Plan und eine Strategie. Diese Strategie muss neben anderen Initiativen auch Schulungen und die Befugnis umfassen, Zuverlässigkeit 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). Selbst 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 regelmäßiger Produktfeature-Entwicklung müssen priorisiert und entsprechend eskaliert werden.

Planen und verwalten Sie die Zuverlässigkeit ganzheitlich, über alle Funktionen und Teams hinweg. Sie sollten ein Cloud Center of Excellence (CCoE) einrichten, das eine Säule für Zuverlässigkeit enthält. Weitere Informationen finden Sie unter Cloud-Transformation Ihrer Organisation mit einem Cloud Center of Excellence optimieren.

Schwerpunkte für Zuverlässigkeit

Die Aktivitäten, die Sie zum Entwerfen, Bereitstellen und Verwalten eines zuverlässigen Systems ausführen, können in die folgenden Schwerpunktbereiche kategorisiert werden. Jedes der Zuverlässigkeitsprinzipien und Empfehlungen in diesem Bereich ist für einen dieser Schwerpunktbereiche relevant.

  • Umfang definieren: Führen Sie eine detaillierte Analyse der Architektur Ihres Systems durch, um es besser zu verstehen. Sie müssen die Komponenten, ihre Funktionsweise und Interaktion, den Daten- und Aktionsfluss durch das System und die möglichen Fehler verstehen. Sie können potenzielle Fehler, Engpässe und Risiken identifizieren, um Maßnahmen zur Behebung dieser Probleme zu ergreifen.
  • Beobachtung: Um Systemausfälle zu vermeiden, sollten Sie eine umfassende und kontinuierliche Beobachtung und Überwachung implementieren. So können Sie Trends besser nachvollziehen und potenzielle Probleme proaktiv erkennen.
  • Reaktion: Um die Auswirkungen von Ausfällen zu reduzieren, reagieren Sie angemessen und erholen Sie sich effizient. Automatisierte Antworten können auch dazu beitragen, die Auswirkungen von Ausfällen zu verringern. Selbst bei 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-Frameworks werden den folgenden Grundprinzipien zugeordnet:

Beitragende

Autoren:

Weitere Beitragende:

Zuverlässigkeit anhand der Ziele der Nutzererfahrung definieren

Dieses Prinzip in der Säule „Zuverlässigkeit“ des Google Cloud Well-Architected Framework hilft Ihnen, die Nutzerfreundlichkeit zu bewerten und die Ergebnisse dann auf Zuverlässigkeitsziele und ‑messwerte abzubilden.

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

Grundsatzübersicht

Observability-Tools liefern große Datenmengen, aber nicht alle Daten beziehen sich direkt auf die Auswirkungen auf die Nutzer. Möglicherweise stellen Sie beispielsweise eine hohe CPU-Auslastung, langsame Servervorgänge oder sogar abgestürzte Aufgaben fest. Wenn sich diese Probleme jedoch nicht auf die Nutzererfahrung auswirken, stellen sie keinen Ausfall dar.

Um die Nutzerfreundlichkeit zu messen, müssen Sie zwischen internem Systemverhalten und Problemen unterscheiden, die für Nutzer sichtbar sind. Konzentrieren Sie sich auf Messwerte wie das Erfolgsverhältnis von Nutzeranfragen. Sie sollten sich nicht nur auf serverzentrierte Messwerte wie die CPU-Auslastung verlassen, da dies zu irreführenden Schlussfolgerungen über die Zuverlässigkeit Ihres Dienstes führen kann. Zuverlässigkeit bedeutet, dass Nutzer Ihre App oder Ihren Dienst kontinuierlich und effektiv nutzen können.

Empfehlungen

Die folgenden Empfehlungen helfen Ihnen dabei, die Nutzerfreundlichkeit effektiv zu messen.

Nutzerfreundlichkeit messen

Wenn Sie die Zuverlässigkeit Ihres Dienstes wirklich verstehen möchten, sollten Sie Messwerte priorisieren, die die tatsächliche Nutzung durch Ihre Nutzer widerspiegeln. Messen Sie beispielsweise das Erfolgsverhältnis von Nutzeranfragen, die Anwendungslatenz und die Fehlerraten.

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

Nutzerpfade analysieren

Mithilfe von Analysetools wie Cloud Trace können Sie nachvollziehen, wie Nutzer mit Ihrem System interagieren. Wenn Sie die User Journey durch Ihre Anwendung verfolgen, können Sie Engpässe und Latenzprobleme finden, die die Nutzererfahrung beeinträchtigen könnten. 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 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 umsetzbar sind.

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

Grundsatzübersicht

Ihre Systeme sollten gerade so zuverlässig sein, dass Nutzer zufrieden sind. 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 mögliche Einschränkungen bei Innovationen. Wenn Nutzer bereits mit dem aktuellen Service zufrieden sind, können Bemühungen, die Zufriedenheit weiter zu steigern, einen geringen Return on Investment erzielen. Stattdessen können Sie Ihre Ressourcen besser anderweitig einsetzen.

Sie müssen herausfinden, welche Zuverlässigkeit Ihre Nutzer zufriedenstellt, und den Punkt bestimmen, an dem die Kosten für inkrementelle Verbesserungen die Vorteile überwiegen. Wenn Sie diese ausreichende Zuverlässigkeit bestimmen, können Sie Ressourcen strategisch einsetzen und sich auf Funktionen und Verbesserungen konzentrieren, die Ihren Nutzern einen größeren Mehrwert bieten.

Empfehlungen

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

Akzeptieren Sie einige Fehler und priorisieren Sie die Komponenten.

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

Die Differenz zwischen 100% Ausfallsicherheit und einem Ziel von 99,99% ist die Toleranz für Fehler. Diese Lücke wird oft als Fehlerbudget bezeichnet. Das Fehlerbudget kann Ihnen helfen, Risiken einzugehen und Innovationen zu entwickeln, was für jedes Unternehmen unerlässlich ist, um wettbewerbsfähig zu bleiben.

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

Zuverlässigkeit und Kosten in Einklang bringen

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

Berücksichtigen Sie Faktoren wie Systemanforderungen, die Folgen von Ausfällen und die Risikotoleranz 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). 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 wichtige Zuverlässigkeitsfunktionen zu beeinträchtigen.

Hochverfügbare Systeme durch Ressourcenredundanz erstellen

Dieses Prinzip in der Säule „Zuverlässigkeit“ des Google Cloud Well-Architected Framework enthält Empfehlungen zur Planung, Erstellung und Verwaltung von Ressourcenredundanz, mit denen Sie Ausfälle vermeiden können.

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

Grundsatzübersicht

Nachdem Sie die erforderliche Zuverlässigkeit festgelegt haben, müssen Sie Ihre Systeme so konzipieren, dass Single Points of Failure vermieden werden. Alle kritischen Komponenten im System müssen auf mehreren Maschinen, Zonen und Regionen repliziert werden. Eine kritische Datenbank kann sich beispielsweise nicht nur in einer Region befinden und ein Metadatenserver kann nicht nur in einer einzigen Zone oder Region bereitgestellt werden. In diesen Beispielen tritt bei einem Ausfall der einzigen Zone oder Region ein globaler Ausfall des Systems auf.

Empfehlungen

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

Fehlerbereiche identifizieren und Dienste replizieren

Planen Sie die Fehlerbereiche Ihres Systems, von einzelnen VMs bis hin zu Regionen, und sorgen Sie für Redundanz in den Fehlerbereichen.

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

Beispiele für mehrzonale und regionsübergreifende 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 fehlerhaften Domains im Blick, um Probleme schnell zu erkennen und zu beheben.

Sie können den aktuellen Status der Google Cloud Dienste in allen Regionen mithilfe des Google Cloud Dashboards für den Dienststatus ü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 Ressourcenstatus erkennen und Traffic automatisch an fehlerfreie Backends weiterleiten. Weitere Informationen finden Sie unter Systemdiagnosen – Übersicht.

Failover-Szenarien testen

Simulieren Sie regelmäßig Ausfälle, um die Wirksamkeit 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 GKE-Regionalclustern simulieren.

Vorteile der horizontalen Skalierbarkeit nutzen

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

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

Grundsatzübersicht

Erstellen Sie eine horizontale Architektur. Wenn Sie mehr Traffic oder Daten verarbeiten möchten, können Sie weitere Ressourcen hinzufügen. Sie können Ressourcen auch 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 gängiges 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 harte Limits für die Größe einer Datenbank gibt. Die Größe von VMs ist nicht unbegrenzt. Es kann vorkommen, dass die Datenbank einen Punkt erreicht, an dem keine weiteren Ressourcen hinzugefügt werden können.

Selbst wenn die 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.

Neben diesen Skalierungslimits ist die vertikale Skalierung in der Regel auch teurer. Die Kosten können exponentiell ansteigen, wenn Maschinen mit mehr Rechenleistung und Arbeitsspeicher erworben werden.

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

Empfehlungen

Wenn Sie von einer einzelnen VM-Architektur zu einer horizontalen Architektur mit mehreren Maschinen wechseln möchten, 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

Bei verwalteten Diensten müssen Sie die horizontale Skalierung nicht manuell verwalten. Mit verwalteten Instanzgruppen (Managed Instance Groups, MIGs) der 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 basierend auf dem eingehenden Traffic automatisch skalieren kann.

Modulares Design fördern

Mit modularen Komponenten und klaren Benutzeroberflächen 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 Säule „Leistungsoptimierung“.

Zustandsloses Design implementieren

Entwerfen Sie Anwendungen als zustandslos, d. h. ohne lokal gespeicherte Daten. So können Sie Instanzen hinzufügen oder entfernen, ohne sich um die Datenkonsistenz kümmern zu müssen.

Mithilfe von Observabilität potenzielle Fehler erkennen

Dieses Prinzip in der Säule „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 Reliabilität relevant.

Grundsatzübersicht

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

  • Messwerte sind numerische Messungen von Aktivitäten, die Sie in bestimmten Zeitintervallen für Ihre Anwendung erfassen möchten. Sie können beispielsweise technische Messwerte wie die Anfragerate und die 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.
  • Protokolle sind zeitgestempelte Datensätze von einzelnen Ereignissen, die in einer Anwendung oder einem System auftreten. Das Ereignis kann ein Fehler, ein Fehlschlag oder eine Statusänderung sein. Protokolle können Messwerte enthalten und Sie können sie auch für SLIs verwenden.
  • Ein Trace stellt den Navigationspfad eines einzelnen Nutzers oder einer einzelnen Transaktion durch eine Reihe separater Anwendungen oder die Komponenten einer Anwendung dar. Das können beispielsweise Mikrodienste sein. Anhand von Traces können Sie nachvollziehen, welche Komponenten bei den Aufrufen verwendet wurden, wo Engpässe auftreten und wie lange die Aufrufe gedauert haben.

Mithilfe von Messwerten, Protokollen und Traces können Sie Ihr System kontinuierlich überwachen. Mithilfe einer umfassenden Überwachung können Sie herausfinden, wo und warum Fehler aufgetreten sind. Außerdem können Sie 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 außerdem dafür sorgen, dass die Messwerte die Anforderungen Ihrer Arbeitslast durchgehend erfüllen.

Analysieren Sie die Standarddienstmesswerte, um Komponentenabhängigkeiten und deren Auswirkungen auf die Gesamtleistung der Arbeitslast zu verstehen und so fundierte Entscheidungen zu treffen.

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 kontrollieren, können Sie Ausschlussfilter für die Logsenken konfigurieren, um das Speichern bestimmter Logs auszuschließen.

Ressourcennutzung optimieren

Überwachen Sie den CPU-Verbrauch, die Netzwerk-I/O-Messwerte und die Laufwerk-I/O-Messwerte, um zu erkennen, ob Ressourcen in Diensten wie GKE, Compute Engine und Dataproc unter- oder überprovisioniert sind. 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 für eine zeitnahe Reaktion auf wichtige Probleme. Mit diesem zielgerichteten Ansatz können Sie die Zuverlässigkeit der Arbeitslast proaktiv aufrechterhalten. Weitere Informationen finden Sie unter Benachrichtigungen.

Design für Graceful Degradation

Dieses Prinzip in der Säule „Zuverlässigkeit“ des Google Cloud Well-Architected Framework enthält Empfehlungen, wie Sie Ihre Google Cloud Arbeitslasten so gestalten können, dass sie bei Fehlern möglichst reibungslos fortgesetzt werden.

Dieses Prinzip ist für den Fokusbereich Antwort „Zuverlässigkeit“ relevant.

Grundsatzübersicht

Die Graceful Degradation ist ein Designansatz, bei dem ein System bei hoher Auslastung weiter funktioniert, möglicherweise mit reduzierter Leistung oder Genauigkeit. Die Graceful Degradation sorgt für die kontinuierliche Verfügbarkeit des Systems und verhindert einen vollständigen Ausfall, auch wenn die Leistung des Systems nicht optimal ist. Sobald die Auslastung wieder auf einem überschaubaren Niveau ist, wird die volle Funktionalität des Systems wiederhergestellt.

In Zeiten hoher Auslastung priorisiert die Google Suche beispielsweise Ergebnisse von Websites mit höherem Ranking, was möglicherweise zu einer gewissen Ungenauigkeit führt. Wenn die Auslastung sinkt, werden die Suchergebnisse in der Google Suche neu berechnet.

Empfehlungen

Beachten Sie die Empfehlungen in den folgenden Abschnitten, um Ihre Systeme so zu entwerfen, dass sie bei einer Überlastung reibungslos abschalten.

Drosselung implementieren

Achten Sie darauf, dass Ihre Replikats unabhängig überlastet werden können und eingehende Anfragen bei hohem Traffic drosseln können. So lassen sich kaskadierende Fehler vermeiden, die durch Verlagerungen von überschüssigem Traffic zwischen Zonen verursacht werden.

Verwenden Sie Tools wie Apigee, um die Rate der API-Anfragen bei hohem Traffic zu steuern. Sie können Richtlinienregeln so konfigurieren, dass Anfragen entsprechend herunterskaliert werden.

Überflüssige Anfragen frühzeitig ablehnen

Konfigurieren Sie Ihre Systeme so, dass überzählige Anfragen in der Frontend-Ebene abgelehnt werden, um Back-End-Komponenten zu schützen. Wenn einige Anfragen verworfen werden, werden globale Fehler verhindert und das System kann sich besser erholen.Bei diesem Ansatz können einige Nutzer jedoch Fehler feststellen. Sie können die Auswirkungen von Ausfällen jedoch minimieren, im Gegensatz zu einem Ansatz wie dem Schutzschalter, bei dem der gesamte Traffic bei einer Überlastung unterbrochen wird.

Teilweise Fehler und Wiederholungen verarbeiten

Entwerfen Sie Ihre Anwendungen so, dass sie partielle Fehler und Wiederholungsversuche nahtlos verarbeiten. So wird sichergestellt, dass bei hoher Auslastung so viel Traffic wie möglich ausgeliefert wird.

Überlastungsszenarien testen

Um zu prüfen, ob die Drosselung und das Aussetzen von Anfragen effektiv funktionieren, sollten Sie regelmäßig Überlastungsbedingungen in Ihrem System simulieren. Tests tragen dazu bei, dass Ihr System auf reale Traffic-Spitzen vorbereitet ist.

Trafficspitzen beobachten

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

Tests zur Wiederherstellung nach Fehlern durchführen

Dieses Prinzip in der Säule „Zuverlässigkeit“ des Google Cloud Well-Architected Framework enthält Empfehlungen zum Entwerfen und Ausführen von Tests zur Wiederherstellung im Falle von Ausfällen.

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

Grundsatzübersicht

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 Sicherungen umfassen.

Mit diesen Tests können Sie die Reaktion auf Ereignisse üben, die ein hohes Risiko für die Zuverlässigkeit darstellen, z. B. der 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 prüfen, ob die replizierten Daten immer auf dem neuesten Stand sind, damit Nutzer keine Datenverluste oder Sitzungsunterbrechungen erleiden. Das Load Balancing-System muss außerdem in der Lage sein, den Traffic jederzeit ohne Dienstunterbrechungen auf die Failover-Region umzuleiten. Um die Ausfallzeit nach einem regionalen Ausfall zu minimieren, müssen die Betriebsingenieure auch in der Lage sein, den Nutzerverkehr manuell und effizient innerhalb kürzester Zeit von einer Region wegzuleiten. Dieser Vorgang wird manchmal als Draining einer Region bezeichnet. Das bedeutet, dass der eingehende Traffic in die Region gestoppt und der gesamte Traffic an anderer Stelle weitergeleitet wird.

Empfehlungen

Berücksichtigen Sie beim Entwerfen und Ausführen von Tests zur Fehlerwiederherstellung die Empfehlungen in den folgenden Abschnitten.

Testziele und -umfang definieren

Definieren Sie klar, was Sie mit den Tests erreichen möchten. Beispiele für Ihre Ziele:

  • Prüfen Sie das Recovery Time Objective (RTO) und das Recovery Point Objective (RPO). Weitere Informationen finden Sie unter Grundlagen der Notfallwiederherstellungsplanung.
  • Bewerten Sie die Systemresilienz und Fehlertoleranz unter verschiedenen Fehlerszenarien.
  • Testen Sie die Effektivität automatisierter Failover-Mechanismen.

Legen Sie fest, welche Komponenten, Dienste oder Regionen in den Test einbezogen werden sollen. Der Umfang kann bestimmte Anwendungsebenen wie das Frontend, das Backend und die Datenbank oder bestimmte Google Cloud Ressourcen wie Cloud SQL-Instanzen oder GKE-Cluster umfassen. Der Umfang muss auch alle externen Abhängigkeiten angeben, 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 Ihre Produktionsumgebung nachahmt. Wenn Sie den Test in der Produktion durchführen, sollten Sie Sicherheitsmaßnahmen wie automatisiertes Monitoring und manuelle Rollback-Verfahren bereithalten.

Erstellen Sie einen Sicherungsplan. Erstellen Sie Snapshots oder Sicherungen kritischer Datenbanken und Dienste, um Datenverluste während des Tests zu vermeiden. Achten Sie darauf, dass Ihr Team für manuelle Eingriffe gerüstet ist, falls die automatischen Failover-Mechanismen versagen.

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

Informieren Sie die Stakeholder, einschließlich der Betriebsabteilung, DevOps-Mitarbeiter und Anwendungseigentümer, über den Testzeitplan, den Umfang und die potenziellen Auswirkungen. Stellen Sie den Stakeholdern einen geschätzten Zeitplan und das erwartete Verhalten während des Tests zur Verfügung.

Fehlerszenarien simulieren

Planen und führen Sie Ausfälle mithilfe von Tools wie Chaos Monkey aus. Mit benutzerdefinierten Scripts können Sie Ausfälle kritischer Dienste simulieren, z. B. das Herunterfahren eines primären Knotens in einem mehrzonenfähigen GKE-Cluster oder einer deaktivierten Cloud SQL-Instanz. Sie können auch Scripts verwenden, um einen regionsweiten Netzwerkausfall zu simulieren. Dazu verwenden Sie Firewallregeln oder API-Einschränkungen, die auf den Umfang des Tests abgestimmt sind. Steigern Sie die Fehlerszenarien nach und nach, um das Systemverhalten unter verschiedenen Bedingungen zu beobachten.

Führen Sie Lasttests zusammen mit Fehlerszenarien durch, um die tatsächliche Nutzung bei Ausfällen zu simulieren. Testen Sie die Auswirkungen von Kaskadenfehlern, z. B. das Verhalten von Frontend-Systemen, wenn Backend-Dienste nicht verfügbar sind.

Testen Sie Szenarien mit Fehlkonfigurationen, um Konfigurationsänderungen zu validieren und die Resilienz des Systems gegenüber menschlichen Fehlern zu bewerten. Beispiel: Sie führen Tests mit falschen DNS-Failover-Einstellungen oder falschen IAM-Berechtigungen aus.

Systemverhalten überwachen

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

Beobachten Sie während und nach der Simulation von Ausfällen Änderungen bei Latenz, Fehlerraten und Durchsatz und überwachen Sie die Auswirkungen auf die Gesamtleistung. Identifizieren Sie Leistungseinbußen oder Inkonsistenzen bei der Nutzererfahrung.

Sorgen Sie dafür, dass Protokolle generiert und Benachrichtigungen für wichtige Ereignisse wie Dienstausfälle oder Failover ausgelöst werden. Anhand dieser Daten können Sie die Effektivität Ihrer Benachrichtigungs- und Notfallreaktionssysteme prüfen.

Wiederherstellung anhand von RTO und RPO prüfen

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

Achten Sie darauf, dass Datenintegrität und Verfügbarkeit mit dem RPO übereinstimmen. Um die Datenbankkonsistenz zu testen, vergleichen Sie Snapshots oder Sicherungen der Datenbank vor und nach einem Fehler.

Prüfen Sie die Dienstwiederherstellung und bestätigen Sie, dass alle Dienste wieder funktionsfähig sind und die Nutzer nur minimal beeinträchtigt werden.

Ergebnisse dokumentieren und analysieren

Dokumentieren Sie jeden Testschritt, jedes Fehlerszenario 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, das während des Tests beobachtet wurde. Kategorisieren Sie Probleme nach Schweregrad und Auswirkungen, um die Fehlerbehebung zu priorisieren.

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

Iterieren und verbessern

Planen Sie regelmäßige Tests (z. B. vierteljährlich), um die anhaltende Zuverlässigkeit und Ausfallsicherheit zu prüfen.

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

Mit CI/CD-Pipelines können Sie Failover-Tests automatisieren und Zuverlässigkeitstests in Ihren Entwicklungszyklus einbinden.

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

Tests zur Wiederherstellung nach Datenverlust durchführen

Dieses Prinzip in der Säule „Zuverlässigkeit“ des Google Cloud Well-Architected Framework enthält Empfehlungen zum Entwerfen und Ausführen von Tests zur Wiederherstellung nach Datenverlust.

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

Grundsatzübersicht

Damit Ihr System bei Datenverlust oder Beschädigung wiederhergestellt werden kann, müssen Sie Tests für diese Szenarien ausführen. Datenverluste können durch einen Softwarefehler oder eine Naturkatastrophe verursacht werden. Nach solchen Ereignissen müssen Sie die Daten aus den Sicherungen wiederherstellen und alle Dienste mit den gerade wiederhergestellten Daten neu starten.

Wir empfehlen, drei Kriterien zu verwenden, um den Erfolg oder Misserfolg dieser Art von Wiederherstellungstest 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.

Das Ziel von Tests zur Datenwiederherstellung besteht darin, regelmäßig zu prüfen, ob Ihre Organisation die Anforderungen an die Geschäftskontinuität weiterhin erfüllen kann. Neben der Messung von RTO und RPO muss ein Test zur Datenwiederherstellung den gesamten Anwendungsstack und alle kritischen Infrastrukturdienste mit den wiederhergestellten Daten umfassen. So können Sie prüfen, ob die gesamte bereitgestellte Anwendung in der Testumgebung ordnungsgemäß funktioniert.

Empfehlungen

Berücksichtigen Sie beim Entwerfen und Ausführen von Tests zur Wiederherstellung nach Datenverlust die Empfehlungen in den folgenden Abschnitten.

Konsistenz der Sicherungen prüfen und Wiederherstellungsprozesse testen

Sie müssen prüfen, ob Ihre Sicherungen konsistente und verwendbare Snapshots von Daten enthalten, die Sie wiederherstellen können, um Anwendungen sofort wieder in Betrieb zu nehmen. Um die Datenintegrität zu prüfen, können Sie automatische Konsistenzprüfungen einrichten, 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 Datenwiederherstellungsszenarien, damit Ihre Sicherungen effizient wiederhergestellt werden können und die wiederhergestellten Daten die Anwendungsanforderungen erfüllen. Dokumentieren Sie die Schritte zur Datenwiederherstellung und schulen Sie Ihre Teams, diese Schritte bei einem Ausfall effektiv auszuführen.

Regelmäßige und häufige Sicherungen planen

Um Datenverluste bei der Wiederherstellung zu minimieren und die 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. Optimieren Sie die Sicherungsintervalle, um das Risiko von Datenverlusten 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 (Point-in-Time-Recovery, PITR) für Cloud SQL oder inkrementelle Sicherungen für große Datenmengen.

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 das definierte RPO überschreiten, richten Sie mit Cloud Monitoring Benachrichtigungen ein.

Zustand der Sicherung überwachen

Verwenden Sie den Google Cloud Dienst für Sicherung und Notfallwiederherstellung oder ähnliche Tools, um den Zustand Ihrer Sicherungen im Blick zu behalten und sicherzustellen, dass sie an sicheren und zuverlässigen Orten gespeichert werden. Achten Sie darauf, dass die Sicherungen für zusätzliche Ausfallsicherheit in mehreren Regionen repliziert werden.

Szenarien jenseits der Sicherung planen

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

Gründliche Postmortem-Analysen durchführen

Dieses Prinzip in der Säule „Zuverlässigkeit“ des Google Cloud Well-Architected Framework enthält Empfehlungen für effektive Postmortem-Analysen nach Ausfällen und Vorfällen.

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

Grundsatzübersicht

Eine Postmortem-Analyse ist eine schriftliche Aufzeichnung eines Vorfalls, seiner Auswirkungen, der ergriffenen Maßnahmen zur Behebung oder Begrenzung des Vorfalls, der Grundursachen und der Folgemaßnahmen, um ein Wiederauftreten des Vorfalls zu verhindern. Das Ziel einer Postmortem-Analyse besteht darin, aus Fehlern zu lernen und nicht, Schuld zuzuweisen.

Das folgende Diagramm zeigt den Workflow einer Postmortem-Analyse:

Der Ablauf einer Postmortem-Analyse.

Der Workflow einer Postmortem-Analyse umfasst die folgenden Schritte:

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

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

  • Nutzer wahrnehmbare Ausfallzeiten oder Leistungseinbußen über einen bestimmten Grenzwert hinaus
  • Datenverluste jeglicher Art.
  • Interventionen von Bereitschaftstechnikern, z. B. ein Release-Rollback oder eine Umleitung des Traffics.
  • Bei einer Auflösungszeit über einem definierten Grenzwert
  • Monitoringfehler, die in der Regel eine manuelle Erkennung von Vorfällen erfordern.

Empfehlungen

Legen Sie die Kriterien für die Analyse vor einem Vorfall fest, damit alle wissen, wann eine Analyse erforderlich ist.

Beachten Sie die Empfehlungen in den folgenden Unterabschnitten, um effektive Postmortem-Analysen durchzuführen.

Postmortem-Analysen ohne Schuldzuweisung durchführen

Effektive Postmortem-Analysen konzentrieren sich auf Prozesse, Tools und Technologien und machen keine Personen oder Teams verantwortlich. Der Zweck einer Postmortem-Analyse besteht darin, Ihre Technologie und Ihre Zukunft zu verbessern, nicht herauszufinden, wer schuld ist. Jeder macht Fehler. Das Ziel sollte sein, die Fehler zu analysieren und daraus zu lernen.

Die folgenden Beispiele zeigen den Unterschied zwischen Feedback, das Schuldzuweisungen enthält, und Feedback ohne Schuldzuweisungen:

  • Feedback, das Schuldzuweisungen enthält: „Wir müssen das gesamte komplizierte Backend-System neu schreiben! In den letzten drei Quartalen ist es jede Woche zu Problemen gekommen und ich bin sicher, dass wir alle es leid sind, die Probleme Stück für Stück zu beheben. Wenn ich noch einmal gerufen werde, schreibe ich den Text selbst.“
  • Feedback ohne Schuldzuweisung: „Eine Maßnahme, das gesamte Backend-System neu zu schreiben, könnte tatsächlich verhindern, dass diese Seiten weiterhin auftreten. Das Wartungshandbuch für diese Version ist ziemlich lang und es ist wirklich schwierig, sich vollständig damit vertraut zu machen. Ich bin sicher, dass unsere zukünftigen Bereitschaftstechniker uns dafür danken werden.“

Den Postmortem-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. 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.

Vermeiden Sie komplexe oder überoptimierte Lösungen

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

Die Postmortem-Analyse möglichst breit streuen

Damit Probleme nicht ungelöst bleiben, veröffentlichen Sie das Ergebnis der Postmortem-Analyse für ein breites Publikum und holen Sie sich Unterstützung vom Management. Der Wert einer Postmortem-Analyse ist proportional zu den Erkenntnissen, die nach der Analyse gewonnen werden. Je mehr Menschen aus Vorfällen lernen, desto geringer ist die Wahrscheinlichkeit, dass ähnliche Fehler wieder auftreten.