Produktionsvorbereitung für die Hauptnutzungszeiten

Dieser Artikel unterstützt Projektmanager und technische Führungskräfte bei der Erstellung von Ausführungsplänen für Zeiträume, bei denen außergewöhnlich hohe Zugriffszahlen zu erwarten sind. In den USA kann beispielsweise der letzte Freitag im November, der sogenannte Black Friday, zu den Tagen des Jahres mit der höchsten Einkaufsaktivität gehören. In vielen anderen Ländern gibt es ebenfalls gewisse Tage oder Wochen, an bzw. in denen Einzelhändler mit extrem hohen Zugriffszahlen rechnen können. In diesem Artikel wird unter anderem beschrieben, in welchen Bereichen der Bereitschaftsgrad der Organisation, die Systemzuverlässigkeit und die Einbindung von Google-Kunden für den Black Friday und ähnliche Ereignisse verbessert werden können.

In diesem Artikel wird ein System beschrieben, das

  • Drei wichtige Phasen eines Ereignisses verwaltet: Planung, Vorbereitung und Ausführung
  • Technisches und operatives Personal sowie Führungskräfte in Verbesserungsprozesse einbindet und die Zusammenarbeit ermöglicht
  • Ein spezielles Architekturgrundgerüst bereitstellt, um Black-Friday-ähnliche Ereignisse durchzuführen
  • die Verwendung der Best Practices von Google Site Reliability Engineering (SRE) fördert

Einführung

Handelssysteme im Einzelhandel stehen vor einer enormen technischen Herausforderung: Wie lassen sich kurzfristige Lastspitzen verarbeiten, die bis zu fünfmal höher liegen als der Durchschnitt? In den USA kommt es zum Beispiel während Thanksgiving, Black Friday und Cyber Monday zu solchen Spitzenwerten. Und auch in anderen Ländern finden zu verschiedenen Zeitpunkten des Jahres ähnliche Ereignisse statt.

Eine Lösung besteht darin, ein cloudnatives System zu verwenden. Im Vergleich zu einer herkömmlichen Implementierung lassen sich mit dieser Strategie die Planung und das Handling von Spitzenlastzeiten verbessern. Außerdem eröffnen sich ganz neue Möglichkeiten.

Der Black Friday gehört in den USA zu den wichtigsten Verkaufstagen. Dabei weist er Züge auf, die auch in anderen Zusammenhängen vorzufinden sind. Beispiele sind Wahlabende oder Feiertage wie Weihnachten und Silvester. Solche Spitzenereignisse zeichnen sich im Allgemeinen durch folgende Merkmale aus:

  • Zwischen 5- bis 20-mal oder noch höhere Zugriffszahlen, außerdem höhere Conversion-Raten und eine stärkere Belastung von Back-End-Systemen.
  • Starke Skalierung in kurzer Zeit, sobald das Ereignis beginnt und die Zugriffszahlen hochschnellen.
  • Nach dem Ereignis sinken die Zugriffszahlen leicht verzögert wieder auf die Normalwerte ab. Die Abnahme verläuft in der Regel langsamer als der Anstieg auf den Spitzenwert.

In Handelssystemen, wo ein Großteil der Zugriffe Transaktionen sind, verläuft der Front-End-Anstieg möglicherweise nicht so drastisch. Während die Zugriffszahlen am Front-End vielleicht um das 2- bis 4-Fache steigen, kann die Belastung der Back-End-Systeme gemessen in Bestellungen/Minute um das 10-Fache oder mehr anwachsen.

Die folgende Abbildung zeigt einen typischen Verlauf bei der Zunahme der Nutzerzugriffszahlen. Deutlich erkennbar ist der plötzliche Anstieg, gefolgt von einer allmählichen Rückkehr zu den Normalwerten.

Zugriffsspitze bei Black-Friday-Ereignis

Für ein Black-Friday-Ereignis empfehlen wir, die Organisation des Projekts in folgende drei Phasen einzuteilen: Planung, Vorbereitung und Ausführung. Wie die nachfolgende Abbildung zeigt, ist jede Phase durch verschiedene Rollen, Fähigkeiten und Prozesse gekennzeichnet.

3 Stufen der Black-Friday-Bereitschaft

Für die taktischen Elemente des Spitzenereignisses sind die im Betrieb und der Verwaltung tätigen Mitarbeiter zuständig. Alle Beteiligten orientieren sich an den drei Phasen und den zugehörigen Aktivitäten, um das Team auf das Spitzenereignis vorzubereiten. Falls während des Ereignisses unerwartet Probleme auftreten, erleichtern diese Vorbereitungen die schnelle Fehlersuche und Problembehebung.

Terminologie

Black Friday
Jede Art von Ereignis, bei dem für eine Anwendung besonders hohe Zugriffszahlen erwartet werden.
QPS
Abfragen pro Sekunde (Queries per Second) sind ein häufig zur Messung von Zugriffszahlen verwendeter Wert. Im Vergleich zu Bestellungen/Minute ist QPS ein allgemeiner technischer Mengenbegriff.
Bestellungen/Minute
Ein Indikator für die Anzahl der Transaktionen. Der Begriff schließt auch andere Indikatoren ein, wie zum Beispiel "Neue Einkaufswagenpositionen/Sekunde". Diese Indikatoren zeigen das Transaktionsvolumen im Vergleich zu den Abfragen pro Sekunde in geschäftlich relevanteren Begriffen an.
SLI
Mit dem "Service Level Indicator" oder "Dienststufenindikator" lässt sich ermitteln, ob ein Dienst innerhalb akzeptabler Grenzen funktioniert. Ein SLI für die Seitenladezeit könnte zum Beispiel das Laden einer Webseite und aller zugrunde liegenden API-Aufrufe innerhalb des 95. Perzentils sein.
SLO
Ein "Service Level Objective" oder "Dienststufenziel" wird mit einem SLI und einem Zielwert definiert. Ein SLO könnte zum Beispiel besagen, dass die vorherige SLI-Latenz unter 400 ms liegen muss.
SLA
Service Level Agreement Zuverlässigkeitsziele, Bedingungen und (oft finanzielle) Konsequenzen für einen Dienst, die im Vertrag zwischen einem Kunden und einem Lieferanten definiert sind. SLA-Beispiel: Wenn die SLI-Latenz 10 aufeinanderfolgende Minuten lang über 1 Sekunde bleibt, hat der Kunde Anspruch auf einen Rabatt von 50 % auf die in Rechnung gestellte Nutzung von Traffic über 100 Abfragen pro Sekunde innerhalb der Stunde, in der der SLA-Verstoß aufgetreten ist.

Planungsphase

Die Redewendung "Hoffnung ist keine Strategie" wird oft als starker Grund für sorgfältige Planung und Vorbereitung angeführt. Eine funktionsübergreifende Planung und Koordination innerhalb der Organisation und mit Drittanbietern erhöht die Erfolgswahrscheinlichkeit. Technik-, Architektur-, Betriebs- und Businessteams müssen sich darüber einig sein, was gemessen wird, und sie müssen wissen, welche Auswirkungen das Spitzenereignis auf die Produktionssysteme haben wird. Was die Planung und die Unterstützung von operativen Systemen angeht, treffen diese Teams datengestützte Entscheidungen darüber, welcher Weg eingeschlagen bzw. welche Kompromisse eingegangen werden.

In der folgenden Tabelle sind die wichtigsten Schritte der Planungsphase zusammengefasst.

Planungsschritt Google Tasks
Datenerfassung Messdaten definieren.
Frühere Spitzenereignisse analysieren.
Geschäftsprognosen vorbereiten.
Programmmanagement etablieren Kommunikationskanäle einrichten.
Teams koordinieren.
Monitoring und Tests einrichten.
Systemmonitoring prüfen.
Kapazitätspläne erstellen.
Checklisten erstellen.
Risikoanalyse teilen und Prioritäten setzen.
Architektur planen Architektur prüfen.
Architekturmuster für den Black Friday prüfen.
Failover-Strategie planen.

Datenerfassung

Der erste Schritt in der Planungsphase ist die Datenerfassung.

Messdaten definieren

Vorhandene Messdaten (Anfragen/Sekunde, Bestellungen/Minute, neue Einkaufswagenpositionen/Sekunde) sind eine gute Grundlage für die Planung eines Spitzenereignisses. Sie stoßen diesen Prozess mit den folgenden Fragen an:

  • Welche Daten über den Normal- bzw. Spitzenbetrieb stehen zur Verfügung?
  • Werden die richtigen System- und Geschäftsmesswerte erfasst?
  • Welche Daten müssen erfasst werden, um die Funktionsweise des Systems besser zu verstehen?

Ihr Ziel: Feststellen, welche Daten verfügbar sind und welche Aussagekraft sie in der Vergangenheit hatten. Wenn Sie Ideen für Messwerte oder SLIs haben, die noch nicht erfasst werden, sollten Sie sich darauf konzentrieren, Ihr System in der Vorbereitungsphase so anzupassen, dass diese Daten erfasst werden.

Das bloße Erfassen von Daten reicht aber nicht aus. Sie müssen auch wissen, welche Erkenntnisse die Daten liefern. Wenn bekannt ist, wie die Messwerte mit den Zufriedenheits- und Erfolgsindikatoren zusammenhängen, können Sie Prognosen darüber abgeben, wie sich ein deutlich größeres System verhalten wird.

Frühere Spitzenereignisse analysieren

Unabhängig vom Prozess ist es wichtig, von früheren Ereignissen zu lernen, vor allem wenn sich daraus ableiten lässt, wie sich das System unter Stress verhält. Im Technologiesektor verwendet man gerne Postmortems, um Daten zu erfassen und Vorfälle zu verstehen.

Geschäftsprognosen vorbereiten

