В 30 раз снизили количество обращений в техподдержку

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

Большинство багов получается устранить до того, как с ними столкнутся пользователи. Для этого перед запуском приложения проводят автоматические и ручные тесты. Но есть ошибки, которые появляются уже после запуска. Если их быстро не исправлять, пользователи будут уходить, а компания — терять деньги. Чтобы этого не происходило, нужно настраивать системы мониторинга: они помогают быстро находить причину и устранять ошибки.

Канадская компания управляет платформой с видео для взрослых. Чтобы не терять пользователей в странах, где подобный контент заблокирован, компания обратилась к OrbitSoft. За 10 месяцев мы разработали VPN-приложение для пяти операционных систем. Клиент сохранил свою аудиторию и даже получил дополнительную прибыль: приложением пользуются не только подписчики платформы, но и другие клиенты. Подробнее о проекте — в статье «Приложение для VPN: как мы исправляли чужие ошибки и запускали проект». В кейсе «Как настраиваем внешнюю интеграцию на примере VPN-приложения» мы рассказали, как подключили онлайн-оплату, систему нотификации и CRM. В этом материале остановимся на организации работы техподдержки и интеграции систем мониторинга ошибок.

Интегрируем сайты и приложения с внешними системами и сервисами:

• CRM, ARM, POS, складские системы;
• системы уведомлений, SMS- и email-рассылок;
• платежные сервисы;
• системы мониторинга ошибок и другие.

Заказать бесплатную консультацию

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

1. В обращениях люди описывают проблему своими словами. Чаще всего пишут что-то вроде «страница не открывается», «приложение зависает», «оплатил подписку, но ничего не происходит». Из этих формулировок разработчикам не всегда понятно, в чем причина ошибки. Приходится долго выяснять, задавать пользователям много вопросов.
2. Пользователи отвечают на вопросы об ошибках с неохотой. Если же просить их делать какие-то сложные вещи, например лезть в реестр, включать и выключать службы для VPN, люди и вовсе не станут напрягаться: им проще удалить приложение и поставить другое.

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

• Система просмотра логов собирает информацию о действиях пользователей.
• Система crash reporting формирует подробные отчеты об ошибках для разработчиков.

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

Первое время логи VPN-приложения хранились на одном сервере. Разработчики могли искать в них информацию вручную. Однако позже мы решили сделать архитектуру более надежной и развернули кластер из трех серверов. Это нужно, чтобы приложение можно было масштабировать и не переживать, что оно зависнет от большого количества пользователей.

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

Автоматизировали работу с логами

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

Мы выбрали готовую библиотеку crash reporting для .Net, на котором написано приложение. Подключили ее к приложению и добавили адреса, куда должны приходить сообщения от пользователей. Чтобы настроить систему, нам понадобился всего день.

Как формируется отчет:

1. Приложение выдает ошибку, пользователь отправляет обращение в техподдержку.
2. Библиотека формирует отчет об ошибке и отправляет его администратору на почту. В отчете есть информация о том, какая часть приложения и кода вызвала ошибку, а также лог-файлы с активностью пользователя. Их можно сравнить с логами нашего API-сервера.

Система crash reporting не только формирует отчеты об ошибках, но и собирает обратную связь от пользователей: присылает письмо и просит оценить само приложение и конкретные VPN-сервера. Так получается собирать статистику по работе серверов — смотреть, какие из них проблемные, и исправлять там ошибки.

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

• Система просмотра логов Elasticsearch. С ней разработчикам не приходится вручную изучать множество лог-файлов, чтобы исправить ошибку. Вся информация собрана в одном хранилище с удобным веб-интерфейсом.
• Система crash reporting автоматически формирует отчет об ошибке, который помогает разработчику быстро понять, какая часть приложения стала причиной сбоя.

Мы не писали системы мониторинга с нуля, а интегрировали сторонние, хорошо известные нам решения. Это позволило сократить сроки проекта.

Обратная связь помогла улучшить приложение: мы доработали его по крэш-репортам, и теперь в поддержку приходят только мелкие ошибки. Например, раньше пользователи Windows-приложения присылали в техподдержку по 2—3 письма в день, а после внедрения системы — 1—2 письма в месяц. С 2022 года в приложении не было ни одного крупного сбоя.