Feature Flags və Fich Release

Feature Flag (FF) kodu buraxmadan sistemin davranışını əhatə edən/söndürən idarə olunan bir şərtdir. Bayraqlar imkan verir: təhlükəsiz fiçləri yuvarlamaq, istifadəçi qruplarını/bazarları/tenantları hədəfləmək, problemli komponentləri tez bir zamanda söndürmək, təcrübələr aparmaq və kirayədə parametrləri konfiqurasiya etmək.

• Buraxılışlarda blast radius azaldın.
• Yerləşdirmə və aktivləşdirməni bölün.
• Audit, SLO və «bir kliklə» geri dönüş ilə dəyişikliklərin şəffaf idarə edilməsini verin.

1) Bayraq növləri və nə zaman tətbiq olunur

Release flags - yeni fiçanın mərhələli daxil edilməsi (dark → canary → ramp-up → 100%).
Ops/kill-switch - asılılığın dərhal dayandırılması (provayder, alt sistem, ağır hesablamalar).
Experiment (A/B, multi-variant) - trafikin variantlara (weights, sticky bucketing) bölünməsi.
Permission/Entitlement - rollara/planlara/yurisdiksiyalara görə fiçalara giriş.
Remote Config - bayraqdan/konfiqdən davranış parametrləri (eşik, vaxt, formula).
Migration flags - verilənlər sxemləri/yolları keçid (yeni indeks/DB/end-point keçid).

Anti-nümunə: eyni «hər şey haqqında» bayraq - fichu, comp switch və parametrləri parçalayın.

2) Bayraq məlumat modeli (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) Qiymətləndirmə və hədəfləmə (evaluation)

Ключи таргетинга: `tenant_id, region/licence, currency, channel, locale, role, plan, device, user_id, cohort, kyc_tier, experiment_bucket`.
Qiymətləndirmə qaydası: prerequisites → deny-qaydalar → allow-qaydalar → defolt.
Sticky bucketing: Təcrübələr üçün sabit bir identifikator (məsələn, 'hash (user_id, flag_key)') - istifadəçinin həmişə bir seçim alması üçün.

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 paylanması və arxitekturası

• Server-side SDK (tövsiyə olunur): arxa planda həqiqət mənbələri və cache; məntiq unifikasiyası.
• Edge/CDN evaluation: perimetrdə sürətli hədəfləmə (PII/sirləri yoxdur).
• Client-side SDK: UI-ni personallaşdırmaq lazım olduqda, lakin - yalnız minimal kontekstlə və həssas qaydalar olmadan.
• Config-as-Code: anbarda bayraqların saxlanması, CI validasiyası, CD vasitəsilə rollout.

• Startup bootstrap + streaming updates (SSE/gRPC) + son snapshot üçün fallback.
• SLA «freshness» bayraqlar: p95 ≤ 5 s

5) Buraxılış strategiyaları

5. 1 Dark Launch

Ficha aktiv, lakin istifadəçi üçün görünməz; metrik və səhvləri toplayırıq.

5. 2 Canary

Bir yurisdiksiya/tenantada trafikin 1-5% -ni daxil edin; p95/p99 monitorinq, səhvlər, dönüşüm.
Stop conditions - metriklərə görə avtokatofun eşik triggerləri.

5. 3 Progressive Rollout

10% → 25% → 50% → 100% əllə/avtomatik yoxlama ilə.

5. 4 Shadow / Mirroring

Yeni bir yolda sorğuları təkrarlayın (görünən effekt olmadan) və nəticələri/gecikməni müqayisə edin.

5. 5 Blue/Green + FF

İki versiyanı açırıq; bayraq trafiki idarə edir və seqmentlərə görə asılılığı dəyişir.

6) Asılılıq və xaç-xidmət sabitliyi

prerequisites və «sağlamlıq bayraqları» hazır istifadə edin: indeks quruldu, miqrasiya tamamlandı.
Hadisələr vasitəsilə koordinasiya: 'FlagChanged (flag_key, scope, new_state)'.

1. read-way daxil → 2) metrik yoxlamaq → 3) write/side-effects daxil.

• Xidmət müqavilələri: defolt təhlükəsiz olmalıdır (fail-safe OFF).

7) Müşahidə və SLO

• `flag_eval_p95_ms`, `errors_rate`, `config_freshness_ms`.
• Biznes metrikası: 'ctr', 'conversion', 'ARPU', 'retention', guardrails (məsələn, RG hadisələri).
• Avtokatof üçün avtomatik SLO eşikləri.

Log/Trace: 'flag _ key', 'variant', 'decision _ source' (server/edge/client), 'context _ hash' əlavə edin.

Dashboard: «pilləkən» eşik rollout, seqmentlər üzrə səhvlər heatmap.

8) Təhlükəsizlik və uyğunluq

kontekstdə PII-minimallaşdırma.
RLS/ACL: Kim hansı bayraqları dəyişə bilər (domenlər/bazarlar üzrə).
Saat pəncərələri dəyişikliklər (change windows) və həssas bayraqlar üçün «ikili təsdiq».
Dəyişməz audit: kim/nə vaxt/nə üçün (ticket/incident link).
Yurisdiksiyalar: bayraqlar tənzimləyici qadağalardan yan keçməməlidir (məsələn, qadağan olunmuş ölkədə oyun daxildir).

