Липнева катастрофа, або чому важливий моніторинг помилок у реальному часі
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 і подивитися, що сталося.