Zuverlässig

In diesem Abschnitt des Architektur-Frameworks wird beschrieben, wie Sie technische und prozedurale Anforderungen für die Architektur und den Betrieb zuverlässiger Dienste in Google Cloud anwenden.

Das Framework besteht aus folgenden Dokumentreihen:

Zuverlässigkeit ist das wichtigste Merkmal jeder Anwendung. Wenn sie nämlich nicht zuverlässig ist, steigen Nutzer irgendwann auf andere Anwendungen um und die anderen Features Ihrer Anwendung spielen keine Rolle.

  • Eine Anwendung muss messbare Zuverlässigkeitsziele haben und Abweichungen müssen sofort korrigiert werden.
  • Die Anwendung muss auf Skalierbarkeit, Hochverfügbarkeit und automatisiertes Änderungsmanagement ausgelegt sein.
  • Die Anwendung muss sich nach Möglichkeit selbst reparieren können und für eine gute Beobachtbarkeit instrumentiert sein.
  • Die zum Ausführen der Anwendung verwendeten Betriebsabläufe sollten einen minimalen manuellen Aufwand verursachen und die kognitive Belastung für Operatoren gering halten. Gleichzeitig muss eine schnelle Fehlerbehebung möglich sein.

Strategien

Nutzen Sie diese Strategien, um für Zuverlässigkeit zu sorgen.

Die Zuverlässigkeit wird vom Nutzer definiert. Bei nutzerorientierten Arbeitslasten sollten Sie nicht nur Servermesswerte wie die CPU-Auslastung messen, sondern auch die Nutzererfahrung (z. B. das Erfolgsverhältnis bei Abfragen). Bei Batch- und Streamingarbeitslasten müssen Sie unter Umständen Leistungskennzahlen (Key Performance Indikators, KPIs) wie beispielsweise pro Zeitfenster gescannte Zeilen messen, statt sich nur auf Servermesswerte wie die Laufwerksnutzung zu konzentrieren. So können Sie sichergehen, dass vierteljährliche Berichte pünktlich fertiggestellt werden.

Beim Thema Zuverlässigkeit lautet die Devise "ausreichend". Ihre Systeme sollten so zuverlässig sein, dass Nutzer zufrieden sind. Gleichzeitig sollten Sie darauf achten, dass sich die Investition lohnt und Sie durch übermäßige Zuverlässigkeit nicht den Kürzeren ziehen. Definieren Sie Service Level Objectives (SLOs), die den Zuverlässigkeitsschwellenwert festlegen, und verwenden Sie Fehlerbudgets, um die Änderungsrate zu verwalten. Wenden Sie die unten aufgeführten zusätzlichen Prinzipien nur an, wenn das SLO die Kosten rechtfertigt.

Sorgen Sie für Redundanz. Systeme mit hohen Zuverlässigkeitsanforderungen dürfen keine Single Points of Failure haben. Ihre Ressourcen müssen über mehrere fehlerhafte Domains hinweg repliziert werden. Eine fehlerhafte Domain ist ein Pool von Ressourcen, die unabhängig voneinander ausfallen können, z. B. eine VM, eine Zone oder eine Region.

Arbeiten Sie mit horizontaler Skalierbarkeit. Achten Sie darauf, dass jede Komponente Ihres Systems das Wachstum des Traffics oder der Daten bewältigen kann. Fügen Sie dazu weitere Ressourcen hinzu.

Sorgen Sie für eine Überlastungstoleranz. Entwickeln Sie Dienste, die ihre Leistung unter Last schrittweise herabsetzen.

Fügen Sie eine Rollback-Funktion ein. Jede Änderung, die ein Operator an einem Dienst vornimmt, muss eine klar definierte Methode zum Rückgängigmachen haben, d. h. für einen Rollback der Änderung.

Vermeiden Sie Trafficspitzen. Synchronisieren Sie keine Anfragen zwischen Clients. Wenn zu viele Clients Traffic gleichzeitig senden, kommt es zu Trafficspitzen, die im schlimmsten Fall zu Fehlerkaskaden führen können.

Testen Sie die Wiederherstellung nach Fehlern. Wenn Sie Ihre Betriebsabläufe zur Wiederherstellung nach Fehlern nicht vor Kurzem getestet haben, funktionieren sie wahrscheinlich genau dann nicht, wenn Sie sie benötigen. Zu den Elementen, die regelmäßig getestet werden sollten, gehören der regionale Failover, das Rollback eines Releases und die Wiederherstellung von Daten aus Sicherungen.

Ermitteln Sie Fehler. Es gilt, einen Kompromiss zwischen zu früher Benachrichtigung und dem damit verbundenen Überbeanspruchen des operativen Teams und der zu späten Benachrichtigung und den damit verbundenen längeren Dienstausfällen zu finden. Der Zeitraum, bevor Operatoren über Ausfälle informiert werden (auch bekannt als Time to Detect bzw. TTD – Zeit zum Erkennen), muss im Zusammenhang mit diesem Kompromiss abgestimmt werden.

Nehmen Sie Änderungen inkrementell vor. Sofortige globale Änderungen an Dienstbinärdateien oder -konfigurationen sind mit Risiken verbunden. Wir empfehlen Ihnen, Änderungen schrittweise zu implementieren und "Canary-Tests" durchzuführen, um Fehler in den frühen Phasen einer Einführung zu erkennen, in denen die Auswirkungen auf die Nutzer minimal sind.

