Wenn Daten entscheiden: Observability als Grundlage für Progressive Delivery

Du hast gerade eine neue Version deiner Anwendung ausgerollt. Das Canary-Deployment beginnt, 10 Prozent des Traffics auf die neuen Instanzen zu leiten. Das gesamte Team starrt auf das Dashboard. Läuft es? Schlägt es fehl? Solltest du weitermachen oder den Stecker ziehen?

Ohne echte Daten rätst du nur. Und Raten während eines Releases ist der schnellste Weg, aus kleinen Problemen Produktionsincidents zu machen.

Progressive Delivery – ob du es Canary, Blue-Green oder Phased Rollout nennst – funktioniert nur, wenn du zuverlässig messen kannst, ob die neue Version tatsächlich gesund ist. Die Entscheidung, ob du fortfährst, anhältst oder zurückrollst, muss auf etwas Soliderem basieren als dem Bauchgefühl oder einem schnellen Blick auf ein einzelnes Diagramm.

Die vier Signale, die während eines Releases zählen

Sobald eine neue Version Traffic erhält, geben vier Metriken das vollständige Bild dessen, was passiert. Das sind keine exotischen Messungen. Es sind dieselben Signale, die du ohnehin in der Produktion überwachen solltest – nur dass du sie während eines progressiven Releases in Echtzeit zwischen alter und neuer Version vergleichen musst.

Fehlerrate

Dies ist der Prozentsatz der Anfragen, die von allen Anfragen an die neue Version fehlschlagen. Wenn deine Anwendung normalerweise mit einer Fehlerrate unter 0,1 Prozent läuft und diese nach dem Livegang der neuen Version plötzlich auf 5 Prozent ansteigt, stimmt etwas nicht.

Fehlerratenspitzen können viele Ursachen haben: einen Bug im neuen Code, eine Abhängigkeit, die ihr Verhalten geändert hat, oder eine Konfigurationsdiskrepanz zwischen Umgebungen. Entscheidend ist, die Differenz zwischen der Fehlerrate der alten und der neuen Version nebeneinander sehen zu können. Eine Fehlerrate von 0,5 Prozent auf der neuen Version mag isoliert betrachtet in Ordnung erscheinen – aber wenn die alte Version bei 0,05 Prozent liegt, ist das eine Verzehnfachung, die eine Untersuchung wert ist.

Latenz

Änderungen der Antwortzeit sind oft das erste Anzeichen dafür, dass etwas nicht stimmt – noch bevor Fehler auftreten. Eine neue Version könnte eine langsamere Datenbankabfrage einführen, einen unnötigen Verarbeitungsschritt hinzufügen oder die Funktionsweise des Cachings ändern. Ein paar zusätzliche Millisekunden fallen Nutzern vielleicht nicht auf, aber wenn die Latenz von 200 Millisekunden auf 2 Sekunden springt, verschlechtert sich die Erfahrung spürbar.

Überwache die Latenz serverseitig, aber wenn möglich auch clientseitig. Serverseitige Metriken zeigen dir, wie schnell deine Anwendung antwortet. Clientseitige Metriken zeigen, was Nutzer tatsächlich erleben – inklusive Netzwerkverzögerungen und Browser-Rendering-Zeit.

Traffic

Diese Metrik bestätigt, dass deine Routing-Konfiguration tatsächlich wie beabsichtigt funktioniert. Wenn du festlegst, dass das Canary 10 Prozent des Traffics erhalten soll, musst du überprüfen, ob tatsächlich 10 Prozent der Anfragen auf die neue Version treffen. Fehlkonfigurierte Load Balancer, Sticky Sessions oder Caching-Layer können dazu führen, dass der Traffic ungleichmäßig verteilt wird.

Das Traffic-Volumen zeigt dir auch, ob die neue Version dieselbe Last wie die alte Version bewältigen kann. Wenn die neue Version bei gleichem Traffic-Level beginnt, Verbindungen zu verwerfen oder Anfragen abzulehnen, ist das ein klares Zeichen für ein Kapazitätsproblem.

Sättigung

Die Sättigung misst, wie voll deine Server-Ressourcen sind. CPU, Arbeitsspeicher, Festplatten-I/O und Datenbankverbindungen müssen alle überwacht werden. Wenn die neue Version plötzlich doppelt so viel Speicher wie die alte Version verbraucht, könnten deine Server die Ressourcen erschöpfen und abstürzen.

Die Sättigung ist oft ein Frühindikator. Sie zeigt sich, bevor Fehlerraten in die Höhe schießen oder die Latenz ansteigt. Wenn du die Sättigung frühzeitig erkennst, kannst du das Release pausieren und untersuchen, bevor Nutzer betroffen sind.

Schwellenwerte vor dem Release festlegen

Diese vier Metriken bedeuten wenig ohne Vergleichsschwellenwerte. Du musst definieren, was „gesund“ bedeutet, bevor das Release beginnt – nicht mitten drin, wenn alle gestresst sind und Meinungen umherfliegen.

Lege für jede Metrik konkrete Zahlen fest. Zum Beispiel:

  • Die Fehlerrate muss unter 0,5 Prozent bleiben
  • Die durchschnittliche Latenz darf im Vergleich zur alten Version nicht um mehr als 20 Prozent steigen
  • Die CPU-Auslastung muss unter 80 Prozent bleiben
  • Die Speichernutzung darf 90 Prozent der verfügbaren Kapazität nicht überschreiten