Durch eine Prognose des Black-Friday-Effekts kann Ihr Unternehmen Lagerbestände vorausplanen und Angebote vorbereiten. Bestandsverwaltung, Lieferkettenmanagement und Personalbesetzung hängen von genauen Geschäftsprognosen ab. Genauso wie die Vorbereitung Ihres Systems auf das zu erwartende hohe Zugriffsaufkommen. Je mehr über frühere Prognosen bekannt ist, desto genauer werden die aktuellen Umsatzprognosen sein. Diese neuen Prognosen lassen wichtige Rückschlüsse darüber zu, welche Systemlast zu erwarten ist.

Die meisten E-Commerce-Websites erfassen Messwerte zu den folgenden Erfolgsfaktoren:

  • Anzahl der Aufrufe
  • Anzahl der Conversions
  • Durchschnittlicher Bestellwert

Auf Basis dieser Erfolgsfaktoren lassen sich die Messwerte in eine Form bringen, die das System analysieren kann. Beispiele für Messwerte:

  • QPS (Abfragen pro Sekunde)
  • Bestellungen/Minute
  • Neue Einkaufswagenpositionen/Sekunde

Die Messwerte lassen sich dann als SLIs und SLOs ausdrücken, die das Systemverhalten messen und den Systemzustand anzeigen.

Programmmanagement etablieren

Gute Koordination ist der Schlüssel zum Erfolg am Black Friday. Planung, Vorbereitung und Ausführung müssen mit den Technik-, Architektur-, Betriebs- und Managementteams, anderen internen Beteiligten und Drittanbietern abgestimmt und koordiniert werden. Gemeinsame Ziele setzen voraus, dass alle Beteiligten offen kommunizieren und zusammenarbeiten.

In einem ersten Schritt sollten funktionsübergreifende Teams und ein Lenkungsausschuss gebildet werden, dessen Aufgabe darin besteht, alle Beteiligten an einen Tisch zu bringen. Richten Sie die Teams frühzeitig ein, damit das Programmmanagement einen Zeitrahmen festlegen kann. Das Programmmanagement muss sich auch um das Budget und die Ressourcen für zusätzliche Infrastruktur, Tests und Schulungen kümmern.

Kommunikationskanäle einrichten

Gute Kommunikation ist in allen Phasen der Ausführung eines Spitzenereignisses von entscheidender Bedeutung. Nutzen Sie in der Planungsphase:

  • Ein Planungsdokument für das Spitzenereignis, das Folgendes beinhaltet:

    • Liste der Annahmen
    • Liste der Unbekannten
    • Teams, Teamleiter, Beteiligte und andere Verantwortliche. Verwenden Sie eine RACI-Matrix oder ein ähnliches Format, um Rollen und Verantwortlichkeiten festzulegen.
    • Ein klarer, unmissverständlicher Zeitplan, in dem kritische Aufgaben und zuständige Teams genau festgelegt sind.
  • Regelmäßige Besprechungen mit Notizen, um alle Teams über den Fortschritt auf dem Laufenden zu halten. Sprechen Sie Bedenken frühzeitig an und lassen Sie Probleme gemeinschaftlich durch die Teams bearbeiten, bevor sie zu unüberwindbaren Hindernissen werden. Spitzenereignisse finden normalerweise an einem bestimmten Termin statt, sodass sich Verzögerungen nur schlecht ausgleichen oder einholen lassen.

  • Zusammenfassung. Fassen Sie die wichtigsten Informationen zu dem Spitzenereignis auf ein bis zwei Seiten zusammen. So ein Dokument ist einfach zu verteilen, bietet Mitarbeitern einen guten Überblick über die Planung und beantwortet allgemeine Fragen. Neue Mitarbeiter können damit schnell auf den aktuellen Planungsstand gebracht werden.

  • Kurzübersichten zur Architektur und deren Komponenten für operative Teams. Wenn genügend Zeit ist, das gesamte System im Detail zu verstehen, sind auch ausführliche Architekturbeschreibungen mit Hunderten Elementen und Dutzenden Verbindungslinien nützlich. Im Betrieb kann ein Übersichtsdiagramm, das die Zusammenhänge zwischen den wichtigsten Komponenten darstellt, bei der Ermittlung und Behebung von Problemen hilfreich sein.

  • Referenzen und Eskalationsverfahren für das operative Team. In diesen Dokumenten wird festgelegt, wie ein Problem ermittelt, gemeldet und behandelt wird. Außerdem ist darin die Zusammenarbeit mit anderen Teams geregelt, z. B. mit Entwicklern oder dem Support einzelner Anbieter. Definieren Sie allgemeine Abläufe für das Vorfallsmanagement und erstellen Sie Vorlagen für die schnelle Bearbeitung bestimmter Vorfallskategorien.

Teams koordinieren

Bei der Teamkoordination geht es darum, die Ansichten der verschiedenen Teams einzuholen und zu einem teamübergreifenden Konsens zu kommen. Anstelle eines Tunnelblicks ergibt sich daraus eine facettenreiche Sicht auf das System. Die Teamkoordination macht auch deutlich, wie sich gemeinschaftliche Entscheidungen über die Entscheidungen von Einzelpersonen hinaus auf das System auswirken. Schon eine kleine technische Änderung an der Konfiguration kann zum Beispiel großen Einfluss auf die Erfolgsmesswerte haben.

Für die Teamkoordination berichtet ein zuständiges Team an alle anderen Teams. Wird das Google Cloud-Team eingebunden, erhalten die beteiligten Google-Teams Einblick in die Planung und können Best Practices vorschlagen, die sich aus der Zusammenarbeit mit vielen anderen Kunden ergeben haben.

Monitoring und Tests einrichten

Monitoring unterstützt Sie dabei, fundierte Entscheidungen zu treffen, um den effizienten Betrieb des Systems aufrechtzuerhalten. Sie können den Systemzustand überwachen, sich aktiv über drohende Probleme informieren lassen und erhalten Einblick in die vier goldenen Signale Ihrer Anwendungen:

  • Latenz. Die Zeit, die das System benötigt, um eine Anfrage zu beantworten.
  • Traffic. Die Systemlast, wird normalerweise in Anfragen pro Sekunde gemessen.
  • Fehler. Rate der fehlgeschlagenen Anfragen, entweder als absoluter Wert oder als Prozentsatz aller Anfragen.
  • Auslastung. Einer oder mehrere Messwerte, die über die Auslastung kritischer Systemressourcen informieren. Die Messwerte können auch aktiv darauf hinweisen, dass Ressourcen wie der Datenbankspeicher knapp werden.

Zur Ermittlung von Problemen während Spitzenereignissen ist es unerlässlich, die kritischen Werte für diese Signale zu kennen. Im Einzelnen sollte das Monitoring Folgendes abdecken:

  • Überwachen Sie wichtige Geschäftsmesswerte wie den Umsatz oder die Anzahl der Bestellungen. Diese Messwerte können auf Probleme in der allgemeinen Systemkoordination hinweisen, obwohl die Einzelkomponenten vielleicht ordnungsgemäß funktionieren. Überwachen Sie außerdem alle E-Mail-Marketingkampagnen und verfolgen Sie, wann und wie viele E-Mails gesendet werden und wann auf die Website zugegriffen wird. Ein E-Mail-Blast in letzter Sekunde kann überraschende Wirkung zeigen und unerwartet hohe Zugriffszahlen generieren oder stattdessen Nutzer auf eine Seite mit einer unzureichenden Zwischenspeicherung weiterleiten.

  • Überwachen Sie Messwerte, die symptomatisch für die Nutzerzufriedenheit sind. Erstellen Sie nur ein paar Dashboards, die einen allgemeinen Überblick über den Zustand der Dienste liefern. Untersuchen Sie dann die jeweiligen Subsysteme oder Standorte im Detail.

  • Sichern Sie sich durch ein mehrstufiges System ab. Kombinieren Sie Blackbox-Monitoring (z. B. Tests) und Whitebox-Monitoring (z. B. aus Anwendungen exportierte Messwerte). Ein Beispiel:

    • Richten Sie Tests ein, um Werte wie Latenz, Paketverlust und Durchsatz für die Netzwerkverbindungen zwischen Google Cloud und den lokalen Netzwerken (VPNs oder direkte Verbindungen) zu messen.

    • Richten Sie Blackbox-Tests ein, um die Verfügbarkeit und Latenz von Drittanbieterdiensten zu messen, von denen Sie abhängig sind. Bitten Sie die Drittanbieter außerdem um Zugriff auf deren Dashboards und Benachrichtigungen.

  • Skalierende Spitzenereignisse können aufgrund des plötzlichen Anstiegs bei den Zugriffszahlen einem DDoS-Angriff (Distributed Denial of Service) auf das System ähneln. Finden Sie heraus, wie Sie die DDoS-Abwehrmaßnahmen so anpassen können, dass legitime Kunden, die Ihr Handelssystem nutzen möchten, nicht blockiert werden.

  • Webbots durchsuchen Websites nach Inhalten und Preisen. Sie sind aufgrund der aggressiven Konkurrenz in der Hochsaison besonders aktiv. Analysieren Sie den Prozentsatz (und die Art) der Botzugriffe im Vergleich zu echten Zugriffen. Ermitteln Sie, wie sich der Wert während eines Spitzenereignisses ändert und wie Sie das System vor unerwünschten Zugriffen schützen können.

Systemmonitoring überprüfen

Wie im Abschnitt zur Terminologie erwähnt, werden SLIs zum Messen von SLOs verwendet. Verwenden Sie Monitoring, um SLIs und andere wichtige Systemwerte zu erfassen. Damit bestimmen Sie:

  • Welche Systemmesswerte durch Monitoring erfasst werden
  • Die Latenz bei der Monitoring-Berichterstellung
  • Welche Benachrichtigungsschwellenwerte für Sie interessant sind

