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. В результате релизы станут частыми, управляемыми и безопасными, а риск инцидентов — предсказуемым и контролируемым.