Сайт может лечь в три часа ночи в субботу, и если никто не следит, об этом узнают в понедельник утром — по звонкам рассерженных клиентов или по пустой статистике заказов. Мы встречали магазины, которые не принимали оплату картой четверо суток, потому что после обновления модуля платёжная форма перестала открываться, а главная страница при этом работала идеально. Мониторинг доступности решает простую задачу: сократить время между моментом, когда что-то сломалось, и моментом, когда об этом узнал тот, кто может починить.
Сколько стоит простой
Прежде чем говорить о настройке, полезно оценить, что на кону. Посчитать стоимость простоя несложно: возьмите среднюю выручку сайта в час в рабочее время и умножьте на продолжительность типичного сбоя без мониторинга. Для интернет-магазина с оборотом 3 000 000 ₽ в месяц час простоя в дневное время означает потерю примерно 6 000–10 000 ₽ выручки. Если сбой обнаружили через 12 часов — уже десятки тысяч.
Прямые потери — не всё. Платная реклама продолжает откручиваться и тратить бюджет на клики, которые ведут на неработающую страницу. Поисковые роботы, несколько раз подряд получившие ошибку, могут временно понизить страницы в выдаче. Покупатель, который не смог оформить заказ, уходит к конкуренту и, возможно, не вернётся. А для B2B-компании неработающая форма заявки в день крупного тендера может стоить контракта.
Что проверять: не только главную страницу
Самая частая ошибка — мониторить только главную. Она открывается — значит, всё хорошо. Но главная страница часто отдаётся из кеша и продолжает работать, даже когда база данных недоступна, а каталог, корзина и формы выдают ошибку. Хороший мониторинг проверяет критические для бизнеса функции, а не просто факт ответа сервера.
Уровень 1: доступность сервера и страниц
Базовая проверка: сервер отвечает, возвращает код 200, время ответа в пределах нормы. Проверяются главная, ключевая категория каталога, популярная карточка товара, страница контактов. Для каждой страницы стоит проверять не только код ответа, но и наличие на ней определённого текста — например, названия товара или кнопки «В корзину». Иначе сервер может отдавать страницу с ошибкой и кодом 200, и мониторинг этого не заметит.
Уровень 2: сценарии
Проверка того, что работают ключевые действия пользователя: поиск возвращает результаты, товар добавляется в корзину, открывается страница оформления заказа, отправляется тестовая заявка через форму. Такие проверки сложнее в настройке, но именно они ловят самые дорогие сбои — когда сайт выглядит рабочим, а продажи не идут.
Уровень 3: инфраструктура и внешние зависимости
Срок действия SSL-сертификата и регистрации домена, заполненность диска на сервере, нагрузка на процессор и память, работа планировщика заданий, свежесть резервных копий, время последнего обмена с 1С. Многие из этих проблем можно увидеть за дни до того, как они приведут к падению.
Как часто проверять и откуда
Интервал проверок определяет, как быстро вы узнаете о проблеме. Для сайта-визитки достаточно проверки раз в 5–10 минут. Для интернет-магазина или сервиса, принимающего заявки круглосуточно, — раз в 1–2 минуты. Сценарные проверки, которые создают нагрузку и, например, отправляют тестовые заявки, делают реже: раз в 15–60 минут.
Важно проверять сайт из нескольких точек. Если проверка идёт с одного сервера, любая проблема со связью у самого сервиса мониторинга будет выглядеть как падение вашего сайта. Обычно используют 2–3 точки проверки и считают сайт недоступным, только если ошибку видят хотя бы две из них. Для сайтов, ориентированных на российскую аудиторию, разумно, чтобы хотя бы часть точек находилась в России: иногда сайт доступен из Европы, но недоступен у российских провайдеров, или наоборот.
| Что проверяем | Сайт компании | Интернет-магазин |
|---|---|---|
| Главная и ключевые страницы | Каждые 5 минут | Каждую 1 минуту |
| Время ответа сервера | Каждые 5 минут, порог 3 с | Каждую минуту, порог 1,5–2 с |
| Отправка формы заявки | Раз в сутки | Раз в час |
| Корзина и оформление заказа | — | Каждые 15–30 минут |
| SSL-сертификат и домен | Раз в сутки | Раз в сутки |
| Ресурсы сервера (диск, память) | Каждые 5 минут | Каждую минуту |
Уведомления: кто, как и когда узнаёт о проблеме
Мониторинг без правильных уведомлений бесполезен. Сигнал о падении, который ушёл на почту, которую никто не читает в выходные, равен отсутствию сигнала. При настройке нужно ответить на три вопроса: кто получает уведомления, по какому каналу и что он должен сделать.
Для критических событий — сайт недоступен, не работает оформление заказа — нужен канал, который точно заметят: сообщение в мессенджер, push-уведомление, при необходимости звонок дежурному. Для предупреждений — сертификат истекает через 20 дней, диск заполнен на 80% — достаточно письма или сообщения в рабочий чат. Если всё идёт в один канал, люди быстро перестают реагировать.
Обязательно должна быть цепочка эскалации: если ответственный не подтвердил получение тревоги за 10–15 минут, уведомление уходит следующему человеку. Иначе ночной сбой может остаться незамеченным, потому что телефон дежурного стоял на беззвучном режиме.
И отдельный совет владельцам: подпишитесь сами хотя бы на уведомления о полной недоступности сайта. Даже если поддержку ведёт подрядчик, вам важно знать о серьёзных проблемах и видеть, как быстро на них реагируют.
Ложные тревоги и как их избежать
Обратная сторона мониторинга — ложные срабатывания. Если система будит дежурного трижды за ночь из-за кратковременных сетевых сбоев, через неделю на её сигналы перестанут обращать внимание. И однажды пропустят настоящую аварию.
- Подтверждайте сбой несколькими проверками подряд: тревога поднимается после 2–3 неудачных попыток, а не после первой
- Проверяйте из нескольких точек и считайте сбоем только ошибку, подтверждённую большинством
- Настраивайте пороги времени ответа с запасом: разовый ответ за 3 секунды — не авария, устойчивые 5 секунд в течение 5 минут — повод разобраться
- Отключайте проверки на время плановых работ, чтобы не получать тревоги о том, что и так известно
- Исключайте тестовые заявки мониторинга из аналитики и из CRM, чтобы они не искажали статистику и не отвлекали менеджеров
- Раз в месяц разбирайте все срабатывания и убирайте проверки, которые шумят без пользы
Хорошо настроенный мониторинг поднимает тревогу редко, но каждый раз по делу. Если за месяц пришло больше 5–7 тревог, а реальных проблем было одна-две, конфигурацию стоит пересмотреть.
Что делать, когда пришла тревога
Мониторинг сокращает время обнаружения, но не время исправления. Чтобы реакция была быстрой, нужен заранее продуманный порядок действий. Он не обязан быть сложным, но должен быть записан.
Сначала ответственный подтверждает получение тревоги, чтобы остальные знали, что проблемой занимаются. Затем проверяет, реальна ли проблема: открывает сайт с телефона через мобильный интернет, смотрит статус в нескольких точках мониторинга. Дальше — быстрая диагностика: доступен ли сервер, что в логах ошибок, не было ли недавних изменений или обновлений, не закончилось ли место на диске, работает ли база данных.
Если причина в недавнем изменении — откат к предыдущей версии. Если в инфраструктуре — обращение к хостинг-провайдеру и переключение на резервные мощности, если они есть. Если сбой затягивается, стоит приостановить рекламные кампании, чтобы не тратить бюджет впустую, и разместить на сайте страницу технических работ с контактами. Подробный план на случай серьёзной аварии мы разбираем в статье «Восстановление сайта после сбоя».
После устранения обязательно короткий разбор: что произошло, почему, как быстро обнаружили и починили, что сделать, чтобы не повторилось. Именно такие разборы со временем делают сайт стабильнее.
Типичные причины ночных падений
Разбирая инциденты на проектах, мы видим одни и те же причины снова и снова. Закончилось место на диске из-за разросшихся логов или резервных копий, которые никто не удалял. Задание обмена с 1С зависло и заблокировало таблицы базы данных. Истёк сертификат, который продлевался вручную. Хостинг-провайдер провёл плановые работы без предупреждения. Поисковый бот или парсер конкурента начал массово обходить фильтры каталога. Почти все эти ситуации мониторинг инфраструктуры видит заранее, если правильно настроены пороги предупреждений.
Отчёты о доступности: что из них извлечь
Данные мониторинга полезны не только в моменты сбоев. Месячный отчёт о доступности и времени ответа показывает тенденции: медленный рост времени загрузки по мере роста каталога, регулярные пики нагрузки в определённые часы, повторяющиеся короткие сбои по ночам, связанные с резервным копированием или обменом с 1С.
Эти данные помогают принимать решения: когда пора переходить на более мощный тариф хостинга, стоит ли подключать кеширование и CDN, насколько хостинг-провайдер выполняет свои обещания. Если провайдер гарантирует 99,9% доступности, а мониторинг показывает 99,5%, это повод для разговора — или для переезда.
Если сайт обслуживает подрядчик, отчёт о доступности — один из самых честных показателей качества его работы. Мы включаем такие отчёты в ежемесячную отчётность по технической поддержке, чтобы клиент видел не только список выполненных задач, но и фактическую стабильность сайта.
Коротко
Мониторинг доступности нужен, чтобы узнавать о сбоях за минуты, а не от клиентов через несколько часов. Проверять стоит не только главную страницу, но и ключевые сценарии — каталог, корзину, формы, — а также инфраструктуру: сертификат, домен, диск, обмен с учётными системами. Проверки из нескольких точек и подтверждение сбоя повторными попытками избавляют от ложных тревог, а продуманные каналы уведомлений и эскалация гарантируют, что сигнал увидят. И наконец, у каждой тревоги должен быть понятный план действий, а у каждого сбоя — короткий разбор.
Нужен сайт или интернет-магазин?
Обсудим задачу, подскажем подходящую платформу и оценим сроки и бюджет — бесплатно и без обязательств.
Обсудить проект
