Feature Flags және фич шығару

Feature Flag (FF) - бұл кодты шығармай жүйенің мінез-құлқын қамтитын/ажырататын басқарылатын шарт. Жалаулар: фичтерді қауіпсіз шығаруға, пайдаланушылар/нарықтар/тенанттар топтарын таргеттеуге, проблемалық компоненттерді жылдам ажыратуға, эксперименттер жүргізуге және рантаймдағы параметрлерді конфигурациялауға мүмкіндік береді.

• Шығарылым кезінде blast radius деңгейін төмендету.
• Өрістету мен белсендіруді бөлу.
• Аудит, SLO және «бір басу» арқылы өзгерістерді мөлдір басқару.

1) Жалаулардың түрлері және оларды қашан қолдану

Release flags - жаңа фичаны кезең-кезеңімен қосу (dark → canary → ramp-up → 100%).
Ops/kill-switch - тәуелділіктерді дереу ажырату (провайдер, кіші жүйе, ауыр есептеулер).
Experiment (A/B, multi-variant) - трафикті нұсқаларға бөлу (weights, sticky bucketing).
Permission/Entitlement - рөлдер/жоспарлар/юрисдикциялар бойынша фичтерге қол жеткізу.
Remote Config - жалаудан/конфигадан мінез-құлық параметрлері (табалдырық, таймаут, формула).
Migration flags - деректер схемаларын/жолдарын ауыстырып қосу (жаңа индекске/БД/эндпоинтке көшу).

Анти-паттерн: бір ғана «бәрі туралы» жалауы - фичаға, комп-свитчке және параметрлерге бөлшектеңіз.

2) Ту деректерінің моделі (минимум)

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) Бағалау және таргетинг (evaluation)

Ключи таргетинга: `tenant_id, region/licence, currency, channel, locale, role, plan, device, user_id, cohort, kyc_tier, experiment_bucket`.
Бағалау тәртібі: prerequisites → deny-ережелер → allow-ережелер → дефолт.
Sticky bucketing: эксперименттер үшін тұрақты идентификаторды хэштеңіз (мысалы, 'hash (user_id, flag_key)') - пайдаланушы әрқашан бір нұсқаны алуы үшін.

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 бөлу және сәулет

• Server-side SDK (ұсынылған): ақиқат көздері және бэкендтегі кэш; логиканы біріздендіру.
• Edge/CDN evaluation: периметрде жылдам таргетинг (PII/құпия жоқ).
• Client-side SDK: UI дербестендіру қажет болғанда, бірақ - тек ең аз контекспен және сезімтал ережелерсіз.
• Config-as-Code: жалауларды репозиторийде сақтау, CI валидациясы, CD арқылы rollout.

• Startup bootstrap + streaming updates (SSE/gRPC) + соңғы снапшотқа fallback.
• SLA «freshness» жалаулары: p95 ≤ 5 с.

5) Шығару стратегиясы

5. 1 Dark Launch

Фича қосылған, бірақ пайдаланушыға көрінбейді; өлшемдер мен қателерді жинаймыз.

5. 2 Canary

Бір юрисдикциядағы/теңгерімдегі трафиктің 1-5% -ын қосамыз; p95/p99 мониторинг, қателер, конверсия.
Stop conditions - автокатофтың шекті триггерлері.

5. 3 Progressive Rollout

10% → 25% → 50% → 100% қолмен/авто тексеру кестесі бойынша.

5. 4 Shadow / Mirroring

Жаңа жолдағы сұрауларды қайталаймыз (көрінетін әсерсіз) және нәтижелерді/жасырындылықты салыстырамыз.

5. 5 Blue/Green + FF

Екі нұсқаны ашамыз; жалауша трафикті басқарады және сегменттер бойынша тәуелділікті ауыстырады.

6) Тәуелділік және кросс-сервистік консистенттілік

prerequisites және дайындық «денсаулық-жалаушаларын» пайдаланыңыз: индекс құрылған, көші-қон аяқталған.
Оқиғалар арқылы үйлестіру: 'FlagChanged (flag_key, scope, new_state)'.

1. → 2) метриканы тексеру → 3) write/side-effects қосу.

• Сервистік келісімшарттар: дефолт қауіпсіз болуы тиіс (fail-safe OFF).

7) Бақылау және SLO

• `flag_eval_p95_ms`, `errors_rate`, `config_freshness_ms`.
• Бизнес-метриктер: 'ctr', 'conversion', 'ARPU', 'retention', guardrails (мысалы, RG-оқиғалар).
• Автоматты SLO-автокатофқа арналған табалдырықтар.

Логи/трейсинг: 'flag _ key', 'variant', 'decision _ source' (server/edge/client), 'context _ hash' қосыңыз.

Дашбордтар: шектері бар «баспалдақ» rollout, сегменттер бойынша қателіктер heatmap.

8) Қауіпсіздік және комплаенс

