Feature-флаг (Feature Flag)

Feature-флаг (также называемый переключателем функций) — это условный переключатель в коде, определяющий, активна ли определённая функциональность, управляемый конфигурацией, а не тем, какой код развёрнут. Вместо того чтобы `if (newCheckoutFlow)` решался на этапе сборки в зависимости от того, какая ветка была слита, это решается во время выполнения путём проверки значения флага — которое можно мгновенно переключить для некоторых, всех или определённого процента пользователей без нового развёртывания. Такие инструменты, как LaunchDarkly, Statsig, PostHog и Unleash, предоставляют выделенные платформы управления флагами; небольшие команды часто реализуют простую версию с таблицей базы данных или переменными окружения. Почему это важно для разработчиков AI/SaaS: feature-флаги отделяют развёртывание от релиза — вы можете слить и задеплоить наполовину готовую функцию в production за флагом, который выключен для всех, продолжать безопасно над ней работать, а затем выпустить её позже, переключив флаг, без дополнительного риска развёртывания в момент релиза. Они также позволяют делать постепенные раскатки (выпустить для 5% пользователей, следить за частотой ошибок и метриками, довести до 100%, если всё в порядке, мгновенно откатить до 0%, если нет — намного быстрее, чем откат кода и повторное развёртывание) и A/B-тестирование (показать вариант A половине пользователей, вариант B — другой половине, измеряя, какой работает лучше). Это особенно ценно именно для функций на базе ИИ, поскольку новый поток на базе ИИ (скажем, сгенерированный ИИ чек-лист онбординга) часто требует осторожного, постепенного вывода в свет с мониторингом качества и стоимости перед полным раскатыванием. Как это работает: код приложения проверяет значение флага в соответствующей точке принятия решения (`if (flags.isEnabled("new-ai-onboarding", userId)) { ... }`), где сервис флагов разрешает значение на основе правил — фиксированное состояние вкл/выкл, процентная раскатка, таргетинг на конкретные сегменты пользователей или отдельных пользователей, обычно всё это настраивается из панели управления без развёртывания. Значения флагов обычно получаются во время запроса из быстрого, кэшированного источника (SDK с локальным кэшем, обновляемым через стриминг/поллинг, так что проверка добавляет незначительную задержку), а не через медленное обращение к базе данных при каждой проверке. Практический пример: SaaS-компания создаёт новую функцию «умный поиск» на базе ИИ. Они оборачивают её в feature-флаг `ai-smart-search`, разворачивают код в production с выключенным для всех флагом и используют свою внутреннюю админ-панель, чтобы включить его только для аккаунтов своей команды для тестирования на реальных данных. Убедившись, что всё работает, они устанавливают раскатку флага на 10%; после 48 часов чистых показателей ошибок и положительных метрик вовлечённости доводят до 100%. Когда три дня спустя приходит отчёт об ошибке, показывающий, что ИИ иногда возвращает нерелевантные результаты для определённого паттерна запросов, они мгновенно переключают флаг обратно на 0% из панели — откатывая функцию для всех пользователей за секунды, без экстренного развёртывания или отката.