Мониторинг сайта и CRM: как узнавать о сбоях раньше клиентов

В пятницу вечером перестаёт работать форма заявки. Сайт открывается, страницы на месте, но после нажатия кнопки ничего не происходит: почтовый сервис отклоняет письма. Заявки не доходят ни до менеджеров, ни до CRM. В понедельник утром кто-то замечает, что за выходные не было ни одного обращения. Это не катастрофа, но два дня потерянных заявок — это реальные деньги, и всё это время никто не знал о проблеме.

Мониторинг нужен ровно для того, чтобы узнавать о таких вещах сразу. Он не предотвращает сбои, но сокращает время, в течение которого они остаются незамеченными. А время незамеченного сбоя — это почти всегда самая дорогая его часть.

Уровень 1. Доступность

Самая простая проверка: внешний сервис раз в минуту открывает страницу и проверяет, что сервер ответил кодом 200 за разумное время. Если нет — отправляет уведомление.

Важные детали:

• Проверяйте не только главную, но и ключевые страницы: каталог, страницу оформления заказа, вход в личный кабинет.
• Проверяйте из внешней сети, а не с того же сервера. Если сервер упал, мониторинг на нём упадёт вместе с ним.
• Ищите на странице ключевое слово, а не только код ответа. Сайт, который отдаёт код 200 с текстом «Ошибка базы данных», формально доступен.
• Настройте повторную проверку перед уведомлением: одна неудачная проверка из-за сетевого сбоя не должна будить дежурного ночью.

Уровень 2. Сертификаты и домен

Истёкший SSL-сертификат делает сайт недоступным для большинства посетителей: браузер показывает предупреждение, и люди уходят. Автоматическое продление обычно работает, но ломается после переноса сервера, смены DNS или изменения настроек веб-сервера.

Мониторинг сертификата предупреждает за 14–30 дней до окончания срока. То же стоит сделать для домена: напоминание о продлении должно приходить не одному человеку на личную почту, а в общий канал.

Уровень 3. Ключевые сценарии

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

1. Отправка формы. Тестовая заявка раз в час или раз в день с проверкой, что она дошла до CRM. Тестовые заявки помечаются, чтобы менеджеры их не обрабатывали.
2. Вход в кабинет. Тестовый пользователь логинится и проверяет, что видит свои данные.
3. Оформление заказа. До шага оплаты или с тестовым режимом платёжного сервиса.
4. Интеграции. Обмен с 1С, CRM, службой доставки: когда была последняя успешная синхронизация.

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

Уровень 4. Ресурсы сервера

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

Пороги для уведомлений лучше ставить с запасом: предупреждение при 80% заполнения диска, критичное — при 90%. Тогда есть время спокойно разобраться, а не чистить диск в аварийном режиме.

Уровень 5. Ошибки приложения

Сбор ошибок из кода: исключения на сервере, ошибки JavaScript в браузерах пользователей, медленные запросы к базе. Это уже инструмент разработчиков, но владельцу продукта полезно видеть хотя бы общую динамику: если после обновления число ошибок выросло в пять раз, что-то пошло не так.

Куда отправлять уведомления

Уведомление, которое никто не прочитал, бесполезно. Несколько правил:

• Отдельный канал. Не общий рабочий чат, где уведомление утонет среди обсуждений, а отдельная группа в Telegram или другом мессенджере, куда пишут только системы мониторинга.
• Несколько получателей. Минимум двое: если один в отпуске или спит, второй увидит.
• Понятный текст. Не «Monitor 7 DOWN», а «Сайт example.ru: форма заявки не отвечает с 21:14».
• Уведомление о восстановлении. Чтобы было понятно, когда проблема ушла сама или её исправили.
• Без шума. Если уведомления приходят по десять раз в день и все ложные, их перестанут читать. Ложные срабатывания нужно разбирать и устранять.

Страница статуса

Публичная страница статуса показывает клиентам, работают ли сервисы прямо сейчас. Во время сбоя она снимает часть нагрузки с поддержки: вместо десятков одинаковых вопросов клиенты видят, что проблема известна. Для SaaS-продуктов это почти обязательный элемент, для обычного сайта — по желанию.

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

Пример набора проверок для небольшого бизнеса

Ниже — пример того, что имеет смысл настроить для компании с сайтом услуг, формой заявки и небольшой CRM. Это не исчерпывающий список, а разумный минимум, который настраивается за день.

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

Как не утонуть в уведомлениях

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

• Отделяйте предупреждения от аварий. Диск заполнен на 80% — предупреждение в рабочее время. Сайт не отвечает — авария в любое время.
• Ставьте повторную проверку перед уведомлением. Одна неудачная проверка из-за сетевого сбоя не должна поднимать людей.
• Группируйте. Если упал сервер, не нужно десять отдельных уведомлений о каждой странице на нём.
• Пересматривайте пороги раз в квартал. Если уведомление ни разу не потребовало действий, его стоит перенастроить или убрать.

Что делать, когда уведомление пришло

Мониторинг без регламента реакции работает наполовину. Запишите короткую инструкцию:

1. Кто реагирует в рабочее время, кто — в нерабочее.
2. Что проверить первым: доступность сервера, логи, последние изменения.
3. Как откатить последнее обновление, если проблема появилась после него.
4. Кому сообщить: руководителю, клиентам, на страницу статуса.
5. Что записать после инцидента: причина, время, что сделано, как предотвратить.

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

С чего начать сегодня

• Подключите внешний мониторинг доступности главной и двух-трёх ключевых страниц.
• Добавьте проверку срока сертификата.
• Создайте отдельный канал для уведомлений и добавьте туда двух человек.
• Проверьте, что резервные копии действительно создаются, — об этом подробно в статье о резервных копиях.
• Запишите, кто и как реагирует на сбой.

Если вы хотите, чтобы за сайтом или CRM следили постоянно, это входит в наше сопровождение: мониторинг, реакция на инциденты и ежемесячный отчёт. А о том, какие ещё расходы появляются после запуска, читайте в статье о поддержке сайта после релиза.