AI-агенты заставляют команды задумываться о том, стоит ли разрабатывать собственные аналоги инструментов, за которые они платят.
Feature flags уже давно стали главной целью в вопросе «создать или купить», еще до того, как ИИ достиг текущего уровня развития. Дело в том, что в самом базовом исполнении флаг — это функция. Вы передаете ей ключ, а она возвращает значение. Насколько это сложно?
Сложность заключается во всем том, что должно происходить «под капотом», чтобы это значение возвращалось надежно, точно и быстро. Команды, выбирающие между собственной разработкой и покупкой, быстро сталкиваются с рядом очевидных факторов:
- Создание, хостинг и поддержка требуют времени и денег.
- Существует множество готового софта для feature flags, который бесплатен и при необходимости соответствует вашим требованиям комплаенса.
- Меньшее количество флагов, пользователей, SDK и сценариев использования упрощает управление.
- Для удобства использования флагов недостаточно базовой функциональности — вам также нужны такие функции, как административный интерфейс.
Как компания, которая предоставляет решение для feature flags и имеет тысячи клиентов, использующих их, мы знаем, что решение выходит далеко за рамки этих пунктов. Чтобы помочь вам, мы собрали неочевидные моменты, которые стоит учесть при выборе между созданием и покупкой feature flags.
Реализация feature flags начинается просто: таблица в базе данных с ключом и значением. Как только вам требуется что-то большее, возникает необходимость интеграции с другими сервисами, и это быстро превращается в основной объем работы.
Несколько примеров:
- Идентификация пользователей. Вам нужно знать, кем является пользователь, чтобы применить к нему флаг. Это может быть простой идентификатор пользователя, но также он может включать такие свойства, как тарифный план, местоположение, устройство и многое другое.
Идентификация пользователей. Вам нужно знать, кем является пользователь, чтобы применить к нему флаг. Это может быть простой идентификатор пользователя, но также он может включать такие свойства, как тарифный план, местоположение, устройство и многое другое.
- Экспериментирование. Флаги могут использоваться для проведения экспериментов, но это требует аналитики использования, логирования показов и статистического анализа для определения влияния различных значений флагов.
Экспериментирование. Флаги могут использоваться для проведения экспериментов, но это требует аналитики использования, логирования файлов экспозиции и статистического анализа для определения влияния различных значений флагов.
- Когорты в реальном времени. Расчет когорт часто никак не связан с самими флагами. Членство в них может меняться в совершенно другой части кодовой базы. Состояние гонки может привести к добавлению или удалению пользователей в неподходящий момент. Постоянный пересчет может быть дорогим удовольствием.
Когорты в реальном времени. Расчет когорт часто никак не связан с самими флагами. Членство в них может меняться в совершенно другой части кодовой базы. Состояние гонки может привести к добавлению или удалению пользователей в неподходящий момент. Постоянный пересчет может быть дорогим удовольствием.
- Хранилища данных. Для многих компаний источником правды является хранилище данных, но оно практически никогда не оптимизировано для тех запросов, которые необходимо делать для работы флагов.
Хранилища данных. For для многих компаний источником правды является хранилище данных, но оно практически никогда не оптимизировано для тех запросов, которые необходимо делать для работы флагов.
Ошибки в этом могут привести не только к тому, что флаги перестанут работать, но и вызвать проблемы в сервисах, с которыми они интегрируются. Представьте, что сервис флагов использует таблицу БД, которая также используется другими сервисами. Неправильный запрос может привести к утечке конфиденциальных данных. Некорректный запрос может заблокировать таблицу и вызвать проблемы в других местах.
Хотя реализация в вашей кодовой базе выглядит как вызов одной функции, данные для расчета возвращаемого значения могут поступать из нескольких сервисов. Запросы и вычисления для получения правильного значения также могут быть сложными. Чтобы все это работало правильно, требуется уровень концентрации, которого может не быть у команд, создающих флаги своими силами.
Подобно тому, как наука развивается от одних похорон до других, надежность feature flags развивается от одного сбоя до другого.
Флаги часто находятся на критическом пути. Проблемы с ними могут означать, что пользователи получат не тот опыт или не получат его вообще. В некоторых случаях это даже стоило компаниям миллионов.
Существует множество неизвестных неизвестных, когда речь заходит о создании собственного сервиса feature flags. Проблемы и слепые зоны проявляются только тогда, когда сервис оказывается в продакшене, например:
- Достижение пределов эффективности нашего основного сервиса на Django.
- Специфические проблемы с Rust, вызывающие всплески задержек.
- Использование гораздо большего объема оперативной памяти, чем требовалось.
С проблематикой сталкивалась каждая платформа флагов, включая нас. Все они извлекли уроки из этих проблем и улучшили свои продукты. Наш показатель p99 теперь составляет менее 25 мс, а бесперебойная работа за последние 90 дней (с 17 июня по 14 сентября 2026 года) составила 100%.
От этого вы отказываетесь, создавая собственный сервис. Вы будете совершать ошибки, и исправлять их придется вам, а не стороннему вендору.
Флаги начинаются просто. Переключатель в базе данных может включать и выключать функции, но со временем в него неизбежно будут добавляться новые возможности. Вы не будете единственным пользователем, и у других ролей будут свои потребности.
Структура, которая работает на раннем этапе, позже может оказаться неверной. Например, добавление базового таргетинга пользователей к вашим переключателям в БД требует написания совершенно нового сервиса, поскольку процесс оценки больше не является операцией только для чтения. Добавьте таргетинг по процентам, и вам потребуется детерминированное распределение по бакетам, о чем вы можете догадаться только после того, как пользователь пожалуется на исчезновение функции.
Готовы ли вы работать со множеством языков программирования? Даже с теми, с которыми вы менее знакомы? Airbnb создала сайдкар для Kubernetes специально для того, чтобы избежать повторной реализации конфигураций на разных языках. Реструктуризация для поддержки новых функций часто требует переписывания кода и рискованных миграций.
Даже крупные компании испытывают трудности с обеспечением долговечности и поддерживаемости флагов. Компания Dropbox создала собственный сервис feature flags под названием Stormcrow в 2017 году. В нем были популяции на базе Hive, интегрированные с их хранилищем аналитики, граф вывода селекторов, доставка конфигураций в формате JSON, пакетная доставка для мобильных и десктопных клиентов, мониторинг в реальном времени, статический анализатор для отслеживания флагов в коде, история аудита и оверрайды. Тем не менее, в 2026 году они перешли на стороннюю платформу флагов.
Агенты становятся основными пользователями feature flags. Около 60% флагов в PostHog создаются вне пользовательского интерфейса. 33% из них создаются непосредственно через MCP.
Разработчики в вашей команде захотят использовать агентов для их создания и редактирования. Это важная поверхность для поддержки, и она означает, что вам понадобятся:
- MCP с наборами инструментов
- CLI
- Контроль доступа для агентов
- Журнал аудита
- Инструменты отладки
Это еще одна область, где возникают проблемы. У нас были случаи, когда агенты вмешивались в работу флагов, чего делать были не должны, из-за чего клиенту пришлось пересматривать права на чтение и запись для агентов. Выяснить, что именно произошло, удалось только благодаря журналу аудита.
Кроме того, само по себе наличие инструментов, доступных агентам, не означает, что они действуют правильно. В прошлом месяце уровень ошибок нашего инструмента флагов MCP составлял около 5% из-за некорректных вызовов и галлюцинирующих идентификаторов. Благодаря аналитике MCP мы смогли исправить это и снизить показатели, но команда без видимости производительности MCP тратила бы время и токены каждый раз при возникновении подобных проблем.
В крупных компаниях внедрение может быть вполне реальной проблемой. Такие компании, как Dropbox и monday.com, писали о фрагментации внутренних инструментов разработки и о том, как это приводит к появлению множества инструментов разного качества, выполняющих одни и те же задачи.
У нас не было одного инструмента, их было несколько: одни для монолита, другие для микросервисов, без четких рекомендаций о том, какой использовать, когда и почему. Не было «золотого пути», только разрозненный набор решений и масса недокументированных знаний. — Йони Алалуф, Tech Lead в monday.com
У нас не было одного инструмента, их было несколько: одни для монолита, другие для микросервисов, без четких рекомендаций о том, какой использовать, когда и почему. Не было «золотого пути», только разрозненный набор решений и масса недокументированных знаний. — Йони Алалуф, Tech Lead в monday.com
Как и в случае с любым другим инструментом, разработчиков нужно будет убедить использовать именно ваш. Что мешает им создать собственный инструмент для управления флагами функций для их простого сценария использования?
Ключевой частью этого процесса являются документация и опыт разработчиков (developer experience). Такая компания, как PostHog, может позволить себе инвестировать в это, потому что у нас много пользователей Feature Flags. Наши команды постоянно обновляют документацию, инструменты и лучшие практики, чтобы помочь пользователям. Этого может не произойти с инструментом собственной разработки.
Хотя мы привели много аргументов в пользу покупки, самостоятельная разработка все же может иметь смысл в некоторых случаях. Вот несколько примеров:
- Когда это является конкурентным преимуществом компании. Вы продаете флаги функций, эксперименты или сопутствующие продукты как услугу.
Когда это является конкурентным преимуществом компании. Вы продаете флаги функций, эксперименты или сопутствующие продукты как услугу.
- У вас есть внутренняя команда для его поддержки. Даже если вы не продаете флаги, вам нужна команда, которая будет относиться к инструменту как к продукту. Они должны отвечать за создание новых функций, исправление ошибок и внесение улучшений.
У вас есть внутренняя команда для его поддержки. Даже если вы не продаете флаги, вам нужна команда, которая будет относиться к инструменту как к продукту. Они должны отвечать за создание новых функций, исправление ошибок и внесение улучшений.
- Вы не можете перестать беспокоиться о стороннем поставщике. Если у вас есть веские причины не доверять вендору — будь то из-за надежности, соответствия требованиям или по другим причинам — создание собственных флагов может быть единственным, что принесет вам душевное спокойствие.
Вы не можете перестать беспокоиться о стороннем поставщике. Если у вас есть веские причины не доверять вендору — будь то из-за надежности, соответствия требованиям или по другим причинам — создание собственных флагов может быть единственным, что принесет вам душевное спокойствие.
Если вы не соответствуете этим критериям, рассмотрите PostHog. Тысячи компаний, таких как Arena, ResearchGate и carVertical, выбирают PostHog для работы с флагами функций. Он предоставляет все преимущества покупки, описанные выше, а первые 1 миллион запросов каждый месяц бесплатны.
