Uptime: как мониторинг доступности сайта спасает позиции и деньги

Что такое uptime и почему доступность сайта влияет на SEO

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

Как поисковые системы реагируют на даунтайм

Алгоритмы Яндекса и Google не любят показывать пользователям неработающие ресурсы. Когда робот получает ошибку 5xx вместо контента, он фиксирует сбой. Единичный случай не критичен, но при регулярной недоступности поисковик сомневается в надёжности ресурса. Следствием становится понижение частоты обхода, что затягивает индексацию новых страниц, а затем снижение позиций по семантическому ядру. На практике мы видели падение трафика на 30–50% после нескольких часов простоя в пиковые дни, когда сайт «лежал» в момент апдейта алгоритмов.

Поведенческий фактор работает как усилитель негатива. Пользователь, перешедший из выдачи на недоступный сайт, мгновенно возвращается обратно. Такой «отказ» поисковик фиксирует как сигнал о нерелевантности. В итоге вы получаете двойной удар: и робот недоволен, и поведенческие метрики ухудшаются. Даже час простоя в рабочее время может стоить десятков заявок, а для интернет-магазина это прямая потеря выручки. Мониторинг доступности это не техническая опция, а базовая потребность проекта, который дорожит позициями.

Как работает мониторинг доступности: протоколы и частота проверок

Мониторинг доступности строится на регулярных проверках с распределённых точек. Самый простой вариант это HTTP-запросы: сервис отправляет GET-запрос на URL и ждёт ответ с кодом 200. Если сервер отвечает 500-м или 502-м, значит, что-то сломалось на стороне приложения или веб-сервера. Есть и более «низкоуровневый» TCP-мониторинг, который проверяет лишь факт установки соединения с портом 80 или 443. Он быстрее детектит падение железа или сети, но не видит проблем на уровне приложения, которые часто проявляются в виде ошибка 503 Service Unavailable.

Частота проверок напрямую влияет на скорость реакции. Для коммерческого сайта интервал в 1 минуту это стандарт де-факто, иначе вы не успеете среагировать до того, как поисковый робот зафиксирует простой. Проверка раз в 5 минут оправдана только для некритичных визиток. Но есть подводный камень: чем чаще проверки, тем выше вероятность ложных срабатываний. Апстрим-провайдер одного из наших клиентов периодически терял пакеты, и при проверке каждые 60 секунд система стабильно показывала недоступность, хотя сайт работал. Поэтому серьёзные сервисы используют порог в 2–3 неудачные попытки подряд, прежде чем объявить аварию.

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

• Для интернет-магазинов и сайтов с оплатой — HTTP-проверка каждые 60 секунд с порогом в 3 попытки.
• Для корпоративных порталов достаточно TCP-мониторинга порта 443 с интервалом 5 минут.
• Для сайтов на дешёвом шаared-хостинге интервал меньше 3 минут часто даёт ложные срабатывания.
• Проверка содержимого страницы по ключевой фразе оправдана только при интервале от 5 минут.

Для API и интеграций лучше использовать HEAD-запросы, они легче и не тянут полный HTML. Это особенно актуально, когда нагрузка на эндпоинты и так высокая, а каждый лишний GET с полным телом ответа добавляет работы бэкенду. HEAD-запрос возвращает только заголовки, чего достаточно для проверки статуса и доступности.

Если только настраиваете мониторинг, начните с HTTP-проверки раз в 5 минут и смотрите статистику пару недель. Когда поймёте, как часто бывают ложные срабатывания, сокращайте интервал до минуты и добавляйте проверку контента.

Почему важна география точек проверки

Одной точки проверки недостаточно. Если сервер лежит в московском ЦОДе, а мониторинг идёт оттуда же, вы увидите идеальный uptime. Но пользователь из Владивостока или Алматы может получать таймауты из-за проблем на транзитных каналах, которые локальный дата-центр не замечает. Яндекс учитывает доступность ресурса для разных регионов, и если сайт стабильно недоступен в каком-то округе, позиции по региональным запросам просядут. Поэтому мы настраиваем проверки минимум из трёх-пяти точек: европейская часть РФ, Сибирь, Дальний Восток и пара зарубежных локаций. Так вы получаете объективную картину доступности по всей географии трафика.

HTTP-мониторинг даёт больше данных, чем простая проверка TCP-коннекта. Он анализирует содержимое ответа, например, наличие нужного заголовка или ключевой фразы на странице. Это помогает отличить ситуацию, когда сервер отвечает, но отдаёт заглушку, от реально работающего сайта. Правда, за это приходится платить: частые проверки с интервалом 60 секунд создают дополнительную нагрузку на сервер и могут давать ложные срабатывания при коротких сетевых сбоях. Если сервер отвечает 503-м кодом, это часто указывает на перегрузку бэкенда или плановые работы. Распределённые точки проверки помогают отличить локальный сбой сети от глобального падения сервера, что экономит время на диагностику. Для сайтов с аудиторией в конкретном городе достаточно точек в этом регионе, иначе вы будете ловить несуществующие проблемы.

Инструменты для мониторинга: от бесплатных до корпоративных

Бесплатные решения: ограничения и нюансы

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

