Отслеживание и аналитика продуктовых метрик — обязательное условие администрирования и развития сервисов на всем жизненном цикле. Но прозрачность и глубина контроля во многом зависят от выбранного инструмента. Важно, чтобы он был удобен в настройке аналитиком, понятен конечным потребителям, а реакция на изменения метрик — достоверной и оперативной. Поэтому с ростом сложности задач и повышением зрелости продукта, компании нередко сталкиваются с необходимостью смены инструмента для мониторинга метрик.
Меня зовут Дмитрий Меситов. Я продуктовый аналитик в ОК, и в этой статье я хочу рассказать о том, зачем нам понадобилась смена стека для мониторинга продуктовых метрик, какие варианты мы рассматривали и какой инструмент выбрали в итоге.
Отправная точка
Изначально основным методом визуализации данных в ОК был Charts — in‑house инструмент с основным методом визуализации Line Chart, поддержкой MS SQL, Clickhouse и Apache Druid.
С его помощью строились дашборды верхнеуровневых метрик по основным сервисам внутри ОК, среди которых сервисы Лента, Игры, Фото, Реклама. По каждому из продуктов список метрик оговаривался с продактами и ответственным аналитиком.
Главными преимуществами Charts была высокая скорость работы и возможность обрабатывать большие объемы данных. Инструмент успешно справлялся с поставленными задачами, но, вместе с тем, имел и ряд недостатков, среди которых:
ограниченный набор аналитических инструментов — например, отсутствовал внутренний редактор запросов
небольшая вариативность, которая сводилась к возможности изменения фильтров в уже заготовленных датасетах;
«громоздкая», кастомная архитектура, которую затруднительно поддерживать и развивать без комьюнити.
Кроме этого, отдельно от Charts, в ОК существовал проект мониторинга продуктовых метрик. Для мониторинга данные ежедневно собирались в Apache Zeppelin из детальных слоев данных и витрин (в зависимости от сложности метрики), а после сбора данных — рассчитывались изменения значений метрик.
Для фиксирования изменения метрик были выбраны заранее заданные пороги (процент изменения метрики между сравниваемыми периодами), при пересечении которых метрика попадала в отчет. Для разных сравниваемых периодов (вчера в сравнении с позавчера, вчера в сравнении с таким же днем прошлой недели, средние значения недели к неделе) подбирались разные пороги. Также учитывалось наличие праздничных дней в рассматриваемые периоды:
Однако, текущий вариант ввиду своей нагруженности был мало популярен вне команды аналитики, и мы решили подыскать мониторингу (и всем продуктовым данным) новый дом. Мы стремились сохранить имеющиеся достоинства и одновременно нивелировать недостатки, поэтому нам было нужно заменить старый табличный формат с его информативными, но трудно читаемыми отчетами, на решение, которое позволит также оперативно, но более структурировано и наглядно отслеживать изменения.
Критерии поиска и варианты
При выборе альтернативы Charts мы хотели найти инструмент, который будет иметь:
возможность визуализации необходимых метрик и гибкой настройки дашбордов;
open‑source‑реализацию, которая исключает зависимость от вендора и позволяет начать работу без больших инвестиций;
удобство работы и низкий порог входа, чтобы команде не пришлось с нуля получать уникальную экспертизу;
поддержку различных БД;
развитое комьюнити, которое в случае необходимости поможет с решением возникающих вопросов.
В качестве вариантов под свои задачи с учетом описанных критериев мы рассматривали несколько инструментов:
Superset — решение для визуализации данных и создания отчетов. Оно позволяет анализировать данные, создавать диаграммы и графики, а также делиться ими с другими пользователями.
Grafana — инструмент для мониторинга и анализа данных в реальном времени. Он предоставляет возможность создания дашбордов, с помощью которых можно отслеживать как продуктовые, так и технические метрики системы.
Tableau — платформа для бизнес‑аналитики, которая дает возможность легко анализировать и визуализировать данные. Предлагает широкий спектр инструментов для создания интерактивных дашбордов и графиков, а также интеграции с разными источниками данных.
Fine BI — платформа для управления данными и бизнес‑анализа. Предоставляет инструменты для обработки больших объемов данных, создания отчетов и дашбордов. Поддерживает интеграцию с разными системами управления данными.
При детальном рассмотрении Grafana не устроила нас с точки зрения удобства интерфейса и настройки, а также оказалась более ориентированной на технический мониторинг по данным, что не совсем подходит под наши задачи.
Tableau не подходил под нашу структуру данных в DWH, что потенциально могло осложнить его интеграцию. Более того, со временем Tableau ушел из России, как продукт — рассматривать далее его не было смысла.
Fine BI подходил по функциональности, но больше ориентирован на локальное хранение и обработку. К тому же, наш объем данных для него был чрезмерным. В итоге от инструмента пришлось отказаться.
С Superset ситуация изначально сложилась иначе — он «из коробки» подходил под наши запросы, в том числе в части интеграций, производительности обработки и формата работы с данными. Таким образом, мы остановили выбор именно на Superset.
Переезд и неочевидные сложности
После выбора инструмента и «введения» его в наш ИТ‑ландшафт мы начали перенос мониторинга из Zeppelin в Superset. При этом, как и планировали, в процессе миграции мы практически полностью сохранили структуру мониторинга — внесли лишь небольшие изменения.
Но довольно быстро стало очевидно, что вместо громоздкого мониторинга мы получили ещё более громоздкий мониторинг, но в красивом интерфейсе.
То есть нам требовался пересмотр формата мониторинга с упором на «сильные» стороны и доработкой недостатков.
В результате, чтобы закрыть эти потребности, мы:
Пересобрали поиск пороговых значений для алертов. Раньше пороговые значения изменения метрик определялись в процентах, при переходе которых изменение считалось важным. На эти пороговые значения влияло только наличие или отсутствие праздников в сравниваемом периоде. Теперь важные праздники выписываются отдельно. Пороговые значения заменены на алгоритм, динамически определяющий точки сдвига (Probabilistic CUSUM).
Внедрили новую версию вероятностной вариации алгоритма CUSUM. За основу идеи взяли статью Сарема Сейтца (Sarem Seitz). При этом сделали выбор в пользу самописной реализации в Clickhouse с некоторыми оговорками.
Алгоритм получился достаточно простой, чтобы его можно было реализовать на стороне SQL-запроса над готовыми данными, где он позволяет найти точки разрыва временного ряда.
В нашем конкретном случае алгоритм упрощён — для «прогрева» смотрится недавний и непродолжительный (несколько недель, чтобы не быть подверженным долгосрочной сезонности) период. По сути этим же методом проводится проверка «был ли сдвиг в течение предыдущей недели»?
Из плюсов — метод прост в реализации, позволяет найти как сдвиги, так и переход от стационарного временного ряда к линейному. Из минусов — алгоритм не уловит долгосрочных линейных трендов. Помимо этого, после каждой найденной точки разрыва нужно снова уходить на «прогрев».
Отображаем значения и изменения метрик более лаконично. Взяв на основу гайд Ивана Шамаева, мы сделали максимально наглядные и удобные дашборды, по которым можем быстро и прозрачно контролировать продуктовые метрики.
Написали гайдлайны по оформлению и добавили CSS‑стайлинг с корпоративными цветами и стилем. Для удобства пользования и быстрого ориентирования при переключении между дашбордами, мы выработали единый стиль и формат именования элементов. Подход оправдал себя, поэтому разработанные стиль и нейминг сейчас применяются в большинстве продуктовых дашбордов.
На выходе мы получили новую версию нашего мониторинга в Superset.
Наши результаты
Переезд на Superset мы смогли реализовать довольно «мягко» — без неочевидных проблем и «подводных камней», хоть и не без дополнительных издержек. Вместе с тем, затраченные нами ресурсы и время, дали комплексный профит.
Время на подготовку мониторинга сократилось. Разработка и финализация каждой версии мониторинга от сбора метрик до выкатки занимала около полутора недель. Теперь, при наличии необходимых данных, разработанные шаблоны и подходы позволяют собрать новый мониторинг по продукту в течение дня.
Работа с данными стала проще и продуктивнее. Данные берутся все также из Hadoop, но расчет агрегированных данных идет на мощностях DWH и помещается в Clickhouse. Результаты ежедневного мониторинга отправляются на почту. При этом, помимо статичной версии, на почте теперь отчет доступен и в интерактивном виде — с возможностью выбора даты отчета и платформы.
Порог входа в мониторинг метрик стал ниже. Superset удобен как менеджерам, так и аналитикам. К тому же он имеет довольно проработанную, подробную документацию. Поэтому на его освоение, при наличии соответствующей экспертизы и опыта работы со схожими решениями, не нужно много времени. Миграция на Superset обычно проходит для специалистов мягко.
Обновленная система позволила сократить «зоопарк технологий». Преимущества, которые мы получили при переходе на Superset, оказались важны и для других аналитических команд. В итоге они тоже начали мигрировать на Superset со своими дашбордами, что уменьшило «зоопарк технологий» внутри компании.
Что дальше?
Мы не останавливаемся на достигнутом и продолжаем совершенствовать систему мониторинга продуктовых метрик. Так, в перспективе мы планируем ряд доработок.
Планируем добавить мониторинги по тем продуктам, которых ещё нет в Superset. Это обеспечит полное покрытие мониторингами продуктовых направлений и позволит в формате «единого окна» следить за здоровьем каждого сервиса.
Хотим внедрить программную генерацию дашбордов. Автоматизация создания дашбордов позволит делать новые и единовременно обновлять старые мониторинги, если такое понадобится, что кратно уменьшит нагрузку на аналитиков.
Настроим рассылку в том числе и через корпоративный мессенджер. Это повысит удобство потребления и сделает взаимодействие с отчетами ещё проще.
О том, как будет меняться наш подход к мониторингу метрик и как будет трансформироваться работа с Superset — обязательно сообщим в одной из следующих статей.