Feature flags инфраструктура

Feature flags (фича-флаги, «переключатели функций») — это система, которая позволяет включать и выключать функции сайта без выкатки кода. Код с новой функцией уже на сервере, но показывается она только когда вы «щёлкнули флаг»: сразу всем, 5% пользователей, своей команде на тест или конкретному сегменту. Если функция ломается — выключаете её одним кликом (kill switch — «аварийный выключатель»: вырубить фичу, не трогая остальной сайт), без срочного передеплоя. Это разделяет «выложить код» и «включить функцию». Важно и честно: деплой становится гибче, но и сложнее — флаги это дополнительный уровень логики, который сам требует учёта и регулярной чистки, иначе багов и путаницы станет больше, а не меньше; мы это закладываем. Чем отличается от A/B-тестов: фича-флаги НЕ отвечают на вопрос «какой вариант лучше» — это задача A/B-тестов (см. «A/B-testing инфраструктура»); флаги решают «кому и когда показать функцию». Часто работают вместе: флаг катит вариант, A/B измеряет эффект. Подбираем инструмент: управляемые облачные (LaunchDarkly, Split.io, ConfigCat) с готовой панелью или open-source на свой сервер (Unleash, Flagsmith, GrowthBook). Про деньги честно: управляемые берут абонплату (например, LaunchDarkly — примерно от $10 за пользователя в месяц и выше), и за год это нередко перекрывает разовый бюджет внедрения, поэтому сразу помогаем спланировать; open-source бесплатны, но нужны поддержка и хостинг. Представьте: выкатили новую корзину, включили сначала для 5% — что-то не так, выключили в один клик, остальные и не заметили. Базовая цена — от 30 000 ₽ за настройку; зависит от инструмента и интеграций.

• Каждая новая функция — рискованный деплой: если сломается, чинить и катить заново это стресс и простой.
• Нельзя показать фичу части пользователей или своей команде — только всем сразу.
• Если новинка «не зашла» или забаговала, быстро выключить её нельзя — нужен срочный передеплой.
• Релизы катятся «всё или ничего» — нет постепенной и безопасной выкатки.

• Подбор инструмента (LaunchDarkly / Split / ConfigCat или open-source Unleash / Flagsmith / GrowthBook)
• Подключение фича-флагов к сайту (фронтенд и/или бэкенд)
• Постепенная выкатка: на % пользователей, сегмент, по гео или устройству
• Kill switch — мгновенное отключение функции при сбое
• Таргетинг: показать фичу команде, бета-группе, конкретным пользователям
• Панель управления флагами для вашей команды
• Учёт, сроки жизни и чистка устаревших флагов — чтобы не копился техдолг
• Документация и передача команде

• Деплой гибче и спокойнее — код выкладываете, а функцию включаете, когда готовы
• Сломалось — выключили в один клик, без срочного передеплоя и простоя
• Постепенные релизы — новинку видит сначала часть пользователей, риск меньше
• Можно тестировать на своих и бета-группе до полного запуска

• Оставляете заявку и описываете стек и задачи (постепенные релизы, kill switch, таргетинг)
• Подбираем инструмент, подключаем флаги к фронту и бэку, настраиваем панель
• Внедряем, показываем команде, передаём с документацией и правилами чистки флагов

• Чем feature flags отличаются от A/B-тестов?

  A/B-тест (см. «A/B-testing инфраструктура») сравнивает варианты и говорит, ЧТО лучше конвертит. Feature flags этого не делают — они про управление выкаткой: КОМУ и КОГДА показать функцию, как мгновенно её выключить. Цель разная: измерение против контроля релиза. Технически близки и часто работают вместе: флаг катит вариант, A/B измеряет эффект, но это две разные задачи.

• Какой инструмент выбрать и сколько он стоит потом?

  Управляемые облачные (LaunchDarkly, Split.io, ConfigCat) удобны, но берут абонплату — например, LaunchDarkly примерно от $10 за пользователя в месяц и выше; за год это нередко дороже самой настройки, поэтому бюджет планируем сразу. Open-source (Unleash, Flagsmith, GrowthBook) ставятся на ваш сервер бесплатно, но нужны поддержка и хостинг. Подберём под команду и бюджет, про регулярные расходы скажем заранее.

• Не превратятся ли флаги в свалку?

  Это реальный риск: если флаги не убирать после релиза, копится техдолг, в коде появляются забытые условия и лишние ветки, команда тратит время на разбор. Поэтому сразу закладываем учёт флагов, сроки их жизни и регулярную чистку — флаг должен быть временным инструментом, а не вечным «если» в коде.