# Was sind Feature Flags? Ein praktischer Leitfaden für SREs URL: https://upstreamapi.com/de/journal/was-sind-feature-flags Type: blog Locale: de Published: 2026-08-29 Updated: 2026-08-31 --- > Feature Flags sind bedingte Abfragen, die Deployment von Release trennen. Erfahren Sie, wie SLOs, Kill Switches und progressive Rollouts echte Production Incidents verhindern. Was sind Feature Flags? Das sind bedingte Abfragen in deinem Anwendungscode, die steuern, welche Codepfade für einen bestimmten Benutzer, eine Session oder eine Umgebung ausgeführt werden – ohne dass du einen neuen Build versenden musst. Ein Flag namens `new_checkout_flow`, das für 99 % deiner Nutzerbasis auf `false` gesetzt ist, bedeutet, dass du diesen Code vor zwei Wochen deployed hast. Du hast ihn nur noch nicht aktiviert. Der Vertrag, den sie etablieren, ist präzise: Deployment und Release werden zu zwei separaten Ereignissen. Für jedes Team, das Continuous Deployment in großem Maßstab betreibt, ist dieser Vertrag fundamental. ## Deployment und Release sind nicht dasselbe Ereignis Die meisten Teams lernen diese Unterscheidung erst nach einem fehlgeschlagenen Rollout. Ein Feature geht Dienstagagnachmittag live, etwas in der Request-Trace beginnt Mittwochmorgen anders zu verhalten, und bis jemand eine Untersuchung einleitet, umfasst der Diff vier Commits und zwei Service-Grenzen. Kausalität in diesem Szenario zuzuordnen ist genuinely schwer. Feature Flags erzwingen Präzision. Wenn der Code hinter einem Flag gemergt und deployed wird, sitzt er inert in Production. Du bestätigst, dass das Deployment erfolgreich war, beobachtest Baseline-Metriken für ein paar Stunden oder Tage, und verifizierts, dass nichts degradiert. Dann stellst du das Flag für 1 % des Traffic auf. Du hast jetzt eine einzige zurechenbare Variable. Wenn die Error-Rate auf dem geflaggten Pfad ansteigt, debuggst du keinen Code-Diff. Du togglest einen Config-Wert. Diese Trennung ist nicht primär ein Speed-Argument. Es ist ein Blast-Radius-Argument. Ein Release, das 1 % der Sessions betrifft und schiefgeht, ist in Minuten wiederhergestellt. Ein Release, das 100 % der Sessions betrifft und schiefgeht, ist ein Major Incident. Der Mechanismus selbst ist unkompliziert. In TypeScript sieht eine Flag-Evaluierung ungefähr so aus: `const showNewCheckoutFlow = flagClient.variation( 'new_checkout_flow', { userKey: session.userId, custom: { plan: user.plan } }, false // default if flag service unreachable ); if (showNewCheckoutFlow) { return renderNewFlow(cart); } return renderLegacyFlow(cart);`Der `false`-Default ist keine Formalität. Es ist das Verhalten, das deine Nutzer bekommen, wenn der Flag-Evaluierungsdienst einen Netzwerkausfall hat. Definiere es bewusst, nicht zufällig. ## Die vier Flag-Typen, die tatsächlich in Production zählen Nicht alle Feature Flags dienen dem gleichen operativen Zweck. Sie in deinem Codebase und deinen Verwaltungstools identisch zu behandeln ist ein zuverlässiger Weg zu Verwirrung während Incidents und zum Aufbau von Flag Debt. **Release Flags** sperren neue Features während der Entwicklung und des Rollouts. Sie sollen temporär sein: erstellt, wenn die Arbeit an einem Feature Branch beginnt, entfernt, sobald das Feature 100 % der Nutzer erreicht und das Team Stabilität bestätigt hat. Release Flags ohne Removal-Datum und ohne zugewiesenen Owner werden zu permanenten Fixtures in deinem Codebase. **Experiment Flags** betreiben A/B-Tests und multivariate Experimente. Sie sind an Analytics-Cohorten-Identifikatoren gebunden und ihr Lebenszyklus ist durch das Experiment begrenzt. Wenn das Experiment zu Ende geht, geht das Flag mit. Der häufige Fehler: die gewinnende Variante unbegrenzt hinter dem Flag zu halten, mit der Begründung, dass das Removal nicht dringend ist. Zwei Jahre später ist das Experiment-Flag Teil des kritischen Pfads und niemand erinnert sich, welche Variante aktiv ist. **Ops Flags** sind Kill Switches und Circuit Breaker. Anders als Release Flags sind sie so gestaltet, dass sie permanente Infrastruktur sind. Ein `disable_ml_recommendations`-Flag, das dir ermöglicht, eine langsame ML-Inference-Schicht zu umgehen, wenn ihr SLO degradiert, ist etwas, das du um 3 Uhr morgens ohne Dokumentation verfügbar haben willst. Diese Flags sollten lokal evaluieren, einen wohldefinierten Fallback haben und regelmäßig unter normalen Bedingungen getestet werden – nicht unter Druck entdeckt. **Permission Flags** kontrollieren Zugriff nach User-Tier, Account-Plan oder Beta-Cohort. Sie sind von Natur aus langlebig. Das Verwechslungsrisiko: Permission Flags sehen für einen Leser ohne Historie oft wie Release Flags aus. Eine klare Namenskonvention ist hier wichtiger als überall sonst. ![Progressive software rollout visualization showing percentage-based traffic routing with concentric node circles](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-08/e28abc-inline1.webp) ## Ein Percentage-Rollout ohne SLO-Gate ist nur ein langsames Deployment Hier ist der Punkt, wo die meisten Feature-Flag-Implementierungen haltmachen. Das Platform-Team verdrahtet einen Rollout-Plan: 1 % am Montag, 5 % Dienstag, 25 % Mittwoch, 100 % Freitag. Sie dokumentieren es, teilen es mit Stakeholdern, und nennen es Progressive Delivery. Aber progressiv ohne eine Validierungsbedingung bei jedem Schritt ist aufgeschobenes Risiko, nicht reduziertes Risiko. Der Prozentsatz-Regler steuert die Exposition. Er validiert keine Sicherheit. Was einen gestaffelten Rollout operativ sinnvoll macht, ist das SLO-Gate zwischen den einzelnen Stufen. Vor dem Wechsel von 5 % zu 25 % sollte etwas antworten: Liegt die Error-Rate auf dem geflaggten Codepfad im SLO-Budget? Hält sich p99 Latency in der gleichen Band wie die Control Group? Brennt das Error-Budget schneller als Baseline? Wenn keine dieser Fragen instrumentiert ist, ist der Rollout-Plan ein Zeitstrahl, keine Validierungsschleife. Ein Setup, das in Production hält: definiere zwei SLO-Evaluierungsfenster. Ein kurzes Fenster (15 Minuten) fängt schnelle Ausfälle – eine schlechte Datenbankabfrage, ein Schema Mismatch, eine Regression in einem kritischen Pfad. Ein längeres Fenster (24 Stunden oder ein vollständiger Traffic-Zyklus) fängt graduelles Degradation – Memory Leaks, Cache Pressure, Edge Cases in Low-Frequency-Traffic-Segmenten. Verlange, dass beide Fenster vor jedem Schritt grün sind. Wenn eines verletzt wird, stoppe den Rollout und benachrichtige On-Call. Der Prozentsatz ist ein Regler. Das SLO-Fenster ist das Gate. Beide sind erforderlich. ## Kill-Switch Engineering: Design es, bevor du es brauchst Der Kill Switch ist kein Fallback. Er ist eine First-Class-Designentscheidung, die existieren sollte, bevor die erste Zeile Feature-Code geschrieben wird. Ein Kill Switch, der unter Druck gestaltet wird, ist ein Kill Switch mit ungeprüften Annahmen. Du testest ihn zum ersten Mal während eines aktiven Incidents, in einer Terminalsession, die von einer PagerDuty-Benachrichtigung geöffnet wurde, mit fünf Leuten, die einen Slack-Thread beobachten. Das ist der schlechtestmögliche Moment, um zu entdecken, dass dein Ops-Flag Nutzer nach Session-ID zielt und dein Session-Service gerade degradiert ist. ![SLO monitoring dashboard with error budget burn rate charts and kill switch indicator for feature rollout control](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-08/dd1477-inline2.webp) Drei Eigenschaften sind nicht verhandelbar für jeden Kill Switch, der für Production gedacht ist: - **Sub-50ms lokale Evaluierung**: die Flag-Prüfung kann kein Netzwerk-Call zu einem Remote-Evaluierungsdienst sein. Wenn die Evaluierung von einem Dienst abhängt, der selbst degradiert sein könnte, hast du eine zirkuläre Abhängigkeit in deinem Incident-Response-Pfad. - **Expliziter Fallback-Wert**: was gibt das Flag zurück, wenn der Flag-Dienst unerreichbar ist? Das muss dokumentiert, im Code definiert und getestet sein. Egal was das SDK-Default ist ist keine Antwort. - **Getestet unter Abhängigkeitsausfall**: Kill Switches sollten Teil deiner Chaos-Engineering-Rotation sein. Validiere sie gegen Szenarien, wo Auth degradiert ist, wo der Flag-Dienst selbst down ist, und wo die Netzwerk-Latenz zum Evaluierungs-Endpoint 2 Sekunden übersteigt. Die Teams, die Incident Response sauber ausführen, sind die, die trainiert haben. Der Kill Switch ist Teil des Runbook. Mach ihn langweilig. ## Flag Debt: Die technische Schuld, die niemand auf dem Roadmap notiert Teams, die Feature Flags aggressiv einführen, sammeln oft das an, was manchmal Flag Debt genannt wird: Flags, die ihren Zweck erfüllt haben, aber nie entfernt wurden. Das Feature wurde shipped, das Experiment ging zu Ende, das Beta endete. Das Flag blieb. Bei 50 Flags ist das eine kleine Unannehmlichkeit. Bei 500 Flags über ein verteiltes System hinweg ist es ein aktives operatives Risiko. Jedes Flag ist ein Code-Branch, der Wartung, Tests und Verständnis bei Incident-Untersuchung erfordert. Ein Entwickler, der um 2 Uhr morgens ein Fehlverhalten nachverfolgst, will nicht durch 40 Conditional Branches tracen, um das relevante zu finden. Ein über mehrere Platform-Teams beobachtetes Pattern: Flag-Evaluierungs-Middleware erscheint in den Top-Five Stack Frames für p99 Latency. Die Ursache in den meisten Fällen sind alte Flags mit komplexen Targeting-Regeln, die bei jedem Request Dutzende Bedingungen evaluieren, das Gewicht von Entscheidungen tragend, die vor zwei Jahren getroffen wurden und die sich niemand traute, zu löschen. Die Gegenmaßnahme ist organisatorisch, nicht technisch. Jedes erstellte Flag sollte drei Attribute haben: einen Owner, einen Typ (Release, Experiment, Ops, Permission) und ein erwartetes Removal-Datum. Release Flags sollten innerhalb von zwei Sprints nach vollständigem Rollout entfernt werden. Experiment Flags sollten entfernt werden, wenn das Experiment endet, nicht wenn jemand dazu kommt. Das Flag-Inventar sollte auf Abruf auditierbar sein und auf Engineering-Health-Dashboards sichtbar. ## Targeting-Granularität: Die Dimension, die bei Enterprise-Scale bricht Die meisten Feature-Flag-Plattformen unterstützen Percentage-basierte Rollouts und einfaches User-Attribute-Targeting. Der Gap, der bei Enterprise-Scale auftaucht, ist Targeting-Granularität: die Fähigkeit, Rollout-Regeln auszudrücken, die spezifisch genug sind, um nützlich zu sein, ohne komplex genug zu sein, um unmerklich zu werden. Eine nützliche Targeting-Hierarchie für Production Rollouts auf Platform-Team-Ebene: - **Environment-Level**: Production, Staging, Preview. Das erste Gate, nicht das einzige. - **Infrastruktur-Segment**: Rechenzentrum, Availability Zone oder Kubernetes-Cluster. Nützlich, um geografischen Blast Radius zu isolieren. - **Account oder Tenant**: Für B2B-SaaS-Plattformen ist ein Pro-Account-Rollout oft sicherer als ein Pro-User-Prozentsatz-Rollout, weil du den kompletten Traffic-Muster eines Accounts beobachten kannst statt einer statistischen Stichprobe. - **User-Cohort**: Beta-Nutzer, interne Nutzer, Power-Nutzer nach Activity-Tier. - **Session-Attribut**: Nützlich für Experiment Flags, gefährlich für Ops Flags. Die Plattformen, die das gut implementieren (LaunchDarkly und Statsig werden von SRE-Teams, die das im großen Stil tun, am häufigsten zitiert) erlauben komplexe Rule-Komposition ohne dass Engineering-Zeit erforderlich ist, um die Targeting-Logik während eines aktiven Rollouts zu modifizieren. Diese Self-Service-Fähigkeit ist der Unterschied zwischen einer 30-Sekunden-Rollout-Pause und einem Ticket zum Platform-Team. Die Plattformen, die das schlecht implementieren, zwingen dich, zwischen Targeting-Granularität und operativer Einfachheit zu wählen. Dieser Tradeoff wird sich um 3 Uhr morgens zeigen. ## Was das Post-Mortem immer wieder findet Jedes Post-Mortem für einen Feature-bezogenen Production Incident stellt die gleichen Fragen. Wurde das Feature hinter einem Flag gesperrt? War der Rollout progressiv? Gab es eine Validierungsbedingung zwischen den Stufen? Wurde der Kill Switch vor dem Incident getestet? Wenn alle vier Antworten ja sind, ist der Incident ein Kalibrierungsproblem: Schwellenwerte zu locker gesetzt, Targeting-Regeln mit einem Edge Case, SDK-Evaluierungsverhalten unter Netzwerkpartition, das nicht berücksichtigt wurde. Das sind lösbar mit Konfigurationsänderungen und Runbook-Updates. Wenn eine Antwort nein ist, ist der Incident ein Architektur-Problem. Feature Flags sind keine Debugging-Bequemlichkeit. Sie sind eine Deployment-Architektur-Entscheidung. Diese Entscheidung existiert entweder bevor das Feature shipped, oder sie existiert gar nicht. Die Frage, die es wert ist, vor dem nächsten Release beantwortet zu werden: Was würde das Post-Mortem über diesen Rollout sagen, wenn heute Nacht etwas schiefgeht? ## FAQ ### Was ist der Unterschied zwischen Deployment und Release? Deployment bedeutet, Code in Production zu bringen; Release bedeutet, ihn Nutzern verfügbar zu machen. Feature Flags trennen diese zwei Events, sodass du Code deployen kannst, ohne ihn sofort zu aktivieren. Das reduziert Blast Radius und ermöglicht schrittweise Validierung. ### Warum benötige ich einen Kill Switch? Ein Kill Switch ist eine permanente Infrastrukturkomponente, die es dir ermöglicht, ein Feature sofort zu deaktivieren, wenn es Production beeinträchtigt. Ohne Kill Switch brauchst du einen Rollback, was langsamer und riskanter ist. Kill Switches müssen lokal (sub-50ms) evaluiert und unter Abhängigkeitsausfällen getestet sein. ### Welche vier Flag-Typen gibt es? Release Flags gaten Features während der Entwicklung; Experiment Flags betreiben A/B-Tests; Ops Flags sind Kill Switches und Circuit Breaker; Permission Flags kontrollieren Zugriff nach Tier oder Plan. Jeder Typ hat unterschiedliche Lebenszyklen und Verwaltungsanforderungen. ### Was ist Flag Debt? Flag Debt ist die Ansammlung von Flags, die ihren ursprünglichen Zweck erfüllt haben, aber nicht entfernt wurden. Bei Hunderten von Flags wird jeder ein Performance-Risiko, da jeder Code-Pfad getestet und verstanden sein muss. Kontermittel: Owner, Typ und Removal-Datum für jeden Flag. ### Was ist ein SLO-Gate in einem Rollout? Ein SLO-Gate ist eine Validierungsbedingung zwischen Rollout-Stufen. Bevor du von 5 % auf 25 % Traffic wechselst, überprüfst du, ob Error-Rate, Latency und Error-Budget-Burn-Rate im erwarteten Bereich sind. Ohne SLO-Gate ist ein Rollout-Plan nur ein Zeitstrahl, keine Validierungsschleife. ### Wie wähle ich zwischen Targeting-Optionen? Eine Hierarchie: Environment (Production/Staging) > Infrastruktur-Segment (Rechenzentrum/AZ) > Account/Tenant (für B2B) > User-Cohort (Beta/Power-Nutzer) > Session-Attribut (für Experimente). Gute Plattformen (LaunchDarkly, Statsig) erlauben selbstständige Rule-Komposition; schlechte zwingen dich, zwischen Granularität und Einfachheit zu wählen. ### Was sollte ich im Post-Mortem eines fehlgeschlagenen Rollouts prüfen? Vier Fragen: War das Feature hinter einem Flag? War der Rollout progressiv? Gab es SLO-Gates zwischen Stufen? Wurde der Kill Switch vor dem Incident getestet? Wenn alle ja sind, ist es ein Kalibrierungsproblem (lösbar). Wenn eine nein ist, ist es ein Architektur-Problem (präventiv redesign).