Sorgen Sie für koordinierte Notfallmaßnahmen. Entwickeln Sie Betriebsabläufe zum Minimieren der Dauer von Ausfällen (auch bekannt als Time to Mitigate bzw. TTM – Zeit zur Problemminderung). Berücksichtigen Sie dabei, wie kundenfreundlich diese sind und wie sie sich auf das Wohlergehen der Operatoren auswirken. Bei diesem Ansatz müssen die Maßnahmen mit klar definierten Rollen und Kommunikationskanälen im Voraus festgelegt werden.

Instrumentieren Sie Systeme zur Beobachtbarkeit. Die Systeme müssen ausreichend gut instrumentiert sein, um eine schnelle Fehlererkennung, Fehlerbehebung und Diagnose von Problemen zu ermöglichen sowie die TTM zu minimieren.

Dokumentieren und automatisieren Sie Notfallmaßnahmen. Im Notfall können Mitarbeiter nur schwer definieren, was zu tun ist, und komplexe Aufgaben ausführen. Daher sollten Sie Notfallmaßnahmen im Voraus planen, dokumentieren und idealerweise automatisieren.

Behalten Sie die Kapazität im Blick. Prognostizieren Sie den Traffic und stellen Sie Ressourcen bereit, bevor Trafficspitzen auftreten.

Reduzieren Sie den Arbeitsaufwand. Als Aufwand werden manuelle und sich wiederholende Arbeiten ohne bleibenden Wert bezeichnet, die zunehmen, je umfangreicher der Dienst wird. Versuchen Sie kontinuierlich, den Arbeitsaufwand zu reduzieren oder zu vermeiden. Andernfalls werden die Operatoren letztendlich durch die operative Arbeit überfordert, was wenig Raum für Wachstum bietet.

Best Practices

Befolgen Sie diese Best Practices, um Zuverlässigkeit zu erreichen.

  • Definieren Sie Ihre Zuverlässigkeitsziele mithilfe von Service Level Objectives (SLOs) und Fehlerbudgets.
  • Sorgen Sie für mehr Beobachtbarkeit in Ihrer Infrastruktur und Ihren Anwendungen.
  • Sorgen Sie bei der Entwicklung für Skalierung und Hochverfügbarkeit.
  • Erstellen Sie flexible und automatisierte Bereitstellungsfunktionen.
  • Erstellen Sie effiziente Benachrichtigungssysteme.
  • Erstellen Sie einen gemeinsamen Prozess für das Vorfallmanagement.

Zuverlässigkeitsziele definieren

Wir empfehlen Ihnen, Ihre bestehende Kundenerfahrung sowie deren Fehlertoleranz zu messen und anhand dieser Ereignisse Zuverlässigkeitsziele aufzustellen. Ein Ziel, das die allgemeine Verfügbarkeit des Systems über einen unbegrenzten Zeitraum bei 100 % vorsieht, kann beispielsweise nicht erreicht werden und ist auch nicht sinnvoll, wenn die vom Nutzer erwarteten Daten nicht vorhanden sind.

Legen Sie SLOs auf Basis der Nutzererfahrung fest. Messen Sie die Zuverlässigkeitsmesswerte so nah wie möglich am Nutzer. Wenn möglich, sollten Sie den mobilen Client oder Webclient instrumentieren. Wenn dies nicht möglich ist, führen Sie eine Instrumentierung des Load-Balancers durch. Das Messen der Zuverlässigkeit auf dem Server sollte die letzte Option sein. Legen Sie das SLO hoch genug fest, um die Zufriedenheit des Nutzers zu gewährleisten – jedoch nicht höher.

Aufgrund ihrer Netzwerkverbindung oder anderer vorübergehender clientseitiger Probleme nehmen Ihre Kunden eventuell für kurze Zeit Zuverlässigkeitsprobleme, die von Ihrer Anwendung verursacht werden, nicht wahr.

Wir empfehlen Ihnen dringend, ein Ziel von weniger als 100 % für die Verfügbarkeit und andere wichtige Messwerte festzulegen. Versuchen Sie aber, sich diesem Ziel anzunähern. Mit einem solchen Ziel kann jeder Anbieter Software schneller und in hoher Qualität bereitstellen. Und mit einem richtig entwickelten System können Sie in vielen Fällen auch eine höhere Verfügbarkeit erreichen, wenn Sie das Tempo und die Menge der Änderungen reduzieren.

Erreichbare und auf die Nutzererfahrung abgestimmte Zuverlässigkeitsziele helfen in der Regel dabei, das maximale Tempo und den Umfang von Änderungen (also die Geschwindigkeit, mit der Features eingeführt werden) zu bestimmen, das bzw. der innerhalb der Toleranzschwelle der Kunden liegt.

Wenn Sie die bestehende Kundenerfahrung nicht messen und keine Ziele definieren können, empfehlen wir eine Benchmark-Wettbewerbsanalyse. Wenn kein vergleichbarer Wettbewerb vorhanden ist, sollten Sie die Kundenerfahrung messen, auch wenn Sie noch keine Ziele definieren können, z. B. die Systemverfügbarkeit oder die Rate aussagekräftiger und erfolgreicher Transaktionen an den Kunden. Sie können dies mit Geschäftsmesswerten oder KPIs wie dem Auftragsvolumen (Einzelhandel), der Anzahl an Kundensupportanfragen und Tickets und deren Wichtigkeit in Beziehung setzen. Im Laufe der Zeit können Sie mithilfe solcher Korrelationsmethoden einen geeigneten Schwellenwert für die Kundenzufriedenheit erreichen – sprich, das SLO.

SLIs, SLOs und SLAs

