Флаги фич в продакшне: польза и технический долг
Флаги фич позволяют выпускать код безопасно и дёшево проводить эксперименты - но каждый добавленный флаг - это логика, которую рано или поздно придётся удалить.
Несколько лет назад флаги фич были паттерном, который использовали преимущественно крупные технологические компании. Сегодня они стали частью стандартного инструментария почти в любой команде. Аргумент простой: разделить деплой и релиз, управлять видимостью фич, откатываться без полного передеплоя, запускать A/B-тесты в продакшне.
Всё это реально. Проблема в том, что вторую половину истории в таких аргументах обычно опускают.
Что флаги фич реально дают
Конкретные преимущества, которые я вижу на практике:
- Можно деплоить незаконченный код без его видимости для пользователей. Новый флоу оформления заказа уходит в продакшн во вторник, становится виден десяти процентам пользователей в четверг и раскатывается на всех в следующий понедельник после проверки метрик.
- Можно тестировать в продакшне на реальном трафике - это принципиально отличается от любого staging-окружения.
- Откат - это изменение конфигурации, а не реверт с передеплоем. В 11 вечера это имеет значение.
- Можно давать ранний доступ внутренним пользователям без отдельной сборки.
Это реальные преимущества, особенно для команд, которые деплоятся часто и не могут позволить себе долгие freeze-окна.
Долг, который накапливается
Каждый флаг - это ветвление в коде. Один флаг означает два пути. Десять флагов теоретически означают до 1024 комбинаций. На практике тестируется лишь несколько из них.
Проблему создают флаги, которые переживают свою задачу. Эксперимент закончился полгода назад, победитель был очевиден, но никто не удалил проигравшую ветку. В кодовой базе теперь есть мёртвая логика, которая выполняется при каждом запросе, покрыта тестами, которые всё ещё проходят, и удивит следующего инженера, который будет трогать этот модуль.
Я видел команды с тридцатью-сорока активными флагами в продакшн-кодовой базе, где активными намеренно были меньше десяти. Остальные - пункты списка «надо бы убрать», который никто не вёл.
Когда флаги создают противоположность безопасности
Флаг, добавленный для снижения рисков при деплое, может скрывать более глубокую проблему. Если команда добавляет флаги, потому что боится деплоиться напрямую, флаг - это симптом, а не решение. Корневая причина обычно в том, что сам процесс деплоя хрупок или тестовое покрытие слишком тонкое, чтобы давать уверенность.
Флаги также вносят собственные режимы отказа. Сервис вычисления флагов падает. Конфигурационный файл оказывается невалидным. Флаг правильно выставлен в продакшне, но не в staging, и баг проявляется в два часа дня во вторник.
Как удержать ситуацию под контролем
Команды, которые я видел справляющимися с флагами, разделяют несколько привычек:
- У каждого флага есть владелец и плановая дата удаления, установленная при создании.
- Удаление флага считается полноценной задачей, а не опциональной уборкой. Она идёт в спринт как любой другой тикет.
- Количество активных флагов отслеживается как метрика. Когда оно пересекает порог, кому-то назначается задача его снизить.
- Флаги классифицируются: краткосрочные экспериментальные флаги имеют другие правила жизненного цикла, чем долгосрочные операционные.
Честная формулировка для менеджера
Флаги фич - это полезный инструмент, который требует активного обслуживания, чтобы оставаться полезным. Если команда добавляет флаги без процесса их удаления, в кодовой базе рано или поздно никто не будет уверен в том, какой код-путь реально работает в продакшне.
Решение принять флаги - это также решение выделить ресурс на поддержание их чистоты. Это не большая нагрузка. Но это реальная нагрузка.