Как построить платформу для A/B-тестов на микросервисах: опыт и грабли

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

Как всё начиналось: от пет-проекта до боевой платформы

Идея создать собственную платформу для A/B-тестов возникла не на пустом месте. Продуктовый аналитик Пётр (имя изменено) работал с экспериментами более 12 лет и понимал, что существующие инструменты либо слишком дороги, либо не подходят под специфику бизнеса. Когда в компании встал вопрос о внедрении потокового (continuous) A/B-тестирования, он решил не покупать готовое решение, а доработать свой пет-проект — микросервис, который он писал для себя.

Потоковое тестирование отличается от классического тем, что эксперименты запускаются непрерывно, без остановки на анализ результатов. Это требует автоматической обработки данных и принятия решений в реальном времени. В компании до этого использовали разовые A/B-тесты с ручным расчётом, что было медленно и трудозатратно. Новая платформа должна была автоматизировать весь цикл: от создания эксперимента до его завершения.

Автор признаётся, что первые версии были сырыми. Например, он неправильно задавал минимальное время жизни эксперимента — из-за этого система могла остановить тест слишком рано, не набрав статистической значимости. Пришлось переписывать логику и добавлять проверки на основе количества событий, а не времени.

Предыстория и контекст: почему компании нужна своя платформа

На рынке есть готовые решения для A/B-тестов: Google Optimize, Optimizely, VWO, но у них есть недостатки. Во-первых, цена — для крупных компаний с миллионами пользователей стоимость может достигать десятков тысяч долларов в месяц. Во-вторых, гибкость — многие инструменты не позволяют настраивать сложные правила разделения трафика или интеграцию с внутренними системами.

Кроме того, в некоторых отраслях (например, финансы или медицина) важно, чтобы данные не уходили на сторонние серверы. Собственная платформа решает эту проблему. Пётр отмечает, что их бизнес-логика требовала учёта множества факторов: времени суток, типа устройства, истории пользователя. Готовые инструменты часто не справлялись с такой кастомизацией.

Ещё один важный момент — скорость внедрения. Покупка и настройка внешнего сервиса может занять месяцы, а свой микросервис автор запустил за несколько недель. Конечно, потребовалась доработка, но базовый функционал заработал быстро.

Какие грабли встретились на пути

Пётр выделяет несколько ключевых ошибок, которые совершил при разработке. Первая — неправильный выбор метрики для остановки эксперимента. Изначально он использовал только p-value, но это приводило к ложным срабатываниям. Пришлось добавить проверку на минимальный размер выборки и доверительные интервалы.

Вторая ошибка — игнорирование эффекта «пика» (peeking). Когда аналитик смотрит на результаты каждый день и останавливает тест при первом значимом результате, это нарушает статистику. В платформу пришлось встроить механизм, который блокирует преждевременную остановку.

Третья — проблема с разделением трафика. В потоковом режиме пользователь может попасть в несколько экспериментов одновременно, и это создаёт перекрёстное влияние. Решение — использовать уникальный идентификатор пользователя и фиксировать его в одном эксперименте за раз, если эксперименты пересекаются по времени.

Технические подробности: как устроена платформа

Архитектура платформы — микросервисная, на Go. Основные компоненты: сервис принятия решений (выдаёт варианты), сервис сбора событий, сервис статистики и админка. Все данные хранятся в PostgreSQL, а для быстрой обработки используется Redis.

Сервис принятия решений работает синхронно — при каждом запросе от пользователя он определяет, в какой эксперимент попал пользователь и какой вариант показать. Для этого используется алгоритм на основе хеширования userid: это гарантирует, что один и тот же пользователь всегда видит один вариант.

Сбор событий происходит асинхронно через очередь (Kafka). Это позволяет не замедлять основной поток. Статистика пересчитывается каждые 10 минут, и если эксперимент достигает значимости, система автоматически останавливает его и фиксирует результат.

Автор подчёркивает, что весь базовый функционал открыт — код доступен на GitHub. Правда, для использования потребуется своя инфраструктура, но это всё равно дешевле, чем покупать готовое решение.

Кого затронет и как: для кого эта платформа

В первую очередь — продуктовых аналитиков и менеджеров, которые проводят много A/B-тестов. Если в компании больше 10 экспериментов в месяц, ручной расчёт становится узким местом. Платформа автоматизирует рутину и снижает риск ошибок.

Разработчикам будет интересна архитектура на Go и подход к интеграции с существующими системами. Для бизнеса — возможность быстрее проверять гипотезы и принимать решения на основе данных.

В российском контексте особенно актуально, что платформа не зависит от зарубежных сервисов и может работать полностью внутри периметра компании. Это важно для тех, кто столкнулся с блокировками или уходом вендоров.

Что будет дальше

Автор планирует развивать платформу: добавлять поддержку многофакторных экспериментов, улучшить визуализацию и сделать более удобную админку. Он также рассматривает возможность выложить готовый Docker-образ, чтобы упростить развёртывание.

В долгосрочной перспективе — интеграция с ML-моделями для автоматического подбора вариантов. Но пока это только планы.

Итог

Создание собственной платформы для A/B-тестов — задача нетривиальная, но вполне выполнимая. Главное — понимать статистику и не бояться переписывать код, когда грабли становятся очевидны. Опыт автора показывает, что даже пет-проект может вырасти в боевой инструмент, который сэкономит компании миллионы и ускорит принятие решений. Если вы задумываетесь об автоматизации экспериментов — возможно, стоит попробовать не купить, а построить.