Feature Flags und Freigabe von fich

Feature Flag (FF) ist eine verwaltete Bedingung, die das Systemverhalten aktiviert/deaktiviert, ohne Code freizugeben. Flags ermöglichen: Fiches sicher ausrollen, Benutzer-/Markt-/Tenant-Gruppen ins Visier nehmen, problematische Komponenten schnell abschalten, Experimente durchführen und Parameter in der Rantime konfigurieren.

• Blast Radius bei Releases reduzieren.
• Trennung von Bereitstellung und Aktivierung.
• Ermöglichen Sie ein transparentes Änderungsmanagement mit Audit, SLO und Rollback „mit einem Klick“.

1) Arten von Flaggen und wann sie anzuwenden sind

Release Flags - stufenweise Aufnahme eines neuen Filzstifts (Dark → Canary → Ramp-Up → 100%).
Ops/Kill-Switch - sofortige Deaktivierung von Abhängigkeiten (Provider, Subsystem, Heavy Computing).
Experiment (A/B, Multi-Variante) - Aufteilung des Verkehrs in Varianten (Gewichte, Sticky Bucketing).
Permission/Entitlement - Zugriff auf Fics nach Rollen/Plänen/Jurisdiktionen.
Remote Config - Verhaltensparameter (Schwellenwert, Timeout, Formel) aus dem Flag/Config.
Migration flags - Schaltpläne/Datenpfade wechseln (Umzug in einen neuen Index/DB/Endpunkt).

Anti-Muster: Die gleiche „Pro-Alles“ -Flag - in Fith, Comp-Switch und Parameter brechen.

2) Flaggendatenmodell (Minimum)

yaml flag:
key: "catalog. new_ranker"
type: "release"    # release      ops      kill      experiment      permission      config     migration description: "New Directory Ranking"
owner: "search-team@company"
created_at: "2025-10-01T10:00:00Z"
ttl: "2026-01-31" # delete deadline after 100% enable rules:
- when:
tenant_id: ["brand_eu","brand_latam"]
region: ["EE","BR"]
user_pct: 10 # progressive percentage then: "on"
- when:
kyc_tier: ["unverified"]
then: "off"
variants: # for experiments
- name: "control"; weight: 50
- name: "v1"; weight: 30
- name: "v2"; weight: 20 payload:
v1:
boost_freshness: 0. 3 boost_jackpot:  0. 2 v2:
boost_freshness: 0. 2 boost_jackpot:  0. 4 prerequisites: # dependent flags/schema versions
- key: "catalog. index_v2_ready"
must_be: "on"
audit:
require_ticket: true change_window: "09:00-19:00 Europe/Kyiv"
safeguards:
max_rollout_pct: 50 # stop threshold auto_rollback_on:
p95_ms: ">200"
error_rate: ">2%"

3) Bewertung und Targeting (Evaluation)

Ключи таргетинга: `tenant_id, region/licence, currency, channel, locale, role, plan, device, user_id, cohort, kyc_tier, experiment_bucket`.
Bewertungsreihenfolge: prerequisites → deny-rules → allow-rules → default.
Sticky Bucketing: Für Experimente eine stabile ID hashen (z.B. 'hash (user_id, flag_key)') - damit der Benutzer immer eine Option erhält.

ts result = evaluate(flag, context)  // pure function if (!prereqs_ok(result)) return OFF if (deny_match(result, ctx)) return OFF if (allow_match(result, ctx)) return resolve_variant_or_on(result, ctx)
return flag. default

4) FF-Verteilung und Architektur

• Server-side SDK (empfohlen): Wahrheitsquellen und Cache im Backend; Vereinheitlichung der Logik.
• Edge/CDN-Auswertung: Schnelles Targeting am Perimeter (wo es keine PII/Geheimnisse gibt).
• Client-side SDK: wenn Sie eine UI-Personalisierung benötigen, aber - nur mit minimalem Kontext und ohne sensible Regeln.
• Config-as-Code: Speicherung der Flags im Repository, CI-Validierung, Rollout via CD.

• Startup Bootstrap + Streaming Updates (SSE/gRPC) + Fallback zum neuesten Snapshot.
• SLA „freshness“ -Flags: p95 ≤ 5 s.

