What we do in the shadows: опыт QIC в мониторинге и аналитике ошибок

Меня зовут Дарья Измоденова, я системный аналитик команды Motor в QIC digital hub. Я отвечаю за онлайн-сервис для покупки страховых полисов на автомобили в Омане — новой для нас стране, где приложение запустилось недавно.

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

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

Как выглядит упрощенный процесс работы над функциональностью:

Как видно из схемы, наша команда работает итеративно. Выпуская улучшение, мы стараемся его анализировать, на основе чего появляются новые и новые гипотезы, которые отправляются в бэклог и на дальнейшую проработку. Для качественного анализа работы сервиса необходимо отслеживать как бизнес и продуктовые метрики, так и технические показатели и ошибки. Над этим работают системный и продуктовый аналитики.

Начнем с продуктовой аналитики.

Для анализа пользовательского поведения используем Google Analytics. За нее отвечают продуктовые аналитики: составляют ТЗ на разметку сервиса, ведут техническую документацию, а также собирают и анализируют данные до и после релиза.

Google Analytics — недорогой и достаточно легкий в настройке и поддержке инструмент. Плюсом идет универсальное подключение дополнительных сервисов: Google Ads, BigQuery, Looker Studio. Из минусов можно выделить наличие лимитов отслеживаемых событий, из-за которых приходится лавировать между качеством и количеством, а также погрешность при отправке событий, которую приходится учитывать при анализе. А еще Google отображает не полные, а сэмплированные данные, поэтому аналитикам приходится тратить дополнительное время на запрос в BigQuery или построение дашборда.

Google Analytics позволяет планово анализировать работу приложения и подсвечивать места, где пользователи сталкиваются с техническими ошибками (для анализа которых используются уже другие инструменты).

Наше приложение интегрируется с мастер-системой, в которой обрабатывается большая часть бизнес-логики. Запросы и ответы к ней хранятся и логируются в базе данных. Получив выгрузку за нужный период, можно смотреть и анализировать request и response, фильтровать запросы по сессиям и отслеживать действия пользователя хронологически. К сожалению, данные с прода доступны с лагом в 1 день, в остальном это отличный способ разобраться в проблеме.

В первое время вместо таблиц существовал только чат, в который логи запросов выгружаются в реальном времени. Это позволяет оперативно отслеживать ситуацию, но при отсутствии алертинга ответственность лежит на том, кто в этот чат заглянул. Для более системной работы, конечно, нужен процесс, который появится позже.

Перед нашей командой встала задача «перейти на error коды», а именно перенести всю логику работы приложения с фронтенда на бэкенд. Приведу пример:

У клиента может быть только один активный полис на VIN-номер (уникальный номер автомобиля). Если такой полис найден, покупка невозможна, и пользователю отображается экран ошибки. Для решения этой задачи фронтенд отправляет VIN-номер на бэкенд, который запрашивает данные у третьей системы и возвращает их на фронт. Фронтенд проверяет определенный параметр, чтобы узнать, есть ли у клиента активный полис, и, в случае его наличия, показывает экран с ошибкой. Мы переписали логику, чтобы бэкенд самостоятельно проверял наличие активного полиса и отправлял фронтенду соответствующий error_code.

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

Несмотря на все трудности, упражнение оказалось очень полезным. Появились четкие маркеры для всех краевых сценариев, что заложило основу для подключения остальных систем мониторинга.

Sentry — программа, для отслеживания ошибок в приложении. Среди ее возможностей также: проверка производительности, сбор обратной связи пользователей, анализ и рекомендации улучшений в коде, запись сессий и инцидент менеджмент. Подробнее про Sentry читайте в другой нашей статье Дастана Абдирайым «Как работать с Sentry: гайд от разработчика». Я лишь опишу опыт внедрения Sentry в нашей команде.

При первом запуске трафика было важно быстро реагировать на ошибки, чтобы не допустить «слив бюджета». Для этого наша команда попробовала использовать Sentry. Идея заключалась в том, что при получении кода ошибки от бэкенда, фронтенд должен отправлять данные в Sentry, который отслеживает ошибки и генерирует алерты по мере необходимости. Мы вдохновились примером смежной команды, которые также настроили уведомления в Slack, и поспешили приступить к реализации.

