В кабинете поставщика появился новый способ рассчитывать доставку. Код уже установлен, но компания пока открыла его только сотрудникам. На демонстрации достаточно перевести переключатель во включённое положение. В рабочем продукте сразу возникают другие вопросы: какую цену увидит клиент с сохранённым предложением, кто может расширить аудиторию и что произойдёт, если настройка не загрузится?
Feature Flag выбирает вариант поведения без обязательной замены программы. Это позволяет отделить поставку кода от запуска функции. Но флаг не хранит ответ на все вопросы о выпуске: его состояние становится ещё одним входом в бизнес-операцию, наряду с данными клиента и версией приложения.
За переключателем должна стоять конкретная задача
Для временного запуска нового расчёта нужен план завершения. Для эксперимента — стабильные группы и способ оценить результат. Для аварийного отключения тяжёлой рекомендации — известное безопасное поведение. В статье Пита Ходжсона о Feature Toggles эти назначения различаются: у флагов неодинаковые сроки жизни и требования к изменению настроек.
Постоянное право использовать платную функцию — другая договорённость. Его можно технически вычислять похожим механизмом, но оно требует проверки полномочий и условий продукта. Команда маркетинга не должна случайно менять доступ к чужим данным той же кнопкой, которой включает новый вид экрана.
Не каждое исправление нуждается во флаге. Для небольшого изменения без отдельной аудитории и момента запуска обычного выпуска может хватить. Два варианта поведения означают дополнительную работу уже сейчас, даже если никто никогда не воспользуется возможностью переключения.
Процент пользователей ещё не определяет безопасную группу
Если два сотрудника одной компании работают с общим предложением, распределение по пользователям может дать им разные расчёты. Иногда правильная единица включения — организация, иногда конкретная операция. Важно выбрать её по тому, что должно оставаться согласованным, а не по самой простой настройке панели.
Для выбора нужен устойчивый идентификатор. OpenFeature описывает targeting key как идентификатор участника вычисления флага; отсутствие нужного ключа может нарушить ожидаемое распределение. Сам стандарт, однако, не решает, кем в нашем продукте является такой участник.
При создании предложения полезно сохранить выбранный вариант расчёта вместе с его условиями. Повторный запрос спустя несколько часов не должен менять уже обещанную сумму только потому, что аудиторию расширили. Продолжение старой операции и начало новой могут использовать разные правила — это надо определить явно.
Что увидит приложение без связи с настройками
Одни реализации получают значения удалённо, другие вычисляют их по локальной копии правил. Изменение в панели поэтому не обязательно одновременно достигает всех процессов. Поддержке нужно видеть фактически применённый вариант и версию конфигурации, а не только последнее положение кнопки.
В API OpenFeature предусмотрено значение по умолчанию на случай ошибки вычисления. Его выбирают под последствия операции. Автоматически считать любое false безопасным нельзя: флаг может называться «отключить отправку», и обратное значение возобновит нежелательное действие.
Испытайте холодный запуск без поставщика настроек, потерю связи после успешного обновления и устаревшую локальную копию. Система должна отличать обычное решение от аварийного значения, чтобы отсутствие ошибок приложения не скрывало неработающий механизм управления. Сбор диагностических сведений не требует записывать личные данные всей аудитории.
Выключение не отменяет уже принятую работу
Новый расчёт мог создать предложение, которое старая ветка не умеет открыть. Фоновое задание могло уже попасть в очередь. Выключение флага не удалит эти состояния и не отзовёт отправленное письмо. Для нашего кабинета нужно отдельно решить, чем завершаются созданные предложения и как исправляются ошибочные суммы.
Флаг также не изолирует весь новый код. Библиотека может загружаться при старте, миграция базы — выполняться при выпуске, фоновый процесс — запускаться до проверки настройки. Поэтому фраза «всё выключено» не освобождает от проверки самого развёртывания.
Скрыть кнопку недостаточно и для безопасности. Пользователь может обратиться к операции напрямую. OWASP рекомендует проверять доступ к ресурсу при запросе. Сервер должен разрешать конкретное действие независимо от того, показывает ли клиентский интерфейс новую функцию.
Кто может изменить поведение работающего продукта
Изменение флага может затронуть клиентов не меньше нового выпуска. Нужны права на рабочее окружение, запись автора и основания, а для значимого риска — проверка перед расширением. В аварийной ситуации допустим ускоренный порядок, но не общий неотслеживаемый доступ к панели.
Для расчёта доставки заранее выбирают наблюдаемый результат: предложения корректны, подтверждаются и не требуют массовых ручных исправлений. Проверка только HTTP-ошибок пропустит неверную цену. Условия остановки должны включать и отсутствие нужных измерений; пустой график не означает удачный запуск.
Проверять все мыслимые комбинации десятков флагов обычно непосильно. Лучше ограничивать поддерживаемые сочетания, тестировать рабочую и планируемую конфигурации и отдельно проверять взаимодействия, влияющие на один процесс. Несовместимые сочетания стоит запрещать, а не надеяться, что их никто не выберет.
Завершение выпуска — отдельная задача
У временного флага есть владелец и условие удаления. После перехода сначала убирают ненужную ветку и обращения к настройке, проверяют версии приложений и активные задания, затем удаляют запись из системы флагов. Иначе старый экземпляр получит значение по умолчанию и неожиданно вернётся к прежнему поведению.
Аварийный выключатель может остаться надолго, если за ним сохраняются понятная задача и регулярная проверка. Но переключатель прошлогоднего запуска не становится полезным резервом от одного своего существования. В кабинете поставщика после завершения перехода должно остаться объяснимое правило расчёта, а не зависимость цены от забытой настройки.