Feature Flags і управління релізами

Feature Flags і управління релізами

1) Навіщо прапори, якщо є релізи?

• Швидкість і безпека релізів: маленькі інкременти + миттєвий відкат.
• Контроль радіуса ураження: прогресивний rollout, кільця, SLO-стопери.
• Експерименти та A/B: multivariate-прапори, статистика ефектів.
• Операційні сценарії: kill-switch для ризикованих платіжних/ігрових шляхів.

Ключовий принцип: «ship dark, enable bright» - поставляти заздалегідь, включати усвідомлено.

2) Типи прапорів

Boolean: вкл/викл фічі, аварійні стоп-прапори (kill-switch).
Multivariate: варіанти поведінки (алгоритм A/B/C, ліміти, коефіцієнти).
Config/Remote Config: параметри (таймаути, ліміти ставок, розмір бонусу).
Permission/Entitlement: доступ до функцій/лімітів за ролями/tiers.
Operational: маршрутизація трафіку (тіньовий запит, включення нового сервісу).

3) Архітектура і потоки даних

Control Plane: консоль/сервер прапорів, зберігання правил/сегментів, аудит.
Data Plane (SDK/Proxy/Edge): отримання і кешування прапорів, оцінка правил локально (мінімум латентності), фолбек при недоступності.

• Pull: SDK періодично синхронізує конфіг (ETag/stream).
• Push/Streaming: сервер пушить оновлення (Server-Sent Events/WebSocket).
• Edge Cache/Proxy: ближче до користувача, знижує p99.

• Локальна оцінка правил (без мережевого хопу в hot-path).
• Таймаути і фолбеки (без «блокуючого» читання прапора).
• Підпис/версіонування снапшотів конфігів.

4) Таргетинг і сегменти

Атрибути: країна/регіон, мова, платформа, KYC-рівень, VIP-рівень, ризик-швидкість, вік акаунту, метод платежу, ліміти відповідальної гри.
Сегменти: збережені правила з версіями; «м'які» (маркетинг) і «жорсткі» (комплаєнс).
Пріоритети/конфлікти: явні порядки правил, «останній збіг» заборонено без тестів.
Гео/регуляторика: прапорці доступності продукту за юрисдикціями; незмінювані предикати (наприклад, заборона бонусу для конкретної країни).

json
{
"flag": "new_withdrawal_flow",
"default": false,
"rules": [
{"when": {"country": "CA", "kyc_level": "FULL"}, "rollout": 25},
{"when": {"segment": "vip_tier_3_plus"}, "rollout": 100},
{"when": {"country": "DE"}, "force": false}
],
"expiresAt": "2026-03-31T00:00:00Z"
}

5) Прогресивний rollout: стратегії

Canary by %: 1% → 5% → 25% → 50% → 100% з авто-стопом по SLO.
Rings: внутрішня команда → бета-користувачі → один регіон → глобально.
Sampling по пристроям/клієнтам: враховуйте stickiness (хеш ID).
Shadow traffic: дублювання запиту в новий шлях без впливу на користувача.
Dark launch: включено, але не мабуть (збір метрик, прогрів кешів).

• Погіршення p95 латентності API'withdraw'> + 15% протягом 10 хвилин.
• Помилки 5xx> 0. 5% або зростання відмов платіжного провайдера> + 0. 3 п.п.
• Алерт фроду/ризик-скорингу вище порогу в сегменті.

6) Kill-switch (аварійні прапори)

Окремий клас прапорів, видимий SRE/On-Call.
Гарантована локальна оцінка з TTL-кешем (мілісекунди).
Безповоротні відключення: require reason + postmortem ticket.
Авто-дія інтеграцій: відключення бонусу, переведення виплат в ручний режим, заборона депозитів для провайдера X.

7) Інтеграція з CI/CD і GitOps

CI: валідація схем прапорів, лінт правил, «сухий прогін» таргетингу за анонімізованими вибірками.
CD: промоушен конфігів прапорів як артефактів (semver), «approval gates» для чутливих прапорів (платежі/комплаєнс).
GitOps: прапори в окремому репозиторії конфігів, мердж-реквест = подія зміни, аудит «з коробки».

8) Безпека та комплаєнс

RBAC/ABAC: хто може створювати/включати/піднімати відсоток; поділ обов'язків (розробник ≠ випускник ≠ власник продукту).
Аудит: хто/коли/що/чому; обґрунтування (ticket/JIRA), зіставлення з інцидентами.
PII-мінімізація: атрибути для таргетингу проходять через анонімізацію/хешування.
Підпис снапшотів: перевірка цілісності на SDK/Proxy.
SLA на доставку конфігів: деградує в «безпечний дефолт».

9) Спостережуваність і метрики

• Час поширення прапора (p50/p95), hit-rate локального кешу, частота оновлень.
• Кількість активних прапорів/застарілих/» висячих» (не знятих за терміном).
• SLO-охоронці: латентність, помилка, конверсія, стабільність провайдера.

• DORA: частота деплоїв, час до включення, відсоток відмов після включення, MTTR.
• A/B показники: CR, ARPPU, LTV-сигнали, вплив на фрод-скоринг.

10) Життєвий цикл прапора

1. Design: мета/метрика/власник/термін придатності ('expiresAt'), сценарії відкату.
2. Implement: SDK-виклики, фолбеки, телеметрія «exposure «/» decision ».
3. Rollout: прогресивна подача + SLO-ворота.
4. Stabilize: зафіксувати ефект, оновити документацію/рутинги.
5. Cleanup: видалити розгалуження коду, закрити прапор, провести аудит «залишків».

