Statist: сбор событий — только полдела

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

В Тинькофф он пришёл инженером в одну из команд и запомнил необычную вакансию без конкретных требований по стеку: собеседовали на том, с чем он тогда работал, — «по-моему, JS». Потом был проект по сбору и отправке performance-метрик из клиентских приложений в отделе базовых технологий; Андрей возглавил небольшую команду, которая его делала, и проект дорос до продукта, собиравшего уже и продуктовую аналитику.

Команду он, по сути, собирал сам: она росла, её делили на команды, выстраивали процессы, а сам он стал руководителем продукта; с Нового года добавилась ещё одна команда — платформа для экспериментов и A/B-тестирования, про которую договорились поговорить отдельно.

Продукт внутренний: им заменяли аналитические решения внешних вендоров, а пользователи — свои же сотрудники, от инженеров до продуктовых аналитиков; Александр прикидывает, что их в компании, наверное, тысячи.

Главная сложность не в сборе данных: в них много специфики, и без её знания собранное может просто не поддаваться анализу. Поэтому отдельная работа — следить за качеством, отсутствием дубликатов и соответствием реальности и объяснять правила работы и проверенные практики. Той же цели служит каталог событий: пользователи размечают отправляемую аналитику, остальные видят, что в системе вообще есть, а метаданные кормят кодогенерацию SDK.

Первая схема начинается с большого и, по признанию Андрея, сложного кубика SDK — под Android, iOS и веб. Они нужны, чтобы клиенты не работали с голым API: SDK кэширует события, чтобы не терять их, и снимает ошибки интеграции.

Часть новых языков принесли контрибьюторы по модели inner source: команды изнутри компании, которым не хватало SDK под свою платформу, получили контракты и правила реализации и вернули код, которым теперь пользуется много людей. Александр замечает, что так в команду приносят не только заказы, но и готовую функциональность.

Андрей соглашается, но предупреждает, что поддерживать эту культуру непросто — разбираться в чужих системах никого не заставишь, поэтому его команда помогает, дописывает части и подсказывает, где ошиблись. Иначе пришлось бы держать экспертизу по Java, .NET, Go, C++ и ещё много каким стекам.

К кодогенерации прикрутили семантическое версионирование: обратно несовместимая правка на iOS и Android скорее всего сломает сборку, а в вебе останется подсказкой в типах TypeScript.

Вторая схема подробнее раскрывает самый трудоёмкий кубик. Всё начинается с коллектора — API, который принимает телеметрию: системные события и то, что человек делает в приложении, нажимает кнопки, ходит по экранам, ищет, получает пуши.

Верхняя ветка исторически первая: события превращаются в метрики и регистрируются во внутренней платформе observability, которую Андрей называет Sage, а дальше работает её экосистема — дашборды, алерты, детектирование аномалий.

Ветка аналитики сложнее: обработка добавляет к событиям тип устройства, версию ОС и приложение, что помогает разбирать ошибки. Геоданные собирают с разрешения пользователя.

Событие также обогащается состоянием профиля на момент его возникновения. Это особенно важно для экспериментов: можно понять, в каком эксперименте участвовал пользователь, когда совершил действие.

Дальше два хранилища: аналитическое для ad hoc-сценариев — конверсии, MAU, группировки, сегментация, пути пользователя, разбор обращений в поддержку — и холодное, где строят автоматизации, ETL-пайплайны, витрины и ноутбуки.

Из технологий: коллектор и пайплайн написаны на Go, много автоматизации на Python, очередь — Kafka, которую как сервис даёт другая команда, профили пользователей лежат в Cassandra, тоже полученной от внутренней платформы, гео и тип устройства отдаёт соседний сервис, а холодное хранение хотят перевезти на S3. Для оперативных аналитических запросов используют ClickHouse; на момент разговора сервиса для него внутри компании нет, поэтому его поддерживает сама команда.

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

Отвечая на вопрос, как он не лопается от нагрузки, Андрей описывает разделение: у каждого поддомена свой лид — команда SDK с кодогенерацией и доставкой событий, команда процессинга и аналитических механик, фронтенд-команда с собственным UI поверх данных. Александр называет это «разделяй и властвуй».

Крупные изменения проходят через RFC и ADR: тех-лиды поддоменов приходят к консенсусу, а если нужна сторонняя экспертиза — выносят на архревю. Александр ценит в этом возможность вернуться и посмотреть, в каком контексте решение принималось и не пора ли его пересмотреть.

Баланс инженера и руководителя на полсотни человек Андрей держит через делегирование и меритократию: архитектурные решения он уже не принимает, а документы заменяют хранителя знаний, которого иначе пришлось бы искать.

Ему важно погружение в бизнес-домен: он вместе с продактом платформы разбирает продукты конкурентов, а сам смотрит доклады ребят из Яндекс Метрики, ведь смотреть на цифры и смотреть на правильные цифры — разное.

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

Любопытство можно поддерживать туториалами и докладами, затем книгами Таненбаума и Клеппмана, инженерными блогами и изучением работающих систем. Александр дополняет список научными статьями. Андрей предлагает читать технические книги под конкретный вопрос: например, открыть главы о шардировании или репликации, а не обязательно проходить всё подряд.