Idealerweise soll das Monitoring über alle relevanten Infrastruktur- und Anwendungsmesswerte Informationen erfassen, die zur Bewertung von Leistung und SLOs wichtig sind.

Sie können Monitoring in vielen Bereichen einsetzen:

  • Infrastrukturmesswerte:

    • VM-Statistiken – Instanzen, CPU, Arbeitsspeicher, Auslastung im Vergleich zur Anzahl.
    • Containerbasierte Statistiken – Clusterauslastung, Clusterkapazität, Pod-Level-Nutzung und jeweilige Anzahlen.
    • Netzwerkstatistiken – eingehender/ausgehender Traffic, Bandbreite zwischen Komponenten, Latenz im Vergleich zum Durchsatz.
  • Anwendungsmesswerte: Anwendungsspezifisches Verhalten wie QPS, Schreibvorgänge/Sekunde und gesendete Nachrichten/Sekunde.

  • Statistiken zu verwalteten Diensten: QPS, Durchsatz, Latenz, Auslastung usw. für von Google verwaltete Dienste wie APIs oder Produkte wie BigQuery, App Engine und Cloud Bigtable.

  • Verbindungsstatistiken: Statistiken zu VPN-/Interconnect-Verbindungen zu lokalen Systemen oder Systemen, die sich außerhalb von Google Cloud befinden.

  • SLIs: Messwerte, die etwas über den Gesamtzustand des Systems aussagen. Im Allgemeinen sind sie breiter gefasst als einzelne Infrastrukturkomponenten und werden zum Beispiel als API-QPS-Rate, Bestellungen/Minute oder neue Einkaufswagenpositionen/Sekunde wiedergegeben.

  • Berücksichtigen Sie die Antwortzeit und den Schwellenwert von Benachrichtigungen: Eine Benachrichtigung, die bei einem 10-prozentigen Absinken der Bestellzahlen ausgegeben wird, meldet ein Problem möglicherweise erst nach mehreren Minuten. Schneller werden Sie auf das Problem hingewiesen, wenn Sie eine Benachrichtigung für "1 Sekunde ohne Bestellungen" definieren.

Lassen Sie sich die SLO-Auswahl von allen Beteiligten bestätigen. Am Ende sollten Sie einen einzigen Satz von Kernmesswerten haben, die den Gesamtzustand des Systems abbilden. Danach können Sie festlegen, welche Daten zur Konfiguration von Benachrichtigungen über anormales Systemverhalten erforderlich sind.

Kapazitätspläne erstellen

Die Kapazitätsplanung spielt für Einzelhandelssysteme eine wichtige Rolle. Cloudnative Systeme weisen mit ihrer dynamischen Kapazitätszuteilung architektonische und technische Vorteile gegenüber herkömmlichen Systemen auf. Eine durchschnittliche Last wird bei cloudnativen Systemen auf Tausende von Rechenkernen verteilt. Große Spitzenlasten beziehen vielleicht mehrere Zehntausend Kerne ein. Die Verantwortung für die Kapazitätsplanung liegt beim Cloudanbieter und dem Cloudinfrastrukturteam, während das operative Team die Kapazität unter Beachtung von Konfidenzintervallen planen muss. Die Intervalle sind dazu da, unerwartete Vorfälle zu vermeiden, z. B. das Unvermögen, mit zusätzlichen VMs weiter zu skalieren.

Systeme mit dynamischer Kapazitätsanpassung funktionieren gut für begrenzte und sporadische Kapazitätsspitzen. Wir empfehlen jedoch, bestehende Kapazitätspläne zu überprüfen und die erforderliche Kapazität vorab zu bestimmen, anstatt sich auf eine automatische Skalierung und Just-in-Time-Bereitstellung zu verlassen. Denken Sie darüber nach, wie Sie und Ihr Cloudanbieter Prescaling, Reservierungen und andere Funktionen nutzen können, um die Systemverfügbarkeit zu verbessern. Sie können die Infrastruktur kurz vor dem Spitzenereignis bereitstellen und gleich darauf wieder herunterfahren, um unnötige Cloudkosten zu vermeiden.

Um die Kapazitätsplanung zu verbessern, haben Google und seine Kunden die folgenden Best Practices entwickelt:

  • Stimmen Sie die Messwerte auf die maximal zu erwartenden Zugriffszahlen ab. Erstellen Sie Pläne, um zu beurteilen, ob Ihre Schätzungen falsch waren. Pläne verringern die Unsicherheit und erlauben schnelle Anpassungen, wenn die Schätzungen überschritten werden.
  • Bestimmen Sie den für die Spitzenauslastung + Konfidenzintervall nötigen Kapazitätsbedarf.
  • Überprüfen und bestätigen Sie den Kapazitätsbedarf gemeinsam mit dem Cloudanbieter und dem Infrastrukturteam.
  • Denken Sie daran, dass Kontingent nicht gleich Kapazität ist. Ein Kontingent bietet die Möglichkeit, eine Ressource zu haben, während die Kapazität angibt, wie viel von dieser Ressource benötigt wird.
  • Evaluieren Sie das Kontingent und die Kapazität für jede verfügbare Ressource: CPU, Arbeitsspeicher, Speicher, Netzwerk, APIs usw. Bei Lasttests können Sie diese Evaluierungen nutzen, um bislang unbekannte Probleme mit Kontingenten und der Kapazität aufzudecken.
  • Legen Sie Kontingente und Kapazitäten so fest, dass ein Ausfall der gesamten Region abgefangen werden kann.
  • Evaluieren Sie Kontingente und Kapazitäten während der Planungsphase und passen Sie beides in der Vorbereitungsphase an.

Checklisten erstellen

Ereignisse wie der Black Friday wiederholen sich. Es gibt immer einen Black Friday im nächsten Jahr, eine weitere Werbekampagne oder eine wichtige Produkteinführung. Jedes Ereignis liefert individuelle Informationen, die Assets aber sind wiederverwendbar und erweiterbar. Mit jedem nachfolgenden Ereignis können Sie den Ablauf optimieren, indem Sie Checklisten erstellen, pflegen und verbessern, um den Verwaltungsaufwand zu verringern. Checklisten werden auch von Piloten im Flugzeug verwendet: Sie helfen, Fehler zu vermeiden, und sorgen für immer gleiche Abläufe.

Wir empfehlen die folgenden Best Practices für Checklisten:

Risikoanalyse teilen und Prioritäten setzen

Informieren Sie alle Beteiligten über die Risikoanalyse und setzen Sie Prioritäten. Die Analyse zeigt die Risiken durch das System, die internen Teams, den Cloudanbieter und die Drittanbieter auf. Informieren Sie auch die Cloudanbieter und die Drittanbieter über diese Risiken. Einige Risiken sind möglicherweise bekannt und akzeptabel. In anderen Fällen müssen der Cloudanbieter oder die Drittanbieter Abhilfemaßnahmen einplanen.

Architektur planen

Die Architekturplanung für den Black Friday ist ein ganz eigener Aufgabenkomplex mit speziellen Best Practices. Ein Spitzenereignis ist immer mit Einschränkungen verbunden, die sich auf die Risikoanalyse auswirken und in Belastungstests einfließen müssen.

Architektur überprüfen

Bilden Sie die zugrunde liegende Architektur allgemein für alle Projektbeteiligten ab. Anhand der Übersicht können die Teams entscheiden, welche Architekturelemente möglicherweise die Zuverlässigkeit gefährden, z. B. Single Points of Failure (SPOF), und ob sie Alpha- oder Betakomponenten von Google verwenden möchten. Wahrscheinlich können nicht alle Probleme beseitigt werden, aber zumindest wissen alle Teams darüber Bescheid.

Ein Produktionssystem lässt sich in zwei Architekturebenen splitten, die jeweils eine bestimmte Zielgruppe ansprechen:

  • Durch die Systemarchitektur erhält das operative Team einen Einblick in die wirklich kritischen Systemkomponenten. Ein Übersichtsdiagramm, in dem die Zusammenhänge zwischen den Hauptkomponenten abgebildet sind, vereinfacht die Eingrenzung und Behebung von Problemen.

  • Die Komponentenarchitektur stellt für Architekten und Entwickler wichtige E/A-Punkte, Abhängigkeiten und primäre Workflows durch die Komponenten dar. Die Komponenten beschreiben komplexe Nutzerwege durch das Angebot. Anhand der Architektur lassen sich Problemursachen innerhalb von Komponenten und Datenströmen, wie Inventar, Preisgestaltung, Masterproduktdaten, Bestellungen und Rechnungen, einfacher ermitteln. Informationen über Datenströme werden auch für Entscheidungen über SLOs, Monitoring und Tests benötigt.

Architekturmuster für den Black Friday überprüfen

Architekturmuster unterstützen Sie bei der Optimierung cloudnativer Systeme und erleichtern den Umgang mit einigen für cloudverteilte Systeme typischen Herausforderungen. Die folgenden Best Practices verbessern die Zuverlässigkeit von Cloudsystemen während Spitzenereignissen:

  • Verwenden Sie Cachesysteme, von denen Sie wissen, wie sie skalieren. Cachesysteme weisen während einer Skalierung eine andere Cache-Trefferquote auf. Dadurch können sich nachgelagerte Probleme ergeben. Cache-Fehler führen während der Skalierung zu einer erhöhten Belastung und können das System schneller als erwartet überfordern.

  • Verwenden Sie ein Content Delivery Network (CDN) wie beispielsweise Cloud CDN, um einen plötzlichen starken Anstieg bei den Zugriffszahlen abzufangen und die Zuverlässigkeit und Verfügbarkeit zu verbessern. CDNs können Spitzenlasten absorbieren, bevor der Traffic Ihre Ursprungsserver erreicht.

  • Verwenden Sie Cloud-Interconnect-Instanzen mit internetbasierten VPNs in einer Aktiv-Aktiv-Konfiguration. Bei einer Aktiv-Aktiv-Konfiguration wird Traffic sowohl über den primären als auch den sekundären Verbindungsweg abgewickelt. Bei einer Aktiv-Passiv-Konfiguration hingegen kommt der sekundäre Server nur bei einem Ausfall des primären Servers zum Einsatz. Interconnects ermöglichen die Aufrechterhaltung einer dedizierten Bandbreite zwischen Cloudanbieter und Rechenzentrum. Eine gute Strategie besteht darin, in den einzelnen Metroregionen mehrere Interconnects von unterschiedlichen Anbietern zu nutzen. Dies unterstützt die Einhaltung des SLA und verbessert die Zuverlässigkeit, wie im Artikel 99,99 % Verfügbarkeit für Dedicated Interconnect einrichten beschrieben. Die VPNs werden verwendet, wenn ein Interconnect ausfällt oder kurzfristig mehr Kapazität benötigt wird.

