На маленьком проекте откат изменений — это одна кнопка. В большой инфраструктуре на десятки серверов с тяжелыми миграциями в базе любой факап после деплоя превращается в инженерный ад. Когда цена ошибки — лояльность сотен тысяч пользователей, выкатывать код «на всех сразу» — непозволительный риск.
Для этого придумали Feature Flag. Это не просто логический переключатель в коде, это в первую очередь аварийная кнопка. Если после релиза мониторинг в Sentry или Grafana заливается красным, инженер не бежит запускать новый пайплай деплоя на 15 минут. Он просто щелкает флаг в конфиге. Скорость реакции: одна секунда против полноценного цикла доставки кода.
От выключателя к диммеру
Feature Flag превращает бинарную логику «есть фича / нет фичи» в гибкий диммер. Мы заливаем готовый код на продакшн, но держим его в спящем режиме. Это позволяет управлять «яркостью» присутствия функционала в системе:
1. Канареечный релиз: Включаем новую страницу избранного только для 1% пользователей.
2. Проверка гипотез: Смотрим, как инфраструктура держит нагрузку. Если система начинает «прилегать», мы откатываем флаг для этого процента и идем дочинивать, не затрагивая остальных 99% юзеров.
3. Делегирование бизнесу: Разработка доставила фичу, а когда её активировать — решает менеджмент или маркетинг. Они просто нажимают галку в админке, не отвлекая инженеров от текущего спринта.
Математика выборки
Когда встает задача выделить 5% пользователей для теста, новички часто используют обычный рандом. Это путь к мусорному UX: пользователь зашел на сайт — фича есть, обновил страницу — рандом выпал иначе, фича пропала.
Инженерный подход требует детерминированности. Чтобы пользователь всегда попадал в одну и ту же группу, используется хеширование:
- Алгоритм: Берем
user_id, добавляем к нему salt (строковый идентификатор конкретной фичи), захешируем эту строку и переводим в число.- Механика: Берем остаток от деления этого числа на 100.
- Результат: Мы получаем стабильное число от 0 до 99 для каждого юзера. Если нам нужно раскатать фичу на 5%, мы просто открываем доступ всем, у кого остаток меньше 5.
Это гарантирует, что выборка будет консистентной, а нагрузка — распределенной. Вы в любой момент можете расширить группу до 10%, 20% или 100%, просто меняя пороговое значение в настройках, при этом те, кто уже видел фичу, ее не потеряют.
Проектируйте системы так, чтобы доставка кода и активация фичи были разнесены во времени. Это единственный способ сохранить нервы и стабильность продакшена.
Ставь 🔥, если всё разложилось по полочкам. А если остались вопросы по реализации или что-то звучит слишком абстрактно — пиши в комменты, обязательно разберем!
10МДК | ВЕБМастер