«Что вы сделали прямо перед тем, как всё сломалось?» — этот вопрос задаёт каждый разработчик, и почти ни один пользователь не может точно на него ответить. Люди не помнят, какую кнопку нажали второй, догрузилась ли страница и что посреди заполнения формы они нажали «Назад». Воспроизведение сессии отвечает на вопрос, не задавая его: к баг-репорту приложена запись с перемоткой того, что происходило в браузере пользователя.
Как устроено воспроизведение сессии
Современное воспроизведение сессии — не видео. Запись пикселей была бы огромной, медленной и ничего не знала бы о структуре страницы. Вместо этого инструменты вроде rrweb — open-source-движка, на котором построено воспроизведение в BugDump, — делают снимок DOM, а потом записывают изменения: добавленные и удалённые узлы, изменения атрибутов, значения полей ввода, прокрутку, движения мыши, клики.
При просмотре страница собирается заново из этих данных — так шахматную партию восстанавливают по записи ходов, а не снимают доску на видео. Запись получается компактной, и раз она структурная, а не визуальная, по ней можно перематывать и точно видеть, с каким элементом работал пользователь, а не только где был курсор на экране.
Практическое следствие: воспроизведение обходится достаточно дёшево, чтобы постоянно работать в фоне, поэтому моменты до того, как пользователь решил сообщить о баге, уже записаны, когда он нажимает кнопку отчёта. Этого никогда не дадут сценарии в духе «запишите экран прямо сейчас»: к моменту, когда кто-то начинает запись, баг уже случился.
Что воспроизведение показывает, а логи — нет
Логи консоли и сети говорят, что делал код. Воспроизведение показывает, что делал пользователь. Баги живут в зазоре между ними, и некоторые их виды почти невозможно диагностировать, не видя действий пользователя:
Баги последовательности — модальное окно ломается, только если его открыть, закрыть и открыть снова. Ни одна строка лога этого не скажет; воспроизведение покажет за десять секунд.
Состояния гонки — пользователь кликнул до того, как завершился запрос. Воспроизведение даёт время клика, сетевой лог — время ответа; вместе это и есть диагноз.
Ввод, который только кажется неправильным — пользователь вставил значение с пробелом в конце, или автозаполнение заполнило поле, которого вы не ждали. Воспроизведение показывает реальное состояние формы.
Путаница с состоянием интерфейса — пользователь был в отфильтрованном представлении, в устаревшей вкладке или посреди несохранённой правки. Состояние DOM в каждый момент — прямо перед вами.
Верно и обратное: воспроизведение без логов показывает, что страница сломалась, но не почему. Необработанное исключение — в консоли, ответ 500 — на вкладке сети. Поэтому воспроизведение полезнее всего как одна из панелей полного отчёта, а не как отдельный инструмент.
Воспроизведение в работе с баг-репортами
Традиционно воспроизведение сессий живёт в аналитике: записывают всех, а потом выборочно смотрят сессии, чтобы изучать UX. Модель мощная, но тяжёлая: вы храните тысячи сессий, чтобы изредка посмотреть одну.
Баг-репорты переворачивают её. BugDump собирает воспроизведение в фоне и прикладывает его, когда пользователь отправляет отчёт, вместе с буфером консоли (до 300 записей, 2000, пока идёт запись экрана), буфером сети (150 запросов, 1000, пока идёт запись экрана, упавшие помечены), данными об окружении и метриками производительности. Вы получаете записи ровно тех сессий, где что-то пошло не так и человек об этом сказал, — самых информативных сессий, какие бывают.
Отчёт приходит как полное досье: прочитайте описание пользователя в одно предложение, перемотайте запись, чтобы увидеть действие, найдите в консоли исключение, которое оно вызвало, и упавший запрос в сетевом логе. Для многих багов эта последовательность заменяет весь разговор о шагах воспроизведения.
Приватность
Запись DOM может содержать всё, что показывает страница, включая то, что вводят пользователи. Отнеситесь к этому серьёзно:
Решите, что записывается. Воспроизведение должно быть осознанным переключателем в каждом проекте, а не невидимой настройкой по умолчанию, о которой вы забыли. В BugDump это флаг функции (
features.sessionReplay), которым управляете вы.Фильтруйте чувствительный трафик. Если вы собираете сетевые данные, фильтрами держите сторонние или чувствительные эндпоинты вообще вне буферов: их отбрасывают до сохранения, а не вымарывают после.
Дайте авторам отчётов закрашивать лишнее на скриншоте. С размытием в редакторе скриншотов пользователь сам прячет номер своего счёта перед отправкой. Скрывать данные лучше тому, кто знает, что в них чувствительного, а не регулярному выражению.
Сообщите об этом. В политике конфиденциальности должно быть сказано, что баг-репорты могут содержать запись сессии автора. Люди, которые отправляют баг-репорт, обычно рады, что данные уходят вместе с ним, но знать об этом они должны.
Когда воспроизведение — лишнее
Не каждому проекту воспроизведение нужно с первого дня. Контентный сайт без интерактивного состояния получает основную пользу от скриншотов и логов консоли. Воспроизведение оправдывает себя, когда в приложении есть сценарии — многошаговые формы, редакторы, оформление заказа, дашборды, — где путь важен не меньше конечной точки. Если в последних пяти разговорах о багах звучала фраза «хорошо, а что вы нажали перед этим?», воспроизведение окупится сразу.
Ещё стоит понимать, какую «запись» вы получаете. В виджете BugDump есть и явная запись экрана (пользователь рассказывает о проблеме и одновременно записывает экран), и фоновое воспроизведение сессии (автоматическое, прикладывается к отчётам). Первое — инструмент общения, второе — криминалистики. Они дополняют друг друга, а не заменяют.
Какой разрыв закрывает воспроизведение
Воспроизведение сессии закрывает самый старый разрыв в баг-репортах: разницу между тем, что, по словам пользователя, произошло, и тем, что произошло. Вместе с логами консоли, сетевыми данными и окружением — и собранное автоматически в тот момент, когда реальный пользователь сталкивается с реальной проблемой, — оно превращает «не воспроизводится» из частого вердикта в редкость.
Читайте также
Воспроизведение сессии без слежки — как BugDump записывает сессию только для отчёта, даёт пользователю скрыть лишнее и выключается одной строкой.
Как собрать логи консоли и сетевые запросы из браузера пользователя — как перехватить console, ошибки, fetch и XHR и не сломать страницу, за которой вы следите.
У меня всё работает: определитель невоспроизводимых багов — около восьми различий между двумя машинами и след, который оставляет каждое из них.