Мониторинг стоит строить вокруг того, что посетитель должен сделать на сайте. Минимум — проверить доступность нужных адресов и ожидаемое содержимое. Для магазина или сервиса отдельно проверяются важные действия: выбор товара, корзина, форма. Каждая проверка должна иметь условия срабатывания, получателя и понятный следующий шаг.
Зелёная отметка рядом с доменом успокаивает. Но если она означает только «сервер ответил», о состоянии оформления заказа мы пока ничего не знаем. Я бы сначала уточнил, за что именно отвечает эта отметка.
Выберите адреса и действия, от которых зависит работа
Для сайта компании это могут быть главная, услуга и форма обращения. Для мебельного магазина — категория, карточка с вариантами, корзина и оформление. Проверять все страницы одинаково часто обычно незачем: сначала выделите критичные точки.
В нашей работе с несколькими мебельными партнёрами и большим числом сайтов важно учитывать домены и городские версии. Исправность одного магазина не подтверждает состояние остальных, даже если они похожи внешне.
Составьте короткий список: что проверяем, зачем, как выглядит успех и кто отвечает. Не оставляйте критерий на уровне «страница выглядит нормально». Для автоматической проверки нужны конкретные признаки: например, на карточке найдено ожидаемое название товара, а после добавления в тестовую корзину совпадают модель и выбранные параметры.
Разделите уровни проверки
Доступность показывает, удалось ли получить ответ за заданное время. Проверка содержимого помогает заметить, что вместо нужной страницы пришла заглушка или исчез важный блок. Проверка сценария подтверждает выполнение цепочки действий в условиях теста.
| Уровень | Пример | Что остаётся за пределами |
|---|---|---|
| Ответ сервера | Открывается адрес карточки | Правильность комплектации и цены |
| Содержимое | Найдены ожидаемые название и кнопка | Реальная отправка заказа |
| Сценарий | Товар добавился в тестовую корзину | Все товары, устройства и способы доставки |
| Передача обращения | Тестовая запись найдена у получателя | Скорость ответа реальному клиенту |
HTTP 200 означает успешный ответ на запрос, но внутри может оказаться страница ошибки с неправильным кодом. Поэтому для важных адресов полезно проверять и ожидаемый признак содержимого.
У нас есть собственный SiteMonitor. При выборе конкретной настройки надо отдельно сверять доступные проверки и их область. Этот список уровней — ориентир для организации мониторинга, а не обещание, что любой установленный монитор уже выполняет их все.
Каждый следующий уровень проверяет другой участок. Успешное открытие адреса не подтверждает корзину, а проверка одной корзины не охватывает весь ассортимент и все устройства.
Настройте интервалы и уведомления под цену пропуска
Частота зависит от важности сценария, нагрузки и возможностей проверки. Не существует одного интервала, который подходит всем сайтам. Проверка раз в некоторое время неизбежно оставляет промежутки, когда новый сбой ещё не замечен.
Чтобы краткий сетевой сбой не создавал лишнюю тревогу, можно предусмотреть повтор или подтверждение из другой точки. При этом подтверждение задерживает сообщение. Выберите компромисс осознанно и зафиксируйте его.
В уведомлении нужны адрес, время, название проверки, обнаруженный признак и ссылка на подробности. При восстановлении тоже полезно сообщить об изменении состояния. Иначе сотрудник может продолжать искать уже исчезнувшую проблему.
Проверьте, кто увидит сообщение ночью и что делать, если основной получатель недоступен. Общая группа без назначенного ответственного не всегда решает эту задачу.
Автоматические проверки не должны мешать работе
Проверять корзину лучше на разрешённом тестовом товаре или в заранее согласованном режиме. Автоматический тест не должен незаметно создавать реальные обязательства, списывать остатки или отправлять менеджерам десятки обычных заказов.
Для формы согласуйте тестовую отметку и место, где видно результат. Если проверка заканчивается только появлением надписи «спасибо», она не подтверждает получение заявки системой. Сохранение и доставку нужно проверять на соответствующем участке.
После изменения шаблона сценарий может перестать находить кнопку, хотя сайт работает. Поэтому различайте сбой сайта и поломку самой проверки. Последняя тоже требует реакции, иначе важный участок окажется без наблюдения.
Скорость наблюдайте в сопоставимых условиях
Время ответа сервера и удобство загрузки в браузере — разные вещи. Нужны понятные условия: адрес, регион проверки, устройство, сеть, состояние кэша. Для обычных посетителей дополнительно полезны реальные данные браузеров, когда их достаточно.
Резкое отклонение от привычного уровня — повод разобраться, а не готовый диагноз. Причина может быть в сервере, внешнем скрипте, сети проверяющего или тяжёлом изображении. Сначала найдите участок задержки.
Не обещайте обнаружить любую проблему раньше всех покупателей. Монитор видит выбранные адреса и сценарии в заданные моменты. Его ценность в сокращении неопределённости и организации реакции в этих пределах.
Проведите учебную тревогу
В согласованном тестовом окружении воспроизведите известную ошибку. Проверьте, сработал ли нужный сигнал, получил ли его ответственный и понял ли, что делать. Затем восстановите состояние и убедитесь, что восстановление замечено.
Сохраните результат: время события, обнаружения, передачи и реакции, а также фактический итог каждого этапа. Если сигнал появился, но до ответственного не дошёл, учебная тревога выявила незакрытую проблему. После изменений сайта повторяйте критичные сценарии. Заодно станет понятно, какие проверки устарели и где появились новые зависимости.
В разборе обновления svalmak.ru есть пример проверки страницы после изменений. Если сайтов несколько и нужен общий порядок наблюдения, можно обсудить набор проверок.
Учебная тревога проверяет не только сам монитор, но и порядок реакции. Время между событием и обнаружением зависит от интервалов и условий проверки.