Отдельно стоят инструменты поисковиков. Яндекс.Вебмастер и Google Search Console показывают доступность по факту обхода роботом. Это скорее диагностика после события, чем превентивный мониторинг. Зато они бесплатны и дают информацию о том, как поисковик видит сайт: ошибки соединения, таймауты, проблемы с DNS. Полезно настроить уведомления в обоих сервисах, чтобы ловить проблемы, которые видят краулеры. Если после простоя сайт вернулся в строй, важно ускорить индексацию сайта, иначе поисковик будет показывать устаревший сниппет.

Платные сервисы вроде Pingdom и Site24x7 закрывают то, за что не берутся бесплатные аналоги: проверки из десятков точек, мониторинг транзакций и детальную аналитику причин сбоя. За $10–30 в месяц вы получаете полную картину: где произошёл сбой, на каком этапе загрузки, и кто виноват, хостер или ваш код. Site24x7 хорош для крупных проектов с распределённой инфраструктурой, Pingdom удобен интеграцией со Slack и Telegram. Таблица ниже поможет сравнить базовые параметры.

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

Начинать стоит с определения критичности, а не с выбора инструмента. Если алерт приходит на каждый чих, через неделю вы перестанете на него реагировать. Мы делим инциденты на три уровня: потеря доступности на 30 секунд, на 5 минут, полное падение на 15 минут и более. Для каждого уровня свой порог и канал. Мелкие флуктуации из-за перезагрузки балансировщика или деплоя отправляются в Telegram-канал для дежурного инженера. Если сайт лежит дольше пяти минут, подключается email и Slack, чтобы в курс были посвящены менеджеры и руководство.

Выбираем каналы уведомлений

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

Эскалация должна работать как лестница. Первая ступень это автоматическая проверка, которая подтверждает сбой и исключает ложную тревогу, например, повторный запрос через 60 секунд с другого региона. Если сбой подтверждён, уведомление уходит дежурному инженеру. Если он не отреагировал за 10 минут, подключается тимлид, а ещё через полчаса технический директор и звонок по телефону. На каждом этапе должны быть чётко прописаны ответственные и временные интервалы, иначе эскалация превратится в перекладывание ответственности. Правильно настроенные алерты экономят нервы и деньги, ведь час простоя интернет-магазина это прямые убытки. Если сайт часто недоступен, это влияет на конверсию, и лучше заранее разобраться, почему сайт не приносит заявки, чем потом бороться с последствиями.

Чтобы не тонуть в уведомлениях, придерживайтесь простых правил:

• Ложные тревоги гасите на уровне проверки, добавляя повторный запрос и проверку из двух точек, это снижает шум на 40%.
• Для каждого алерта задавайте таймаут реакции: 10 минут для критичного инцидента, 2 часа для предупреждения.
• Раз в месяц пересматривайте пороги срабатывания, рост трафика и изменения в инфраструктуре меняют картину.
• Подключайте интеграцию с PagerDuty, если команда больше пяти человек и нужна ротация дежурств.
• Используйте отдельный Telegram-бот для мониторинга, чтобы уведомления не терялись в общих чатах.

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

Что делать, если сайт недоступен: чек-лист реакции

Первые 10 минут после алерта

Сработал алерт — отключаем панику и проверяем доступность с нескольких независимых точек. Откройте сайт с телефона через мобильную сеть, используйте downdetector или 2ip, зайдите через VPN с другим регионом. Если сайт открывается хотя бы откуда-то, проблема локальная: ваша сеть, DNS на провайдере или блокировка по гео. Если не открывается ниоткуда, смотрим дальше. Параллельно проверяем SSL-сертификат, часто причина именно в нём: истёкший или неправильно настроенный сертификат даёт ошибку соединения, хотя сервер жив.

Дальше смотрим в логи. Если есть доступ к серверу, проверяем ошибки веб-сервера (nginx/apache), нагрузку на CPU и память, свежие записи в error.log. Типичная картина: сайт лежит, но процессы живы, это указывает на проблему кода или базы данных. Если сервер не отвечает на SSH, а пинг проходит, дело в хостинге или DDoS. Ошибки 502/504 говорят о проблемах бэкенда, 429 о rate limiting, а полная недоступность по TCP чаще всего означает сетевые проблемы или атаку.

Подключаем хостинг-провайдера. Звоните или пишите в поддержку сразу, не ждите автоматических ответов, у нормальных хостеров есть круглосуточный телефон. Уточните, не было ли DDoS-атак на подсеть, не проводились ли работы, не превышен ли лимит по inode или трафику. Если проблема на вашей стороне, фиксируйте время начала простоя. Мы в Cinar обычно готовим для клиентов регламент: кто отвечает за мониторинг, кто связывается с хостингом, кто проверяет код после восстановления. Такой порядок превращает хаос в понятный процесс, и среднее время восстановления падает с часов до 15–20 минут. Главное, чтобы после каждого инцидента вы фиксировали причину и обновляли чек-лист, иначе следующий сбой застанет врасплох.

Часто задаваемые вопросы

Константин Крючков

Senior SEO-специалист

Подписаться на ТГ