9) «Uzunömürlü» bayraqların idarə edilməsi

Hər bayrağın TTL/silinmə tarixi var.
100% daxil olduqdan sonra - kod budaqlarını silmək üçün task yaradın, əks halda «bayraq-borc» artacaq.
Bayraqları 'migration '/' one-time' kimi qeyd edin, onları daimi 'permission/config' -dən ayırın.

10) API/SDK müqaviləsinin nümunəsi

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) Digər konturlarla qarşılıqlı əlaqə

Rate limits/kvotalar: bayraqlar hadisə zamanı RPS/trottling aşağı bilər.
Circuit breaker/degradation: kill-switchy ağır yolları söndürür və deqradasiya daxildir.
Kataloq/personalizasiya: bayraqlar çəkiləri/sıralama qaydalarını dəyişir (Remote Config vasitəsilə).
DB miqrasiyaları: bayraqlar tədricən yeni sxemə (read-replica → dual-write → write-primary) oxu/yazını köçürür.

12) Playbooks (runbooks)

1. 25% daxil olduqdan sonra hadisə

Avtokatof çalışdı → bütün/seqment üçün OFF bayrağı, on-call bileti, stats toplama, RCA.
Müvəqqəti miqration bayraq vasitəsilə deqradasiya/köhnə filial daxil edin.

2. Kataloq üzrə böyümə p95

Eşik 'p95 _ ms> 200' - avtokatof; 'flag _ key = catalog ilə log snapshot qeyd. new_ranker`.
Sadələşdirilmiş sıralama siqnallarını (payload config) işə salın.

3. Yurisdiksiya uyğunsuzluğu

Permission bayrağı səhvən «NL» oyununu açdı - OFF + post-fakt audit, «region deny» guard qaydasının əlavə edilməsi.

4. A/B-də dispersiya

Təcrübəni dayandırın, CUPED/stratified analizini yerinə yetirin, yenilənmiş tərəzi ilə yenidən işləyin.

13) Test

Unit: qaydaların/prioritetlərin/prerekvizitlərin determinik qiymətləndirilməsi.
Contract: Bayraq sxemi (JSON/YAML), validatorlar, merj qarşısında CI-yoxlama.
Property-based: «deny> allow», «most specific wins», sabit bucketing.
Replay: yeni konfiqurasiyada real kontekstləri oynatmaq.
E2E: Kanarya skriptləri (step-up/step-down), avtokatofun yoxlanılması və audit hadisələri.
Chaos: axın qırılması, köhnəlmiş snapshot, bayraqların kütləvi yenilənməsi.

14) Tipik səhvlər

Müştəri bayraqlarında gizli məntiq (sızma/dəyişdirmə).
Kodda TTL → «qəbiristanlıq» bayraqlarının olmaması.
Seqmentasiya olmadan «universal» bayraqlar → problemi lokallaşdırmaq mümkün deyil.
Heç bir guardrails/avtokatoflar - əl hadisələri.
Bayraqlar arasında uyğun olmayan asılılıqlar → dövrlər/rasinxron.
Hər sorğuda bayraqların cache olmadan qiymətləndirilməsi → gecikmə sıçrayışı.
Audit/dəyişiklik pəncərəsinin olmaması - uyğunluq riskləri.

15) Satış öncəsi yoxlama siyahısı

• Bayraq növü, owner, təsviri, TTL və bilet tələbi ilə yaradılmışdır.
• Hədəfləmə qaydaları müəyyən edilmişdir; 'deny' üçün arzuolunmaz bölgələr/rollar.
• Sticky bucketing determined; identifikator sabit seçilir.
• Prerekvizitlər və sağlamlıq bayraqları hazırdır; defolt təhlükəsiz.
• p95/p99, error_rate, Business Guardrails üçün Dashboard və Alert.
• Avtokatof konfiqurasiya; rollout stop-eşik və geri dönüş şərtləri.
• Kanarya planı: faiz/mərhələlər/dəyişiklik pəncərəsi/məsul.
• Konfiqlər CI-də təsdiqlənir; snapshot klasterlər/regionlar üzrə paylanmışdır.
• Dəstək/məhsul üçün sənədləşdirmə; hadisələrin playbook.
• 100% sonra kod budaqları və bayrağın özü aradan qaldırılması planı.

16) «Miqrasiya» bayrağının nümunəsi (DB/indeks)

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"

Nəticə

Feature Flags yalnız «on/off» deyil, dəyişiklik risklərinin idarə edilməsi intizamıdır. Aydın bayraq növləri, determinik hədəfləmə, guardrails ilə mütərəqqi hesablamalar, avtokatof, audit və silinmə planı buraxılışları proqnozlaşdırıla bilən, hadisələri isə qısa və nəzarət edilə bilən edir. Bayraqları memarlığa birinci dərəcəli vətəndaşlar kimi daxil edin - dəyərinizi daha tez-tez, daha təhlükəsiz və daha mənalı şəkildə çatdıra bilərsiniz.