Липнева катастрофа, або чому важливий моніторинг помилок у реальному часі
TL;DR: через випадкову помилку в новій версії VS Code я на кілька тижнів залишився без нових користувачів. Урок: моніторинг помилок у реальному часі варто впроваджувати якомога раніше.
Розробляти проєкт наодинці важко. Доводиться бути всім одразу: розробником, дизайнером, маркетологом, підтримкою — і це ще не все. Постійно жонглюєш завданнями та пріоритетами, і часом щось таки випадає з рук.
В перший тиждень липня чергове оновлення VS Code змінило внутрішню систему автентифікації, і наявні версії GitByBit почали зациклюватися одразу на старті. Фактично, доки проблему не було усунуто, ніхто з користувачів не міг пройти курс. А я, нічого не підозрюючи, працював над майбутньою практикою пулл реквестів (яка, до речі, дуже крута й вийшла минулого тижня).
Зрештою хтось повідомив про проблему на GitHub, тож я зміг виправити її та випустити нову версію. Але нових користувачів за ці кілька тижнів фактично втрачено: скористатися курсом вони так і не змогли.
Коли усвідомлюєш, що твій проєкт не працював останні кілька тижнів.
Більшість моїх інших проєктів — це звичайні вебзастосунки, які працюють на моєму сервері. Вони збудовані на популярних фреймворках на кшталт Laravel чи React, тож їх легко інтегрувати із системою моніторингу помилок у реальному часі, як-от Sentry або Rollbar. Щойно стається помилка, я одразу отримую сповіщення, заливаю виправлення на сервер — і воно миттю доступне всім користувачам. Налагоджувати проблему теж простіше: у мене є доступ до серверних логів, тож видно, що саме пішло не так.
Але GitByBit — не звичайний вебзастосунок. Є розширення для VS Code і вебверсія, і кожна частина має окремий фронтенд і бекенд. Усе це збудовано на різних технологіях, тож звітування про помилки не зводиться до «вставити API-ключ Rollbar десь у конфіг». Досі всі ці частини надсилали телеметрію на мій основний сервер, де вона зберігалась в єдиному централізованому журналі.
Але, на жаль, жодної системи моніторингу, яка сповіщала б про помилки в реальному часі, не було. Тож, щоб дізнатися про помилки, доводилося відкривати й читати ось це:
Не надто читабельно — хіба що ти володієш клінгонською.
Можна час від часу переглядати такі логи, але користь від цього є хіба що одразу після релізу. Здебільшого нічого поганого не відбувається, тож регулярні перевірки поступово закидаєш. Заглядаєш раз на тиждень, потім поринаєш в інші справи — і все, забуто.
Власне, я так і роблю... Але логи треба не лише збирати, а й моніторити.
Здається, що коли щось зламається, про це розкажуть користувачі або воно зрештою спливе в логах. Частка правди тут є, але проблема може висіти непоміченою досить довго — а за цей час можна втратити чимало користувачів, яким помилка не дала пройти курс. Саме це й сталося з проєктом у липні.
Гей, Олександре, хіба ж ти не досвідчений розробник? Чому було не зробити нормальне звітування про помилки від самого початку? Навіщо чекати аж дотепер?
Гарне запитання! У цьому й складність соло-розробки: справ безліч, а рук лише дві (сподіваюся). Доводиться ПРІОРИТЕЗУВАТИ! До того ж:
- Базові логи вже були, тож за бажання можна було подивитися, що йде не так.
- Я був зайнятий роботою над матеріалами курсу, тож витрачати тижні на бекенд-інфраструктуру здавалося не найнагальнішою справою.
- Це ранній доступ, тож люди більш-менш готові до проблем і помилок. Я сподівався: якщо щось піде не так, користувачі повідомлять, і я швидко все виправлю.
Але тепер, коли курс набирає популярності, саме час подбати про нормальний моніторинг помилок і проблем у реальному часі.
PostHog поспішає на допомогу
Я вже кілька років намагаюся відв'язатися від Google, але для відстеження дій користувачів на своїх проєктах досі здебільшого використовую Google Analytics. Нещодавно я натрапив на PostHog і вирішив спробувати. Він поєднує кілька потрібних мені речей: відстеження подій, запис сесій і звітування про помилки. А ще в нього щедрий безкоштовний тариф, тож у проєкті на етапі раннього доступу можна поки не перейматися витратами. До того ж є в них і милий їжачок-маскот на ім'я Max, якого я просто обожнюю.
Якщо тобі не подобається Max — ти погана людина.
Настанови для розробників VS Code забороняють підключати власні аналітичні скрипти всередині розширення — здебільшого з міркувань продуктивності та безпеки. Проте телеметрія, зібрана через VS Code API, не порушує правил: її можна приймати на своєму сервері й пересилати далі в PostHog чи будь-який інший сервіс аналітики. Так можна стежити за діями користувачів і помилками в розширенні, лишаючись у межах настанов.
Тепер помилки збираються в читабельному форматі, тож видно, що і де пішло не так. Повтори групуються, тому одразу зрозуміло, скількох користувачів зачепило.
Кожна помилка містить чимало деталей, які допомагають знайти першопричину. Виправлену помилку можна позначити як розв'язану, щоб вона не захаращувала список.
Це розв'язало проблему з читабельністю та відстеженням, але лишалося питання сповіщень про нові помилки в реальному часі. У PostHog є вбудована система сповіщень, яка може писати в Discord, Slack чи інші канали, щойно стається нова помилка. Тож тепер я одразу дізнаюся про будь-які проблеми й можу швидко їх виправити.
Тепер, якщо з Discord лунає безперервний потік БУП!!!, я знаю: курс зламався. Можна швидко відкрити дашборд PostHog і подивитися, що сталося.