Drei Hebel für sicherere Releases: Traffic, Kohorten und Feature Flags

Sie haben eine neue Version Ihrer Anwendung fertig. Die Tests im Staging laufen durch. Das Team ist zuversichtlich. Aber trotzdem zögern Sie, bevor Sie auf "Deploy to Production" drücken. Dieses Zögern ist gesund. Jeder Deployment birgt Risiken, und der sicherste Weg, dieses Risiko zu reduzieren, ist, die Änderung nicht an alle auf einmal auszuliefern.

Die Idee ist einfach: Schrittweise ausrollen. Aber "schrittweise" bedeutet je nachdem, was Sie kontrollieren, unterschiedliche Dinge. Wenn Sie sich entscheiden, eine Änderung nicht gleichzeitig an alle Benutzer auszuliefern, haben Sie drei unabhängige Hebel, die Sie ziehen können. Jeder kontrolliert einen anderen Aspekt des Releases. Zu verstehen, wann man welchen Hebel einsetzt und wie sie sich kombinieren lassen, unterscheidet ein kontrolliertes Rollout von einem Glücksspiel.

Traffic: Kontrolle darüber, wie viel Last auf die neue Version trifft

Der einfachste Weg, schrittweise auszurollen, ist die Kontrolle des Anteils der Anfragen, die die neue Version erreichen. Anstatt den gesamten Traffic zur aktualisierten Anwendung zu leiten, senden Sie nur einen Bruchteil davon. Fünf Prozent aller Anfragen gehen an die neue Version. Die restlichen fünfundneunzig Prozent treffen weiterhin auf die alte Version.

Dieser Ansatz heißt Traffic-Splitting. Sie konfigurieren ihn auf Infrastrukturebene: Ihrem Load Balancer, Service Mesh oder API-Gateway. Die Konfiguration ist einfach. Sie geben einen Prozentsatz an, und die Infrastruktur verteilt die Anfragen entsprechend. Keine Benutzeridentität ist involviert. Keine Targeting-Logik. Nur ein roher Anteil des Netzwerkverkehrs.

Traffic-Splitting ist ideal für die früheste Validierungsphase. Sie möchten wissen, ob die neue Version beim Start abstürzt, unter realer Last Fehler wirft oder mehr Speicher verbraucht als erwartet. Da die Stichprobe zufällig ist, erhalten Sie ein schnelles Signal zur grundlegenden Gesundheit. Steigen die Fehlerraten, stoppen Sie das Rollout, bevor die meisten Benutzer betroffen sind.

Hier ist ein realistisches Beispiel mit Istios VirtualService, um den Traffic zu 5 % auf die neue Version und zu 95 % auf die alte Version aufzuteilen:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: myapp
spec:
  hosts:
  - myapp.example.com
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: myapp
        subset: v2
      weight: 5
    - destination:
        host: myapp
        subset: v1
      weight: 95

Die Einschränkung ist offensichtlich: Sie können nicht kontrollieren, wer die neue Version bekommt. Derselbe Benutzer könnte bei einer Anfrage die neue Version und bei der nächsten die alte Version treffen. Diese Inkonsistenz ist für die Infrastrukturvalidierung in Ordnung, wird aber zum Problem, wenn Sie das Verhalten über die Zeit beobachten oder Feedback von bestimmten Benutzern einholen müssen.

Kohorten: Kontrolle darüber, wer die neue Version bekommt

Wenn Sie bestimmte Benutzer ansprechen müssen, reicht Traffic-Splitting nicht aus. Sie möchten, dass interne Tester zuerst die neue Version sehen. Oder Beta-Benutzer. Oder Benutzer in einer bestimmten Region. Oder Konten mit einer bestimmten Abonnementstufe. Hier kommen Kohorten ins Spiel.

Eine Kohorte ist eine Gruppe von Benutzern, die durch ein Kriterium definiert ist: Benutzer-ID-Bereich, geografischer Standort, Kontotyp, Geschäftssegment oder jedes andere Attribut, das Ihr System kennt. Anstatt einen zufälligen Prozentsatz des Traffics zu routen, leiten Sie den gesamten Traffic einer bestimmten Kohorte zur neuen Version. Dies wird als gestaffeltes Rollout bezeichnet.

Der Vorteil gegenüber Traffic-Splitting ist die Nachvollziehbarkeit. Wenn Sie an eine Kohorte interner Benutzer ausrollen, wissen Sie genau, wer die neue Version sieht. Wenn sie Probleme melden, können Sie das Problem mit der spezifischen Änderung korrelieren. Wenn die Kohorte klein und kontrolliert ist, ist der Schaden begrenzt. Sie können reale Nutzungsmuster beobachten, nicht nur Fehlerraten.

Kohorten ermöglichen auch eine progressive Ausweitung. Sie beginnen mit internen Benutzern, erweitern dann auf Beta-Benutzer, dann auf fünf Prozent der Produktionsbenutzer in einer bestimmten Region, dann auf fünfundzwanzig Prozent und so weiter. In jeder Phase haben Sie eine bekannte Gruppe von Benutzern, die Signale liefert. Das Rollout wird zu einer Reihe von bewussten Erweiterungen und nicht zu einer einzigen binären Entscheidung.

Der Nachteil ist die Komplexität. Sie benötigen die Infrastruktur, um Benutzer anhand von Attributen zu identifizieren und zu routen. Ihr Load Balancer oder Ihr Gateway muss die Benutzeridentität verstehen, nicht nur die Anforderungspfade. Dies erfordert oft die Integration mit Authentifizierungssystemen, Benutzerdatenbanken oder Sitzungsverwaltung. Es ist aufwändiger einzurichten als Traffic-Splitting, gibt Ihnen aber eine viel reichhaltigere Kontrolle.