Ein Service Level Indicator (SLI) ist ein quantitatives Maß für einen bestimmten Aspekt des bereitgestellten Service-Levels. Es handelt sich um einen Messwert, kein Ziel.

Service Level Objectives (SLOs) geben ein Zielniveau für die Zuverlässigkeit Ihres Dienstes an. Da SLOs entscheidend für datengestützte Zuverlässigkeitsentscheidungen sind, bilden sie das Herzstück von SRE-Methoden. Das SLO ist ein Wert für einen SLI. Wenn der SLI diesen Wert überschreitet, gilt der Dienst als "zuverlässig genug".

Fehlerbudgets werden als (100 % – SLO) für einen bestimmten Zeitraum berechnet. Sie geben Aufschluss darüber, ob Ihr System über einen bestimmten Zeitraum hinweg mehr oder weniger zuverlässig ist als erforderlich. Wir empfehlen in der Regel ein rollierendes Zeitfenster von 30 Tagen.

Service Level Agreements (SLAs) sind explizite oder implizite Verträge mit Ihren Nutzern, die die Folgen der Einhaltung (oder Nichteinhaltung) der darin enthaltenen SLOs beinhalten.

Es empfiehlt sich, interne SLOs höher als externe SLAs festzulegen. Der Grund dafür ist, dass bei Verstößen gegen das SLA in der Regel eine Finanzgutschrift oder Erstattung für den Kunden erforderlich ist. Sie sollten Probleme wiederum beheben können, bevor sie finanzielle Auswirkungen haben. Wir empfehlen, strengere interne SLOs mit einem Blameless-Postmortem-Prozess mit Vorfallsüberprüfungen zu kombinieren.

Achten Sie darauf, SLIs auf Mandantenebene zu erfassen, wenn die Anwendung eine Mehrmandantenarchitektur hat – wie sie für SaaS-Anwendungen üblich ist, die von mehreren unabhängigen Kunden verwendet werden. Wenn Sie SLIs nur auf globaler aggregierter Ebene messen, kann Ihr Monitoringsystem keine kritischen Probleme melden, die einzelne oder wenige Kunden betreffen. Gestalten Sie die Anwendung so, dass sie in jede Nutzeranfrage eine Mandanten-ID aufnimmt und diese über jede Schicht des Stapels weitergibt. Wenn Sie diese ID weitergeben, kann das Monitoringsystem Statistiken auf Mandantenebene für jede Schicht oder jeden Mikrodienst im Anfragepfad zusammenfassen.

Fehlerbudgets

Nutzen Sie Fehlerbudgets, um die Entwicklungsgeschwindigkeit zu steuern. Wenn das Fehlerbudget noch nicht aufgebraucht ist, fahren Sie umgehend mit der Einführung neuer Features fort. Wenn das Fehlerbudget fast null ist, können Sie Dienständerungen einfrieren oder verlangsamen und technische Ressourcen für Zuverlässigkeitsfeatures nutzen.

Google Cloud minimiert den Aufwand für die Einrichtung von SLOs und Fehlerbudgets durch Service Monitoring. Dieses Produkt bietet eine Benutzeroberfläche zur manuellen Konfiguration von SLOs, eine API für die programmatische Einrichtung von SLOs und integrierte Dashboards für das Tracking der Fehlerbudget-Brennrate.

Beispiel-SLIs

Für Serving-Systeme sind die folgenden SLIs üblich:

  • Die Verfügbarkeit gibt an, wie lange ein Dienst nutzbar ist. Oftmals wird sie als Anteil von erfolgreichen, korrekt formulierten Anfragen definiert – z. B. 99 %.
  • Die Latenz gibt an, wie schnell ein bestimmter Prozentsatz an Anfragen erfüllt werden kann. Sie wird oft als ein Perzentil ungleich 50 definiert, z. B. als 99. Perzentil bei 300 ms.
  • Die Qualität weist darauf hin, wie gut eine bestimmte Antwort ist. Die Definition der Qualität ist oft dienstspezifisch und gibt an, inwieweit der Inhalt der Antwort auf eine Anfrage vom idealen Antwortinhalt abweicht. Sie kann binär (gut oder schlecht) oder auf einer Skala von 0 % bis 100 % ausgedrückt werden.

Für Datenverarbeitungssysteme sind die folgenden SLIs üblich:

  • Die Abdeckung gibt den Anteil der verarbeiteten Daten an, z. B. 99,9 %.
  • Die Richtigkeit gibt den Anteil der als korrekt eingestuften Antworten an, z. B. 99,99 %.
  • Die Aktualität gibt an, wie aktuell die Quelldaten oder die zusammengefassten Antworten sind, wobei gilt: je aktueller, desto besser, z. B. vor 20 Minuten.
  • Der Durchsatz gibt an, wie viele Daten verarbeitet werden, z. B. 500 MiB/s oder sogar 1.000 RPS.

Für Speichersysteme sind die folgenden SLIs üblich:

  • Die Langlebigkeit gibt an, wie wahrscheinlich es ist, dass die in das System geschriebenen Daten in Zukunft abgerufen werden können, z. B. 99,9999 %. Bei einem dauerhaften Datenverlust wird der Messwert für die Langlebigkeit reduziert.
  • Durchsatz und Latenz (wie oben beschrieben)

Fragen zum Design

  • Messen Sie im Rahmen der Nutzererfahrung die Zuverlässigkeit der Anwendung?
  • Sind die Clientanwendungen darauf ausgelegt, Zuverlässigkeitsmesswerte zu erfassen und zu dokumentieren?
  • Ist die Systemarchitektur auf bestimmte Zuverlässigkeits- und Skalierbarkeitsziele ausgerichtet?
  • Enthalten Nutzeranfragen in Systemen mit mehreren Mandanten eine Mandanten-ID, und wird diese über jede Schicht des Softwarestapels weitergegeben?