Failover-Strategie planen

Bei wichtigen Ereignissen wie dem Black Friday ist mit Ausfällen und Problemen auf Nutzerseite zu rechnen, weshalb die Teams gut vorbereitet sein sollten. Eine Failover-Strategie sorgt dafür, dass das System verfügbar bleibt, während die Teams sich daran machen, die Problemursache zu ermitteln. Fehler und Probleme kommen immer vor. Deshalb ist es wichtig, Risiken und SLOs zu kennen, um Zuverlässigkeitsbedarf und Kosten gegeneinander abzuwägen.

Cloudsysteme verwenden die folgenden Failover-Muster:

  • Regionale Fehler behandeln. Entwickeln Sie Muster, die dafür sorgen, dass persistente Daten zwischen Regionen synchronisiert werden und ein regionaler Ausfall behoben werden kann. Zustandslose Anwendungsserver sind weitaus einfacher zu handhaben als eine Datensynchronisierung. Nutzen Sie verwaltete Dienste, um die Zuverlässigkeit zu erhöhen und den Verwaltungsaufwand zu verringern. Synchronisierungsmuster sind von den Funktionen der Datenplattform abhängig. Interessante Artikel dazu:

  • Das System an mehreren Standorten bereitstellen. Stellen Sie das System in mindestens zwei – besser drei – Regionen bereit, um etwaige Probleme in einer Zone, einer Region oder bei einem Cloudanbieter abzufedern.

    • Richten Sie in jeder Region mehrere Zonen für ein regionales Failover bzw. Ausfallsicherheit ein, damit der Betrieb auch ohne ein vollständiges Failover für die gesamte Region fortgeführt werden kann. Dadurch verringern Sie außerdem die Latenz für die Kunden und können regionale Ausfälle ausgleichen.

    • Verwenden Sie einen für Ihr Szenario geeigneten Load-Balancer. Google Cloud verfügt über verschiedene Load-Balancer, die eine Vielzahl von Funktionen bieten. Weitere Informationen finden Sie in der Dokumentation zu Cloud Load Balancing.

  • Sorgen Sie dafür, dass das System auch ohne Cache einen starken Anstieg der Zugriffszahlen verkraftet. Testen Sie das System vorab für den Fall, dass das Caching-System ausfällt oder die Cache-Trefferrate zu gering ist. Ein Cache-Systemfehler oder ein Cache-Flush kann weitere Probleme nach sich ziehen. Komponenten können überlastet werden und ausfallen.

  • Planen Sie CDN-Fehler ein. Diese Fehler ähneln in ihrer Auswirkung Cache-Systemfehlern. Fragen Sie Ihren CDN-Anbieter, wie mit CDN-Systemausfällen umgegangen wird, die während des Black Friday zu einem unerwarteten Lastanstieg führen können.

  • Automatisieren Sie alle Failover-Szenarien. Vermeiden Sie manuelle Schritte. Sie sind zeitaufwendig und fehleranfällig, insbesondere wenn Sie einen Ausfall schnell beheben müssen und sowieso schon unter Stress stehen.

  • Sorgen Sie bei abhängigen externen Diensten für Ausfallssicherheit. Bauen Sie Ausfallsicherheitsmuster als eine Art "Trennschalter" ein, damit der Ausfall eines einzelnen Dienstes nicht eine ganze Fehlerkette nach sich zieht.

  • Begrenzen Sie die Latenz für Drittanbieterprodukte. Passen Sie den clientseitigen Code Ihrer Website so an, dass HTTP-Aufrufe von Drittanbieter-Webdiensten nur begrenzt oder gar nicht blockiert werden. Latenz- oder Verfügbarkeitsprobleme mit dem Drittanbieterprodukt können dazu führen, dass Ihre Website auf Nutzerseite nicht reagiert.

  • Schützen Sie sich gegen Netzwerkangriffe. Schützen Sie Ihre Website vor DDoS-Angriffen und Webbots. Verwenden Sie Websicherheitstools wie Cloud Armor und die Sicherheitsplattform Ihres CDN.

Ergebnisse aus der Planungsphase

Aus der Planungsphase fließen die folgenden Ergebnisse in die Vorbereitungs- und Ausführungsphase ein:

  • Risikoanalyse: Geht auf die Eintrittswahrscheinlichkeit und die Auswirkungen bestimmter Projektrisiken ein, unter anderem bezüglich Betrieb, Technik, Business und Zeit.
  • Architekturänderungsplan: Enthält Verbesserungsvorschläge für das System, um den Betrieb unter erhöhter Last zu optimieren.
  • Testplan: Bewertet den Systembetrieb bei unerwartet hohem Traffic und deckt typische Fehlertestszenarien ab.
  • Kommunikationsplan: Dient dazu, alle Beteiligten auf dem Laufenden zu halten. Darin enthalten ist auch ein Eskalationsplan für die Kommunikation und für Fälle, in denen schnell Entscheidungen getroffen werden müssen.
  • SLO/SLI-Vereinbarung: Beschreibt die vereinbarten Monitoring-Messwerte und die zu erfassenden SLIs. Enthält auch Vereinbarungen zu SLOs, welche die Systemverfügbarkeit aus Kundensicht abbilden. Die Vereinbarung umfasst Pläne zur Implementierung von Messdaten, die aktuell noch nicht erfasst werden, sowie ein Monitoring-Dashboard, um die Einhaltung von SLOs zu überwachen. In der Vereinbarung wird auch beschrieben, wie sich die SLAs von Drittanbietern auf Ihre SLO-Messwerte auswirken.
  • Übersicht der Checklisten: Die Checklisten sorgen für eine einheitliche Überprüfung und Durchführung vereinbarter Verfahren.
  • Playbook-Übersicht: Eine Liste der Playbooks, in denen die Reaktion auf Vorfälle am Black Friday beschrieben ist. Playbooks erleichtern den Teams die schnelle Wiederherstellung des Normalbetriebs.

Vorbereitungsphase

In der Vorbereitungsphase wird getestet, ob das System auf die erwarteten Nutzerzahlen skalieren kann. Die Ergebnisse der Tests werden dokumentiert. Die Ergebnisse werden zur weiteren Optimierung der Architektur verwendet. Ziel ist es, Spitzenlasten effizienter zu verarbeiten und die Zuverlässigkeit des Systems zu erhöhen. Aus dieser Phase ergeben sich auch Abläufe für den Betrieb und den Support, die bei der Bewältigung der zu erwartenden Spitzenlast und möglicher Probleme helfen. Betrachten Sie diese Phase als eine Art Übung für das Spitzenereignis aus System- und Betriebsperspektive.

In der folgenden Tabelle sind die wichtigsten Schritte der Vorbereitungsphase zusammengefasst.

Vorbereitungsschritt Google Tasks
Zuverlässigkeit verbessern Last- und Leistungstests einrichten.
Szenarien bewerten und testen.
Architektur für Skalierbarkeit und Zuverlässigkeit optimieren Warteschlangen- und Nachrichtenvermittlungsschicht implementieren.
Caching implementieren, um die Leistung zu verbessern.
Entlastungsfunktion (Load Shedding) implementieren.
Trennschaltermuster implementieren.
Monitoring und Logging einrichten Monitoring konfigurieren.
Monitoring-Informationen über ein Dashboard bereitstellen.
Betriebsabläufe und Support anhand von Feedback überarbeiten Checklisten und Playbooks erstellen.
Schulungen zu Support- und Eskalationsverfahren.
Gute Arbeitsbedingungen für das operative Team schaffen.
Kapazitätsanfragen koordinieren Den erwarteten Ressourcenbedarf abschätzen und Google Cloud mitteilen.
Änderungsstopp festlegen Vor dem Ereignis Zeit für die Bereitstellung neuer Software und Infrastruktur einplanen.
Keine Änderungen vornehmen, während das Ereignis beworben wird.
Mit dem Entwicklerteam die Durchführung von Fehlerkorrekturen koordinieren.

Zuverlässigkeit verbessern

Google Site Reliability Engineers sind darauf spezialisiert, die Zuverlässigkeit und Reaktionsfähigkeit von Google-Diensten zu optimieren. SREs kümmern sich um die Plattformintegrität und sorgen dafür, dass Google-Dienste mit höchster Zuverlässigkeit funktionieren. Viele Best Practices und Ratschläge rund um die Erstellung, Implementierung und den Betrieb von skalierbaren Systemen hat ein Team von Google SREs in zwei Büchern veröffentlicht. Viele der darin beschriebenen Verfahren treffen auch auf ein Black-Friday-Ereignis zu, wobei zwei Aspekte besonders wichtig sind: Lasttests und Fehlertests.

Last- und Leistungstests einrichten

Bei einem Lasttest wird eine Testversion des Systems einer hohen Anzahl von Anfragen ausgesetzt, um die zu erwartende Belastung während des Ereignisses zu simulieren. Lasttests konzentrieren sich normalerweise darauf, das vom Nutzer wahrgenommene Verhalten bei einem bestimmten Perzentil unterhalb des absoluten Spitzenwerts zu beurteilen. Der Lasttest gilt als bestanden, wenn bei diesem obersten Perzentil eine konstant gute Leistung zu beobachten ist.