Контекстегі PII-барынша азайту.
RLS/ACL: қандай жалаушаларды кім өзгерте алады (домендер/нарықтар бойынша).
Өзгерістердің сағат терезелері (change windows) және сезімтал жалаушалар үшін «қос растау».
Өзгермейтін аудит: кім/қашан/не/неге (ticket/incident link).
Юрисдикциялар: жалаулар реттеушілік тыйым салуларды айналып өтпеуі тиіс (мысалы, тыйым салынған елдегі ойынды қосу).

9) «Ұзақ өмір сүретін» туларды басқару

Әрбір жалаушаның TTL/жойылған күні бар.
100% қосылғаннан кейін - код тармақтарын жою үшін task жасаңыз, әйтпесе «жалауша-борыш» өседі.
Жалаушаларды 'migration '/' one-time' деп белгілеңіз, оларды 'permission/config' тұрақты жалаушаларынан бөліңіз.

10) Келісімшарттың 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) Басқа контурлармен өзара әрекеттесу

Rate limits/квоталар: жалаулар инцидент кезінде RPS/троттлингті қоса алады.
Circuit breaker/degradation: kill-switchi ауыр жолдарды өшіреді және тозуды қосады.
Каталог/Дербестендіру: жалаулар салмақтарын/саралау ережелерін өзгертеді (Remote Config арқылы).
ДБ көші-қоны: жалаулар жаңа схемаға (read-replica → dual-write → write-primary) оқуларды/жазбаларды кезең-кезеңімен ауыстырады.

12) Плейбуктар (runbooks)

1. Қосылғаннан кейінгі инцидент 25%

Автокатоф жұмыс істеді → Барлық/сегмент үшін OFF жалауы, on-call тикеті, статустарды жинау, RCA.
Көші-қон жалауы арқылы тозуды/ескі тармақты уақытша қосу.

2. p95 каталогының биіктігі

'p95 _ ms> 200' - автокатоф шегі; 'flag _ key = catalog. new_ranker`.
Реттеудің жеңілдетілген сигналдарын қосу (payload config).

3. Юрисдикцияның сәйкессіздігі

Permission жалауы 'NL' - OFF + пост-факт аудит, «region deny» guard ережесін қосу ойынын қате ашты.

4. A/B дисперсиясы

Экспериментті тоқтату, CUPED/stratified талдауын орындау, жаңартылған таразылармен қайта өңдеу.

13) Тестілеу

Unit: ережелерді/басымдықтарды/пререквизиттерді детерминирленген бағалау.
Contract: жалаулар схемасы (JSON/YAML), валидаторлар, мердж алдындағы CI-тексеру.
Property-based: «deny> allow», «most specific wins», тұрақты bucketing.
Replay: жаңа теңшелімде нақты мәтінмәндерді ойнату.
E2E: канареялық скрипттер (step-up/step-down), автокатофты және аудит оқиғаларын тексеру.
Chaos: стримингтің үзілуі, ескірген снапшот, жалауларды жаппай жаңарту.

14) Типтік қателер

Клиенттік жалаулардағы құпия логика (ағу/ауыстыру).
Кодта TTL → «зират» жалауларының болмауы.
Сегментациясыз «әмбебап» жалаушалар → мәселені оқшаулау мүмкін емес.
guardrails/автокатофтар жоқ - қолмен оқыс оқиғалар.
Жалаулар арасындағы үйлеспейтін тәуелділіктер → циклдар/рассинхрон.
Әрбір сұраудағы жалаушаларды кэшсіз бағалау → жасырындылық жарқылдауы.
Аудит/өзгерістер терезесінің болмауы - комплаенс тәуекелі.

15) Азық-түлік алдындағы чек-парағы

• Ту түрі, owner, сипаттамасы, TTL және тикет талабымен жасалған.
• Таргетинг ережелері анықталған; 'deny' жағымсыз өңірлерге/рөлдерге.
• Sticky bucketing детерминирленген; идентификаторы тұрақты таңдалған.
• Пререквизиттер мен health-жалаулар дайын; дефолт қауіпсіз.
• p95/p99, error_rate, бизнес-guardrails.
• Автокатоф теңшелген; rollout тоқтау шегі және қайтару шарттары.
• Канареялық жоспар: пайыздар/кезеңдер/өзгерістер терезесі/жауапты.
• Конфигалар CI-де валидацияланады; снапшот кластерлер/өңірлер бойынша бөлінген.
• Қолдау/өнім үшін құжаттама; инциденттердің ойнатқыштары.
• 100% -дан кейін код тармақтарын және жалауды жою жоспары.

16) «Көші-қон» туының үлгісі (ДБ/индексі)

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"

Қорытынды

Feature Flags - бұл «қосылу/қосылу» ғана емес, өзгерістердің тәуекелдерін басқару тәртібі. Жалаулардың нақты түрлері, детерминирленген таргетинг, guardrails-пен прогрессивті есептеулер, автокатоф, аудит және жою жоспары релиздерді болжауға, ал тосын оқиғаларды қысқа және бақылауға мүмкіндік береді. Жалауларды сәулетке азаматтардың бірінші сыныбы ретінде кіріктіріңіз - сонда сіз құндылықтарды жиі, қауіпсіз және мағыналырақ жеткізе аласыз.