Empfehlungen

  • Definieren und messen Sie kundenorientierte SLIs.
  • Definieren Sie ein kundenorientiertes Fehlerbudget, das strenger als Ihr externes SLA ist und Konsequenzen für Verstöße hat, z. B. Produktionsstopps.
  • Richten Sie Latenz-SLIs zum Erfassen von Ausreißerwerten ein, also für das 90. oder 99. Perzentil, um die langsamsten Antworten zu erkennen.
  • Prüfen Sie die SLOs mindestens einmal pro Jahr.

Ressourcen

Für mehr Beobachtbarkeit in Ihrer Infrastruktur und Ihren Anwendungen sorgen

Die Beobachtbarkeit umfasst Monitoring, Logging, Tracing, Profiling, Debugging und ähnliche Systeme.

Instrumentieren Sie Ihren Code, um die Beobachtbarkeit zu maximieren. Schreiben Sie Log- und Trace-Einträge und exportieren Sie Monitoringmesswerte unter Berücksichtigung von Debugging und Fehlerbehebung. Priorisieren Sie dabei nach den wahrscheinlichsten oder häufigsten Fehlerarten des Systems. Prüfen und bereinigen Sie Ihr Monitoringsystem regelmäßig und löschen Sie nicht verwendete oder nutzlose Dashboards, Benachrichtigungen sowie Tracing- und Logging-Daten, um überflüssige Daten zu entfernen.

Monitoring bildet die Basis der Dienstzuverlässigkeitshierarchie. Ohne ein entsprechendes Monitoringsystem können Sie nicht feststellen, ob eine Anwendung überhaupt funktioniert.

Ein gut durchdachtes System zielt ab der Entwicklungsphase auf die richtige Beobachtbarkeit ab. Warten Sie nicht, bis eine Anwendung in der Produktionsphase ist, um sie zu beobachten.

Die Operations-Suite von Google Cloud bietet Monitoring, Logging (Google Cloud und AWS) sowie Tracing, Profiling und Debugging in Echtzeit. Sie kann auch ein Service Mesh mit Istio und App Engine-Diensten (Cloud Monitoring) überwachen.

Häufige Anti-Muster sind das Over-Engineering des Monitoringsystems und Einstellungen, die eine Überflutung von Benachrichtigungen mit sich bringen. Vermeiden Sie diese Anti-Muster dadurch, dass Sie proaktiv Zeitachsen, Dashboards und Benachrichtigungen löschen, die während der ersten Phasen des externen Starts nicht angesehen oder selten ausgelöst werden. Dies gilt auch für Logeinträge, die selten gescannt werden.

Prüfen Sie, ob Sie alle oder eine Auswahl von Anwendungsereignissen an ein Cloud Data Warehouse wie BigQuery senden sollten. Dies ist nützlich, da Sie damit beliebige Abfragen zu geringeren Kosten ausführen können, anstatt das Monitoringsystem direkt im Voraus zu gestalten. Außerdem wird dadurch die Berichterstellung vom Monitoring entkoppelt. Die Berichterstellung kann von allen Nutzern durchgeführt werden, die Google Data Studio oder Looker verwenden.

Fragen zum Design

  • Gibt es bei der Designüberprüfung Standards für die Beobachtbarkeit, die als Leitfaden für Design- und Codeüberprüfungen dienen?
  • Sind die von der Anwendung exportierten Messwerte für die Behebung von Ausfällen geeignet?
  • Sind Anwendungslogeinträge detailliert und relevant genug, um Sie beim Debugging zu unterstützen?

Empfehlungen

  • Implementieren Sie das Monitoringsystem frühzeitig, bevor Sie eine Migration starten oder während Sie eine neue Anwendung vor der ersten Produktionsbereitstellung erstellen.
  • Unterscheiden Sie zwischen Anwendungsproblemen und zugrunde liegenden Cloud-Problemen. Verwenden Sie beispielsweise transparente SLIs und das Google Cloud-Status-Dashboard.
  • Definieren Sie neben dem Profiling eine Strategie für Beobachtbarkeit, die Tracing, Profiling und Debugging umfasst.
  • Bereinigen Sie regelmäßig Beobachtbarkeitsartefakte, die nicht verwendet werden oder nicht nützlich sind. Dazu gehören Warnungen, aus denen sich keine Handlungen ableiten lassen.
  • Senden Sie Anwendungsereignisse (also Messwerte mit hoher Kardinalität) an ein Data Warehouse-System wie BigQuery.

Bei der Entwicklung für Skalierung und Hochverfügbarkeit sorgen

Multiregionale Architektur mit Failover entwerfen

Wenn Ihr Dienst auch dann ausgeführt werden muss, wenn eine gesamte Region ausgefallen ist, sollte er Pools von Rechenressourcen verwenden, die über verschiedene Regionen verteilt sind. Diese Ressourcen sollten einen automatischen Failover haben, wenn eine Region ausfällt. Beseitigen Sie Single Points of Failure, z. B. eine Masterdatenbank in einer Region, die bei Nichterreichbarkeit einen globalen Ausfall verursachen kann.

Engpässe bei der Skalierbarkeit beseitigen

