Представьте: платёжный модуль упал в пятницу вечером, а вы узнаёте об этом в понедельник — из гневных отзывов и отчёта о упавших продажах. Ситуация типичная: по разным оценкам, о проблеме сообщают лишь единицы процентов пользователей, остальные просто уходят к конкурентам. Мониторинг в продакшене — это система датчиков, которая сообщает команде о сбое за минуты, а не за дни. В статье разберём три его основы — трекинг ошибок, логи и алерты — и покажем, почему это страховка для выручки.
Цена молчания: что происходит без мониторинга
Считается, что «клиенты же скажут, если что-то сломалось». Не скажут. По классическому исследованию Akamai, до 88% пользователей после негативного опыта на сайте реже возвращаются — и почти никто из них не напишет в поддержку. Простой пример: интернет-магазин со 150 заказами в день и средним чеком 4 000 ₽, в котором сутки «тихо» падала оплата на определённом устройстве, теряет десятки тысяч рублей — без единого падения сервера, потому что формально всё «работало». Вторая проблема — скорость починки: без логов и трейсов разработчик ищет причину вслепую, воспроизводя баг со слов клиента, и это часы или дни. С настроенным мониторингом тот же инцидент закрывается за минуты, потому что отчёт об ошибке уже лежит в системе с точным указанием строки кода.Sentry: аварийный маяк для ошибок
Sentry — сервис, который встраивается в фронтенд и бэкенд и перехватывает все необработанные ошибки автоматически. У клиента упала страница — через несколько секунд в Sentry появляется полный отчёт. Что именно вы получаете:- Stack trace — файл, строка кода и версия релиза, где произошёл сбой;
- Группировку — тысячи одинаковых ошибок собираются в одну карточку со счётчиком, а не заваливают почту;
- Контекст — браузер, ОС, идентификатор пользователя и его последние действия до сбоя;
- Привязку к релизам — сразу видно, что ошибка появилась после конкретного деплоя;
Логи: чёрный ящик вашего приложения
Sentry ловит исключения, но не всё. Ошибки бизнес-логики, медленные операции, странные повторяющиеся действия пользователей — это видно только в логах. Главный принцип — структурированные логи: каждая запись в формате JSON с уровнем (INFO, WARNING, ERROR), временем, идентификатором запроса и пользователя. Тогда по одному request id можно собрать всю цепочку: запрос пришёл — БД ответила медленно — платёжный шлюз вернул ошибку. Второй принцип — централизованное хранилище, а не файлы на разных серверах, которые никто никогда не откроет. Обязательно настройте срок хранения — обычно 30–90 дней — и маскирование чувствительных данных: пароли, номера карт и персональные данные в логи попадать не должны, это требование в том числе 152-ФЗ.Алерты: сигнал, который невозможно пропустить
Метрики и логи без оповещений — просто архив, в который смотрят постфактум. Алерты превращают данные в действие, но настраивать их нужно по правилам. Во-первых, пороги: не «любая ошибка — сигнал», а «доля ответов 5xx выше 1% за 5 минут» — иначе команда получит сотни уведомлений и перестанет их читать. Во-вторых, градация критичности: сбой оплаты или регистрации — это уведомление в Telegram немедленно и в любое время, замедление страницы на 200 мс — тикет на утро. В-третьих, эскалация: если дежурный не отреагировал за 15 минут, алерт уходит дальше — руководителю разработки. И в-четвёртых, дедупликация: 500 одинаковых ошибок за минуту — это один алерт со счётчиком, а не 500 сообщений. Правильно настроенные алерты — это 3–7 сигналов в неделю, каждый из которых реально важен.Что мониторить помимо ошибок
Трекинг исключений — необходимый минимум, но сбой не всегда выглядит как исключение в коде. Полноценный мониторинг закрывает несколько уровней:- Доступность — внешние проверки uptime каждые 1–5 минут с разных точек;
- Скорость ответа — среднее и 95-й перцентиль времени ответа, доля медленных запросов;
- Ресурсы — CPU, память, место на диске, срок действия SSL-сертификата;
- Фоновые процессы — очереди задач, cron-скрипты, интеграции с 1С и CRM (их падение часто незаметно в интерфейсе);
- Синтетические проверки — автотест ключевых сценариев (логин, корзина, оплата) каждые 5–10 минут;
- Бизнес-метрики — количество заказов и оплат в час.
Как настраивается мониторинг на практике
Хорошая новость для владельца бизнеса: базовый контур мониторинга для типового проекта — это несколько дней работы, а не месяцы. Порядок обычно такой:- Инвентаризация: определяем критичные сценарии и точки отказа — оплата, регистрация, интеграции с 1С и платёжными шлюзами.
- Подключаем Sentry к фронтенду и бэкенду, настраиваем привязку к релизам.
- Переводим логирование на структурированный формат и поднимаем централизованное хранилище.
- Строим дашборды и настраиваем алерты с порогами, выводим их в Telegram команды.
- Пишем регламент: кто дежурит, кто и в какой срок реагирует, что делать при каждом типе алерта (runbook).
- Проводим учебную аварию: искусственно роняем тестовый сценарий и проверяем, что сигнал доходит и команда действует по регламенту.
Пять вопросов подрядчику о мониторинге
Если разработку ведёт подрядчик или штатный разработчик, отношение к мониторингу — быстрый маркер зрелости команды. Задайте пять вопросов. Где лежат Sentry и логи, и покажите живой пример отчёта об ошибке? Кто и как узнаёт о сбое ночью и в выходные? Какое целевое время реакции на критичный алерт? Можно посмотреть дашборд с доступностью и метриками? Что произошло во время последнего реального инцидента и какие выводы были сделаны? Если на большинство вопросов ответ «ну, если клиенты напишут…» — вы платите за разработку вслепую, а риски простоя фактически остаётесь нести вы. Нормальный подрядчик отвечает на эти вопросы за пять минут и сам предлагает внедрить мониторинг на этапе запуска.Мониторинг в продакшене окупается первым же предотвращённым инцидентом: одни сэкономленные сутки работы платёжки стоят дороже, чем неделя настройки логов и алертов. Итоговый эффект — сокращение времени обнаружения и починки сбоев с часов и дней до минут, а главное — первым о проблеме узнаёт ваша команда, а не клиент. Базовый контур ставится за несколько дней, сервисы вроде Sentry имеют бесплатные тарифы, а дежурство и регламент — вопрос дисциплины, а не бюджета. Если вы сейчас не можете за минуту ответить, падало ли что-то на вашем сайте за последнюю неделю и как вы об этом узнали, — начните именно с этого разговора со своей командой или подрядчиком.