Features: Kontrolle darüber, welche Funktionalität aktiv ist

Traffic und Kohorten kontrollieren, welche Version der Anwendung ein Benutzer ausführt. Aber manchmal möchten Sie die neue Version überall bereitstellen und selektiv bestimmte Features darin aktivieren. Vielleicht läuft die neue Version bereits auf allen Servern, aber ein bestimmtes Feature soll noch nicht für alle sichtbar sein. Oder Sie möchten ein Feature für eine Teilmenge von Benutzern aktivieren, ohne neu bereitzustellen.

Hier kommen Feature Flags ins Spiel. Ein Feature Flag ist ein bedingter Schalter in Ihrem Code, der bestimmt, ob ein Feature für einen bestimmten Benutzer aktiv ist. Das Flag kann zur Laufzeit umgeschaltet werden, ohne ein neues Deployment. Sie können das Feature für zehn Prozent der Benutzer aktivieren, für interne Konten, für Benutzer mit geraden IDs oder basierend auf einer beliebigen Logik, die Sie definieren.

Feature Flags entkoppeln Deployment von Aktivierung. Sie können den Code, der ein neues Feature enthält, Tage oder Wochen bereitstellen, bevor das Feature tatsächlich eingeschaltet wird. Dies reduziert das Risiko des Deployments selbst, da Sie das Verhalten nicht gleichzeitig mit dem Code ändern. Wenn etwas mit dem Feature schiefgeht, deaktivieren Sie das Flag. Kein Rollback nötig. Kein erneutes Deployment. Nur eine Konfigurationsänderung.

Die Stärke von Feature Flags liegt in der Granularität. Sie können einzelne Benutzer ansprechen, A/B-Tests durchführen, die Exposition schrittweise erhöhen oder ein Feature, das Probleme verursacht, sofort deaktivieren. Aber diese Stärke bringt Verantwortung mit sich. Feature Flags fügen Ihrer Codebasis bedingte Logik hinzu. Zu viele Flags oder Flags, die nie aufgeräumt werden, erzeugen technische Schulden. Jedes Flag, das nach der vollständigen Auslieferung seines Features im Code bleibt, wird zu totem Gewicht.

Kombination der drei Hebel

Diese drei Komponenten schließen sich nicht gegenseitig aus. In der Praxis verwendet eine ausgereifte Progressive-Delivery-Strategie alle drei zusammen.

Das folgende Diagramm zeigt, wie die drei Hebel in einer typischen Progressive-Delivery-Sequenz zusammenwirken.

flowchart TD A[Start Release] --> B{Infrastruktur validieren?} B -->|Ja| C[Traffic-Splitting] C --> D[Fehlerraten prüfen] D -->|OK| E{Benutzer-Feedback nötig?} D -->|Hoch| F[Rollout stoppen] E -->|Ja| G[Kohorten-Rollout] E -->|Nein| H{Code jetzt deployen, später aktivieren?} G --> H H -->|Ja| I[Feature Flags] H -->|Nein| J[Vollständiges Rollout] I --> K[Flag schrittweise aktivieren] K --> L[Überwachen & Anpassen] L -->|Sicher| J L -->|Problem| M[Flag deaktivieren]

Eine typische Sequenz könnte so aussehen:

  1. Stellen Sie die neue Version für einen kleinen Prozentsatz des Traffics mittels Traffic-Splitting bereit. Validieren Sie, dass die Anwendung nicht abstürzt oder Speicher verliert.
  2. Erweitern Sie auf eine Kohorte interner Benutzer mittels gestaffeltem Rollout. Sammeln Sie Feedback und beobachten Sie Verhaltensmuster.
  3. Sobald Sie zuversichtlich sind, stellen Sie die neue Version auf allen Servern bereit, halten aber ein neues Feature hinter einem Feature Flag. Aktivieren Sie das Flag für zehn Prozent der Benutzer.
  4. Erhöhen Sie den Prozentsatz des Feature Flags schrittweise, während Sie die Metriken überwachen. Wenn etwas schiefgeht, deaktivieren Sie das Flag sofort.

Jeder Hebel gibt Ihnen eine andere Art von Kontrolle. Traffic kontrolliert, wie weit sich die neue Version verbreitet. Kohorten kontrollieren, wer betroffen ist. Features kontrollieren, welche Funktionalität aktiv ist. Wenn Sie alle drei verstehen, können Sie eine Release-Strategie entwerfen, die Ihrer Risikotoleranz und Ihren Validierungsanforderungen entspricht.

Eine praktische Checkliste

Stellen Sie sich vor Ihrem nächsten Release diese Fragen:

  • Muss ich zuerst die grundlegende Infrastruktur-Gesundheit validieren? Verwenden Sie Traffic-Splitting.
  • Benötige ich Feedback von bestimmten Benutzern? Verwenden Sie Kohorten und gestaffeltes Rollout.
  • Möchte ich Code jetzt deployen, aber Features später aktivieren? Verwenden Sie Feature Flags.
  • Habe ich eine Möglichkeit zu messen, ob die neue Version oder das Feature sicher ist? Wenn nicht, starten Sie das Rollout noch nicht.

Das Fazit

Schrittweises Ausrollen ist nicht eine einzelne Technik. Es sind drei unabhängige Kontrollen, die unterschiedliche Probleme lösen. Traffic-Splitting validiert die Infrastruktur. Kohorten validieren die Benutzererfahrung. Feature Flags trennen Deployment von Aktivierung. Die Teams, die sicher releasen, sind diejenigen, die wissen, welchen Hebel sie wann ziehen müssen.