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