Ermitteln Sie Systemkomponenten, die nicht über die Ressourcenlimits einer einzelnen VM oder einer einzelnen Zone hinauswachsen können. Einige Anwendungen sind für die vertikale Skalierung ausgelegt, bei der mehr CPU-Kerne, Arbeitsspeicher oder Netzwerkbandbreite auf einer einzelnen VM benötigt werden, um die erhöhte Last zu bewältigen. Derartige Anwendungen haben feste Skalierungsgrenzen und erfordern oft eine manuelle Neukonfiguration, um das Wachstum zu bewältigen. Gestalten Sie diese Komponenten mithilfe von Fragmentierung (Partitionierung über VMs oder Zonen) horizontal skalierbar, sodass die Traffic- oder Nutzungszunahme problemlos durch Hinzufügen weiterer Shards bewältigt werden kann. Shards verwenden Standard-VM-Typen, die automatisch hinzugefügt werden können, um erhöhte Shard-Lasten zu verarbeiten. Als Alternative zur Neugestaltung können Sie diese Komponenten durch verwaltete Dienste ersetzen, die für eine horizontale Skalierung ohne Eingreifen durch Nutzer konzipiert sind.

Service-Levels ordnungsgemäß heruntersetzen

Entwerfen Sie Ihre Dienste so, dass sie eine Überlastung erkennen und infolge der Überlastung nicht vollständig ausfallen. Stattdessen sollten sie Antworten von geringerer Qualität an den Nutzer zurückgeben oder den Traffic teilweise unterbrechen. Beispielsweise kann ein Dienst auf Nutzeranfragen mit statischen Webseiten antworten und dabei das teurere dynamische Verhalten vorübergehend deaktivieren oder schreibgeschützte Vorgänge zulassen, während Datenaktualisierungen zeitweise deaktiviert werden.

Exponentiellen Backoff mit Jitter implementieren

Wenn mobile Clients auf eine Fehlerantwort Ihres Dienstes stoßen, müssen sie den Vorgang nach einer zufälligen Verzögerung wiederholen. Wenn sie wiederholt Fehler erhalten, sollten sie exponentiell länger warten, bevor sie es noch einmal versuchen, und zusätzlich zu jedem Wiederholungsvorgang zufällige Zeitverschiebungen (Jitter) hinzufügen. Dadurch wird verhindert, dass große Gruppen von Clients nach einem Mobilfunknetzausfall sofortige Trafficspitzen erzeugen, da diese Spitzen Ihre Server möglicherweise abstürzen lassen.

Trafficspitzen vorhersagen und dafür planen

Wenn in Ihrem System bekannte Trafficspitzen auftreten, z. B. für Einzelhändler am Black Friday, sollten Sie sich auf solche Ereignisse vorbereiten, um zu vermeiden, dass es zu einem erheblichen Traffic- und Umsatzverlust kommt. Prognostizieren Sie die Größe der Trafficspitze, fügen Sie einen Puffer hinzu und sorgen Sie dafür, dass Ihr System über genügend Rechenkapazität verfügt, um die Spitze zu bewältigen. Führen Sie einen Lasttest am System durch und verwenden Sie dafür die erwartete Mischung aus Nutzeranfragen, um sicherzugehen, dass die geschätzte Lastbewältigungskapazität mit der tatsächlichen Kapazität übereinstimmt. Führen Sie Übungen aus, in denen Ihr operatives Team Ausfälle simuliert, Reaktionsmaßnahmen darauf übt und die unten beschriebenen kollaborativen Vorgänge zum teamübergreifenden Vorfallmanagement durchführt.

Notfallwiederherstellung testen

Warten Sie nicht auf den Notfall. Testen Sie regelmäßig Ihre Abläufe und Prozesse zur Notfallwiederherstellung. Möglicherweise planen Sie auch eine Architektur für Hochverfügbarkeit (High Availability – HA). Sie gehört zwar nicht unbedingt zum Thema Notfallwiederherstellung (Disaster Recovery – DR), allerdings muss die HA oft berücksichtigt werden, wenn Sie an Werte für die Zeit bis zur Wiederherstellung (Recovery Time Objective – RTO) und den hinnehmbaren Datenverlust (Recovery Point Objective – RPO) denken. HA hilft dabei, eine vereinbarte Betriebsleistung zu gewährleisten, die in der Regel länger als die Standardverfügbarkeit ist. Wenn Sie Produktionsarbeitslasten in Google Cloud ausführen, können Sie ein global verteiltes System verwenden, sodass die Anwendung im Falle eines Fehlers in einer Region weiterhin Dienste bereitstellt, auch wenn sie im Allgemeinen weniger verfügbar ist. Im Wesentlichen ruft diese Anwendung hier ihren DR-Plan auf.

Fragen zum Design

  • Kann die Anwendung ohne zusätzliche Architekturänderungen durch Hinzufügen weiterer VMs vertikal skaliert werden?
  • Ist jede Komponente in der Architektur horizontal skalierbar, durch Fragmentierung oder auf andere Weise?
  • Sind Clientanwendungen so konzipiert, dass Anfragen nicht zwischen Clients synchronisiert werden?
  • Kann die Anwendung den Ausfall einer gesamten Cloud-Region ohne globalen Ausfall bewältigen?
  • Sind Nutzeranfragen gleichmäßig auf Shards und Regionen verteilt?
  • Kann die Anwendung erkennen, wenn sie überlastet ist, und ihr Verhalten ändern, um einen Ausfall zu verhindern?

