Баг, фича или «на что я жмал»? Детективы из поддержки снова вступают в игру

Пять новых кейсов, над которыми пришлось поломать голову агентам поддержки Топвизора. А ещё внутри вас ждёт интерактив, в котором мы вместе попробуем поразмышлять над тремя вечными истинами: баг, фича или пользовать просто не понял, на что жмал?

Привет! На связи Топвизор и его агент поддержки — Вика Анохина. Я уже рассказывала о буднях в поддержке, которые часто выглядят как детектив, а сегодня хочу продолжить свой рассказ, ведь с тех пор в наше бюро расследований поступили новые дела.

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

Небольшой дисклеймер: ОС, браузер и другая техническая информация о пользователе здесь не важна.

Тикет №1. Кривые запросы

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

Тикет №2. Исчезновение графиков

У пользователя не отображаются данные на графиках в проекте. С другими проектами пользователя проблемы нет. Вы проверяете проблемный проект со своей стороны, но у вас данные есть. Что предпримете?

Тикет №3. Странный порядок групп

Пользователь жалуется, что при добавлении новых групп или запросов в интерфейсе они всегда отображаются в начале списка (сверху), а не добавляются по порядку (в конце списка). Баг или фича?

Тикет №4. Неработающая сортировка

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

Тикет №5. Медленный API

Пользователь жалуется на медленный ответ от сервиса по API. Однако никаких промедлений ни в работе по API, ни в интерфейсе вы не видите и воспроизвести не можете.

Если все ситуации обдуманы, а теории записаны, приступим к разбору!

Если в первые секунды вы были в ступоре, то мы прекрасно понимаем ваши ощущения — 10 секунд паники. Ситуация у нас не воспроизводилась и запросы выглядели, как и должны — на узбекском языке:

Но ничто не укроется от внимательного взгляда агента поддержки. Мы попросили у пользователя полноэкранный скриншот страницы (до этого никаких визуальных данных от пользователя не было) и заметили, что некоторые элементы интерфейса также выглядят странно. Например, в пользовательской версии «Запрос» называется «Ключевым словом», а «Позиции» — «Рейтингом»:

Вся страница выглядела так, как будто бы прошла афганскую войну с Google Translate. И здесь нам в голову пришла гениальная мысль — автоперевод страниц. У пользователя был включен интерфейс на английском языке, браузер счёл, что это не по-православному (?) и автоматически перевел всё на русский. В том числе и добавленные запросы.

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

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

Самые внимательные из вас должны были заметить, что URL topvisor.com под графиком на первом скриншоте неактивен (серого цвета). Поэтому для него данные не отображаются. А так как это единственный домен в проекте, то данные на графике совсем отсутствуют.

Такая же ситуация была и у пользователя. Поняли мы это не сразу, но, догадавшись, сразу же сообщили ему об этом!

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

Проблема пользователя заключалась в том, что новые группы не добавлялись в том порядке, какой ему был нужен. И после добавления приходилось сортировать их вручную. Когда групп немного — это не большая проблема, но у некоторых пользователей число групп доходит до нескольких тысяч. Даже просто создание такого ядра будет уже трудозатратным, помимо танцев с бубнами вокруг порядка групп. Однако для решения этой задачи у нас есть импорт с помощью файлов — через него группы добавятся в том порядке, который вы укажете в нём.

И молодцы все, кто отметил создание группы в начале списка как фичу. В интерфейсе группы действительно добавляются в обратном порядке — последняя добавленная группа всегда будет вверху списка.

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

Пользователь обратился с такой проблемой: некорректная работа сортировки в разделе Проверка позиций. Однако мы ситуацию изначально воспроизвести не смогли и попросили пользователя обновить страницу и проверить, сохранится ли проблема после этого.

В попытке разобраться, что же произошло, мы пошли в наши ✨логи✨

Там мы посмотрели, каким образом проводилась сортировка, какие ещё действия совершал пользователь перед ней или после. Возможно, это как-то повлияло на результат? При проверке мы заметили, что в некоторых запросах параметр содержит в себе конкретную дату для сортировки, а в некоторых нулевое значение — 0000-00-00. Протестировали работу в своём проекте и выяснили, что нулевое значение указывается при сортировке по дате последней проверки. Также обратили внимание, что после сортировки была запущена новая проверка. Так как после обновления страницы проблема с сортировкой решилась, мы пошли воспроизводить полную картину в тестовом проекте:

1. Отсортировали позиции по последней существующей сейчас проверке:

2. Запустили проверку позиций, после ее завершения НЕ обновляем страницу.

3. Вновь сортируем позиции по проверке из 1 пункта:

В этом случае сортировка проходит опять-таки с параметром 0000-00-00, однако теперь у нас уже другая последняя дата, и по факту позиции сортируются по ней, хотя пользователь выбирает не её.

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

Что сделали:

Пожалуй, этот кейс — самый сложный для анализа без знаний особенностей Топвизора. Пользователь без всяких уточнений написал нам о каких-то проблемах с API, с которыми он столкнулся в процессе работы. Обычно мы запрашиваем текст запроса, который отправляет юзер, а также ошибку, которую он получает в ответ. Но тут пришло следующее сообщение: «Как будто медленно отвечает ваш апи сервис». Это показалось нам странным, поэтому решили проверить одну гипотезу, которая в дальнейшем и подтвердилась.

Для понимания, почему нам пришла именно эта идея, окунёмся в контекст нашего рабочего дня. Это был не особо примечательный вторник, который ознаменовался только одним — это был первый рабочий день после новогодних праздников, а значит, всем сеошникам России и ближайшего СНГ настало время запустить проверку позиций.

Начало рабочей недели в отделе поддержки выглядит примерно так:

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

Для пользователя ситуация выглядела следующим образом: «Я с помощью API запустил проверку и очень долгое время не могу получить её результаты. Наверное, это какие-то проблемы со скоростью API». И исходя из этого контекста ситуации, он написал нам.

Что же в свою очередь наблюдаем мы со своей стороны? В аккаунте очень много маленьких проектов отправлены на проверку. Все они долгое время находятся в статусе «В очереди», то есть их проверка еще не началась. Соответственно, мы выдвинули предположение, что проблема пользователя именно в этой скорости — скорости проверки его проектов, а никакой проблемы именно с работой API нет. И оно подтверилось.

5 дел закрыто, и наше детективное агентство вынесло такой вердикт:

1. Фича

2. Фича

3. Фича

4. Баг

5. Фича

А что получилось у вас? Были в вашей практике подобные случаи, когда на первый взгляд 100-процентный баг после проверки оказывался неочевидной фичой?