Здарово, работяги! 💪

В прошлом посте я начал разговор про System Design, давайте продолжим.

Представим ситуацию. Солнечный денёк, ветер за окном треплет листья деревьев... 🍃☀️ Вы сидите, себе работаете, попиваете кофеёк ☕️... У вас интересные задачки... Вы можете сконцентрироваться на работе... Представили? Тогда идём дальше. Сидите, работаете, никого не трогаете...
И тут вам прилетает сообщение, сообщение от коллеги из саппорта 😈... В письме он говорит, что у них за час/день/другой промежуток времени накопилось большое количество обращений от пользователей, которые жалуются, что не могут использовать какую‑то функциональность вашего приложения. Вы начинаете судорожно вспоминать, когда был последний релиз, и понимаете, что совсем не 5 минут назад... И тут вашу концентрацию, великолепный настрой и всё хорошее просто сметает к чёртям, заменяя холодным потом и кучей тревог 😰, да ещё и кофе перестал быть вкусным, а приобрёл вкус страданий — если ещё не пили такой, то попробуйте, считаю его самым бодрящим.

Знакома ли вам такая ситуация? Мне — да. И, к сожалению, в моей памяти количество таких эпизодов не равно одному... Бррр, как вспомню — аж передёргивает...

Что же делать, чтобы в такой ситуации не оказаться? Писать хороший код, скажете вы. Хорошее решение!) Конечно, нужно стараться, но ошибки действительно случаются, случаются баги и т. д. И в таких ситуациях самое главное — скорость детекта проблемы и скорость восстановления ⏱️.

Сегодня начнём с первого — скорость детекта. И главным решением тут является хорошо настроенная система мониторинга, которая позволит вам узнавать о проблемах не когда количество обращений пользователей стало критичным и ваша компания стремительно теряет деньги, а намного раньше.

Если вы никогда не сталкивались с таким, то у вас, скорее всего, возникнет вопрос: с чего начать? Что мониторить? ❓
Вариантов большое количество, но совершенно точно я предложил бы начать именно с ошибок. Таким образом вы сможете понять следующее:

- Вы сможете увидеть текущий фон - какие ошибки уже возникают у ваших пользователей и выстроить процесс постепенного снижения фона;
- Отслеживать появление новых ошибок.
- Отслеживать тренды — рост и падение 📈📉. Важно! Падение тоже очень важно, т. к. неожиданное падение может тоже быть сигналом о проблеме.

Также не забывайте, что для разбора важно логировать информацию не только о названии ошибки, но и контекст - версия/релиз, окружение, браузер/ОС, stacktrace и другую подобную информацию, которая позволит вам быстрее разобраться с ошибкой и ускорит время восстановления.

Следующим шагом может стать настройка алёртов(автоматическое оповещение, при возникновении определеныых условий) — они позволят вам узнавать о проблемах быстро и не сидеть, гипнотизируя графики, весь день.🚨 Реакцию на них добавьте в рутину вашего дежурного (On call)

Для организации мониторинга ошибок есть множество решений. Скорее всего вы слышали про Sentry, Raygun, Bugsnag и прочее. Но вы, может быть, уже заметили, что я в последнее время часто пишу про открытые отечественные решения, т. к. у многих из вас могут быть проблемы с использованием зарубежных решений. Тут тоже задался вопросом, а что такого на рынке есть, и нашёл — Хоук. Потыкал его какое‑то время на своих пет‑проектах и могу вам его посоветовать.
Основные фичи(критичные для меня):
- Реалтайм мониторинг ошибок
- Возможность логировать не только название ошибки, но и контекс - stack trace, релиз, коммит, окружение и тд
- Алерты
- Поддержка Source Maps
- Настройка доступов
- Open source SDK(полезно посмотреть как устроен инструмент, котрый вы используете)

Также, как я и говорил выше, ПО отечественное, поэтому:
- Серверы в РФ, а для многих это сейчас критично;
- Можно оплачивать RU‑картой (для меня это супер‑критерий, т. к. я очень не люблю всю бумажную, банковскую волокиту). 💳

Резюмируя: мониторинг — это маст‑хэв. Начинайте с мониторинга ошибок, следите за трендами ошибок, настройте алерты и выстраивайте процесс постепенного уменьшения уровня ошибок. Ну и ссылочка на Хоук — хороший кандидат для старта.