5) Freigabestrategien

5. 1 Dark Launch

Ficha ist aktiviert, aber für den Benutzer unsichtbar; Wir sammeln Metriken und Fehler.

5. 2 Canary

1-5% des Datenverkehrs in einer Jurisdiktion/Tenant; Überwachung p95/p99, Fehler, Konvertierung.
Stop-Bedingungen sind die Schwellentrigger eines Autokathofs nach Metriken.

5. 3 Progressive Rollout

10% → 25% → 50% → 100% nach Zeitplan mit manueller/automatischer Verifizierung.

5. 4 Shadow / Mirroring

Wir duplizieren Abfragen in einen neuen Pfad (ohne sichtbaren Effekt) und vergleichen die Ergebnisse/Latenz.

5. 5 Blue/Green + FF

Wir erweitern zwei Versionen; flag lenkt den Verkehr und schaltet die Abhängigkeiten nach Segmenten um.

6) Abhängigkeiten und serviceübergreifende Konsistenz

Verwenden Sie Prerequisites und „Health-Flags“ bereit: Index gebaut, Migration abgeschlossen.
Koordination durch Ereignisse: „FlagChanged (flag_key, Scope, new_state)“.

1. read-path → 2) Metriken überprüfen → 3) write/side-effects aktivieren.

• Serviceverträge: Der Ausfall muss sicher sein (fail-safe OFF).

7) Beobachtbarkeit und SLO

• `flag_eval_p95_ms`, `errors_rate`, `config_freshness_ms`.
• Geschäftskennzahlen: 'ctr', 'conversion', 'ARPU', 'retention', guardrails (z.B. RG-Vorfälle).
• Automatische SLO-Schwellen für Autokathofen.

Protokolle/Tracing: 'flag _ key', 'variant', 'decision _ source' (server/edge/client), 'context _ hash' hinzufügen.

Dashboards: „Leiter“ rollout mit Schwellen, heatmap Fehler durch Segmente.

8) Sicherheit und Compliance

PII-Minimierung im Kontext.
RLS/ACL: Wer kann welche Flags ändern (nach Domains/Märkten).
Einstündige Änderungsfenster (Change Windows) und „Double Acknowledge“ für sensible Flags.
Unveränderliches Audit: Wer/Wann/Was/Warum (Ticket/Incident Link).
Jurisdiktionen: Flaggen dürfen regulatorische Verbote nicht umgehen (z. B. das Spielen in einem verbotenen Land ermöglichen).

9) Verwaltung von „langlebigen“ Flaggen

Jede Flagge hat ein TTL/Löschdatum.
Nach 100% Aktivierung - Erstellen Sie eine Aufgabe zum Entfernen von Codezweigen, da sonst die „Flag-Pflicht“ wächst.
Markieren Sie die Flaggen als' migration '/' one-time', trennen Sie sie von den permanenten 'permission/config'.

10) Beispielvertrag API/SDK

Evaluation API (server-side)

http
POST /v1/flags/evaluate
Headers: X-Tenant: brand_eu
Body: { "keys":["catalog. new_ranker","rgs. killswitch"], "context": { "user_id":"u42", "region":"EE" } }
→ 200
{
"catalog. new_ranker": { "on": true, "variant":"v1", "as_of":"2025-10-31T12:10:02Z" },
"rgs. killswitch":  { "on": false, "variant":null, "as_of":"2025-10-31T12:10:02Z" }
}

Client SDK (кэш, fallback)

ts const ff = await sdk. getSnapshot()     // bootstrap const on = ff. isOn("catalog. new_ranker", ctx)
const payload = ff. payload("catalog. new_ranker", "v1")

11) Interaktion mit anderen Kreisläufen

Ratenlimits/Quoten: Flags können den RPS senken/Drosseln für die Dauer des Vorfalls aktivieren.
Circuit breaker/degradation: Kill-Switches schalten schwere Pfade ab und ermöglichen Degradation.
Katalog/Personalisierung: Flags ändern Gewichte/Ranking-Regeln (über Remote Config).
DB-Migrationen: Flags übersetzen die Lese-/Schreibvorgänge schrittweise auf ein neues Schema (read-replica → dual-write → write-primary).

