Мониторинг доступности: сколько заявок утекает, пока сайт лежит ночью

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

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

Сколько стоит ночное падение

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

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

И вторая поправка, о которой забывают: человек, который не смог открыть сайт, редко возвращается позже. Он возвращается в выдачу и открывает следующий сайт. Заявка не откладывается, она уходит. Подробный разбор этой арифметики с распределением по часам у меня есть отдельно — сколько заявок вы теряете ночью, пока сайт лежит.

Что делают с позициями регулярные падения

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

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

Отдельно про код ответа. Когда сайт временно недоступен, правильный ответ сервера — тот, который означает «сервис временно недоступен, зайдите позже». Тогда робот понимает, что страница жива, просто сейчас не отдаётся. Плохо, когда вместо этого отдаётся «страница не найдена» или, что хуже, пустая страница с кодом «всё в порядке»: в первом случае робот решает, что страницы больше нет, во втором — индексирует пустышку. Подробнее — в разборе ошибки 503 и того, что она делает с позициями.

Ещё сценарий, который с аптаймом не связывают: сайт отвечает, но по двадцать-тридцать секунд. Для мониторинга он «работает», для человека — нет. Поэтому в проверку включают и время ответа.

Какие бывают проверки

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

Тип проверки	Что проверяет	Что пропустит	Кому хватит
Пинг сервера	Отвечает ли машина на сетевой запрос	Почти всё: сервер жив, а сайт не открывается — частая ситуация	Никому в одиночку
Код ответа страницы	Открывается ли адрес и с каким кодом	Белый экран, сломанную вёрстку, пустую страницу с правильным кодом	Минимум для любого сайта
Содержимое страницы	Есть ли на странице заданное слово — например, название компании или текст кнопки	Неработающую форму	Основной вариант для бизнеса
Срок сертификата и домена	Когда истекает защищённое соединение и оплата домена	Технические сбои	Обязательно всем
Время ответа	Не деградировал ли сайт до состояния «формально жив»	—	Полезно всем
Сценарий с формой	Проходит ли путь до отправки заявки	—	Магазинам и тем, кто живёт с сайта

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

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

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

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

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

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

Оповещения: куда и кому

Письмо на почту — плохой канал для аварии. Ночью почту никто не читает, а утром письмо теряется среди рассылок. Работают: сообщение в мессенджер, звонок или push от приложения. Идеально — два канала сразу, потому что один может не сработать.

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

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

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

Что требовать от хостинга

Обещание «аптайм 99,9 %» звучит солидно, пока не перевести его в часы. Важно не только число, но и то, что за него отвечают.

Обещанный аптайм	Допустимый простой в месяц	Для кого приемлемо
99 %	около 7 часов	Сайт-визитка без заявок
99,5 %	около 3,5 часов	Минимум для сайта услуг
99,9 %	около 45 минут	Нормальная планка для бизнеса
99,95 % и выше	менее 25 минут	Магазины, сервисы с оплатой

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

Критерий простой: если на вопрос «что будет, если сайт упадёт на четыре часа» вам отвечают общими словами, считайте, что обязательств нет. И не полагайтесь только на мониторинг самого хостинга: он проверяет своё оборудование изнутри и не покажет проблему, которая видна извне.

Сравнение способов

Способ	Что увидит	Чего не увидит	Чего стоит
Внешний сервис мониторинга	Падения с точностью до минут, историю, сроки сертификата	Почему именно упало	Бесплатно на базовом уровне
Мониторинг хостинга	Сбои своего оборудования	Проблемы сети и сбои, видимые только снаружи	Входит в тариф
Панель веб-мастера	Ошибки, которые встретил робот	Оперативность: узнаете через день-два	Бесплатно
Статистика посещений	Провал трафика в определённые часы	Причину и точное время	Бесплатно
Проверять руками	Только то, что происходит в момент проверки	Всё, что случилось пока вы спали	Ваше время

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

Порядок настройки на вечер

1. Выберите сервис внешнего контроля, который умеет проверять содержимое страницы, а не только код ответа.
2. Добавьте три адреса: главную, основную страницу услуги, контакты.
3. Для главной задайте проверку на слово, которое точно есть в тексте и не изменится.
4. Поставьте интервал пять минут, для магазина — минуту.
5. Включите оповещение в мессенджер и вторым каналом на почту.
6. Настройте тревогу после двух-трёх неудачных проверок подряд, не после первой.
7. Включите оповещение о восстановлении работы.
8. Добавьте контроль срока действия сертификата и оплаты домена.
9. Выясните у хостинга, как оформить срочное обращение ночью, и запишите это туда, где найдёте в панике.
10. Через месяц откройте сводку и посмотрите, нет ли сбоев по расписанию.

Когда мониторинг не нужен и не поможет

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

Некому реагировать. Оповещение без исполнителя превращается в источник тревоги. Сначала договоритесь, кто и как чинит, потом настраивайте тревоги.

Падения — следствие, а не причина. Если сайт падает от любого всплеска посещений, дело в том, что он тяжёлый или тариф маленький. Мониторинг покажет симптом, а решается это ускорением сайта и переездом на подходящие ресурсы. И не пытайтесь закрыть проблему модными средствами: CDN ускоряет не всегда и от падений самого сервера не спасает.

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

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

Коротко

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

Частые вопросы

Сайт падает на 30–40 секунд несколько раз в день. Это страшно?

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

Как понять, падал ли сайт раньше, если мониторинга не было?

Посмотрите панель веб-мастера: там видно ошибки, которые встречал робот при обходе. Второй источник — статистика посещений по часам: провал в ноль на несколько часов при обычном фоне выглядит однозначно. Третий — попросить у хостинга данные о простоях и перезагрузках.