11) Приклади впровадження

11. 1 Веб/Node. js

ts
// Инициализация SDK (псевдо)
const flags = await sdk.init({ sdkKey: process.env.FLAGS_KEY, user: { id: userIdHash, country, vipTier } });

// Не блокировать рендер:
const showNewCashout = flags.bool("new_withdrawal_flow", false);

if (showNewCashout) {
renderNewFlow();
} else {
renderClassic();
}

11. 2 Kotlin / JVM

kotlin val client = FlagsClient(sdkKey = System.getenv("FLAGS_KEY"))
val context = UserContext(id = userHash, country = country, kycLevel = kyc)
val enabled = client.getBoolean("risk_guard_withdrawals", default = true, context = context)
if (!enabled) {
// аварийный режим: все выводы в manual review routeToManual()
}

11. 3 NGINX (зовнішній toggle через map)

nginx map $http_x_feature $cashout_new {
default 0;
"~enabled" 1;
}

location /withdraw {
if ($cashout_new) { proxy_pass http://new_flow; }
if (!$cashout_new) { proxy_pass http://classic_flow; }
}

12) Управління ризиком і прогресивні кроки

Кроки включення: 1% співробітників → 5% «бета» → 10% RU → 25% EU → 100% крім DE (регулятор).
Обмежувачі: макс. 1 крок/30 хв; вимога стабільності метрик за вікно 15 хв.
Авто-стоп: політика на рівні платформи (див. нижче OPA).

rego package flags.guard

deny[msg] {
input.flag == "new_withdrawal_flow"
input.metrics["withdraw_5xx_rate"] > 0.5 msg:= "Stop rollout: withdraw 5xx too high"
}

13) Управління доступом та узгодження

Change Types: стандартні (безпечні) vs чутливі (платежі/виплати/ліміти).
Approvals: власник продукту + тех. відповідальний + комплаєнс (для юрисдикцій).
Тимчасові вікна (freeze): заборона включень/розширень у високоризиковані періоди (прайм-тайм, великі турніри).

14) Експерименти і статистика

Exposure events: логуємо рішення прапора з атрибутами.
Аналітика: поточне значення rollout, сегменти, ефект на конверсії/помилки.
Статистичні перевірки: коректний спліт, контрольні коваріати (пристрої/гео).
Етика та регуляторика: уникати сегментацій, обмежених місцевим правом.

15) Анти-патерни

Довгоживучі прапори без'expiresAt', «кладовище гілок» в коді.
Блокуючий мережевий виклик SDK в hot-path.
Надлишковий таргетинг по PII, відсутність анонімізації атрибутів.
Включення без SLO-охоронців/авто-зупинки.
Немає kill-switch для високоризикових потоків (депозити/висновки/бонуси).
«Таємні» ручні правки прапорів без аудиту та обґрунтування.

16) Чек-лист впровадження (0-60-90)

0-30 днів

Вибрати платформу прапорів/підготувати self-host (SDK, proxy, кеш).
Ввести схему («flag», «owner», «purpose», «expiresAt», «risk _ level»).
Підключити SLO-метрики до платформи (латентність/помилки ключових API).

31-60 днів

Додати approvals по чутливих прапорів, OPA-охоронці.
Налаштувати прогресивні стратегії (percent/rings), kill-switch панель.
Вбудувати лінтер схеми прапорів в CI; почати зачистку перших «висячих».

61-90 днів

Повна інтеграція з GitOps (MR-редагування прапорів, аудит).
Візуальні дашборди: coverage SDK, час поширення,% кеш-хітів.
Регулярний «Flag Debt Day»: видалення коду і закриття прапорів.

17) Метрики зрілості

Техніка: p95 прийняття конфігурації <5 с; cache hit-rate SDK> 95%;% прапорів з'expiresAt'> 90%.
Процеси: 100% чутливих прапорів з approvals; середній «час до відкату» <3 хв.
Кодова гігієна: частка закритих прапорів протягом 30 днів після глобального включення> 80%.
Бізнес-ефект: поліпшення DORA (частота релізів ↑, MTTR ↓), зниження інцидентів при релізах.

18) Додатки: шаблони та політики

Схема прапора (YAML)

yaml flag: new_withdrawal_flow owner: payments-team risk_level: high purpose: "Новый поток вывода средств"
expiresAt: "2026-03-31T00:00:00Z"
sla:
propagation_p95_ms: 3000 slo_guards:
withdraw_p95_ms_increase_pct: 15 withdraw_5xx_rate_pct: 0.5 approvals:
required: ["product_owner","tech_lead","compliance"]

Політика «немає вічних прапорів» (умовно для лінтера)

yaml rules:
- check: expiresAt max_days_from_now: 180 action: error

SDK-контракт подій (exposure)

json
{
"event": "flag_exposure",
"flag": "new_withdrawal_flow",
"variant": "on",
"userKey": "hash_abcdef",
"context": {"country":"CA","vipTier":"3"},
"traceId": "9f1c...a2",
"ts": 1730623200000
}

19) Висновок

Feature Flags - це «ручка гучності» для змін. З'єднайте прогресивні включення, SLO-охоронців, жорсткий аудит і регулярну зачистку, а також прив'яжіть прапори до CI/CD і GitOps. В результаті релізи стануть частими, керованими і безпечними, а ризик інцидентів - передбачуваним і контрольованим.