Мониторинг интернет-магазина: метрики и алерты

Мониторинг нужен не для красивых дашбордов, а чтобы узнавать о проблеме раньше покупателей. Если сайт упал, оплата не проходит или цены разошлись с 1С, бизнес теряет деньги каждую минуту.

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

Что должен показывать мониторинг

Технические метрики

Начните с того, что напрямую влияет на доступность и деньги. Не нужно сразу собирать сотни метрик: десять правильных лучше, чем сто бесполезных.

• Код ответа главной, каталога, карточки и checkout.
• Время ответа сервера и TTFB.
• Доля 5xx и 4xx на ключевых страницах.
• Доступность базы и количество соединений.
• Длина очереди и время обработки задач.
• Ошибки оплат и внешних сервисов.
• Свободное место на диске.
• Размер и скорость роста логов.

Бизнес-метрики

Технически сайт может быть доступен, но не приносить заказы. Поэтому смотрите не только на инфраструктуру, но и на поведение покупателей.

• Число заказов и выручка за час и день.
• Конверсия checkout и брошенные корзины.
• Оплаты: успешные, неуспешные, зависшие.
• Заказы без статуса и без движения.
• Расхождения цен и остатков с 1С.
• Ошибки форм и обращения в поддержку.

Как настроить алерты

Что не стоит мониторить

• Каждую метрику сервера без привязки к влиянию на заказы.
• Сотни событий, которые никто не читает.
• Показатели, которые невозможно улучшить.
• Дублирующие алерты из разных систем.
• Всё сразу на телефон без приоритетов.

Инструменты

Можно начать с бесплатных или недорогих решений, а позже усложнять. Главное — не инструмент, а покрытие ключевых сценариев.

• Uptime-мониторинг внешних страниц.
• APM или логи для ошибок и медленных запросов.
• Метрики сервера и базы.
• Очереди и фоновые задачи.
• Синтетические проверки checkout.

Регламент реакции

Типичные ошибки

• Следить только за главной страницей.
• Не проверять checkout и оплату.
• Настроить алерты, но не проверить их.
• Игнорировать предупреждения до аварии.
• Не хранить историю инцидентов.

Мониторинг — это не разовая настройка. Раз в месяц стоит смотреть, какие алерты были ложными, какие проблемы пропустили и что стоит добавить.

Дашборд для бизнеса

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

• Заказы и выручка за сегодня и вчера.
• Конверсия checkout и оплат.
• Число ошибок и зависших заказов.
• Доступность сайта и время ответа.
• Задержка обмена с 1С.
• Количество обращений в поддержку.

Такой дашборд не должен требовать технических знаний. Если для понимания графика нужно открывать логи, он не выполняет задачу.

Мониторинг оплат и заказов

Оплата — самый критичный шаг. Если платёжный сервис отвечает медленно или отклоняет платежи, это видно не сразу: часть пользователей просто уходит.

• Доля успешных и неуспешных оплат.
• Зависшие платежи без статуса.
• Ошибки платёжного шлюза.
• Заказы без подтверждения.
• Расхождение оплат с CRM.
• Время от заказа до оплаты.

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

Как выбрать инструмент

Не начинайте с покупки дорогой платформы. Сначала определите, какие сигналы нужны и кто будет реагировать. Инструмент — вторичен.

• Uptime-проверки для внешних страниц.
• Логи и APM для ошибок и медленных запросов.
• Метрики сервера и базы.
• Очереди и фоновые задачи.
• Синтетические проверки checkout.

Для небольшого магазина часто достаточно uptime-сервиса, алертов из логов и нескольких проверок checkout. Главное — не количество инструментов, а покрытие сценариев.

Регламент на случай аварии

Регламент не обязан быть большим. Достаточно одной страницы, где написано, кто что делает и в каком порядке. В момент аварии это экономит больше времени, чем любой дашборд.

Как часто проверять

Частота зависит от критичности. Доступность и checkout стоит проверять каждую минуту, бизнес-метрики — раз в час или день, инфраструктурные тренды — раз в неделю.

• Доступность и оплата — постоянно.
• Заказы и ошибки — каждый час.
• Скорость и Core Web Vitals — раз в день.
• Инфраструктура и отчёты — раз в неделю.

Что делать с ложными алертами

Ложные срабатывания быстро убивают доверие к мониторингу. Если алерт приходит слишком часто и ничего не значит, его перестают читать.

• Поднимите порог или добавьте условие длительности.
• Уберите дубли из разных систем.
• Разделите критичные и информационные события.
• Раз в месяц пересматривайте правила.

Хороший алерт — это событие, на которое есть понятное действие. Если действие не описано, скорее всего, алерт лишний.

Как связать мониторинг с поддержкой

Мониторинг и поддержка должны работать вместе. Если алерт приходит, но никто не знает, что делать, система создаёт шум, а не пользу.

• У алерта есть владелец и инструкция.
• Поддержка видит статус и историю.
• Критичные события эскалируются разработчику.
• После инцидента обновляется регламент.

Раз в месяц стоит разбирать, какие события произошли и как на них реагировали. Это помогает убрать лишнее и добавить то, что действительно важно.

И не превращайте мониторинг в самоцель. Если дашборд никто не открывает, а алерты игнорируются, проблема не в инструменте, а в процессе. Начните с одного критичного сценария и доведите его до рабочего состояния.

Через месяц посмотрите, сколько инцидентов вы поймали до жалоб. Если ноль, возможно, вы мониторите не те сценарии или алерты слишком шумные.

Начните с малого: доступность, checkout и оплата. Этого уже достаточно, чтобы не узнавать о проблеме от клиента.