12) Playbooks (Runbooks)

1. Vorfall nach Aufnahme 25%

Autokathof ausgelöst → Flag OFF für alle/Segment, Ticket im On-Call, Sammelstände, RCA.
Zeitweilig Abbau/alter Zweig über Migration-Flag aktivieren.

2. P95 Wachstum nach Katalog

Schwelle „p95 _ ms> 200“ - Autokathof; SnapShots von Protokollen mit 'flag _ key = catalog. new_ranker`.
Vereinfachte Rankingsignale aktivieren (payload config).

3. Unvereinbarkeit der Zuständigkeit

Flag permission fälschlicherweise eröffnete das Spiel in 'NL' - OFF + Post-Fact-Audit, Hinzufügen der guard-Regel „region deny“.

4. Varianz in A/B

Stoppen Sie das Experiment, führen Sie eine CUPED/stratifizierte Analyse durch, scrollen Sie mit aktualisierten Gewichten um.

13) Testen

Einheit: deterministische Bewertung von Regeln/Prioritäten/Vorbesuchen.
Vertrag: Flag-Schema (JSON/YAML), Validatoren, CI-Check vor dem Merge.
Property-based: „deny> allow“, „most specific wins“, stabiles Bucketing.
Replay: Wiedergabe realer Kontexte in einer neuen Konfiguration.
E2E: Kanarienskripte (Step-up/Step-down), Autokathof-Check und Audit-Events.
Chaos: Streaming-Klippe, veralteter Snap-Shot, massives Flaggen-Update.

14) Typische Fehler

Geheime Logik in Client-Flags (Lecks/Ersatz).
Das Fehlen von TTL → den „Friedhof“ der Flaggen im Code.
„Universelle“ Flags ohne Segmentierung → Es ist unmöglich, das Problem zu lokalisieren.
Keine Guardrails/Autokathofen - manuelle Vorfälle.
Inkompatible Abhängigkeiten zwischen Flags → Schleifen/Rassynhron.
Bewertung von Flags in jeder Abfrage ohne Cache → Latenzspitzen.
Kein Audit/Änderungsfenster - Compliance-Risiken.

15) Checkliste vor dem Verkauf

• Das Flag wird mit Typ, Besitzer, Beschreibung, TTL und Ticket-Anforderung erstellt.
• Targeting-Regeln sind definiert; 'deny' für unerwünschte Regionen/Rollen.
• Sticky Bucketing ist deterministisch; id ist stabil ausgewählt.
• Vorbesuche und Gesundheitsflaggen sind fertig; Standard ist sicher.
• Dashboards und Alerts auf p95/p99, error_rate, Business-Guardrails.
• Der Autocatof ist eingerichtet; Stopp-Rollout-Schwelle und Rollback-Bedingungen.
• Kanarejetschnyj der Plan: die Prozente/Etappen/Fenster/Verantwortlichen der Veränderungen.
• Configi werden im CI validiert; Der Snapshot ist über Cluster/Regionen verteilt.
• Dokumentation für Support/Produkt; Playbooks der Vorfälle.
• Plan zum Entfernen der Codezweige und der Flagge selbst nach 100%.

16) Beispiel „Migration“ Flag (DB/Index)

yaml flag:
key: "search. use_index_v2"
type: "migration"
description: "Switching reads to index v2"
prerequisites:
- key: "search. index_v2_built"
must_be: "on"
rules:
- when: { tenant_id: ["brand_eu"], user_pct: 5 } then: "on"
- when: { tenant_id: ["brand_eu"], user_pct: 25 } then: "on"
safeguards:
auto_rollback_on:
search_p95_ms: ">180"
error_rate: ">1%"
ttl: "2026-02-01"

Schlussfolgerung

Feature Flags sind nicht nur „on/off“, sondern die Disziplin des Change Risk Managements. Klare Flaggentypen, deterministisches Targeting, progressive Layouts mit Guardrails, Autokathof, Audit und Löschplan machen Releases vorhersehbar und Vorfälle prägnant und kontrollierbar. Bauen Sie Flaggen als erste Klasse der Bürger in die Architektur ein - und Sie können den Wert häufiger, sicherer und sinnvoller liefern.