Leitfaden für Peak Readiness

In den letzten paar Jahren hatte ich das Vergnügen, mit einigen Kund:innen zusammenzuarbeiten, um Observability für die Infrastruktur und Anwendungen zu implementieren, die sie tagtäglich nutzen. Und der Erfolg einer Implementierung zeigt sich besonders daran, wie Teams diese Daten für ihre Incident Response in Zeiten starker Auslastung nutzen. 

Im E-Commerce fluktuieren die Umsätze in der Regel im Verlauf eines Jahres und es gibt bestimmte saisonale Bedarfsspitzen, also Zeiten, zu denen die meisten Käufe getätigt werden. Damit diese Umsatzchancen realisiert werden können, sind die richtigen Anwendungen und Tech-Stacks notwendig, denn im hart umkämpften Online-Shopping-Markt können Kund:innen besonders leicht abwandern. 

Die technischen Teams, die sich um die Anwendungs-Stacks kümmern, müssen nicht nur in der Lage sein, alle Vorgänge zu sehen, sondern eventuelle Probleme müssen rasch erkannt und je nach Priorität sofort behoben werden.

Dieser Blogpost befasst sich mit folgenden Aspekten:

• Was versteht man unter „Peak Readiness“?
• Häufige Fehler bei der Peak Readiness-Planung
• Der Planungsprozess im Detail

Weitere Informationen finden Sie in dem am Ende dieses Blogposts verlinkten Dokument.

Was versteht man unter „Peak Readiness“?

Verfügbarkeit ist nicht das Gleiche wie Performance. 

Als absolutes Minimum bedeutet „peak-ready“, dass Ihre Anwendung auch bei hoher Auslastung jederzeit für Benutzer:innen verfügbar ist. Allerdings gehört zur Peak Readiness mehr als nur die Verfügbarkeit einer App.

Verfügbarkeit und Performance Ihrer Anwendung müssen mit den Geschäftszielen Ihres Unternehmens im Einklang stehen, denn die Anwendung soll zum Erreichen bestimmter Unternehmensziele dienen. 

Alle Beteiligten, vom Management bis zu den Entwickler:innen, können sehen, wie sich das Unternehmen gerade schlägt – gerade wenn die Auslastung hoch ist oder Systemstörungen mit Soft- oder Hardware auftreten und die Auswirkungen auf das Unternehmen und das Benutzererlebnis offensichtlich werden. Um Ihre Infrastruktur angemessen auf Stoßzeiten vorzubereiten, müssen Sie die Zusammenhänge zwischen App-Performance und potenziellen geschäftlichen Auswirkungen erkennen.

Häufige Fehler bei der Peak Readiness-Planung

Folgende Fehler kommen mir immer wieder unter:

Fehler Nr. 1: Planung beginnt zu spät

Viele Teams beginnen erst ein bis zwei Monate vor den erwarteten Stoßzeiten mit der Planung. Das ist viel zu spät und bedeutet, dass nicht alle notwendigen Schritte abgeschlossen werden können. Es bleiben Lücken, die nur mit viel Glück nicht zu Problemen führen.

Fehler Nr. 2: Keine Verknüpfung von Anwendungs-Performance und Geschäftszielen

Manchmal liegt der Fokus zu sehr auf den Anwendungs- und Infrastrukturdaten – den technischen Aspekten. Inwieweit Umsätze oder Kundenzufriedenheit beeinträchtigt sein können, wird nicht berücksichtigt. Wenn man sich nicht über die Auswirkungen auf das Geschäft im Klaren ist, werden bei der Fehlerbehebung eventuell die falschen Prioritäten gesetzt.  

Fehler Nr. 3: Datensilos

