Caracteristică Steaguri și versiune caracteristică

Feature Flag (FF) este o condiție gestionată care permite/dezactivează comportamentul sistemului fără a elibera cod. Steagurile vă permit: să introduceți funcții în siguranță, grupuri țintă de utilizatori/piețe/chiriași, să dezactivați rapid componentele problematice, să efectuați experimente și să configurați parametrii în timpul rulării.

• Reduceți raza de explozie pentru eliberări.
• Implementare și activare separate.
• Permiteți gestionarea transparentă a schimbărilor cu audit, SLO și rollback cu un singur clic.

1) Tipuri de steaguri și când să le aplicați

Lansați steaguri - includerea treptată a unei noi caracteristici (întuneric → canar → rampă-up → 100%).
Ops/kill-switch - deconectarea instantanee a dependențelor (furnizor, subsistem, calcule grele).
Experiment (A/B, multi-variantă) - împărțirea traficului în variante (greutăți, bucketing lipicios).
Permisiunea/Dreptul - accesul la funcții prin rol/plan/jurisdicție.
Config la distanță - parametrii de comportament (prag, timeout, formulă) de la pavilion/config.
Steaguri de migrare - scheme de comutare/căi de date (trecerea la un nou index/DB/punct final).

Anti-model: același pavilion „despre tot” - împărțit în caracteristică, comutator rep și parametri.

2) Model de date de pavilion (minim)

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) Evaluarea și direcționarea

: 'chiriaș _ id, regiune/licență, valută, canal, local, rol, plan, dispozitiv, , cohortă, .
Ordinea de evaluare: condiții prealabile → refuza regulile → permit reguli → implicit.
Bucketing lipicios: pentru experimente, hash un identificator stabil (de exemplu, „hash (user_id, flag_key)”), astfel încât utilizatorul primește întotdeauna o opțiune.

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 distribuție și arhitectură

• Server-side SDK (recomandat): surse de adevăr și cache în backend; unificarea logicii.
• Evaluare Edge/CDN: direcționare rapidă pe perimetru (unde nu există PII/secrete).
• SDK client: atunci când aveți nevoie de personalizare UI, dar numai cu context minim și fără reguli sensibile.
• Config-as-Code: stocarea steagurilor în depozit, validarea CI, rollout prin CD.

• Startup bootstrap + actualizări de streaming (SSE/gRPC) + rezervă la ultimul instantaneu.
• Steaguri „prospețime” SLA: p95 ≤ 5 s.

5) Strategii de lansare

5. 1 Lansare întunecată

Caracteristica este activată, dar invizibilă utilizatorului; colecta metrici și erori.

5. 2 Canare

Includem 1-5% din trafic într-o singură jurisdicție/chiriaș; monitor p95/p99, erori, conversie.
Condiții de oprire - declanșează pragul autocatoph prin măsurători.

5. 3 Rollout progresiv

10% → 25% → 50% → 100% programat cu verificare manuală/automată.

5. 4 Umbră/Oglindire

Duplicăm cererile către noua cale (fără efect aparent) și comparăm rezultatele/latența.

5. 5 Albastru/Verde + FF

Implementăm două versiuni; steagul conduce traficul și comută dependențele pe segmente.

6) Dependențe și consistență încrucișată

Utilizați condiții prealabile și „steaguri de sănătate” de pregătire: indicele este construit, migrația este finalizată.
Coordonarea prin evenimente: „FlagChanged (flag_key, domeniu de aplicare, new_state)”.

1. activați citirea traseului → 2) verificați măsurătorile → 3) activați scrierea/efectele secundare.

• Contracte de servicii: default trebuie să fie în siguranță OFF.

7) Observabilitate și SLO

• 'flag _ eval _ p95 _ ms',' errors _ rate ',' config _ freshness _ ms'.
• Valori de afaceri: „ctr”, „conversie”, „ARPU”, „retenție”, parapete (de ex. Incidente RG).
• Praguri automate SLO pentru autocatopa.

Jurnale/urmărire: adăugați 'flag _ key', 'variant', 'decision _ source' (server/edge/client), 'context _ hash'.

Tablouri de bord: rollout „scara” cu praguri, erori heatmap pe segmente.

8) Siguranță și conformitate