Die folgenden Best Practices haben sich für Last- und Leistungstests bewährt:

  • Last- und Leistungstest bei 100 % oder mehr der maximal zu erwartenden Zugriffszahlen. Passen Sie die Perzentile an und achten Sie darauf, dass der Spitzenwert auf über 100 % eingestellt ist. Durch die Anpassung sollte ein gewisses Maß an schlechter Systemleistung toleriert werden, während Spitzenlasten angemessen verarbeitet werden.

    Wie weit über dem Spitzenwert sollte getestet werden? Das ergibt sich aus Konfidenzintervallen für die Spitzenzugriffszahlen. Eine geringere Konfidenz erfordert eine höhere Last, um die Chance für ein erfolgreiches Spitzenereignis zu erhöhen. Ist das Konfidenzintervall enger gefasst und genauer, genügt es schon, den Lasttest einen kleinen Prozentsatz über dem Spitzenwert anzusetzen.

  • Testen Sie die Geschwindigkeit bei normalen und maximalen Zugriffszahlen. Abhängig vom Spitzenereignis können die Zugriffszahlen binnen Sekunden stark schwanken. Bestes Beispiel ist die Freischaltung eines Black-Friday-Shops. Testen Sie daher, wie schnell Ihr System skalieren kann, um einen plötzlichen Anstieg der Zugriffszahlen abzufangen. Teile des Systems benötigen möglicherweise Zeit, um auf die Lastsignale zu reagieren.

  • Testen Sie das zonale/regionale Failover, die wiederholte Bereitstellung und Cache-Flush-Szenarien unter Last.

  • Testen Sie den Kaufprozess unter Last. Testen Sie das System vollständig, um sicherzugehen, dass der Kaufprozess auch unter Last reibungslos funktioniert. Tests, die nur bestimmte Komponenten oder technische Ablaufwege betrachten, verbessern vielleicht die Systemzuverlässigkeit, messen jedoch nicht das tatsächliche Kundenerlebnis.

  • Ziehen Sie Load Shedding (Entlastung) in Betracht, um Fehlerkaskaden auszuschließen. Nutzen Sie Load Shedding, um auf Kosten weniger wichtiger Prozesse genügend Leistung für kritische Kaufprozesse bereitzustellen. Zum Beispiel könnten Sie die Katalogsuche oder das Durchsuchen von Käuferbewertungen deaktivieren, um im Gegenzug dafür zu sorgen, dass die Kassenfunktion das SLO einhält.

  • Werten Sie Testergebnisse aus und machen Sie sie möglichst breit bekannt. Nutzen Sie einen "Blameless Postmortem"-Prozess, um eine offene, ehrliche Diskussion und konstruktives Feedback zu fördern. Sprechen Sie im Team über Probleme mit Datenbanken und Kontingenten, unerwartete Abhängigkeiten unter Last und andere Fehler, die sich nur schwer beheben lassen.

  • Testen Sie verschiedene Lastvarianten. Vergleichen Sie das Verhalten auf Mobilgeräten und Desktops, an verschiedenen geografischen Standorten, unterschiedliche Transaktionstypen usw., da diese unterschiedliche Teile des Systems belasten können.

Szenarien bewerten und testen

Um das Vertrauen in den Erfolg des Spitzenereignisses zu erhöhen, ist es wichtig, Szenarien zu bewerten und zu testen, die während des Ereignisses auftreten können. Wie ein System in Notfallsituationen reagiert, lässt sich zum Beispiel mit Google DiRT, Netflix Chaos Monkey und anderen Prozessen und Tools testen.

Die Erfolgswahrscheinlichkeit lässt sich erhöhen, wenn in der Vorbereitungsphase die Szenarien mit dem höchsten Fehlerrisiko getestet werden. Sollte diese Situation dann während des Spitzenereignisses eintreten, gibt es zumindest einen Prozess oder eine technische Lösung, um das Problem zu beheben. Wir empfehlen folgende Best Practices:

  • Testen Sie die wahrscheinlichsten Fehlerszenarien. Verwenden Sie eine Wahrscheinlichkeits-/Risikofaktorgewichtung, um die Probleme zu ermitteln, die während eines Spitzenereignisses die größten Auswirkungen haben können. Simulieren Sie dieses Fehlerszenario unter Last, um zu sehen, wie das System reagiert. Geben Sie absichtlichen Fehlerszenarien den Vorrang vor chaotischen Fehlersituationen.

  • Erwägen Sie die Verwendung des Trennschaltermusters. Finden Sie heraus, an welcher Stelle in der Architektur Trennschaltermuster implementiert werden können und der Betrieb auch ohne bestimmte Komponenten bzw. Funktionen möglich ist. Diese Vorgehensweise empfiehlt sich vor allem, wenn Drittanbieterabhängigkeiten außerhalb der direkten Kontrolle des Systems liegen. Durch das Kappen der Drittanbieterabhängigkeit geht zwar ein wenig an Funktionalität verloren, aber die Leistung bleibt für die Mehrheit der Nutzer gut.

  • Testen Sie die Reaktionsfähigkeit der operativen Teams. Die Geschwindigkeit, mit der operative Teams auf Fehlersituationen reagieren, ist sogar wichtiger als die Reaktionsgeschwindigkeit des Systems. Es reicht nicht aus, wenn die Teams mit aus Fehlertests bekannten Situationen vertraut sind. Sie müssen auch auf den Umgang mit unvorhergesehenen Fehlern vorbereitet sein.

  • Simulieren Sie Fehlersituationen so realitätsnah wie möglich. Geben Sie den Betriebs- und Supportteams keine Insiderinformationen. Testen Sie die Interaktion mit dem internen und externen Support unter möglichst realen Bedingungen, um Reaktionszeiten, die Zusammenarbeit und das Verhalten des operativen Teams während eines Problems zu überprüfen.

  • Führen Sie einen "Blameless Postmortem"-Prozess durch, um die Situation, die Reaktion auf die Situation und Bereiche zu dokumentieren, in denen Verbesserungen vorgenommen werden können, um zukünftige Probleme erfolgreich zu beheben.

Architektur für Skalierbarkeit und Zuverlässigkeit optimieren

Lasttests, Fehlertests und Architekturüberprüfungen ermöglichen eine graduelle Anpassung der Architektur, um ihre Skalierbarkeit und Zuverlässigkeit zu verbessern. Änderungen bringen jedoch auch neue Risiken mit sich. Planen Sie den Zeitraum für Änderungen daher konservativ.

Hier einige Beispiele für Änderungen:

  • Implementieren Sie eine Warteschlangen- und Nachrichtenvermittlungsschicht, um zugriffs- und lastsensible Systeme wie solche mit begrenzter Skalierbarkeit zu managen. Beispiele hierfür sind die Bestandsverwaltung und die Bestellverarbeitung. Eine Warteschlange kann Anfragespitzen an das Back-End-System abfangen und bestimmte Arten von Überlastungsverhalten verhindern.
  • Caching implementieren, um die Leistung zu verbessern. Es gibt im Grunde drei Cache-Kategorien:

    • Front-End: Mit einem Content Delivery Network wie Cloud CDN entlasten Sie Ihr System, da Sie Assets verteilen und näher zum Kunden bringen.
    • Anwendungsebene: Sich selten ändernde Daten werden durch den Nutzer eines Back-End-Dienstes beispielsweise in Memorystore zwischengespeichert. Das können zum Beispiel an Nutzer gerichtete Produktinformationen sein.
    • API-Ebene: Nutzen Sie eine API, um Daten in Memorystore im Cache zu speichern.

    Verlassen Sie sich nicht zu sehr auf den Cache, andernfalls riskieren Sie einen kaskadierenden Fehler. Ein Cache eignet sich auch nicht wirklich zur Skalierung. Sollte er durch einen Fehler nicht mehr verfügbar sein, kann das gesamte zugrunde liegende System unter der Zugriffslast zusammenbrechen.

  • Implementieren Sie Load Shedding (Entlastung), um Systemfehler zu vermeiden. Diese Methode sorgt dafür, dass wichtige Kaufprozesse auch unter starker Belastung zuverlässig ausgeführt werden. Andere Kaufprozesse werden dabei absichtlich eingeschränkt.

  • Implementieren Sie das Trennschaltermuster. Dieser Ansatz ist eine elegante Methode für den Umgang mit Komponentenfehlern und ermöglicht es, kaskadierende Fehler zu vermeiden. Mit diesem Muster kann verhindert werden, dass aufrufende Komponenten ausfallen, wenn bestimmte andere Komponenten überlastet sind.

Im Idealfall wurden viele dieser Architekturänderungen bereits während der Funktionsentwicklung implementiert. Solange das Risiko akzeptabel ist und die erforderlichen Ressourcen bereitstehen, sind Änderungen an der Architektur ein probates Mittel, um die Systemverfügbarkeit zu verbessern.

Monitoring und Logging einrichten

Verwenden Sie Monitoring und Logging, wenn Sie wissen möchten, wie sich das System verhält. Der Detaillierungsgrad und die Informationstiefe entscheiden über die Rechen- und Speicherressourcen, die für Monitoring und Logging benötigt werden.

Monitoring konfigurieren

