Feature flags не спасают релиз, если rollout спроектирован как лотерея

Feature flags не спасают релиз, если rollout спроектирован как лотерея

Флаг — это не тумблер «включить смелость». Это контрольная плоскость эксперимента и релиза. Если вы не знаете, кто попал под флаг, когда попал и почему откатился, у вас не rollout, а шумогенератор.

Минимальный порядок:
— флаг создаётся с владельцем, целью и датой удаления;
— включение идёт ступенями, а не «давайте сразу 50%»;
— сегменты фиксируются до старта, без ручного шаманства;
— guardrails смотрятся на каждом шаге: ошибки, latency, оплату, ретеншн;
— логируется экспозиция, а не только факт клика.

Главная грязь начинается, когда rollout смешивают с A/B-тестом. Если часть пользователей получает фичу из-за флага, часть из-за эксперимента, часть после ручного allowlist — поздравляю, интерпретация умерла. Один пользователь должен иметь один понятный путь назначения.

После раскатки флаг не должен жить вечно. Старые флаги ломают код, метрики и головы аналитиков. Закрыли решение — удалили ветку, зафиксировали эффект, почистили дашборды.

Хороший rollout скучный: заранее заданные пороги, понятный откат, чистая экспозиция. Всё остальное — продакшен-рулетка с красивым интерфейсом.