PII-minimizare în context.
RLS/ACL: cine poate schimba ce steaguri (după domeniu/piață).
Ferestre oră de modificări (schimbare ferestre) și „dublă confirmare” pentru steaguri sensibile.
Audit imuabil: cine/când/ce/de ce (link bilet/incident).
Jurisdicții: steagurile nu trebuie să eludeze interdicțiile de reglementare (de exemplu, să includă jocul într-o țară interzisă).

9) Gestionarea steagurilor „de lungă durată”

Fiecare steag are o dată TTL/ștergere.
După includerea 100% - creați o sarcină de a șterge sucursalele de cod, în caz contrar „datoria de pavilion” va crește.
Marcați steagurile ca „migrație ”/„ o singură dată”, separați-le de constanta „permisiune/config”.

10) Contract de probă API/SDK

API de evaluare (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 (кэш, rezervă)

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

11) Interacțiunea cu alte circuite

Limite/cote de tarif: steagurile pot reduce SPR/activa accelerarea pe durata incidentului.
Întrerupător/degradare: kill-switchi dezactivează căile grele și permite degradarea.
Director/Personalizare: Steagurile schimbă greutatea/regulile de clasificare (prin intermediul Remote Config).
Migrarea bazelor de date: steagurile traduc treptat citirile/scrierile într-o nouă schemă (citire-replică → scriere dublă → scriere primară).

12) Cărți de joc (runbooks)

1. Incident după includerea a 25%

Autocatoff a declanșat → steag OFF pentru toate/segment, bilet la apel, colectarea statisticilor, RCA.
Permite temporar degradarea/ramura veche prin drapelul de migrare.

2. creșterea catalogului p95

Prag 'p95 _ ms> 200' - autocatoph; fixați un instantaneu de jurnale cu 'flag _ key = catalog. new_ranker'.
Activați configurarea sarcinii utile.

3. Lipsa jurisdicției

Steagul permisiunii a deschis din greșeală jocul în auditul „NL” - OFF + post-fapt, adăugând regula de gardă „regiunea neagă”.

4. Variația în A/B

Opriți experimentul, efectuați analiza CUPED/stratificată, re-rola cu scale actualizate.

13) Testarea

Unitate: evaluare deterministă a regulilor/priorităților/condițiilor prealabile.
Contract: sistem de pavilion (JSON/YAML), validatoare, verificare CI înainte de fuzionare.
Bazat pe proprietate: „neagă> permite”, „cele mai multe câștiguri specifice”, bucketing stabil.
Replay-Plays contexte reale pe noua configurație.
E2E: scripturi canare (step-up/step-down), autocatoff check and audit events.
Haos: Streaming faleză, instantaneu moștenire, actualizare masivă de pavilion.

14) Erori tipice

Logică secretă în steagurile clienților (scurgeri/spoofing).
Absența TTL → „cimitirul” steagurilor în cod.
Steagurile „universale” fără segmentarea → nu pot localiza problema.
Fără parapete/autocatofone - incidente manuale.
Dependențe incompatibile între steaguri → bucle/în afara sincronizării.
Evaluarea steagurilor în fiecare cerere fără vârfuri de cache → latență.
Nicio fereastră de audit/schimbare - riscuri de conformitate.

15) Lista de verificare pre-vânzare

• Steag creat cu tipul, proprietarul, descrierea, TTL și cerința biletului.
• Regulile de direcționare definite; „deny” pe regiuni/roluri nedorite.
• Bucketing lipicios este determinist; ID-ul este stabil.
• Prerechizite și steaguri de sănătate gata; safe implicit.
• Tablouri de bord și alerte pe p95/p99, error_rate, parapete de afaceri.
• Autocatoff configurat; pragul de oprire și condițiile de întoarcere.
• Planul Canare - Procente/Repere/Fereastră de schimbare/Proprietari
• Configurările sunt validate în CI; instantaneu distribuit în grupuri/regiuni.
• Suport/documentația produsului; playbook-uri incidente.
• Planul de a elimina ramurile de cod și pavilionul în sine după 100%.

16) Exemplu de pavilion „migrație” (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"

Concluzie

Feature Flags nu este doar „on/off”, ci disciplina managementului riscului de schimbare. Tipurile clare de pavilion, direcționarea deterministă, afișajele progresive cu parapete, autocathof, audit și plan de ștergere fac lansările previzibile și incidentele concise și controlate. Construiți steaguri în arhitectură ca o primă clasă de cetățeni - și puteți oferi valoare mai des, mai sigur și mai semnificativ.