Empfehlungen

  • Implementieren Sie den exponentiellen Backoff mit zufälliger Anordnung in der Fehlerwiederholungslogik von Clientanwendungen.
  • Implementieren Sie eine multiregionale Architektur mit automatischem Failover für Hochverfügbarkeit.
  • Verwenden Sie Load-Balancing, um Nutzeranfragen auf Shards und Regionen zu verteilen.
  • Entwickeln Sie die Anwendung so, dass sie ihre Leistung bei Überlastung schrittweise herabsetzt, Teilantworten liefert oder eingeschränkte Funktionalität bietet, anstatt vollständig auszufallen.
  • Richten Sie einen wiederkehrenden datengestützten Prozess für die Kapazitätsplanung ein. Verwenden Sie dafür Lasttests und Trafficprognosen, um die Bereitstellung von Ressourcen zu fördern.
  • Legen Sie Notfallwiederherstellungsverfahren fest und testen Sie sie regelmäßig.

Flexible und automatisierte Bereitstellungsfunktionen erstellen

Gewährleisten, dass jede Änderung rückgängig gemacht werden kann

Wenn es kein durchdachtes Verfahren gibt, um bestimmte Arten von Änderungen rückgängig zu machen, sollten Sie das Design des Dienstes ändern, damit Rollbacks unterstützt werden. Testen Sie die Rollback-Prozesse dann regelmäßig. Dies kann kostenintensiv für mobile Anwendungen sein. Wir empfehlen Entwicklern, Firebase Remote Config anzuwenden, um das Rollback von Features zu vereinfachen.

Traffic für zeitlich begrenzte Werbeaktionen und Markteinführungen verteilen

Gestalten Sie den Clientcode so, dass der Traffic über zufällige Verzögerungen von einigen Sekunden vor dem Starten von Anfragen verteilt wird. Dies empfiehlt sich beispielsweise für Marketingmaßnahmen wie Verkaufsaktionen, die zu einem bestimmten Zeitpunkt (z. B. Mitternacht) beginnen und viele Nutzer gleichzeitig dazu veranlassen, sich mit dem Dienst zu verbinden. Durch ein solches Design werden plötzlich auftretende Trafficspitzen verhindert, die Ihre Server zum geplanten Beginn zum Absturz bringen könnten.

Schrittweise Rollouts mit Canary-Tests implementieren

Führen Sie neue Versionen ausführbarer Dateien und Konfigurationsänderungen schrittweise ein, beginnend mit einem kleinen Rahmen wie einigen VMs in einer Zone. Ihr Ziel sollte darin bestehen, Programmfehler zu erkennen, solange nur ein kleiner Teil des Nutzertraffics betroffen ist und bevor die Änderung global eingeführt wird. Richten Sie ein Canary-Testsystem ein, das solche Änderungen erkennt und einen A/B-Vergleich der Messwerte der geänderten Server mit denen der verbleibenden Server durchführt, um ungewöhnliches Verhalten zu melden. Das Canary-System sollte die Operatoren auf Probleme hinweisen und Rollouts möglicherweise sogar automatisch anhalten können. Nachdem die Änderung den Canary-Test bestanden hat, geben Sie sie nach und nach an größere Bereiche weiter, z. B. an eine vollständige Zone und dann an eine zweite Zone, sodass das geänderte System langsam immer größere Mengen an Nutzertraffic verarbeitet, um eventuell vorhandene Fehler zu erkennen.

Erstell-, Test- und Bereitstellungsvorgänge automatisieren

Mit CI/CD-Pipelines können Sie den Aufwand bei neuen Releases reduzieren und automatische Tests in Ihre Releases einbinden. Führen Sie automatisierte Integrationstests und Bereitstellungen durch.

Automatisierung ist zwar nützlich, aber längst kein Allheilmittel. Sie umfasst neben den anfänglichen Entwicklungs- und Einrichtungskosten auch nicht außer Acht zu lassende Wartungskosten und Zuverlässigkeitsrisiken.

Wir empfehlen Ihnen, zuerst den Arbeitsaufwand der Teams, die Ihre Systeme verwalten, zu erfassen und zu bewerten. Gestalten Sie diesen Prozess als kontinuierlich und beginnen Sie ihn, bevor Sie in eine benutzerdefinierte Automatisierung investieren, um die bereits von Google Cloud-Diensten und -Partnern bereitgestellten Dienste zu erweitern. Häufig können Sie die eigene Automatisierung von Google Cloud anpassen, z. B. den Autoscaling-Algorithmus von Compute Engine.

Wir betrachten Aufwand als manuelle, sich wiederholende, automatisierbare und reaktive Arbeit, die meist keinen bleibenden Wert hat und mindestens genauso schnell wächst wie ihre Quelle. Weitere Informationen finden Sie im SRE-Kapitel Eliminating Toil.

Im Folgenden finden Sie einige der wichtigsten Bereiche, in denen Arbeitsaufwand mithilfe von Google beseitigt wurde und unsere Kunden durch konfigurierbare oder benutzerdefinierte Automatisierung unterstützt wurden:

Wir empfehlen, vor der Automatisierung zuerst die Beseitigung von Arbeitsaufwand zu priorisieren und so die von Google bereitgestellte konfigurierbare Automatisierung so weit wie möglich zu nutzen. In einem zweiten Schritt kann dann der verbleibende Arbeitsaufwand reduziert werden. Der dritte Schritt, der parallel zum ersten und zweiten Schritt ausgeführt werden kann, besteht darin, andere Lösungen zu entwickeln oder zu kaufen, wenn der Arbeitsaufwand hoch bleibt, z. B. mehr als 50 % der Zeit für ein Team beträgt, das Ihre Produktionssysteme verwaltet. Berücksichtigen Sie beim Erstellen oder Kaufen von Lösungen die Kosten für Integration, Sicherheit, Datenschutz und Compliance.

