# Was ist ein Feature Flag? Eine SRE-Antwort mit Code URL: https://upstreamapi.com/de/journal/was-ist-ein-feature-flag Type: blog Locale: de Published: 2026-10-17 Updated: 2026-10-17 --- > Ein Feature Flag macht aus einem Release einen Regler. Hier erfahren Sie, was er ist, welche vier Typen es gibt, wie SREs damit den Blast Radius verkleinern und warum Flag-Schulden teuer werden. Es ist 03:12 Uhr, und die Fehlerquote im Checkout ist gerade über 4 Prozent gestiegen. Die Änderung, die das verursacht hat, ging vor sechs Stunden live. Das ganze Release zurückzudrehen will niemand, denn es enthält auch zwei unabhängige Fixes. Was ist ein Feature Flag in so einer Lage? Es ist eine Bedingung in Ihrem Code, die zur Laufzeit ausgewertet wird und entscheidet, ob ein Codepfad läuft. Schalten Sie sie aus, läuft der neue Pfad nicht mehr, ohne Build und ohne Deployment. Mehr steckt im Kern nicht dahinter. Alles Weitere ist Betrieb. ## Was ein Feature Flag wirklich ist (und was nicht) Ein Feature Flag ist ein Entscheidungspunkt. Irgendwo im Code steht ein `if`, und der Wert, den es liest, kommt von außerhalb des Binärs: aus einem Konfigurationsdienst, einer Datenbankzeile, einem Vendor-SDK oder einer Umgebungsvariable, die Sie ohne Neustart ändern können. `const useNewPricing = await flags.isEnabled("new-pricing-engine", { userId: user.id, plan: user.plan, region: request.region, }); return useNewPricing ? newPricingEngine.quote(cart) : legacyPricing.quote(cart);`Aus diesem Snippet folgen drei Dinge. Der alte Pfad muss weiterhin existieren und weiterhin funktionieren. Der Flag braucht Kontext, also die Frage, wer gerade anfragt, sobald Sie mehr als ein Ein oder Aus wollen. Und die Auswertung liegt auf dem heißen Pfad jeder Anfrage, deshalb sind Latenz und Fehlerverhalten ab jetzt Ihr Problem. „Feature Toggle“ und „Feature Flag“ werden oft synonym verwendet. Das Wort spielt keine Rolle, das Verhalten schon: Sie trennen das Deployment von Code vom Release. Der Code geht dunkel in Produktion, und eine Person oder ein System entscheidet später, wer ihn sieht. ## Die vier Arten von Flags und warum das Mischen wehtut Der größte Teil des Flag-Schmerzes entsteht, wenn man alle Flags als dieselbe Sache behandelt. Martin Fowlers [Taxonomie der Feature Toggles](https://martinfowler.com/articles/feature-toggles.html) unterteilt sie danach, wie lange sie leben und wie dynamisch die Entscheidung ist. In der Praxis hält diese Einteilung gut. Release-Toggles sind Übergangslösungen. Sie verstecken unfertige Arbeit hinter einem Flag, damit Sie täglich in den Hauptzweig (Trunk) mergen können. Fowler empfiehlt, dass sie selten länger als ein oder zwei Wochen leben. Die Entscheidung ist statisch: Jede Anfrage für ein bestimmtes Release bekommt dieselbe Antwort. Experiment-Toggles leiten verschiedene Nutzer auf verschiedene Varianten. Sie bleiben so lange, bis statistische Signifikanz erreicht ist, also Stunden bis Wochen, und nicht länger. Die Entscheidung fällt pro Anfrage. Ops-Toggles steuern den Betrieb: ein unkritisches Feature unter Last abschalten, auf eine Ersatzabhängigkeit umschalten, eine teure Abfrage deaktivieren. Einige davon werden zu langlebigen Kill Switches. Sie müssen in Sekunden umschaltbar sein, was jeden Umweg über ein Release ausschließt. Permission-Toggles steuern Features nach Tarif oder Berechtigung. Sie können jahrelang bestehen, und die Entscheidung fällt bei jeder Anfrage pro Nutzer. Der Fehler besteht darin, allen vier denselben Lebenszyklus zu geben. Ein Permission-Toggle braucht dauerhaft einen Owner und ein Audit-Log. Ein Release-Toggle braucht am Tag seiner Erstellung ein Löschdatum. Wenn Sie einem Namen nicht ansehen können, um welche Art es sich handelt, können Sie auch nicht sagen, welche Flags sich gefahrlos entfernen lassen. ![Hand zieht einen roten Kill-Switch-Hebel an einem dunklen Schaltschrank](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/fa4827-i1.webp) ## Warum SREs sich dafür interessieren: Flags als Regler für den Blast Radius Für ein Platform-Team ist nicht das A/B-Testen die spannende Eigenschaft. Spannend ist, dass ein Flag ein Release von einem Ereignis in einen Regler verwandelt. Ohne Flags setzt ein Deployment 100 Prozent des Traffics der Änderung auf einmal aus. Die einzige Zurücknahme ist ein weiteres Deployment, und das dauert so lange, wie Ihre Pipeline braucht, plus die Zeit, die ein Mensch braucht, um sicher zu sein. Mit Flags können Sie 1 Prozent der Nutzer freigeben, Fehlerquote und p99 beobachten und dann auf 5, 25, 50 Prozent erhöhen. Der Blast Radius entspricht dem Prozentsatz, den Sie gewählt haben, und die Zurücknahme ist eine Konfigurationsänderung, die sich in Sekunden verteilt. Das verändert Ihre mittlere Wiederherstellungszeit (MTTR) stärker als die meisten Investitionen in Tools. Die Frage im Post-Mortem verschiebt sich von „Warum hat der Rollback 40 Minuten gedauert?“ zu „Warum lief das nicht hinter einem Flag?“ Der Regler hat allerdings einen Haken. Jemand muss die Signale beobachten und ihn drehen, und um 03:12 Uhr ist dieser Jemand müde. Die brauchbare Variante bindet den Regler an ein Service Level Objective: Verbrennt die Fehlerquote einen festgelegten Anteil des Budgets, stoppt der Rollout und wird ohne Mensch in der Schleife zurückgenommen. Die meisten Teams bauen das von Hand, mit einem Webhook vom Alerting-Tool zur Flag-API. Es sind einige hundert Zeilen Code, und sie zahlen sich in der ersten Nacht aus, in der sie auslösen. ## Die Rechnung kommt: Flag-Schulden und die Lehre aus Knight Capital Jeder Flag verdoppelt theoretisch die Zahl der Pfade durch diesen Code. In der Praxis testen Sie ein paar Kombinationen und hoffen auf den Rest. Fowler empfiehlt, Flags als Inventar mit laufenden Kosten zu behandeln: Legen Sie beim Anlegen eines Flags direkt ein Entfernen-Ticket im Backlog an, setzen Sie Ablaufdaten, und lassen Sie in den strengsten Teams den Build fehlschlagen, sobald ein abgelaufener Flag noch im Code steht. Die teure Variante dieser Lektion ist Knight Capital. Am 1. August 2012 verwendete ein neues Deployment einen alten Flag wieder, der früher ein inzwischen ausgemustertes Feature gesteuert hatte. Ein Server hatte das Deployment verpasst und lief noch mit dem alten Code. In den ersten 45 Minuten nach Börseneröffnung schickte der Router mehr als 4 Millionen Orders an den Markt, um 212 Kundenaufträge auszuführen, wie die [Verfügung der SEC gegen Knight Capital](https://www.sec.gov/newsroom/press-releases/2013-222) dokumentiert. Fowlers Artikel verweist auf den Verlust von rund 460 Millionen $ als warnendes Beispiel für Flags, die niemand verwaltet. Der Flag war nicht das einzige Versagen. Manuelles Deployment, fehlender Kill Switch und langsame Erkennung spielten ebenfalls hinein. Doch die Wiederverwendung eines toten Flagnamens ist das Detail, das sich jedes Platform-Team an die Wand hängen sollte. Flags nie umwidmen: Den alten löschen, einen neuen anlegen und das Entfernen zu einem eigenständigen Schritt machen. ![Notizbuch mit handgezeichneten Flussdiagrammen neben Tastatur und Laptop auf einem Holztisch](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/652884-i2.webp) ## Selbst bauen oder eine Flag-Plattform kaufen? Ein selbst gebautes Flag-System beginnt als Konfigurationsdatei mit einem Boolean. Für die ersten Dutzend Release-Toggles auf einem Service reicht das. Es wird untragbar, sobald Sie Percentage-Rollouts brauchen, die pro Nutzer stabil bleiben, Targeting-Regeln nach Segment, ein Audit-Log darüber, wer was geändert hat, und Flag-Änderungen, die in Sekunden alle Instanzen erreichen, ohne Ihren Konfigurationsspeicher unter einer Lawine von Anfragen zu begraben. Ab diesem Punkt vergleichen Sie Plattformen anhand messbarer Kriterien: SDK-Auswertungslatenz (lokal gegenüber Netzwerkaufruf), Streaming gegenüber Polling bei Updates, Granularität der Targeting-Regeln, Unterstützung mehrerer Umgebungen und wie das Preismodell mit Ihrem Traffic skaliert. Die Preismodelle unterscheiden sich stärker als die Feature-Listen. LaunchDarkly ist die Referenzimplementierung der Kategorie: ausgereiftes Targeting, abgesicherte Releases und eine tiefe Integrationsfläche. Die nutzungsbasierten Tarife rechnen pro Service-Verbindung und pro tausend monatlich aktiver Client-Side-Nutzer ab. Eine Consumer-App mit großer anonymer Nutzerbasis sieht die Rechnung deshalb anders wachsen als ein reines Backend-Team. Der Vorteil ist real: Wenn Sie Governance und Audit auf Enterprise-Niveau brauchen, hatte LaunchDarkly die meiste Zeit, die Lösung zu härten. Statsig bündelt Flags mit Experimenten und Produktanalytik und rechnet nach Events ab. Das passt zu Teams, die Flags überwiegend als Experimentierfläche nutzen. Wenn Sie hauptsächlich Ops-Toggles und Kill Switches brauchen, bezahlen Sie für Analytik, die Sie vielleicht nie lesen. Beachten Sie außerdem, dass der Anbieter seit September 2025 zweimal den Eigentümer gewechselt hat. Das gehört in Ihre Bewertung von Lieferantenrisiken. Testen Sie in jedem Fall den Fehlerfall, bevor Sie unterschreiben. Blockieren Sie in Staging den Netzwerkzugriff des SDK und prüfen Sie, was die Anwendung tut. Ein gutes SDK liefert die zuletzt bekannten Flag-Werte aus dem Cache und loggt laut. Ein schlechtes blockiert den Anfragepfad. ## Observability ist die halbe Flag-Architektur Ein Flag ohne Telemetrie ist eine Vermutung. Das Minimum ist, den Flag-Zustand an jeden Trace und jede Log-Zeile der Anfrage zu hängen. So können Sie bei einem Fehlerspike nach Flag-Variante gruppieren und sehen, ob der neue Pfad die Ursache ist. Datadog und ähnliche All-in-one-Plattformen machen die Aufschlüsselung pro Variante einfach, sobald Ihr SDK die Spans taggt. Achtung: Die Abrechnung pro Host und pro Signal wächst schnell, wenn Sie hochkardinale Tags wie Flag-Schlüssel plus Variante plus Nutzersegment hinzufügen. Wählen Sie bewusst aus, welche Dimensionen Sie taggen. Grafana ist der günstigere Weg, wenn Sie Prometheus und OpenTelemetry ohnehin betreiben. Sie bauen die Flag-Dashboards selbst, was Entwicklungszeit kostet, dafür behalten Sie die volle Kontrolle über die Labels, die Sie ausgeben. Für ein Team mit 50 bis 500 Ingenieuren und einer Platform-Gruppe ist dieser Tausch oft der richtige. ![Ingenieur geht durch einen Serverraum-Gang, beleuchtet in Blau und Bernstein](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/3ea456-i3.webp) ## Ein kurzes Runbook für den ersten Flag in Produktion Wenn Sie Flags in einem Team einführen, das bisher keine hat, halten Sie den ersten Rollout langweilig. - Wählen Sie eine Änderung mit klarer Erfolgsmetrik, etwa Fehlerquote im Checkout oder p99-Latenz eines Endpunkts. - Benennen Sie den Flag nach Typ und Owner, zum Beispiel `release.checkout.new-tax-calc.owner-payments`. - Schreiben Sie das Entfernen-Ticket sofort und setzen Sie ein Ablaufdatum, das höchstens zwei Wochen entfernt liegt. - Rollen Sie auf 1 Prozent aus, halten Sie einen vollständigen Traffic-Zyklus und erhöhen Sie dann Schritt für Schritt. Legen Sie vorab die Schwelle fest, ab der Sie zurücknehmen. - Machen Sie das Zurücknehmen zu einem einzigen Befehl oder Knopfdruck und proben Sie es einmal in Staging, bevor Sie es nachts brauchen. - Wenn 100 Prozent einige Tage stabil gelaufen sind, löschen Sie Flag und alten Codepfad im selben Change. Der unspektakuläre Teil ist Schritt 6. Teams, die ihn überspringen, landen bei einigen hundert Flags, bei niemandem, der weiß, was die Hälfte davon tut, und bei einem Risiko nach dem Muster Knight Capital im Repository. ## Wie wäre Ihr letzter Incident hinter einem Flag verlaufen? Nehmen Sie den letzten Produktionsincident, den Ihr Team dokumentiert hat, und stellen Sie drei Fragen. Hätte die Änderung dunkel ausgeliefert werden können? Hätte eine Person sie in unter einer Minute ohne Deployment abschalten können? Hätte ein Alert Ihnen gesagt, welche Variante fehlschlägt? Wenn die Antwort dreimal Nein lautet, haben Sie Ihren ersten Flag-Kandidaten und eine ehrliche Schätzung, was ein Rollback Sie heute kostet. Das Post-Mortem wird sagen, was es sagt. Die bessere Frage lautet, wie viel davon Sie hätten verkleinern können, bevor der Pager ging. ## FAQ ### Was ist ein Feature Flag einfach erklärt? Ein Feature Flag ist eine Laufzeitbedingung im Code, die festlegt, ob ein Codepfad läuft. Der Wert kommt von außerhalb des Binärs, etwa aus einem Konfigurationsdienst oder einem Vendor-SDK, sodass sich das Verhalten ohne neues Deployment ändern lässt. ### Was ist der Unterschied zwischen Feature Flag und Feature Toggle? In der Praxis keiner. Beide Begriffe beschreiben denselben Mechanismus. Manche Anbieter sagen Toggle für die Praxis und Flag für die Code-Ebene, doch in Teams werden beide Begriffe austauschbar verwendet. ### Welche Arten von Feature Flags gibt es? Man unterscheidet meist vier: Release-Toggles für unfertige Arbeit, Experiment-Toggles für A/B-Tests, Ops-Toggles für die Laufzeitsteuerung wie Kill Switches und Permission-Toggles für Tarif- oder Berechtigungslogik. Jede Art hat eine eigene erwartete Lebensdauer. ### Wie lange sollte ein Feature Flag leben? Das hängt vom Typ ab. Release-Toggles sollten meist nach ein bis zwei Wochen entfernt werden. Experiment-Toggles bestehen so lange, bis Signifikanz erreicht ist. Ops-Kill-Switches und Permission-Toggles können jahrelang bestehen, wenn ein klarer Owner existiert. ### Was ist ein Kill Switch in der Software? Ein Kill Switch ist ein langlebiger Ops-Flag, mit dem ein Operator ein Feature oder eine Abhängigkeit in Produktion sofort abschalten kann, ohne Deployment. Er dient dazu, unter Last kontrolliert zu degradieren oder eine fehlschlagende Änderung zu stoppen. ### Sollen wir ein Feature-Flag-System selbst bauen oder kaufen? Eine Konfigurationsdatei mit einem Boolean reicht für einige Release-Toggles auf einem Service. Sobald Sie stabile Percentage-Rollouts, Segment-Targeting, Audit-Logs und schnelle Verteilung über Instanzen brauchen, vergleichen Sie Plattformen nach SDK-Latenz, Update-Mechanismus, Targeting-Granularität und Preismodell. ### Können Feature Flags Ausfälle verursachen? Ja. Häufige Ursachen sind die Wiederverwendung eines alten Flagnamens, tote Codepfade, die liegen bleiben, und ungetestete Flag-Kombinationen. Der Knight-Capital-Vorfall von 2012 hing mit einem umgewidmeten Flag zusammen. Behandeln Sie Flags als Inventar mit Ablaufdatum und widmen Sie nie einen um.