Привет! Меня зовут Маша Иванова, я старший аналитик монетизации в Авито. В статье рассказываю, как несовершенство процесса логирования приводит к ошибкам в данных, как это влияет на достоверность аналитики и что мы сделали, чтобы предотвратить такие проблемы. Материал будет интересен аналитикам, QA-инженерам и разработчикам.
Содержание:
Старый процесс и проблемы логирования
Мы записываем логи постоянно: интересуемся, какую страницу открыл пользователь, какую кнопку нажал, какую иконку увидел. Мы анализируем взаимодействие пользователей с интерфейсом, чтобы отслеживать и исправлять ошибки — смотрим именно на действия, а данные обезличены или псевдонимизированы.
При этом процесс проверки неформализованный, полностью ручной и неодинаковый у разных команд. Подобная несистемность демонстрирует два ключевых недостатка: низкую надёжность и чрезмерную ресурсоёмкость. Расскажу подробнее, как мы работаем в обычном режиме и с какими проблемами при этом встречаемся.
Этап 1. Создаём инструкцию. Перед реализацией новой фичи аналитик составляет логинг-инструкцию в Confluence. Это табличный документ, по которому разработчик настраивает, в каком виде события (действия пользователей) отправятся в базу данных.
В инструкции описано:
какие события надо отправлять в лог;
в какой момент это происходит;
какие параметры включаются в лог. Например, уникальный идентификатор пользователя, откуда он пришёл, расположение элемента взаимодействия и другие;
какие значения считаются допустимыми или обязательными.
Писать инструкции в Confluence не очень удобно. По сути это мостик между аналитиком, который описывает требования к данным и разработчиком, который далее пишет код. И это критически важный шаг, так как именно здесь мы задаём структуру и ожидаемый формат данных, на основе которых потом будем строить метрики.
Этап 2: Реализуем код. Разработчики пишут код логирования в соответствии с инструкцией, но они не всегда знают бизнес-контекст, могут неправильно интерпретировать её или ошибиться. В результате качество событий, которые поступают в систему аналитики, ухудшается, что значительно снижает их ценность.
Мы используем специализированное хранилище Clickstream — туда собирается информация обо всех действиях пользователей на сайте.
Подробнее о том, как мы перевели аналитику для внутренних сервисов компании на собственную платформу, читайте в статье фронтенд-инженера: «Как мы перевели аналитику внутренних сервисов Авито на собственное решение».
Этап 3: Проверяем логи. У нас нет единого утверждённого процесса валидации событий, поэтому в разных командах подходы отличаются. Например, в одном случае тестировщик вручную сверяет события с инструкцией. В другом — аналитик вместе с разработчиком отслеживает, отправляется ли событие в нужный момент и с нужными параметрами.
Бывают случаи, когда валидация вообще не происходит, особенно если нет формального запроса на проверку. А если валидации нет, события могут попасть на продовую витрину с ошибками.
Например, в базу данных могут попасть логи с пустыми или некорректными параметрами.
Это затрудняет работу:
искажает данные аналитики, в том числе в витринах и дашбордах;
ломает A/B-тесты, особенно если событие используют в качестве метрики;
усложняет отладку, поскольку ошибки замечают с большим опозданием
Этап 4: Логи попадают в витрину. Все события загружаются в Clickstream, где с ними начинают работать аналитики, чтобы строить отчёты и рассчитывать метрики.
Если ошибка проскочила, то на этом этапе она уже «закреплена в истории», поэтому может незаметно повлиять на анализ и исказить выводы. Чтобы её исправить, сначала нужно найти, а потом составить задачу, формализовать её, отдать разработчикам и реализовать. Это всё занимает много времени.
Разработка автоматизированного решения
Чтобы повысить качество данных и снизить нагрузку на команды, мы решили перевести валидацию логирования в автоматический режим аналогично тому, как в разработке работают линтеры, тесты или code review.
Линтер — автоматический помощник, который проверяет код на ошибки и соответствие стандартам без запуска.
Тесты — специальные программы, которые запускают код с разными данными и сравнивают результаты с ожиданиями.
Автоматический code review — проверка кода на типовые ошибки, уязвимости и соответствие стандартам качества, перед тем как он попадёт в проект.
Мы разработали систему, которая проверяет события и сообщает об ошибках в мессенджер Mattermost. Реализовали три основных компонента: инструкцию, сбор данных и систему уведомлений.
Этап 1. Создали инструкцию. Сначала это были JSON-описание события. Это минимально формализованный, машиночитаемый, хотя и не слишком удобный формат для ручного редактирования.
JSON (JavaScript Object Notation) — универсальный текстовый формат, чтобы хранить и передавать структурированные данные. Несмотря на название, не зависит от JavaScript.
Представляет данные в виде пар «ключ-значение», где ключи — это строки, а значениями могут быть строки, числа, логические значения, массивы или другие объекты.
Позже инструкция переехала на платформу Clickstream с UI интерфейсом, и теперь аналитикам удобнее использовать конкретные параметры или регулярные выражения.
Этап 2. Подключили бота к витрине Clickstream.
Мы рассматривали несколько вариантов реализации системы алертинга, включая настройку дашбордов в Redash и создание DAG-ов в Airflow. Для MVP версии мы выбрали бота, так как им легко управлять и можно быстро настроить. В результате в сжатые сроки реализовали логику проверок, идеально соответствующую нашим задачам.
Техническая реализация была построена на базе фреймворка mmpy_bot, развёрнутого на платформе PaaS.
Принцип работы
Ежедневно и самостоятельно бот подключается к витрине Clickstream, выгружает данные за последние 24 часа и фильтрует события согласно JSON-инструкции. Все расхождения автоматически транслирует в виде алертов в Mattermost. Таким образом, команда может оперативно реагировать на проблемы.
Единственное ограничение — потенциальная нагрузка на витрину, если количество событий резко вырастет. Однако на этапе MVP такой сценарий маловероятен. В любом случае мы находимся в процессе разработки плана масштабирования, который предусматривает переход на более оптимальный способ выгрузки данных.
Этап 3. Подключили бот-алертинг. Это основной компонент системы, который развёрнут на платформе PaaS. Бот работает на cron-триггере и запускается раз в день, чтобы находить ошибки и оповещать о них.
Бот подгружает инструкции и собирает данные из витрины, после чего последовательно проверяет данные:
что все обязательные поля присутствуют (поле required не null);
во всех checked-полях указаны допустимые значения.
Для каждого события бот проставляет метку ошибки: если она есть, то «1», если нет, то «0», потом группирует ошибки и формирует отчёт (summary). Затем отправляет сообщения в указанный в инструкции канал, а команда узнаёт, какие события содержат ошибки, а также какие поля отсутствуют или содержат недопустимые значения.
После внедрения MVP для ежедневной проверки событий и запуска бота на PaaS система стабильно заработала и сразу начала приносить ценность — уже в первую неделю удалось выявить реальные ошибки в логировании.
Теперь мы замечаем все ошибки и стараемся разобраться в причинах: где и почему произошло нарушение. Например, одна ошибка выскочила из-за бага в логике отправки событий, а вторая — потому что в код забыли залогировать параметр. Раз мы знаем о причине, можем завести задачу для разработчика, чтобы он исправил ошибку.
Что ещё хочется сделать
Перенести процесс валидации ошибок ближе к разработке, чтобы находить ошибки до того, как они попадут в базу данных, которой все пользуются. То есть искать их проактивно, а не реактивно.
Внедрение автоматизации
Мы уже используем новую систему валидации ежедневно. На старте к боту подключилась только наша команда «Комфортная сделка», чтобы мониторить логирование всех виджетов и профиля кабинета продавца. Успешные кейсы и аккуратный процесс работы привлекли внимание других коллег, поэтому к нам присоединилась команда «Ипотека», которая теперь использует бота для контроля качества данных в своей APM-платформе.
Как это работает. Когда бот находит аномалию, отправляет алерт в общий чат Mattermost, где нахожусь я и QA-инженер. Моя задача — оперативно завести тикет, в котором описать баг и дать предварительную оценку масштабу проблемы. Затем тестировщик проводит детальную проверку и передаёт задачу разработчикам с определённым приоритетом, что значительно ускоряет процесс исправления.
Как это сработало в жизни
В личном кабинете продавца недвижимости есть виджет обращений в поддержку. Ключевые события (такие как тема, текст, ID пользователя) должны логироваться стабильно. Это обеспечивает корректный исторический анализ обращений. Но для этого важно не менять их имена.
Когда разработчики реализовали дополнительный функционал, то изменили названия (title) уже существующих типов обращений в системе логирования. В результате события с новыми именами начали поступать в витрину как совершенно новые метрики и создали параллельную ветку данных.
В будущем это привело бы к трём проблемам:
«распил» исторических данных;
необходимость создавать костыли в витринах и дашбордах;
полная потеря консистентности аналитики по обращениям.
Бот быстро обнаружил расхождение, когда сверял фактические логи с эталонной JSON-инструкцией. Он заметил новые, не согласованные названия событий в день возникновения инцидента и тут же отправил об этом алерт в Mattermost.
В результате команда получила оповещение до того, как проблема повлияла на аналитические отчёты и оперативно скорректировала изменения.
Вся статья кратко
Раньше логирование проходило в наполовину ручном режиме. Сначала мы создавали инструкцию, по которой разработчик собирал код логирования. Код записывал события, а затем эти записи вручную анализировали тестировщики и аналитики.
Из-за ручной работы, некоторые ошибки попадали в базу данных, а потом искажали аналитику и влияли на бизнес-решения.
Теперь мы внедрили новое решение, в котором всё логирование проходит в автоматическом режиме с помощью двух ботов: первый собирает все логи, а второй проверяет их и сообщает об ошибках в чат Mattermost.
Новая система уже работает в двух командах, и мы планируем расширить её на весь Авито.
Больше кейсов из работы в Авито читайте в нашем телеграм-канале: «Коммуналка аналитиков».
А если хотите вместе с нами помогать людям и бизнесу через технологии — присоединяйтесь к командам. Свежие вакансии есть на нашем карьерном сайте.