Однако нужного результата мы не достигли. Мониторинг ошибок с http статусом 4хх пришлось отключить, чтобы не захламлять поток информации - их было очень много. Как итог — действительно проблемные запросы не попадали в статистику.

Вот, как прокомментировал ситуацию наш разработчик Максим Долгих:

«Sentry служит для мониторинга разработчиками непредвиденных ошибок в приложении. Идея, что аналитики будут через эти ошибки что-то отслеживать изначально была провальной — это была попытка «пилой забивать гвозди».

Сейчас Sentry используется для фронтовых ошибок и запросов со статусом 5хх. В планах часть запросов перевести на статус код 422 — этот код как раз сообщает о том, что нарушена бизнес-логика.

Мы получили отличный урок — не торопиться и изучать контекст применения того или иного инструмента другими командами перед его внедрением у себя. Пост-фактум оказалось, что ребята из смежной команды использовали схему мониторинга бизнес логики через Sentry в качестве исключения для одной фичи, которую важно было досконально мониторить после запуска. Когда все убедились, что критичных ошибок нет, Sentry стали использовать по назначению — для отслеживания фронтовых ошибок в приложении.

Elastic Search, далее ELK, давно является стандартом для работы с логами. Для внедрения этого инструмента требуется время и большое количество усилий, поэтому мы не могли его использовать сразу. Для внедрения Elastic были проделаны следующие шаги:

В нашем продукте ELK стал настоящим спасением. Чтобы разметить все методы и подготовить их к логированию у аналитика ушел один день, озаботиться нужно было лишь маскированием данных. Разработка также мгновенно добавила нужные методы в ELK и уже совсем скоро можно было смотреть первые логи на тестовом стенде.

Из плюсов использования Elasticsearch можно выделить очень быстрый поиск по большому набору данных, особенно на контрасте с существующими ограничениями к доступу к данным прода. У ELK удобный механизм агрегации данных для анализа логов: можно строить отчеты и дашборды, визуализировать данные, фильтровать их по приложению, сессии и так далее — это невероятно удобно.

К сожалению, на текущий момент есть и минусы: достаточно большой гэп между вызовами методов и появлением их в логах на проде. Наша разработка делает все возможное, чтобы это исправить. Часть команды также испытывает трудности к доступу к сервису из-за особенностей удаленной работы и сложной комбинации из нескольких VPN. Эти задачи также уже на проработке у отдела DevOps.

Тем не менее, с ELK у нас есть потенциально быстрый доступ к логам и возможность оперативно реагировать на инциденты и анализировать проблемные кейсы. Усилия на затрату внедрения Elasticsearch совершенно точно не будут потрачены впустую.

Инструменты — это хорошо. Работающие и задокументированные процессы — еще лучше. При внедрении мониторинга важно обговорить на старте, кто и за что будет отвечать. В нашей команде мы как раз допустили эту ошибку: пришлось собирать большую встречу и на ходу решать, как будем наблюдать за ситуацией на проде. И вот к каким зонам ответственности мы пришли:

Наша команда продолжает делать подходы к запуску трафика. Недавно мы выпустили большой релиз и переключили органический трафик на наш новый портал. За короткое время мы протестировали разные инструменты для анализа трафика и выбрали подходящие для нашего продукта. Критические ошибки удалось устранить, теперь наш фокус на улучшение бизнес-показателей.

Хорошая новость — не так давно в компании появился отдел Support, на руководителя которого легла задача выстроить систему мониторинга ошибок и работы с инцидентами. Совсем скоро у нас появится понятный процесс работы, доска в JIRA и даже своя почта для саппорт запросов! Совместными усилиями команд была заложена основа для работы сотрудников поддержки, теперь нас ждет будущее со стабильными сервисами и понятными процессами, а новые продукты станет запускать гораздо проще.

Благодарю Максима Долгих, Данила Малича, Марию Полякову, Александра Гордиенко, Владислава Щербакова за помощь в написании статьи.