Июльская катастрофа, или Важность мониторинга ошибок в реальном времени
TL;DR: Я потерял несколько недель притока новых пользователей из-за случайной ошибки в новой версии VS Code. Урок: прикручивай мониторинг ошибок в реальном времени как можно раньше, если есть возможность.
Делать соло-проект сложно. Приходится примерять кучу ролей: разработчика, дизайнера, маркетолога, техподдержки и так далее. Нужно жонглировать задачами и приоритетами, и иногда что-то выпадает из рук.
В первую неделю июля рандомное обновление VS Code изменило внутреннюю систему аутентификации. Из-за этого существующие версии GitByBit стали уходить в бесконечный цикл прямо на старте. Грубо говоря, никто из пользователей не мог проходить курс, пока проблема не была решена. Ничего не подозревая, я спокойно пилил практику по пулл реквестам (которая, кстати, получилась суперкрутой и вышла на прошлой неделе).
В какой-то момент кто-то наконец создал задачу на GitHub, я всё починил и выкатил новую версию. Но по факту я потерял приток новых пользователей за несколько недель, потому что люди просто не могли запустить курс.
Тот самый момент, когда понимаешь, что твой проект не работал последние пару недель.
Большинство моих других проектов — это обычные веб-приложения на моём собственном сервере. Если они написаны на популярных фреймворках вроде Laravel или React, туда легко прикрутить какую-нибудь систему мониторинга ошибок, например Sentry или Rollbar. Если что-то падает, я моментально получаю уведомление, заливаю исправление на сервер, и все пользователи сразу его получают. Отлаживать такие вещи тоже проще: есть доступ к логам сервера и видно, что именно пошло не так.
Но GitByBit — это не обычное веб-приложение. Тут есть VS Code-расширение и веб-версия, и у каждого свои фронтенд и бэкенд. Всё это написано на разных технологиях, поэтому настроить сбор ошибок — это не просто вставить API-ключ от Rollbar в конфиг. До сих пор все эти куски отправляли телеметрию на мой главный сервер, где она оседала в одном общем логе.
Увы, никакой системы алертов об ошибках в реальном времени не было. Поэтому, чтобы узнать, что что-то сломалось, мне приходилось открывать и читать вот это:
Не очень читабельно, если только не владеешь клингонским.
Можно, конечно, заглядывать в такие логи время от времени, но это имеет смысл разве что сразу после релиза. Большую часть времени ничего страшного не происходит, и ты просто перестаёшь проверять логи регулярно. Заглядываешь раз в неделю, потом заваливаешься другими задачами и вообще забываешь об этом.
Вообще-то, они собирались... Но логи нужно не только собирать, за ними нужно ещё и следить.
Кажется, что если всё сломается, то пользователи сами об этом напишут, или ты всё равно рано или поздно увидишь это в логах. Доля правды в этом есть, но проблема может всплыть не сразу, и к тому моменту отвалится куча людей, которые не смогли запустить курс. Ровно это и случилось с проектом в июле.
Эй, Санёк, ты же вроде опытный разработчик? Почему ты сразу не прикрутил нормальный мониторинг ошибок? Чего ждал до сих пор?
Хороший вопрос! В этом-то и вся проблема соло-разработки: дел море, а рук всего две (хочется верить!). Приходится расставлять приоритеты! К тому же:
- У меня уже собирались базовые логи, поэтому, если я туда заглядывал, было видно, что идёт не так.
- Я был по уши загружен работой над новыми материалами, поэтому тратить несколько недель на бэкенд-инфраструктуру казалось не самой важной задачей.
- Проект пока в раннем доступе, поэтому люди морально готовы к каким-то ошибкам. Я надеялся, что если что-то отвалится, пользователи об этом сообщат, и я быстро всё починю.
Но раз курс становится популярнее, думаю, пришло время настроить нормальный мониторинг ошибок в реальном времени.
PostHog спешит на помощь
Уже несколько лет я стараюсь отказаться от сервисов Google, но на своих проектах всё ещё часто использую Google Analytics для отслеживания действий пользователей. Недавно я наткнулся на PostHog и решил его попробовать. В нём есть всё, что мне нужно: трекинг событий, запись сессий и отчёты об ошибках. А ещё у них щедрый бесплатный тариф, так что на раннем этапе можно не париться о расходах. Ну и у них крутой маскот — ёжик Макс, которого я просто обожаю.
Если тебе не нравится Макс, у тебя нет сердца.
Правила разработки расширений для VS Code запрещают пихать свои скрипты аналитики внутрь расширения — в основном из соображений производительности и безопасности. Зато телеметрия, которую ты собираешь через API самого VS Code, вполне легальна. Можно принимать её на своём сервере, а потом пересылать в PostHog или любой другой сервис аналитики. Так можно отслеживать ошибки и то, как пользователи взаимодействуют с расширением, ничего не нарушая.
Теперь ошибки собираются в читабельном виде, и сразу понятно, что и где сломалось. Дубликаты группируются, так что видно, сколько пользователей столкнулись с проблемой.
В каждой ошибке достаточно деталей, чтобы помочь найти её причину. После исправления помечаешь ошибку статусом resolved, чтобы не засорять список.
Это решило проблему с читабельностью и отслеживанием ошибок, но мне всё ещё не хватало алертов в реальном времени. В PostHog встроена система уведомлений: если вылезает новая ошибка, она может стукнуть в Discord, Slack или куда-то ещё. Так я моментально узнаю о проблемах и могу быстро их закрыть.
Теперь, если из Discord слышен непрекращающийся ПИП!!!, я знаю: курс сломался. Можно быстро открыть дашборд PostHog и посмотреть, в чём дело.