Für das Monitoring benötigen Sie Messwerte von früheren Ereignissen, die sich auch für aktuelle und künftige Ereignisse eignen. Außerdem müssen Sie Systeme bereitstellen, die eine Erfassung, Zusammenfassung und Berichterstellung zu den Messwerten ermöglichen. Berücksichtigen Sie Folgendes für Ihre Monitoring-Konfiguration:

  • Sorgen Sie für eine angemessene Systemabdeckung. Erfassen Sie hierfür neue Messwerte oder während der Planungsphase ermittelte SLIs.
  • Überwachen Sie die Monitoring-Konfiguration, um sicherzugehen, dass Ressourcen ordnungsgemäß überwacht werden. Ein gängiger Fehler bei der Ressourcenerstellung besteht darin, dass Ressourcen nicht ordnungsgemäß für das Monitoring registriert werden.

  • Nutzen Sie die Messwerte des Monitoring-Systems, um Automatisierungssysteme wie Autoscaling- oder Selbstreparatursysteme zu informieren.

  • Nutzen Sie das Monitoring als kritischen Bestandteil betrieblicher Playbooks.

Monitoring-Informationen über ein Dashboard bereitstellen

Richten Sie ein Monitoring-Dashboard ein, um alle Beteiligten auf demselben Stand zu halten. Auf diese Weise stehen die SLOs im Mittelpunkt, nicht einzelne Messwerte. Ein Dashboard bietet folgende Vorteile:

  • Alles auf einen Blick: Ein zentrales System mit gemeinsam genutzten Messwert-Dashboards verbessert die Reaktionsfähigkeit und senkt die Wahrscheinlichkeit von Interpretationsfehlern.
  • Der richtige Detaillierungsgrad für die Berichterstattung: In Zusammenfassungen lassen sich Trends mitunter besser ermitteln, während Probleme mit einzelnen Ressourcen möglicherweise unerkannt bleiben.
  • Geeignete Benachrichtigungsfunktionen: Verwenden Sie Standardmethoden, um die Teams über wichtige Änderungen zu informieren. Je nach Playbook können Sie Benachrichtigungen per E-Mail, SMS oder Pager an die Teams senden.

Betriebsabläufe und Support anhand von Feedback überarbeiten

Die bekannten dokumentierbaren Elemente wurden in der Planungsphase vorgestellt. In der Vorbereitungsphase müssen Sie diese Dokumente mit Feedback zu Architekturänderungen, Lasttests und Fehlertests aktualisieren.

Checklisten und Playbooks erstellen

Hier einige Best Practices zur Erstellung von Checklisten:

  • Erlauben Sie dem Inhaber der Checkliste, ihre ordnungsgemäße Funktion zu prüfen. Ermächtigen Sie den Inhaber, Änderungen vorzunehmen, die den Zielen der Checkliste entsprechen.
  • Planen Sie die Behebung oder Abmilderung von Problemen anhand akzeptabler Risiken. Vereinbaren Sie funktionsübergreifende Abhilfemaßnahmen, wenn der Punkt auf der Checkliste nicht realisierbar ist. Alle Teams sollten die Auswirkungen der Abhilfemaßnahmen verstehen.

Entwickeln Sie Playbooks für bekannte Probleme und allgemeine Probleme, die Sie während der Fehlertests entdeckt haben.

Schulungen zu Support- und Eskalationsverfahren

Sorgen Sie dafür, dass alle Mitglieder des Betriebsteams sich ihrer Zuständigkeiten und derer der anderen Teams bewusst sind:

  • Achten Sie darauf, dass die Mitglieder des Bereitschaftsteams die geforderte Reaktionszeit kennen und wissen, wie sie mithilfe der vorhandenen Dokumentation und Playbooks die Problembehebung beschleunigen können.
  • Planen Sie eine Besprechungsrunde für das Vorfallsmanagement. Richten Sie eine Einsatzzentrale ein, die die virtuelle Einsatzzentrale für den Black Friday simuliert, wie später in diesem Dokument erläutert wird. Testen Sie verschiedene Vorfälle und die Reaktion des Teams. Für eine ordnungsgemäße Koordination während Vorfällen sollte der Prozess auch das Melden von Ereignissen bei Google umfassen. Erstellen Sie jedoch kein "gefaktes" P1-Ticket bei Google. Klären Sie dies zuvor mit dem CE/Support. Deutlich gekennzeichnete Test/Fake-P4-Tickets sind akzeptabel.

    • Führen Sie Wheel of Misfortune-Besprechungsrunden durch. Bei diesen Besprechungsrunden werden die Einsatzbereitschaft des operativen Teams, die Zuverlässigkeit von Verfahren und Playbooks sowie die ordnungsgemäße Abstimmung mit anderen Teams getestet.
    • Spielen Sie verschiedene Situationen durch, z. B. den Ausfall des CDN-Cachings, die hohe Nachfrage nach einer Artikelnummer mit schlecht angesetztem Preis (gut für Ihre Kunden!) oder den Ausfall einer Region. Überlegen Sie, wie das operative Team diese Ereignisse handhaben sollte.

Halten Sie die Besprechungsrunde mehrmals ab, um die Reaktionszeiten zu verkürzen und bei nachfolgenden Simulationen die Koordination zu verbessern. Verwenden Sie Postmortems, um die Ergebnisse jeder Besprechungsrunde festzuhalten und sich bei der nächsten Besprechungsrunde schrittweise zu verbessern.

Anbietersupport koordinieren

Prüfen Sie, wie Sie andere Teammitglieder oder den Anbietersupport kontaktieren und Informationen für diese bereitstellen können. Anbieter implementieren Supportverfahren auf unterschiedliche Weise. Daher ist es wichtig zu wissen, wie Sie am besten mit ihren Supportangeboten umgehen. Informieren Sie sich in den Anbieter-SLAs über die Supportreaktionszeiten sowie die Verfügbarkeits- und Latenzkennzahlen.

Google Cloud-Support einbinden

Google Cloud bietet Informationen zum Optimieren der Einbindung des Google Cloud-Supports. Allen Kunden steht eine öffentlich zugängliche Dokumentation zur Verfügung. Kunden, die in direktem Kontakt mit Google Cloud Customer Engineering stehen oder die Supportstufe "Platin" haben, können sich direkt an ihren Google-Ansprechpartner wenden, um Informationen zum Supportumfang zu erhalten. Weitere Informationen finden Sie in diesem Dokument im Abschnitt zur Ausführungsphase unter Google Cloud-Support.

Gute Arbeitsbedingungen für das operative Team schaffen

Spitzenereignisse zeichnen sich durch Stress, Emotionen und hohe Intensität aus. Implementieren Sie einen Rotationsplan, um zu verhindern, dass das operative Team überbeansprucht wird. Ein ausgeruhtes Team ist gleichbedeutend mit weniger Fehlern und Ihnen bleibt eine zusätzliche Reserve im Falle eines schwerwiegenden Vorfalls. Folgende Punkte sollten beachtet werden:

  • Das operative Team übernimmt während des Spitzenereignisses angemessene Arbeitslasten.
  • Es sind Ruhezeiten geplant.
  • Alle Teammitglieder erhalten ausreichend Schlaf.
  • Das Team verfügt über einen Eskalationspfad oder Backups und weiß, wo es gegebenenfalls Hilfe erhält.

Die meisten operativen Teams haben schon des Öfteren "Nächte durchgemacht", um ein Problem zu beheben. Wir schätzen dieses Engagement zwar, dennoch ist es besser, eine Jobrotation einzuführen, als übermenschliche Anstrengungen zu verlangen. Sie können Spannungen und Fehlerraten reduzieren, indem Sie Teammitglieder in mehreren Bereichen schulen, sodass Sie über mehrere Spezialisten verfügen.

Kapazitätsanfragen koordinieren

In der Planungsphase haben Sie die Kapazitätsplanung mit dem Google Cloud-Team und anderen Anbietern geteilt und koordiniert. Hier sind einige weitere Kapazitätsplanungsstrategien, die zu berücksichtigen sind:

  • Schätzen Sie den erwarteten Ressourcenbedarf ab und teilen Sie diesen dem Google Cloud-Team so genau wie möglich mit. Machen Sie Angaben zu CPUs, Kernen, Laufwerken, APIs, QPS usw. Sorgen Sie dafür, dass Kontingente für das Unternehmen und einzelne Projekte in geeigneter Weise zugewiesen werden. Passen Sie sie bei Bedarf an.
  • Das Kontingent sollte deutlich höher als die erwartete Nutzung sein, um unvorhergesehen hohe Zugriffszahlen abzufangen.
  • Das Kontingent ist nicht dasselbe wie die Kapazität und kann unterschiedliche Auswirkungen auf die Systeme haben. Lasttests in großem Maßstab können helfen, Kontingente in Google Cloud, wie z. B. API-Aufrufbeschränkungen, oder Kontingente für andere Google-Systeme wie OAuth2 zu ermitteln.
  • Treffen Sie sich regelmäßig mit dem Google-Team, um den aktuellen Kapazitätsbedarf zu besprechen und herauszufinden, ob dieser erfüllt werden kann.

Änderungsstopp festlegen

Black Friday ist wahrscheinlich eines der wichtigsten Ereignisse des Jahres für Ihr Unternehmen. Er verursacht nicht nur eine erhebliche Belastung Ihrer Webinfrastruktur, sondern kann Ihrem Unternehmen auch Rekordeinnahmen bescheren. Die Hauptursache für Fehler sind Veränderungen (erwartete oder unerwartete). Darüber hinaus können Architekturänderungen die Skalierbarkeit Ihrer Infrastruktur beeinträchtigen. Deshalb empfehlen wir, kurz vor und während des Spitzenereignisses einen Änderungsstopp festzulegen.