Wenn Sie auf ein Google Cloud-Produkt oder einen Google Cloud-Dienst stoßen, das oder der Ihre technischen Anforderungen im Hinblick auf die Automatisierung oder Beseitigung manueller Workflows nur teilweise erfüllt, sollten Sie eine Funktionsanfrage über Ihren Google Cloud-Kundenbetreuer einreichen. Möglicherweise sehen weitere Kunden dies als Priorität an oder das Feature ist bereits Teil unserer Planung. Wenn ja, können Sie durch Informationen zur Priorität und zum Zeitplan des Features besser abwägen, ob Sie Ihre eigene Lösung erstellen oder warten möchten, bis Sie sie als Google Cloud-Feature nutzen können.

Fragen zum Design

  • Ist der Änderungsprozess für ausführbare Dateien und Konfigurationen automatisiert?
  • Ist die Änderungsautomatisierung darauf ausgelegt, bei jeder möglichen Änderung ein schnelles Rollback zu ermöglichen?
  • Gibt es einen Designüberprüfungsprozess für Änderungen, die nicht rückgängig gemacht werden können (z. B. Schemaänderungen), um die Vorwärts- und Abwärtskompatibilität zwischen aktuellen oder früheren Binärversionen und Datenschemas zu gewährleisten?
  • Sind Systemkonfigurationsdateien fragmentiert, sodass Konfigurationsänderungen inkrementell statt global eingeführt werden können?

Empfehlungen

  • Richten Sie Canary-Tests für neue Releases und Konfigurationen ein.
  • Definieren Sie den Aufwand für Ihre Teams und prüfen Sie die Kosten dafür regelmäßig.
  • Beseitigen Sie unnötige Arbeit/Workflows, bevor Sie eine benutzerdefinierte Automatisierung entwickeln.
  • Nutzen Sie die vorhandene Automatisierung, die bereits über Google Cloud-Dienste verfügbar ist. Passen Sie dazu die Standardkonfiguration an oder erstellen Sie eine neue, wenn keine Standardkonfiguration vorhanden ist.
  • Prüfen Sie, ob Sie eine benutzerdefinierte Automatisierung erstellen (oder kaufen) sollten, wenn sich die Wartungskosten und die Risiken für die Zuverlässigkeit und Sicherheit des Dienstes in einem sich lohnenden Rahmen bewegen. Wir empfehlen auch, eine gut verwaltete Open-Source-Software zu testen.

Effiziente Benachrichtigungssysteme erstellen

Benachrichtigungsverzögerung optimieren

Stellen Sie die konfigurierte Verzögerung ein, bevor das Monitoringsystem Personen über ein Problem benachrichtigt. Dadurch minimieren Sie die TTD und maximieren gleichzeitig das Signal-zu-Rausch-Verhältnis. Verwenden Sie die Fehlerbudget-Verbrauchsrate, um die optimale Benachrichtigungskonfiguration zu ermitteln.

Benachrichtigung bei Symptomen, nicht Ursachen

Lösen Sie Benachrichtigungen anhand der direkten Auswirkungen auf die Nutzererfahrung aus, d. h. die Nichteinhaltung globaler SLOs oder SLOs pro Kunde. Senden Sie Benachrichtigungen nicht bei jeder möglichen Fehlerursache, insbesondere wenn die Auswirkungen auf ein einzelnes Replikat beschränkt sind. Ein gut durchdachtes verteiltes System wird nahtlos wiederhergestellt, wenn ein einzelnes Replikat ausfällt.

Gemeinsamen Prozess für Vorfallmanagement aufbauen

Es ist unvermeidlich, dass Ihr gut durchdachtes System die SLOs irgendwann nicht erfüllt. Denken Sie daran, dass Ihre Kunden auch ohne SLO das akzeptable Service-Level auf Grundlage ihrer bisherigen Erfahrung frei definieren und an Ihren technischen Support oder eine ähnliche Gruppe eskalieren werden, unabhängig davon, was in Ihrem SLA steht.

Damit Ihre Kunden ordnungsgemäß versorgt werden können, empfehlen wir Ihnen dringend, einen Plan zum Vorfallmanagement zu erstellen und regelmäßig zu implementieren. Der Plan kann eine einseitige Checkliste mit etwa zehn Elementen sein. Dieser Prozess hilft Ihrem Team dabei, die mittlere Diagnosezeit (Mean Time to Detect – MTTD) und die mittlere Zeit zur Problemminderung (Mean Time to Mitigate – MTTM) zu reduzieren. Wir verwenden die Abkürzung MTTM im Gegensatz zu MTTR, da letztere nicht eindeutig ist. Das R bezeichnet oft "Repair" (also Reparatur) oder "Recovery" (Wiederherstellung) und weist auf eine vollständige Korrektur statt auf eine Problemminderung hin. Bei MTTM hingegen ist das Gegenteil der Fall und es wird explizit auf eine Problemminderung statt auf eine vollständige Korrektur hingewiesen.

Ein gut durchdachtes System mit ebenso durchdachten Abläufen erhöht die mittlere Zeit zwischen Fehlern (Mean Time Between Failures – MTBF). Weitere Informationen finden Sie in den Abschnitten zum Systemdesign und zur operativen Exzellenz.

