Мониторинг доступности сайта: как настроить uptime-контроль, уведомления и SLA

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

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

Короткий ответ

Для обычного бизнес-сайта проверяйте главную и как минимум одну критическую страницу каждые одну-пять минут из нескольких локаций. Успех должен означать ожидаемый HTTP-код, приемлемое время ответа, наличие стабильного контрольного текста и действующий TLS-сертификат.

После двух-трёх последовательных ошибок система должна уведомить владельца минимум по двум независимым каналам. Для интернет-магазина отдельно тестируют каталог, корзину и безопасное оформление без реального списания. У каждого сигнала должны быть ответственный, инструкция и целевое время реакции.

Что такое uptime и почему 100% почти ничего не объясняет

Uptime — доля времени, в течение которого ресурс отвечает установленным условиям доступности:

uptime = успешное время / всё измеряемое время × 100%.

Результат зависит от определения успеха. Если монитор принимает любой HTTP-ответ, страница технических работ с кодом 200 попадёт в зелёную статистику. Одна географическая точка не заметит часть региональных проблем DNS или CDN. Интервал в 30 минут может пропустить короткие, но регулярные сбои.

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

Пять уровней мониторинга

1. DNS и сетевой маршрут

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

После изменений проверьте записи A, AAAA, CNAME, MX и TXT и оставьте несколько региональных проверок до завершения распространения.

2. HTTP-статус и время ответа

Базовый монитор отправляет GET или HEAD на конкретный URL. Для обычной страницы ожидается 200, для штатного постоянного перенаправления — 301 или 308. Коды 500, 502, 503 и 504 показывают серверный сбой, но не каждая сломанная страница возвращает 5xx.

Контролируйте задержку. Сайт может формально работать, но отвечать 15 секунд, из-за чего посетители уходят, а платные переходы тратятся впустую. Причины производительности разбираются отдельно в гайде про TTFB, Core Web Vitals и проверку скорости.

3. Проверка содержимого

Ищите в ответе стабильный маркер: название компании, заголовок тестового товара или техническую строку, которая появляется только после успешной загрузки данных. Это выявляет мягкие сбои, когда сервер отвечает 200, но шаблон пуст, база недоступна или вместо сайта открывается парковочная страница.

Не используйте текст, который редактор может изменить без предупреждения. Лучше добавить стабильный HTML-маркер или отдельный health endpoint без секретной информации.

4. TLS-сертификат и срок домена

Проверяйте дни до окончания сертификата, соответствие имени и полноту цепочки. Автопродление иногда ломается после изменения DNS, прав доступа или reverse proxy. Подробный порядок есть в инструкции про SSL-сертификат и ошибки HTTPS.

Продление домена контролируйте отдельно. Действующий сертификат не спасёт после завершения регистрации или ошибки NS. Для общей диагностики используйте чек-лист домена, хостинга и сервера.

5. Синтетические транзакции

Для магазина или веб-сервиса мало открыть главную. Сценарий должен найти тестовый товар, добавить его в корзину, открыть checkout и проверить ответ API. На сайте услуг можно открыть форму и отправить помеченную тестовую заявку в отдельный технический канал.

Такая проверка не должна создавать настоящие заказы, списывать деньги или загрязнять CRM. Используйте тестовый товар, отдельный адрес, служебную метку и автоматическое удаление результатов.

Что именно контролировать

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

Интервал и количество локаций

Проверка каждую минуту быстрее обнаруживает сбой, но создаёт больше запросов и чувствительнее к коротким сетевым проблемам. Небольшому сайту без крупной рекламной кампании часто достаточно пяти минут. Для checkout, API и дорогого рекламного лендинга оправдана одна минута.

Один узел не отличит падение сайта от собственной проблемы. Практическая последовательность:

1. повторить запрос после первой ошибки;
2. подтвердить из второго региона;
3. уведомить после двух-трёх ошибок подряд;
4. снизить порог для критического endpoint;
5. отдельно сообщить о восстановлении.

Так снижается шум без опасной задержки.

Как убрать ложные тревоги

Худший мониторинг — тот, сообщения которого перестают читать. Ложные срабатывания появляются из-за коротких сетевых разрывов, блокировки IP проверяющего сервиса, слишком жёсткого лимита времени, плановых работ или нестабильного браузерного сценария.

Для каждой проверки задайте:

• ожидаемый статус и контрольный текст;
• допустимое время ответа;
• число ошибок до тревоги;
• подтверждение из другого региона;
• окна плановых работ;
• уровень важности;
• условие восстановления;
• срок эскалации.