Diese Schwellenwerte sollten aus deinen bestehenden Service Level Objectives (SLOs) oder aus historischen Daten zum normalen Verhalten der Anwendung stammen. Wenn du keine historischen Daten hast, beginne mit konservativen Werten und passe sie an, sobald du mehr lernst.

Die Schwellenwerte müssen auch den Traffic-Prozentsatz berücksichtigen. Ein Canary, das mit 5 Prozent Traffic läuft, zeigt möglicherweise keine Probleme, die erst unter voller Last auftreten. Ziehe in Betracht, für verschiedene Phasen des Rollouts unterschiedliche Schwellenwerte festzulegen oder statistische Methoden zu verwenden, die selbst bei kleinen Stichproben Anomalien erkennen.

Entscheidungen auf Basis von Daten treffen

Sobald die Metriken fließen und die Schwellenwerte festgelegt sind, wird der Entscheidungsprozess unkompliziert. Du musst nicht darüber diskutieren, ob das Release in Ordnung aussieht. Die Daten sagen es dir.

Wenn alle Metriken für einen definierten Beobachtungszeitraum – sagen wir fünf Minuten stabile Daten – innerhalb der sicheren Grenzen bleiben, fährst du mit der nächsten Stufe fort. Erhöhe den Traffic-Prozentsatz von 10 auf 25 Prozent oder verschiebe mehr Nutzer auf die neue Version. Dann beobachte erneut.

Der Entscheidungsprozess folgt einem klaren Ablauf basierend auf den vier Signalen und ihren Schwellenwerten:

flowchart TD A[Vier Signale überwachen] --> B{Alle innerhalb sicherer Schwellenwerte?} B -->|Ja| C[Nächste Stufe fortsetzen] B -->|Nein| D{Irgendein kritischer Schwellenwert überschritten?} D -->|Nein| E[Release anhalten, untersuchen] D -->|Ja| F[Sofort zurückrollen] C --> G[Traffic-Prozentsatz erhöhen] G --> A E --> A

Wenn eine Metrik einen Warnschwellenwert überschreitet, aber unter dem kritischen Schwellenwert bleibt, hältst du das Release an. Erhöhe den Traffic nicht. Rolle noch nicht zurück. Gib dem Team Zeit zu untersuchen, ob es sich um ein echtes Problem oder eine vorübergehende Spitze handelt.

Wenn eine Metrik den kritischen Schwellenwert überschreitet – die Fehlerrate steigt dramatisch, die Latenz verdreifacht sich oder Server beginnen, den Arbeitsspeicher zu erschöpfen – rollst du sofort zurück. Warte nicht auf ein Meeting. Frage nicht um Genehmigung. Die Daten haben bereits entschieden.

Die Entscheidungsschleife automatisieren

Manuelle Entscheidungsfindung funktioniert für kleine Teams und risikoarme Releases, aber sie skaliert nicht. Menschen sind langsam, inkonsistent und anfällig für Verzerrungen. Dieselbe Person, die am Montag sofort zurückrollt, zögert vielleicht am Freitag, weil das Release dringend ist.

Der bessere Ansatz ist, die gesamte Entscheidungsschleife zu automatisieren. Deine Deployment-Pipeline sollte Observability-Daten lesen, sie mit Schwellenwerten vergleichen und ohne menschliches Eingreifen entscheiden, ob sie fortfährt, anhält oder zurückrollt.

Das bedeutet nicht, Menschen vollständig aus dem Prozess zu entfernen. Es bedeutet, menschliches Eingreifen dorthin zu verlagern, wo es den größten Mehrwert bringt: Schwellenwerte definieren, Muster im Zeitverlauf überprüfen und Grenzfälle behandeln, die die Automatisierung nicht vorhersehen kann. Die Routineentscheidungen – „Ist dieses Canary gesund genug, um den Traffic zu erhöhen?“ – sind genau die Art von Entscheidungen, die Computer besser treffen als Menschen.

Eine praktische Checkliste für dein nächstes Release

Bevor du dein nächstes progressives Delivery durchführst, stelle sicher, dass diese Punkte vorhanden sind:

  • Fehlerrate, Latenz, Traffic und Sättigung werden sowohl für die alte als auch für die neue Version erfasst
  • Schwellenwerte sind vor Release-Beginn definiert und dokumentiert
  • Das Beobachtungsfenster ist festgelegt (wie lange gewartet wird, bevor eine Entscheidung getroffen wird)
  • Automatisiertes Rollback ist konfiguriert und getestet, nicht nur geplant
  • Jemand im Team weiß, was zu tun ist, wenn die Automatisierung fehlschlägt oder einen Fehlalarm auslöst

Das Fazit

Observability verwandelt Progressive Delivery von einem Ratespiel in einen datengesteuerten Prozess. Wenn du Echtzeit-Metriken, klare Schwellenwerte und automatisierte Entscheidungsfindung hast, hörst du auf zu fragen „Ist dieses Release sicher?“ und fragst stattdessen „Was sagen die Daten?“ Die Antwort wartet immer in deinen Dashboards und Logs. Der schwierige Teil ist, das System so einzurichten, dass es zuhört.