Außerdem sollten Sie auf Blameless-Postmortem-Analysen und einen Überprüfungsprozess für Vorfälle setzen. "Blameless" bedeutet, dass Ihr Team den Fehler auf objektive Weise bewerten und dokumentieren muss, ohne mit dem Finger auf den potenziellen Schuldigen zu zeigen. Fehler werden als Lernmöglichkeiten behandelt, nicht als Grund zur kritischen Auseinandersetzung. Versuchen Sie immer, das System stabiler zu machen, damit es sich schnell von menschlichen Fehlern erholen kann, oder noch besser, damit es menschliche Fehler erkennen und verhindern kann.

Mittlere Diagnosezeit reduzieren

Eine Voraussetzung für die Reduzierung der MTTD ist, dass Sie die Empfehlungen im Abschnitt "Beobachtbarkeit" und "Monitoringziele definieren" umsetzen, z. B. die Unterscheidung zwischen Anwendungsproblemen und zugrunde liegenden Cloud-Zielen.

Mit gut abgestimmten SLIs wird Ihr Team zur richtigen Zeit benachrichtigt, ohne dass es zu einer Überlastung mit Benachrichtigungen kommt. Weitere Informationen finden Sie unter Tune up your SLI metrics: CRE life lessons.

Mittlere Zeit zur Problemminderung reduzieren

Wenn Sie die MTTM reduzieren möchten, sollten Sie einen angemessen dokumentierten und gut erprobten Vorfallmanagementplan haben. Außerdem sollten Sie jederzeit über Änderungen informiert sein.

Beispiel für einen Vorfallmanagementplan

  • Produktionsprobleme wurden erkannt (Benachrichtigung, Seite) oder an mich eskaliert.
  • Sollte ich überhaupt delegieren? Ja, wenn Sie und Ihr Team das Problem nicht lösen können.
  • Handelt es sich um einen Datenschutz- oder Sicherheitsverstoß? Wenn ja, delegieren Sie diesen an das Datenschutz-/Sicherheitsteam.
  • Handelt es sich um einen Notfall oder sind SLOs gefährdet? Im Zweifelsfall sollten Sie den Vorfall als Notfall behandeln.
  • Sollte ich weitere Personen einbeziehen? Ja, wenn mehr als X % der Kunden betroffen sind oder die Behebung mehr als Y Minuten dauert. Im Zweifelsfall sollten Sie immer mehr Personen einbeziehen, insbesondere während der Geschäftszeiten.
    • Definieren Sie einen primären Kommunikationskanal, z. B. IRC, Hangouts Chat oder Slack.
    • Delegieren Sie zuvor definierte Rollen, zum Beispiel:
      • Incident Commander: verantwortlich für die Gesamtkoordinierung
      • Communications Lead: verantwortlich für die interne und externe Kommunikation
      • Operations Lead: verantwortlich für die Minderung des Problems
    • Definieren Sie, wann der Vorfall als beendet gilt. Dafür ist möglicherweise eine Bestätigung durch einen Supportmitarbeiter erforderlich.
  • Arbeiten Sie gemeinsam an der Postmortem-Analyse.
  • Nehmen Sie an regelmäßigen Postmortem-Besprechungen zur Überprüfung von Vorfällen teil, um Aufgaben zu besprechen und an Mitarbeiter zu verteilen.

Grafiken

Im Folgenden finden Sie eine nicht vollständige Liste von Grafiken, die es zu beachten gilt. Das Vorfallmanagementteam sollte sie in einer einzigen Ansicht parat haben und ansehen können.

  • Service Level Indicator(s), z. B. erfolgreiche Anfragen geteilt durch die Gesamtzahl
  • Konfiguration und/oder binäre Rollouts
  • Anfragen pro Sekunde an das System
  • Vom System zurückgegebene Fehler pro Sekunde
  • Anfragen pro Sekunde vom System an seine Abhängigkeiten
  • Fehler pro Sekunde vom System an seine Abhängigkeiten

Außerdem sehen wir häufig, dass auch die Größe von Anfragen und Antworten, Abfragekosten, Threadpools (um nach einer durch Poolauslastung bedingten Regression zu suchen) und JVM-Messwerte als Grafik dargestellt werden (falls zutreffend).

Testen Sie einige Szenarien in Bezug auf die Platzierung dieser Grafiken. Sie können auch maschinelles Lernen anwenden, um die richtige Teilmenge dieser Grafiken anzuzeigen (also Techniken zur Anomalieerkennung einsetzen).

Ein weiterer häufiger Ansatz für die schnelle Problemminderung besteht darin, Systeme und Änderungen zu entwerfen, die leicht rückgängig gemacht werden können.

Empfehlungen

  • Stellen Sie Ihre Teams zusammen und schulen Sie sie zum Vorfallmanagementplan.
  • Implementieren Sie Empfehlungen aus dem Abschnitt "Beobachtbarkeit", um die MTTD zu reduzieren.
  • Erstellen Sie ein Dashboard mit Änderungen, das Sie sich bei Vorfällen ansehen können.
  • Dokumentieren Sie Abfrage-Snippets oder erstellen Sie ein Data Studio-Dashboard.
  • Prüfen Sie, ob Firebase Remote Config das Richtige für Sie ist, um Rollout-Probleme im Zusammenhang mit mobilen Anwendungen zu minimieren
  • Implementieren Sie Empfehlungen zur "Notfallwiederherstellung", um die MTTM für einen Teil Ihrer Vorfälle zu reduzieren.
  • Entwerfen und testen Sie Konfigurationen und binäre Rollbacks.
  • Implementieren Sie die Empfehlungen in den Abschnitten "Systemdesign" und "Notfallwiederherstellung" (Tests), um die MTBF zu erhöhen.

Ressourcen