Не добавляйте IP монитора в безусловный белый список, если он обходит реальную защиту. Маршрут должен быть близок к клиентскому, а тестовые запросы можно пометить в User-Agent и логах.

Уведомления и эскалация

Email подходит для отчёта, но слаб как единственный критический канал. Сбой checkout дублируют в мессенджер, push или телефон. При этом один медленный запрос не должен будить всю команду.

В сообщении нужны URL, время начала, локации, статус, задержка, последнее развёртывание и ссылка на инструкцию. Регулярная поддержка сайта полезна, когда вместе с сигналом есть специалист с доступами и ответственностью за восстановление.

SLI, SLO и SLA

SLI — измеряемый показатель, например доля успешных запросов checkout. SLO — внутренняя цель команды, например 99,9% доступности за месяц. SLA — соглашение с клиентом или провайдером, где закреплены уровень сервиса, методика, исключения и последствия нарушения.

SLA нельзя сводить к красивому проценту. В нём определяют объект, часовой пояс, период расчёта, плановые работы, внешние зависимости, момент начала инцидента, срок реакции и компенсацию.

Сколько простоя скрывают «девятки»

Это математический расчёт до исключений договора. Если плановые работы, внешние системы или атаки не входят в SLA, фактический опыт клиентов может быть хуже отчёта.

Что делать после уведомления

Мониторинг без плана реакции только быстрее сообщает о проблеме. Подготовьте короткий runbook:

1. Подтвердить сбой из независимой сети и другого региона.
2. Определить уровень: DNS, CDN, TLS, сервер, CMS, база, внешнее API или функция.
3. Проверить последнее развёртывание, обновление, импорт и настройку.
4. Безопасно откатить изменение или переключить трафик.
5. Сохранить симптомы и логи до перезапуска компонентов.
6. Сообщить бизнесу о влиянии и времени следующего обновления статуса.
7. После восстановления проверить формы, оплату, почту, CRM и аналитику.
8. Записать причину, продолжительность, влияние и профилактическое действие.

При подозрении на взлом используйте чек-лист проверки сайта на вирусы. Если нужен откат, используйте проверенный процесс резервного копирования и восстановления, а не случайный архив.

Настройка за один рабочий день

Шаг 1. Определите критические пути

Запишите, что приносит деньги: лендинг, форма, телефон, каталог, корзина, оплата, личный кабинет или API. Оцените последствия 15 минут, часа и дня недоступности.

Шаг 2. Создайте базовые проверки

Добавьте главную, одну коммерческую страницу и критический endpoint. Контролируйте статус, контент, TLS и задержку из двух-трёх регионов.

Шаг 3. Настройте пороги

Для обычной страницы начните с пяти минут и трёх ошибок; для checkout — с одной минуты и двух ошибок. Лимиты скорости задавайте по стабильной базовой линии сайта, а не по случайной идеальной цифре.

Шаг 4. Настройте маршруты уведомлений

Назначьте основного и резервного владельца. Проверьте email, мессенджер и телефон тестовой тревогой. Храните доступы в защищённом хранилище, а не в сообщении.

Шаг 5. Проведите учебный инцидент

Измените ожидаемый маркер в тестовой проверке или используйте безопасный несуществующий URL. Измерьте время обнаружения, подтверждения и диагностики, затем верните правильное условие.

Типичные ошибки

• контролируется только главная;
• любой HTTP-статус считается успехом;
• содержимое не проверяется;
• используется один регион;
• сигнал получает один человек только по email;
• нет уведомления о восстановлении;
• плановые работы не отмечаются;
• монитор расположен на том же сервере;
• каналы уведомлений не тестируются;
• uptime публикуется без методики;
• после инцидента не устраняется системная причина.

Чек-лист владельца

• проверяются главная и конверсионная страница;
• успех определяется статусом, задержкой и содержимым;
• есть минимум две независимые локации;
• TLS и домен контролируются заранее;
• магазин имеет безопасный тест корзины;
• повторы не скрывают устойчивый сбой;
• критические тревоги идут двумя каналами;
• назначены основной и резервный ответственные;
• инструкция реакции актуальна;
• восстановление из копии проверено;
• uptime, задержка и причины анализируются ежемесячно;
• каждый инцидент создаёт профилактическое действие.

Вывод

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

Начните с трёх проверок и тестовой тревоги. Затем добавьте синтетические транзакции, SLO и ежемесячный разбор. Если нужно спроектировать мониторинг, убрать шум или определить SLA под риск бизнеса, свяжитесь с BB STUDIO — подготовим практическую схему.