Hier einige Best Practices zum Festlegen eines Änderungsstopps:

  • Planen Sie vor dem Ereignis ausreichend Zeit für die Bereitstellung neuer Software und Infrastruktur ein. Zu den Grundkriterien für einen Änderungsstopp sollten erfolgreiche Spitzenlast- und Fehlertests gehören.
  • Unterbrechen Sie keine Werbemaßnahmen, z. B. Verkaufs- und Marketingkampagnen vor dem Black Friday. Vermeiden Sie Änderungen in diesen Zeiten.
  • Stimmen Sie mit Ihrem Entwicklungsteam ab, wann die letzten kleineren Fehlerkorrekturen umgesetzt werden können. Fehlerbehebungen müssen zwar nicht so früh wie Architektur- oder Infrastrukturänderungen eingefroren werden, sollten aber auch nicht erst kurz vor dem Spitzenereignis erfolgen.
  • Sorgen Sie dafür, dass auch Drittanbieter Änderungsstopps einhalten. Sie müssen wissen, wann der Änderungsstopp beginnt und endet. Erwägen Sie, ihre SLAs zu aktualisieren, um den Vorgang verbindlich zu machen.
  • Erkundigen Sie sich bei Ihrem Cloudanbieter nach dessen Änderungsmanagementprozess und darüber, welche Änderungen an Ihren Spitzentagen möglich sind (wenn überhaupt).

Ergebnisse der Vorbereitungsphase

Die Vorbereitungsphase umfasst die Überarbeitung von Dokumenten der Planungsphase sowie neuer Elemente, die während dieser Phase entwickelt wurden. Dazu gehören:

  • Prüfen, überarbeiten und verteilen Sie Ergebnisse aus der Planungsphase, die in der Vorbereitungsphase geändert wurden. Bei Last- und Fehlertests werden bestimmte Annahmen mitunter in Frage gestellt, sodass Zeitpläne sowie Risiko-, Kapazitäts- und Betriebspläne überarbeitet werden müssen.
  • Informieren Sie die Beteiligten im Rahmen der Teamkoordination über die Ergebnisse der Last- und Fehlertests. Sorgen Sie dafür, dass jeder über Erfolge sowie Bereiche informiert ist, in denen Verbesserungen vorgenommen oder neue Risiken erkannt wurden.
  • Stellen Sie eine gemeinsame, zentrale Monitoring-Funktion bereit, auf die alle Beteiligten Zugriff haben. Der transparente Zugriff auf Informationen ermöglicht eine schnellere Entscheidungsfindung.
  • Binden Sie das operative Team voll ein und sorgen Sie dafür, dass es die Verantwortung für die Ausführungsphase übernimmt.
  • Achten Sie auf eine geeignete Personalbesetzung. Die Mitarbeiter sollten ausgeruht sein, um gute Entscheidungen zu treffen, und es sollte Übergabeverfahren für Schichtwechsel geben.
  • Dokumentieren Sie die Kapazitätspläne und lassen Sie die Kontingente durch Google Cloud prüfen und in den Systemen von Google implementieren.
  • Führen Sie für jeden Anbieter eine Bewertung der Anbietersupportbereitschaft durch. Informieren Sie sich, wie Supportfälle eingereicht und Fälle eskaliert werden.

Ausführungsphase

Nach Abschluss der Planungs- und Vorbereitungsphase basiert Ihr Black-Friday-Prozess nicht mehr auf dem Prinzip Hoffnung. Und wenn alles nach Plan verläuft, ist das Spitzenereignis dank hervorragender operativer Unterstützung ein Kinderspiel. Das operative Team ist gut informiert und vorbereitet und es gibt keine unerwarteten Vorfälle. Wenn doch ein Vorfall auftritt, kann er schnell identifiziert und behoben werden.

In der folgenden Tabelle sind die wichtigsten Schritte der Ausführungsphase zusammengefasst.

Ausführungsschritt Google Tasks
Manuell bis zur Spitzenkapazität skalieren Zum vertikalen Skalieren benötigen Sie als erstes einen Plan dazu, wie Sie nach dem Black Friday schrittweise wieder herunterskalieren können.
Ausführung auf schnelle Wiederherstellung auslegen Virtuelle Einsatzzentrale einrichten.
Auf Personal mit Erfahrung im Vorfallsmanagement zurückgreifen.
Playbooks ausführen.
Mit dem Google Cloud-Support arbeiten.
Datenbereitstellungsprozess verbessern Ursachenanalysen machen.
Vorhersagen und tatsächliche Werte vergleichen und analysieren.
Postmortem und Aufarbeitung zusammenfassen.
Erfolg anerkennen.

Manuell bis zur Spitzenkapazität skalieren

Autoscaling-Systeme eignen sich hervorragend für unerwartete Spitzen. Sie eignen sich jedoch in der Regel nicht als primärer Skalierungsprozess für 5- bis 10-mal höhere Zugriffszahlen. Autoscaling-Systeme skalieren im Allgemeinen nur in kleinen Schritten, üblicherweise um eine VM mit zusätzlicher Kapazität pro Auswertungszyklus. Wenn Ihr System sich schnell auf Dutzende oder Hunderte von VMs mit zusätzlicher Kapazität skalieren lassen muss, ist eine manuelle Skalierung des Systems auf die richtige Größe die bessere Lösung.

Verwenden Sie die manuelle Skalierung so, dass die Systemkapazität langsam angehoben wird, die Caches vorbereitet ("aufgewärmt") werden können und langsamere Ereignisse wie das Starten virtueller Maschinen bereits vor Eintritt des Spitzenereignisses ausgeführt werden können. Dieser Prozess eignet sich auch zur Absicherung, dass die Kapazität des Systems ausreicht.

Das vertikale Skalieren bis zu den Spitzenzugriffszahlen ist zwar das Hauptziel, dennoch benötigen Sie auch einen Plan, wie Sie die Skalierung nach dem Black Friday schrittweise wieder reduzieren können. Wenn die ursprünglichen Skalierungsstrategien für normale Zugriffszahlen wieder implementiert sind, die Zugriffszahlen sich aber noch nicht normalisiert haben, können durch das vorzeitige Herunterskalieren Ausfälle entstehen.

Ausführung auf schnelle Wiederherstellung auslegen

Das Hauptziel des operativen Teams ist, dafür zu sorgen, dass das System immer zuverlässig und betriebsbereit ist. Entwickler neigen dazu, die Ursache eines Problems zu ermitteln, während es noch akut ist, um Daten zum Problem erfassen zu können. Die Ursachenanalyse ist zwar wichtig, dennoch sollten Sie sich auf die Wiederherstellung konzentrieren. Suchen Sie nach Möglichkeiten, Daten zu erfassen und zu Analysezwecken zu speichern, aber widmen Sie sich primär der Systemwiederherstellung, z. B. durch das Hinzufügen von Kapazität, das Entfernen von Komponenten mit unzureichender Leistung oder das Neustarten von Systemen. Sie können das "Warum" eines Problems immer noch offline analysieren, nachdem der Vorfall behoben ist.

Virtuelle Einsatzzentrale einrichten

Die Mitglieder des operativen Teams sind die primären Akteure während der Ausführung, aber nicht die einzigen involvierten Personen. Mechanismen zur teamübergreifenden Zusammenarbeit helfen dem Team dabei, Unterstützung innerhalb des Unternehmens und von Anbietern zu erhalten.

Eine virtuelle Einsatzzentrale stärkt den Teamgeist aller Beteiligten während des Spitzenereignisses. Die Personen können schnell Ideen austauschen, ohne dass durch asynchrone Chatsysteme oder E-Mail-Kommunikation Verzögerungen entstehen. Virtuelle Einsatzzentralen sind eine einfache Möglichkeit, sich auf den neuesten Stand zu bringen und zu beteiligen.

Erstellen Sie für das Spitzenereignis auch Bereiche für einzelne Untergruppen. Durch diese Unterteilung erhält die Einsatzzentrale die Möglichkeit, Handlungsabfolgen schnell zu bestimmen bzw. Aufgaben zu verteilen, wenn mehrere Vorfälle auftreten.

Auf Personal mit Erfahrung im Vorfallsmanagement zurückgreifen

Nutzen Sie Fehlertests, Modellversuche und Testdurchläufe für den Vorfallsmanagementprozess, um die richtigen Personen mit der Bearbeitung von Vorfällen zu betrauen. Wenn das operative Team mit dem Vorfallsmanagementprozess vertraut ist, wird es schneller reagieren und seine Erfolgsquote wird sich verbessern.

Playbooks ausführen

Für akute Vorfälle, Systembenachrichtigungen und gemeldete Probleme sind Playbooks erforderlich. Die darin enthaltenen Informationen ermöglichen es Teams, Situationen schnell zu bewerten und geeignete Abhilfemaßnahmen zu ergreifen. Playbooks enthalten auch Daten für unvorhergesehene Probleme, anhand derer Teams Probleme schnell erkennen und beheben können. Das Ergänzen des Playbooks um Notizen und das Sammeln von konstruktivem Feedback haben jedoch nicht die höchste Priorität. Notieren Sie sich stattdessen die Informationen und setzen Sie einen Termin für ein Postmortem an, bei dem die Playbook-Ausführung besprochen wird.

Mit dem Google Cloud-Support arbeiten

Machen Sie gegenüber dem Google Cloud-Support so genaue Angaben wie möglich und setzen Sie keine Kenntnisse voraus, die nicht explizit angegeben sind. So kann der Support das Problem aus Kundensicht sehen und seine Nachforschungen besser eingrenzen. Konzentrieren Sie sich auf diese vier wichtigen Punkte:

  • Zeit: Erläutern Sie das Problem auf klare, nicht relative Weise (verwenden Sie niemals Begriffe wie "vorhin" oder "gestern") und geben Sie die Zeitzone an (möglichst in Bezug auf die UTC). Oft sehen sich Google-Techniker Logs oder sonstige Daten an, ohne die Zeitzone des Kunden zu kennen. Die Techniker befinden sich möglicherweise in einer anderen Zeitzone als der Kunde und sind sich nicht bewusst, dass andere Zeiten gemeint sind.

  • Produkt: Geben Sie das Produkt und die Maßnahmen an, die Sie dafür ergreifen. Die Angabe "Es funktioniert nicht" ist zu ungenau, um feststellen zu können, was der Kunde im Gegensatz zum Google-Techniker sieht.

  • Standort: Geben Sie die Region und die Zeitzone an. Diese Angabe kann hilfreich sein, wenn standortspezifische Ereignisse wie eine Softwareeinführung oder Umstände auftreten, die auf eine Korrelation zwischen dem Kundenproblem und einem anderen Ereignis hindeuten.

  • Spezifische Identifizierungsmerkmale: Geben Sie die Projekt-ID, die Abrechnungs-ID, die betroffene VM und andere relevante Merkmale an. Kunden haben viele unterschiedliche Projekte und Ressourcen, oft mit kundenspezifischen Namenskonventionen, die Google nicht bekannt sind. Wenn sich Google-Techniker gleich das richtige Projekt, das richtige Abrechnungskonto bzw. die richtige Ressource ansehen, beschleunigt dies die Problemlösung.