Die derzeitige Anwendungsarchitektur von Microservices sowie die zunehmende CI-/CD-Praxis führten oft dazu, dass die technischen Teams isoliert voneinander arbeiteten. Jedes Team kennt sich hervorragend mit dem eigenen Verantwortungsbereich aus, weiß aber oft nicht genug über die gegenseitigen Abhängigkeiten oder darüber, welchen Einfluss die Performance ihrer Anwendungen auf den gesamten Betrieb im Unternehmen hat. Fehlt dieser Überblick, wirkt sich das auch darauf aus, welche Informationen ein Team mit anderen teilt, und kann die Triage im Ernstfall verzögern.  

Fehler Nr. 4: Keine Berücksichtigung der Spitzenauslastung bei der Entwicklung

Die Peak-Readiness-Maßnahmen beschränken sich in der Regel auf die Produktionsumgebung. Deshalb ist es dem Team nicht möglich, das normale Verhalten der Anwendung während der Entwicklung zu sehen, um Schwachstellen und deren wichtigste Indizien, effektive Alerts und mögliche Behebungsstrategien zu identifizieren. Werden Schwächen bereits in der Nichtproduktionsumgebung erkannt und behoben, ist die endgültige App-Version meist besser für Bedarfsspitzen gewappnet.

Die richtige Planung im Detail

Nachstehend finden Sie einige Tipps, die Ihnen bei der Vorbereitung auf Bedarfsspitzen helfen sollen. Der Ablauf ist dabei in acht Phasen aufgeteilt:

Phase 1: Prüfung und Planung

In dieser Phase wird ermittelt, wer maßgeblich am Projekt beteiligt ist, wer der Executive Sponsor ist und welche Geschäftsziele verfolgt werden. Zusätzlich sollten Umfang, Projektziele, relevante Kennzahlen und Kommunikationsplan geprüft werden. 

Phase 2: Ermitteln kritischer Geschäftsprozesse

Als Nächstes müssen Sie die kritischen Geschäftsprozesse identifizieren und beschreiben – Prozesse, die umsatzrelevant sind oder Auswirkungen auf Kundenzufriedenheit und Kundentreue haben. Diese können eventuell anhand typischer Request-Fulfillment-Datenflüsse ermittelt werden.

Phase 3: Prüfung der Datenerfassung

Diese Phase dient der Prüfung der Daten, die als absolutes Minimum zur Erfassung von Performance- und Geschäftsinformationen notwendig sind. Für die Geschäftsinformationen ist oft eine Custom-Instrumentierung notwendig, z. B. für den Wert des Einkaufskorbs. Es empfiehlt sich, bei der Prüfung der verfügbaren Daten zusätzlich zu den Metriken und Events auch Logs und Traces zu berücksichtigen. Nachstehend sind die Funktionen und Ressourcen der New Relic Plattform aufgeführt, mit denen der Observability-Reifegrad erhöht werden kann:

• Prüfung auf obsolete Agents (mit Agent Groundskeeper)
• Verwendung von Logs in Context, um die MTTR beim Troubleshooting von Anwendungsfehlern zu verkürzen
• Troubleshooting mit Distributed Tracing, um Verzögerungen oder Fehler in mehreren Services zu erkennen
• Verbessern der Website und Prüfung der Web Vitals mithilfe von Browserdaten
• Analyse und Behebung von Abstürzen mithilfe mobiler Daten
• Darstellung Ihrer Infrastruktur-Health mithilfe von Infrastrukturdaten
• Darstellung der K8s- und App-Performance im Kontext
• Monitoring Ihrer Cloud-Services in AWS, GCP und Azure mithilfe von Infrastruktur-Integrationen
• Lenken des Fokus auf die für Sie relevanten Faktoren mithilfe von Workloads
• Errors Inbox, in der Fehler an einem zentralen Ort angezeigt werden, sodass Teams sie besser gemeinsam beheben können
• Vulnerability Management, damit kritische Schwachstellen nicht übersehen werden 
• Befolgen des Qualitätssicherungsprozesses bei Alerts, um die Alert-Effektivität zu verbessern
• Nutzung von Service-Level-Daten für effektives Service-Level-Management
• Automatisierung von Dashboards und Alerts mithilfe von Terraform
• Darstellung der Änderungen, die aus einem Deployment oder kritischen Event resultieren, mithilfe von Change Tracking
• Reduzierung der MTTR und Beschleunigung der Fehlerbehebung mithilfe von New Relic Logs
• Darstellung der Performance in der IDE für Entwickler:innen mithilfe von New Relic CodeStreams
• Verbesserung der gesamten Observability mithilfe von Guides zu Observability-Reifegraden
• Monitoring von AWS Lambda, Azure Functions sowie Google Cloud Functions

