Ein Feature Flag, auch Feature Toggle genannt, ist ein Laufzeitschalter, der festlegt, welcher Codepfad ausgeführt wird, für alle Nutzer oder für eine gezielte Teilmenge, ohne neues Deployment. Flags trennen das Ausrollen von Code von der Freigabe von Features und ermöglichen schrittweise Rollouts, Experimente und Kill Switches.
Was ein Feature Flag ist
Ein Feature Flag kapselt eine Funktion in einer Bedingung, die zur Laufzeit entschieden wird. Im Code sieht das aus wie eine gewöhnliche if-Abfrage, der Wert kommt aber aus einem Flag-Management-System, das ihn innerhalb von Sekunden ändern kann, für alle oder für ausgewählte Nutzer, Regionen oder Mandanten. Damit trennen Sie zwei Schritte, die früher zusammenfielen: Code in Produktion zu deployen und ein Feature für Nutzer freizugeben.
Diese Trennung ermöglicht Trunk-based Development mit unfertigen Features hinter Flags, schrittweise Rollouts ähnlich einem Canary Deployment, nur auf Feature-Ebene, A/B-Experimente und sofort wirksame Kill Switches, die ein fehlerhaftes Feature ohne Rollback abschalten.
Typen von Feature Flags
Eine verbreitete Einteilung, beschrieben von Pete Hodgson auf martinfowler.com, unterscheidet Flags nach Lebensdauer und Zweck:
| Typ | Zweck | Typische Lebensdauer |
|---|---|---|
| Release Toggle | Unfertige oder noch nicht freigegebene Features verbergen | Tage bis Wochen |
| Experiment Toggle | A/B- oder multivariate Tests | Dauer des Experiments |
| Ops Toggle | Kill Switches, Load Shedding, Fallback-Modi | Kurzlebig oder dauerhaft |
| Permission Toggle | Features für bestimmte Tarife, Beta-Nutzer oder interne Teams | Langlebig |
Die Unterscheidung ist wichtig, weil jeder Typ eine eigene Governance braucht. Ein Release Toggle, der ein Jahr überlebt, ist technische Schuld geworden; ein Permission Toggle ist Teil des Produkts.
OpenFeature: der offene Standard
Die meisten Flag-Anbieter liefern proprietäre SDKs, wodurch Flag-Abfragen zu einer über den ganzen Code verteilten Quelle von Vendor-Lock-in werden. OpenFeature, ein CNCF-Projekt mit Incubating-Status seit Dezember 2023, definiert eine herstellerneutrale Evaluation-API mit SDKs für viele Sprachen. Die Kernkonzepte:
- Evaluation-API: typisierte Aufrufe wie
getBooleanValue("new-checkout", false, context)mit Standardwert. - Provider: Adapter, die die API mit einem konkreten Flag-Backend verbinden, kommerziell oder selbst betrieben, etwa mit der Referenzimplementierung flagd.
- Evaluation Context: Attribute wie Nutzer-ID, Tarif oder Region, auf die Targeting-Regeln zugreifen.
- Hooks: Code, der vor und nach Auswertungen läuft, etwa um Telemetrie zu erzeugen.
Ein Anbieterwechsel bedeutet dann, den Provider zu tauschen, nicht jede einzelne Flag-Abfrage.
Warum Feature Flags Observability brauchen
Eine Flag-Änderung ist eine Produktionsänderung wie ein Deployment, umgeht aber oft die Deployment-Pipeline und ihre Marker. Steigt die Fehlerrate um 14:02 Uhr und es wurde nichts deployt, kann ein um 14:01 Uhr umgeschaltetes Flag die Ursache sein. So machen Sie das sichtbar:
- Auswertungen erfassen. Die OpenTelemetry-Semantic Conventions für Feature Flags definieren für Evaluation-Events Attribute wie
feature_flag.key,feature_flag.result.variantundfeature_flag.provider.name. Diese Konventionen gelten noch als „in Entwicklung“, einige Namen haben sich 2025 geändert. Legen Sie die verwendete Version deshalb fest. - Änderungen erfassen. Senden Sie Änderungs-Events aus Ihrem Flag-System als Annotationen, neben den Deployment-Markern.
- Varianten vergleichen. Teilen Sie Latenz und Fehler nach Variante auf, um zu sehen, ob sich der neue Pfad anders verhält.
OpenFeature-Hooks eignen sich gut, um diese Attribute an den aktiven Span zu hängen. So zeigt jeder Trace, welche Variante die Anfrage bedient hat.
Beispiel: ein Rollout per Flag
Ein beispielhafter Rollout eines neuen Checkout-Ablaufs hinter dem Flag new-checkout:
- Code mit für alle deaktiviertem Flag deployen. Für Nutzer ändert sich nichts.
- Für interne Mitarbeitende aktivieren und Traces, Fehler sowie Business-Metriken prüfen.
- Für 5 % der Kunden freigeben, dann für 25 %, 50 % und 100 %. Jede Stufe so lange halten, bis aussagekräftige Daten vorliegen.
- Auf jeder Stufe die neue mit der alten Variante vergleichen: Latenz, Fehlerrate und Conversion. Verbraucht sich das Error Budget zu schnell, schalten Sie das Flag ab, und die Änderung wirkt ohne erneutes Deployment.
- Nach einer stabilen Phase bei 100 % das Flag und den alten Codepfad entfernen.
Prozentuale Rollouts sollten stabil zugeordnet sein: Derselbe Nutzer muss immer dieselbe Variante erhalten, meist über einen Hash einer stabilen Kennung. Sonst werden Nutzererlebnis und Messwerte gleichermaßen verrauscht, und Unterschiede zwischen den Varianten lassen sich kaum noch sauber zuordnen.
Best Practices
- Jedem Flag einen Owner und ein Ablaufdatum geben und Release Toggles nach abgeschlossenem Rollout entfernen.
- Sichere Standardwerte verwenden. Ist der Flag-Dienst nicht erreichbar, muss der Standardwert das sichere Verhalten sein.
- Rollouts an SLOs koppeln. Die Freigabe schrittweise erhöhen und stoppen, wenn der Verbrauch des Error Budgets steigt.
- Flag-Logik flach halten. Verschachtelte Flags vervielfachen die Zahl der zu testenden Codepfade.
- Änderungen auditieren. Wer wann welches Flag für wen geändert hat, muss für Compliance und Incident-Analyse nachvollziehbar sein.
Typische Fehler
Das häufigste Problem sind Flag-Schulden: Hunderte veraltete Flags, die niemand zu entfernen wagt. Weitere Fehler sind Nutzer-IDs oder personenbezogene Daten in Flag-Keys oder Telemetrie-Attributen, Flag-Auswertungen mit Remote-Aufrufen in engen Schleifen und die Annahme, Flag-Änderungen seien harmlose Konfiguration ohne Review und Monitoring.
Wie Obseria unterstützt
Obseria verarbeitet OpenTelemetry-Spans und -Events mit Feature-Flag-Attributen. Sie können Traces und Fehler nach Flag-Key und Variante filtern und Varianten direkt vergleichen. Deployment Tracking legt Releases auf dieselbe Zeitachse, und SLOs mit Error Budgets, in jedem Tarif enthalten, geben Rollouts ein klares Abbruchkriterium.