Wenn Sie einen Supportfall initiieren, geben Sie so viele Daten wie möglich an und beantworten Sie die Informationsanfragen von Technikern. Stellen Sie zur Beschleunigung der Problembehebung Screenshots, tcpdump-Ausgaben, Log-Datei-Snippets und andere angeforderte Informationen bereit.

Google geht bei der Fehlerbehebung folgendermaßen vor:

  1. Systembeobachtungen erfassen und teilen
  2. Eine Hypothese aufstellen, die die Beobachtungen erklärt
  3. Tests ermitteln, die diese Hypothese belegen oder widerlegen könnten
  4. Die Tests durchführen und sich darüber verständigen, wie die Ergebnisse auszulegen sind
  5. Mit der nächsten Hypothese fortfahren
  6. Wiederholen, bis das Problem behoben ist

Durch das gemeinsame Durchführen dieser Schritte und das Weitergeben der Informationen zum Fortschritt lässt sich die Fehlerbehebungszeit drastisch reduzieren.

Datenbereitstellungsprozess verbessern

Da der erste Schritt in einem neuen Zyklus die Datenerfassung ist, ist der letzte Schritt in der Ausführungsphase folglich die Datenbereitstellung. Bewahren Sie Messwerte und Logs zusammen mit anderen während des Prozesses erstellten Ergebnissen auf. So schaffen Sie eine solide Grundlage für den nächsten Zyklus, wenn Sie eine neue Planungsphase beginnen.

Ursachenanalyse durchführen

Eine Ursachenanalyse dient dazu, die Fehler auf der untersten Ebene in einem System zu erkennen, bei deren Behebung das System wieder normal funktionieren würde. Eine Ursachenanalyse sollte nicht bereits während eines Ausfalls durchgeführt werden (mit Ausnahme der Datenerfassungskomponente). Versuchen Sie während der Wiederherstellung der Betriebsbereitschaft des Systems Daten zu erfassen und zu speichern, die während des Ereignisses und unmittelbar danach generiert wurden. Wenn die Systemwiederherstellung abgeschlossen ist, führen Sie kurz danach eine Ursachenanalyse durch, um eine Verschlechterung der Datenqualität oder einen Rückgang der Anstrengungen/Motivation zu verhindern.

Eine Ursachenanalyse umfasst Folgendes:

  • Beschreiben des aufgetretenen Problems mithilfe der "5-Why-Methode".
  • Angeben einer Zeitachse zur Zuordnung von Daten zu Zeitpunkten während des Systemausfalls.
  • Trennen sekundärer Faktoren von primären Faktoren für den Systemausfall. Versuchen Sie, die Faktoren zu identifizieren, die die Grundursache des Problems sind. Durch Iteration über die Faktoren können Sie die Komponenten auf der niedrigsten Ebene ermitteln, die mit dem Ausfall zusammenhängen.
  • Prüfen Sie die Erkennung und Benachrichtigung und suchen Sie nach Möglichkeiten für automatische Abhilfemaßnahmen:

    • Wie lange hat es gedauert, das Problem zu erkennen und zu diagnostizieren?
    • Waren alle Telemetriedaten verfügbar?
    • Gab es frühzeitige Warnungen?
    • Wurden Alarme ausgelöst? Wie schnell? Waren genügend Informationen enthalten, sodass das operative Team das Problem sofort verstehen und bearbeitet konnte?
    • Gab es zu viele Abhängigkeitsalarme? Sollten Alarme korreliert und unterdrückt werden?
    • Könnten diese Alarme mit automatischen Abhilfemaßnahmen verknüpft werden?

Für jeden Vorfall sollte es eine eigene Untersuchung geben. Wenn sich Vorfälle überschneiden, besprechen Sie sich mit dem Support, um festzustellen, ob ein ursächlicher Zusammenhang besteht. Wenn die Ursache bekannt ist, erstellen Sie eine Liste umsetzbarer Maßnahmen, die zukünftige Vorfälle verhindern können. Ermitteln Sie den Ressourcen-, Zeit- und Kostenaufwand zum Beheben des Vorfalls und zum Verhindern eines erneuten Auftretens. Wenn ein System durch den Vorfall das SLO nicht einhält, legen Sie geeignete Termine zur Verhinderung eines erneuten Auftretens fest.

Vorhersagen und tatsächliche Werte vergleichen und analysieren

Einer der ersten Schritte im Zyklus ist das Erfassen von Daten aus früheren Ereignissen und deren Verwendung als Grundlage für die Prognose des zukünftigen Bedarfs. Durch das Ermitteln von Unterschieden und deren Ursachen können Sie bei der Planung zukünftiger Spitzenereignisse helfen. Durch Kenntnis der Auswirkungen von Geschäftskennzahlen auf SLOs lassen sich Wege zur Steigerung der Systemzuverlässigkeit finden.

Prüfen Sie auch die Kapazitätspläne. Bereiche, in denen die Kapazität unter den erwarteten Werten lag, haben möglicherweise dazu geführt, dass ein Vorfall zusätzliche Kapazität erhalten hat.

Postmortem und Aufarbeitung zusammenfassen

Es empfiehlt sich, ein Postmortem und einen Aufarbeitungsprozess durchzuführen. Bei diesem Prozess tauschen sich alle Teams zu den aufgetretenen Ereignissen und zum Verhalten der Kunden- und Google-Systeme während des Spitzenereignisses aus. Die Teams sprechen über ihre Erfahrungen und lassen sie in zukünftige Planungen einfließen.

Erfassen Sie während des Postmortems und Aufarbeitungsprozesses die folgenden Informationen:

  • Analyse des Prozesses und ermitteln, welche Schritte der Planungsphase effektiv waren.
  • Besprechen, was in den Vorbereitungs- und Ausführungsphasen aus unterschiedlichen Perspektiven gut funktioniert hat, und Feedback zu möglichen Verbesserungen in beiden Phasen.
  • Möglichkeiten, Best Practices und Lösungen zu veröffentlichen, die anderen Kunden beim erfolgreichen Einsatz in Google Cloud helfen können.
  • Einblicke aus den Bereichen Technik, Betrieb, Projektmanagement, Business und Unternehmensführung. Gegebenenfalls Kontaktieren von Kundengruppen, um Feedback einzuholen.
  • Festhalten von Informationen und in Meetings besprochenen Inhalten in schriftlicher Form. Erkenntnisse aus Besprechungen werden oft nicht notiert.

Erfolg anerkennen

Lassen Sie den funktionsübergreifenden Teammitgliedern, die zum Erfolg des Black Friday beigetragen haben, Anerkennung zukommen. Feiern Sie den Erfolg mit Anerkennungen für die Teams und die einzelnen Mitarbeiter und einer Belohnung für alle, die höchste Anstrengungen unternommen haben.

Wenn Teams über ihren Erfolg reflektieren und ihn zu schätzen wissen, sind sie auf dem besten Wege, sich von Stress und enorm hohem Arbeitsaufwand zu erholen. Die Mitarbeiterzufriedenheit ist ein entscheidender Faktor für den langfristigen Teamerfolg. Genießen Sie den Moment, halten Sie inne, reflektieren Sie und stoßen Sie auf den Erfolg an.

Ergebnisse der Ausführungsphase

Zu den Ergebnissen der Ausführungsphase gehören der erfolgreiche Abschluss des Black-Friday-Ereignisses – nicht gerade unerheblich – sowie das Ende der Planung, Vorbereitung und Ausführung. Die primären Ergebnisse für diese Phase sind die Datenerfassung und -analyse, einschließlich folgender Aspekte:

  • Prüfung der Projektionen und der tatsächlichen Daten hinsichtlich Messwerten, SLOs und Kapazitätsplänen
  • Ursachenanalyse von Vorfällen, die während der Ausführungsphase aufgetreten sind
  • Postmortem und Aufarbeitung, Ermittlung von Bereichen, die gut funktioniert haben, und verbesserungsfähigen Bereichen (mit speziellen umsetzbaren Maßnahmen)

Weitere Informationen

Kein Artikel dieses Umfangs kann alle Informationen liefern. Arbeiten Sie innerhalb Ihres Unternehmens und mit dem Google Cloud-Team zusammen, um Punkte zu ermitteln, die in diesem Artikel nicht behandelt werden, sowie um Fragen und Kommentare zu erstellen. Folgende Themen könnten ebenfalls für Sie interessant sein:

  • Weitere SRE-Verfahren kennenlernen und eine Leitlinie des skalierbaren Produktionssupports schaffen
  • Next 2018-Präsentation auf YouTube zu diesem Thema ansehen – einschließlich der Perspektive eines Google-Kunden
  • Mehr über Customer Reliability Engineering, das Engagement-Modell von Google erfahren, bei dem in Zusammenarbeit mit Kunden die Zuverlässigkeit von Systemen gesteigert werden soll
  • Mehr über Cloud Load Balancing erfahren, das in mehreren Architekturdesignmustern verwendet wird
  • Referenzarchitekturen, Diagramme, Anleitungen und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center