Плановые работы у CDN, DNS-провайдера или хостинга обычно выглядят безобидно: поставщик заранее предупреждает, что трафик может быть перенаправлен, а часть узлов временно уйдет на обслуживание. Для владельца сайта это все равно риск. В одном регионе сайт открывается как обычно, в другом начинает отвечать медленнее, а отдельные пользователи видят ошибку или таймаут.
Ниже — практический порядок проверки, который помогает быстро понять, затронут ли именно ваш сайт, где искать причину и когда пора подключать поддержку.
Почему плановые работы могут быть заметны посетителям
Даже если провайдер называет работы плановыми, технически в этот момент меняется маршрут пользователя до сайта. CDN может перевести трафик в соседний дата-центр, хостинг — обслуживать сетевое оборудование, DNS-провайдер — менять часть инфраструктуры. Чаще всего сайт продолжает работать, но появляются побочные эффекты:
- страница открывается дольше обычного;
- часть посетителей попадает на другой edge-узел CDN;
- запросы из одного города проходят, а из другого дают таймаут;
- SSL-рукопожатие или DNS-ответ занимают больше времени;
- админ видит рабочий сайт, а клиент уже пишет, что оформить заказ не получается.
Главная сложность в том, что проблема может быть не внутри сайта. Код, база данных и CMS работают, но путь до сайта для части аудитории стал нестабильным.
Что проверить сначала
Начните с простых действий, которые отделяют локальную проблему от внешней.
Откройте сайт не только со своего устройства
Проверьте главную страницу, важную посадочную страницу, корзину, форму заявки и страницу авторизации. Если сайт открывается только у вас, это еще не доказательство, что все в порядке. У вашего офиса, мобильного оператора и клиентов могут быть разные маршруты до CDN или хостинга.
Практический пример: владелец интернет-магазина открывает сайт из офиса и видит нормальную главную страницу. В это же время клиенты из другого региона получают долгую загрузку каталога. Для бизнеса это уже инцидент, даже если сервер не упал полностью.
Посмотрите статус-страницу провайдера
У CDN, облаков, DNS-сервисов и крупных хостингов обычно есть публичные статус-страницы. Ищите не только слово outage. Плановое окно обслуживания, rerouting, degraded performance, increased latency и maintenance тоже важны: они объясняют, почему сайт может работать неровно.
Если статус-страница показывает работы в конкретном дата-центре, не делайте вывод только по названию города. Трафик редко идет строго по географии пользователя. Маршрут зависит от провайдера доступа, пиринга, DNS-ответа и настроек CDN.
Сравните DNS, SSL и HTTP
Один и тот же симптом может иметь разные причины. Поэтому полезно проверять цепочку по шагам:
- DNS: домен вообще превращается в IP-адрес или возвращает ошибку.
- TCP: удается ли установить соединение с сервером.
- TLS: проходит ли HTTPS-рукопожатие и подходит ли сертификат.
- HTTP: какой статус возвращает сайт и есть ли корректный текст страницы.
Если DNS отвечает стабильно, а HTTP дает 502 или 504, вероятнее всего проблема ближе к CDN, прокси, балансировщику или origin-серверу. Если DNS периодически возвращает ошибку, нужно смотреть делегирование домена, DNSSEC, записи у провайдера и кэш резолверов.
Как отличить плановые работы от аварии сайта
Плановые работы обычно имеют признаки: есть объявление провайдера, известное окно времени, статус обновляется, а проблема затрагивает не все запросы. Авария сайта чаще выглядит иначе: ошибки повторяются постоянно, backend не отвечает, база данных недоступна, приложение возвращает 500 или сайт открывается только статической заглушкой.
Но граница не всегда очевидна. Во время обслуживания CDN может просто перенаправлять трафик, а ваш origin-сервер внезапно не выдерживает новую схему запросов. Или наоборот: провайдер работает нормально, но после ночного обновления сайта ломается форма заявки. Поэтому проверка должна смотреть не только на факт открытия главной страницы.
Практический чеклист на время окна обслуживания
Перед началом работ у провайдера подготовьте короткий список критичных URL. Для интернет-магазина это главная, категория, карточка товара, корзина и оформление заказа. Для сервиса — главная, вход, личный кабинет, страница оплаты и API endpoint, если он есть. Для корпоративного сайта — главная, контакты, форма заявки и ключевая посадочная страница.
Во время окна обслуживания проверьте:
- открывается ли сайт по HTTPS без предупреждений браузера;
- не меняется ли код ответа на 5xx, 403, 404 или бесконечный редирект;
- загружается ли важный текст на странице, а не только пустой шаблон;
- работает ли форма, корзина или авторизация;
- одинаково ли ведут себя страницы из разных сетей;
- нет ли резкого роста времени ответа.
После окончания работ не ограничивайтесь одним обновлением главной страницы. Проверьте те же URL повторно. Иногда последствия проявляются позже: кэш CDN очищен, DNS еще не везде обновился, часть пользователей остается на старом маршруте.
Когда нужен автоматический мониторинг
Ручная проверка полезна в моменте, но она плохо подходит для длительных окон обслуживания. Человек проверяет сайт выборочно, а сбой может длиться несколько минут и попасть ровно между проверками. Кроме того, владелец часто узнает о проблеме от клиентов, а не из собственной диагностики.
Автоматический мониторинг решает эту задачу спокойнее: он регулярно проверяет выбранные страницы, фиксирует код ответа и помогает заметить, что сайт перестал открываться или начал отвечать нестабильно. Чтобы не проверять сайт вручную, можно настроить мониторинг в Web-Puls и добавить в проверку не только главную страницу, но и важные URL для бизнеса. Для разовой диагностики пригодится и ручная проверка сайта.
Что делать, если сайт недоступен только у части пользователей
Соберите факты до обращения к провайдеру или разработчику. Нужны URL, время проблемы, регион или сеть пользователя, код ошибки, скриншот браузера и результат проверки из внешней сети. Это экономит время: вместо общего «сайт не работает» вы передаете конкретную картину.
Если ошибка связана с DNS, SSL, хостингом или сервером, не стоит хаотично менять записи и настройки. Так можно сделать хуже: сбить кэш, добавить конфликтующие DNS-записи или нарушить выпуск сертификата. При сложном сбое можно отправить заявку на профессиональную поддержку. Если удобнее сначала обсудить ситуацию, используйте контактную информацию.
Какие страницы добавить в мониторинг
Минимальный набор зависит от типа проекта, но логика одна: проверять нужно то, что влияет на деньги, заявки и доверие.
Интернет-магазин
Добавьте главную страницу, категорию, карточку товара, корзину и оформление заказа. Если сайт внешне доступен, но корзина падает, потери будут такими же реальными, как при полном падении.
Сайт услуг
Проверьте главную, страницу услуги, контакты и страницу с формой заявки. Если форма отправляет пользователя на ошибку или показывает пустой экран, это тоже инцидент.
Онлайн-сервис
Следите за страницей входа, личным кабинетом, оплатой и публичным API, если от него зависят клиенты. Для SaaS-проекта частичная недоступность часто опаснее полной: часть пользователей продолжает работать, а часть не понимает, почему сервис нестабилен.
Вывод
Плановые работы у CDN, DNS-провайдера или хостинга не всегда означают аварию, но их нельзя игнорировать. Сайт может оставаться доступным для владельца и одновременно плохо открываться у части клиентов. Правильный подход — заранее знать критичные страницы, проверять DNS, SSL и HTTP отдельно, смотреть статус провайдера и фиксировать факты.
Web-Puls помогает регулярно проверять доступность сайта и быстрее узнавать, если он перестал открываться. А если проблема требует технического разбора, лучше передать специалистам конкретные симптомы: URL, время, ошибку и результаты внешней проверки.