Комментарии 9
Спасибо, что поделились опытом. По-моему описан очень естественный процесс от понимания, что какую-то проблему можно было бы обнаружить более оперативно, если бы был реализован мониторинг соответствующего показателя, до реализации мониторинга на всем множестве метрик.
Каждый день в 6 утра запускается скрипт на питоне, который выгружает из ClickHouse все события за последние 6 недель, предварительно агрегируя их по часам в разрезе платформы, события и уникальных для этого события параметров
Если не секрет, сколько срезов (метрик / временных рядов) таким образом анализируется? Хотя бы порядок: 1к, 10к?
Спасибо, рад, что оказалось полезно)
Если не секрет, сколько срезов (метрик / временных рядов) таким образом анализируется?
Вообще не секрет - где-то в районе тысячи
3 платформы * ~300 событий * N дополнительных параметров (например, события доски анализируются также в разрезе параметра board_type). Но некоторые из этих 300 событий приходят очень редко (меньше 100 в сутки), поэтому их отфильтровываем, чтоб не шуметь всякими ложно-положительными срабатываниями
Очень круто, спасибо!
Очень крутая статья! Было интересно увидеть как это происходит.
Только в отличие от последней, у анализа аномалий поведения пользователей есть огромное преимущество — вся информация находится на сервере, не требуется ничего выкачивать на стороне клиента.
Хорошая практика, как мне показалось. Если, конечно, есть кому регулярно разгребать false positive/negative )
Не исключаю, что подобный подход со временем станет стандартом де факто, или как мы айтишники выражаемся — must have )
Если, конечно, есть кому регулярно разгребать false positive/negative
Мой рабочий день обычно и начинается с того, что я открываю чатик с аномалиями, смотрю на картинки от бота и разгребаю их)
На самом деле занимает это прям мало времени - по части событий сразу видно, что false-positive (событий мало, разброс исторически большой, событие минорное). Если понятно, что что-то сильно поменялось - чаще я всё-таки в курсе предстоящих изменений, поэтому не сложно сопоставить изменения в продукте с аномалиями в событиях аналитики. Ну а если уж сходу не становится понятно, что произошло - идём в дашборд, локализуем проблему, быстро чекаем релизы, призываем разработчиков нужной команды (по названию ивента понятно, в какой части продукта он находится и какая команда за него отвечает).
Но и это не всегда приходится делать, т.к. разработчикам детектор аномалий тоже нравится и многие из них сами заглядывают в чатик с аномалиями и смотрят, что же там происходит :) Часто к тому моменту, как я захожу посмотреть аномалии, уже кто-то успевает отписаться в треде и скинуть ссылку на задачку, в которой вносили изменения
Спасибо, очень круто!
Всё таки не понял чем это отличается от мониторинга. Системы мониторинга могут такие же графики с количеством кликов и количеством событий рисовать.
Тут вопрос в том, что подразумевается под мониторингом
В моём понимании мониторинг - это инструмент, который в реалтайме может сообщить и том, что где-то что-то сломалось и надо срочно бежать чинить.
Здесь же речь об инструменте, который позволяет на регулярной основе в автоматическом режиме получать отчёты о каких-то нетипичных вещах, при чем их "нетипичность" определяется исключительно на основе данных за последние полтора месяца. Здесь нет необходимости ловить такие явления в тот же миг, как они начали происходить, достаточно смотреть раз в день (раньше пробовали раз в час, но это избыточно).
А уж реализация такого инструмента может быть любой - кому-то достаточно отчётов, которые метабейз умеет из коробки отправлять на почту. Мы, кстати, сначала им и пользовались, но быстро стало понятно, что автоматический расчёт аномалий уместить в SQL-скрипты очень сложно, да и это тупо неудобно, легче делать всё в питоне и слать куда-то в Slack
Как из данных узнавать о том, что в продукте что-то пошло не по плану