Phase 4: Implementierung in die Produktion

In dieser Phase werden die Tasks, die in der vorherigen Phase ermittelt wurden, in der Produktionsumgebung implementiert. Dieser Schritt wird jeweils von den einzelnen Anwendungsteams ausgeführt. Dazu gehören eventuell auch zusätzliche Agent-Deployments, Agent-Updates, Custom-Instrumentierung, Konfiguration von Alert-Bedingungen, Benachrichtigungs-Workflows, Abhilfemaßnahmen und erforderliche Dashboards. 

Phase 5: Teamübergreifende Prüfung

In dieser Phase werden die Resultate mit anderen Teams geteilt. Dieser Schritt ist besonders wichtig für die Teams, deren Anwendungen direkt voneinander abhängig sind, denn so wird deutlich, inwieweit die Anwendung eines Teams von Vorfällen in anderen Anwendungen betroffen ist. 

Phase 6: Letzte Verbesserungen

Diese Phase findet kurz vor dem Code-Freeze statt, wenn Bug-Fixes nur noch für wirklich kritische Bugs veröffentlicht werden können. Neue New Relic-Deployments sind ebenfalls nicht mehr möglich. Dies ist allerdings ein guter Zeitpunkt für letzte Verbesserungen an Alerts und Dashboards, denn diese Dinge haben keinerlei Auswirkungen auf die Anwendung oder die Verfügbarkeit des Dev-Teams. 

Phase 7: Code-Freeze

Jetzt wird es ernst. Wenn Sie sich genug Zeit für die vorherigen Phasen genommen haben, sollte es hier aber keine bösen Überraschungen mehr geben, und Sie können noch immer Änderungen an Alerts und Dashboards vornehmen, denn die Anwendungen selbst sind davon unberührt. 

Phase 8: Nachbearbeitung 

Wie im professionellen Projektmanagement üblich, sollten die Teams nach der ersten Hochsaison besprechen, was gut lief und was verbessert werden sollte.

In dieser Phase bewerten die wichtigsten Mitglieder des Peak-Readiness-Teams gemeinsam mit den Anwendungsarchitekten, wie eventuell auftretende Probleme vom Team insgesamt gehandhabt wurden. Zusätzlich ist jetzt der richtige Zeitpunkt, bereits bekannte Umgebungsänderungen für die nächste Saison zu besprechen, z. B. neue Software-Releases, neue Tech-Stacks und/oder neue Geschäftsprozesse und die daraus resultierenden Auswirkungen auf die Observability.

Zusammenfassung

Peak Readiness ist ein umfangreiches Projekt und erfordert als solches eine strukturierte Durchführung von der Nichtproduktions- bis zur Produktionsumgebung. An der Planung, Vorbereitung und Ausführung des Projekts sollten zusätzlich Kolleg:innen aus Entwicklung, Operations und Management beteiligt sein. Die Peak Readiness-Planung sollte sich an den Geschäftsdaten sowie den Performance- oder Betriebsdaten orientieren, damit sie mit den Geschäftszielen im Einklang steht. 

Bei korrekter Planung für saisonale Bedarfsspitzen verursachen diese weitaus weniger Stress für alle Beteiligten. 

Weitere Informationen und Beispiele finden Sie in unserem umfassenden Leitfaden zur Peak Readiness.