Мониторинг и оповещения: доступность, сертификаты, формы и аномалии сканеров

Сначала вывод: Типичный сбой сайта — не «сломался», а «сломался и несколько дней никто не знал». Цель мониторинга — сократить время обнаружения с недель до минут: пять категорий мониторинга — доступность каждые 1–5 минут, предупреждение об истечении сертификата за 30 дней, самопроверка форм каждые 15–60 минут, недельные колебания числа страниц в индексе, ежедневная сверка резервных копий — плюс трёхуровневые оповещения P0/P1/P2. Всё настраивается один раз при сдаче нового сайта.

I. Время обнаружения определяет масштаб потерь

Сначала разграничим:Ежемесячное обслуживание о том, что делать ежемесячно,Учения по восстановлению из резервных копий о том, восстанавливаются ли резервные копии,Диагностика индексации о том, как разбираться с аномалиями индексации. В этой статье — только один предварительный вопрос: откуда берутся данные, по которым эти действия обнаруживаются и запускаются. Без мониторинга обслуживание идёт вслепую; с мониторингом оповещение указывает на конкретную неисправность.

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

Сценарий сбоя	Типичное время обнаружения без мониторинга	Время обнаружения с мониторингом	Прямые последствия
Истёк сертификат	1–7 дней	Предупреждение за 30 дней до истечения	Сайт полностью недоступен, клиенты уходят
Формы молча не работают	3–14 дней	Оповещение после 2 подряд неудачных самопроверок	Все заявки теряются незаметно
Сайт взломали	Несколько недель	Оповещение об аномалиях индексации и контента	Выдача по брендовым запросам загрязнена
Резкое падение числа страниц в индексе	1–2 месяца	Оповещение при превышении порога недельного изменения	Трафик падает, никто не реагирует
Хостинг недоступен	От нескольких часов до нескольких дней	Оповещение после 2 подряд неудачных проверок доступности	Заявки не поступают

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

II. Сводная таблица: пять категорий мониторинга и пороги

Пять категорий мониторинга покрывают все ключевые пути корпоративного сайта B2B — пороги можно брать как есть.

Категория мониторинга	Объект мониторинга	Рекомендуемая частота и пороги	Условие оповещения
Доступность	HTTP-статус и время отклика	Проверка каждые 1–5 минут, минимум 2 внешних узла	2 подряд неудачи; время отклика 3 раза подряд превышает 5 секунд
Сертификаты и домены	Срок действия SSL, срок регистрации домена, записи DNS	Ежедневная проверка, предупреждения за 30/14/7 дней до истечения	До истечения менее 30 дней; изменение записей DNS
Формы и почта	Самопроверка цепочки доставки, возвраты писем	Отправка самопроверки каждые 15–60 минут	2 подряд самопроверки не дошли; доля возвратов превышает 2%
Сканеры и индексация	Статус сканирования ключевых URL, число проиндексированных страниц	Раз в неделю проверять индексацию и ошибки sitemap	Число проиндексированных страниц упало более чем на 20% за неделю; в sitemap появились новые ошибки
Резервное копирование и обновления	Результаты задач резервного копирования, проверка после обновления	Резервные копии проверять ежедневно; в течение часа после обновления компонентов проверять белый экран	Сбой резервного копирования; после обновления главная или страница формы возвращает ошибку

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

III. Детали настройки доступности и доменов с сертификатами

В мониторинге доступности проще всего ошибиться с расположением проб и условиями срабатывания.

Параметр	Рекомендуемая практика	Частая ошибка
Узлы проверки	Минимум 2 внешних узла в разных регионах (например, один за рубежом, один в России)	Проба стоит на том же сервере, что и сайт: при падении сервера проба замолкает вместе с ним
Пути проверки	Главная страница плюс страница формы и страница ключевого продукта	Проверяется только главная: кэш CDN скрывает сбои внутренних страниц
Условие	Оповещение после 2 сбоев подряд, порог времени отклика — 5 секунд	Оповещение после первого же сбоя: сетевые колебания тревожат каждый день
Интервал проверки	1–5 минут; для важных сайтов — 1 минута	Раз в 30 минут: о падении узнаёте только через час

Расписание сертификатов и доменов — самый простой и самый предсказуемо выгодный пункт во всём материале, потому что это «предупредить заранее», а не «сообщить постфактум».

Что проверить	Момент предупреждения	Действие
Срок действия SSL-сертификата	Оповещение за 30, 14 и 7 дней до истечения	Проверить, что задача автообновления работает (сертификаты Let’s Encrypt продлеваются каждые 90 дней)
Срок действия домена	Напоминание за 60 и 30 дней до истечения	Убедиться, что аккаунт регистратора и способ оплаты действуют, включить автопродление
Изменение DNS-записей	Оповещение при любом изменении	Внеплановые изменения A- и MX-записей проверять немедленно

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

IV. Формы, почта и индексация краулерами

Логика мониторинга форм — не «открывается ли страница», а «дошло ли то, что отправили». Когда страница работает, а цепочка доставки оборвана, это самый незаметный и самый дорогой сбой B2B-сайта: клиент думает, что отправил заявку, а вы не получили ни одной.

Способ мониторинга	Как сделать	Критерий и оповещение
Тестовая отправка	Скриптом или сторонним инструментом отправлять тестовую заявку раз в 15–60 минут	Тестовая заявка получена и все поля заполнены — успех; после 2 сбоев подряд оповещение P0
Проверка на стороне получателя	Тестовому ящику задать единый формат имени (например, test+метка_времени@домен) для удобной фильтрации и сверки	Не пришло вовремя — значит, разрыв на почтовом уровне
Мониторинг отказов	Следить за уведомлениями о недоставке на ящике отправителя	Доля отказов выше 2% — проверить настройки SPF, DKIM, DMARC
Битые ссылки и повторная проверка доставки	Раз в квартал вручную пройти реальный сценарий отправки формы	Сверить с результатами автопроверки, чтобы сам скрипт проверки не перестал работать

Для мониторинга сканирования и индексации не нужна высокая частота — достаточно раза в неделю. Смотрим три показателя: коды ответа при сканировании ключевых URL (главная, страницы основных продуктов, страница заявки), число ошибок сканирования после отправки sitemap, недельная динамика числа проиндексированных страниц. Число проиндексированных страниц колеблется естественным образом: если недельный спад в пределах 20%, волноваться не стоит, сигнал тревоги уместен только при падении больше 20% или снижении две недели подряд. Подробный порядок действий при аномальных кодах сканирования описан в Диагностика индексации отдельной статье — мониторинг лишь вовремя подаёт сигнал «пора проверить». Результаты задач резервного копирования достаточно сверять раз в день на успех или неудачу, а способность к восстановлению обеспечивается учениями, а не мониторингом.

Пять. Уровни оповещений, каналы и борьба с ложными срабатываниями

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

Уровень	Критерий оценки	Каналы и требования к реакции
P0	Сайт недоступен более 5 минут; форма дважды подряд не отправилась; обнаружены признаки взлома	Звонок или сообщение бота дежурному напрямую, реакция в течение 30 минут
P1	До истечения сертификата меньше 14 дней; число проиндексированных страниц упало за неделю более чем на 20%; время отклика стабильно превышает 5 секунд	Уведомление по почте и в чате, обработка в течение 24 часов
P2	Напоминание за 30 дней до истечения сертификата; разовый сбой резервного копирования с восстановлением на следующий день; показатели медленного тренда	В недельный отчёт, разбираем на планёрке

В борьбе с ложными срабатываниями есть жёсткое правило: если пункт мониторинга часто ложно срабатывает три месяца подряд, его либо настраивают по порогу, либо отключают — третьего варианта нет. У каждого правила оповещения должен быть ответственный: правило, на которое никто не откликается, равносильно не настроенному. Частые источники ложных срабатываний и что с ними делать: разовый сбой из-за сетевых колебаний (решается проверкой по двум срабатываниям подряд), сбой внутренних страниц не виден из-за кэша CDN (добавляем точку проверки на странице формы), почтовый провайдер помечает тестовые письма (фиксированный тестовый ящик добавляем в белый список).

Шесть. Дежурство и чек-лист запуска нового сайта

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

Уровень реакции	Условие	Действие	Целевой срок
Первый уровень	Единичный сбой, быстро устраняется	Перезапустить сервис, откатить последнее обновление	В течение 15 минут
Второй уровень	Первый уровень не помог или зона сбоя расширяется	Переключиться на статическую кэш-страницу, сохранить доступность для внешних пользователей	В течение 1 часа
Третий уровень	Быстро починить не удаётся	Прекратить догадки, объявить о проблеме и передать внешней поддержке	В течение 4 часов

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

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

Обязательный набор при сдаче	Содержание
Пять проверок	Доступность, срок действия сертификата и домена, доставка форм, недельный отчёт по индексации, результаты бэкапов — пороги из второго раздела
Три получателя	Дежурный P0, технический руководитель P1, контактное лицо P2 — у каждого настроен свой канал, и один раз проведена реальная учебная тревога

Семь. Как использовать данные алертов для улучшений и когда не стоит строить мониторинг своими силами

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

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

FAQ: частые вопросы

Нужен ли мониторинг небольшому сайту?

Нужен, но достаточно минимального набора из трёх проверок: проверка доступности (каждые 5 минут, алерт после 2 сбоев подряд), предупреждение об истечении сертификата (за 30 дней) и самопроверка доставки форм (раз в час). Эти три проверки покрывают три типа инцидентов с самыми большими потерями для корпоративного сайта и реализуются на бесплатном тарифе стороннего сервиса. Недельный отчёт по индексации и сверку бэкапов можно делать реже, а полный набор из пяти проверок дополнить, когда с сайта пойдёт поток заявок.

Хватит ли бесплатных инструментов мониторинга?

В большинстве случаев хватает. Бесплатные тарифы сторонних сервисов обычно дают интервал 1–5 минут и проверку с нескольких узлов, что укладывается в пороги читаемости из второго раздела. Учтите два ограничения: на бесплатном тарифе мало узлов, поэтому иногда бывают ложные срабатывания с одного узла — фильтруйте их правилом «2 сбоя подряд»; бесплатный тариф обычно поддерживает только HTTP-проверки, а для самопроверки доставки форм придётся писать скрипт или брать платный тариф с возможностью скриптовых проверок. Как оценить бюджет: если год мониторинга стоит меньше потерь от одного случая истечения сертификата, его стоит настроить.

Что делать, если алертов так много, что к ним привыкают и перестают реагировать?

Сводим шум по правилам: если правило срабатывает ложно часто три месяца подряд — поднимаем порог или отключаем его совсем; за каждым правилом закрепляем ответственного, бесхозные правила снимаем. Дальше разводим каналы по уровням: только P0 идёт в мгновенные громкие уведомления, P1 — в почту и чат, P2 — только в недельный отчёт. Критерий, что шум сведён: две недели подряд ни одного ложного срабатывания в канале P0 и при этом ни одного пропущенного реального инцидента.

Нужно ли ставить алерт на падение числа проиндексированных страниц?

Нужно, но порог должен быть мягким. Число проиндексированных страниц колеблется само по себе: падение до 20% неделя к неделе — норма, алерт не нужен; срабатывает только падение больше 20% или две недели снижения подряд — это P1. Мониторинг лишь подаёт сигнал «пора проверить», а разбор обхода и индексации идёт отдельным процессом. И ещё: проверять индексацию достаточно раз в неделю — ежедневное слежение только плодит тревогу и не помогает раньше найти реальную проблему.

Как мониторинг связан с ежемесячным обслуживанием?

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

Что делать, если ночью сработал алерт, а обрабатывать некому?

Значит, не продумано дежурство. Сначала ответьте на вопрос «кто может среагировать ночью»: нужен хотя бы один человек с доступом к серверу, которого разбудят по каналу P0; если такого нет — настройте автоматические действия для P0: перезапуск сервиса, переключение на статическую кэш-страницу. Затем опишите в документе три уровня реакции: перезапуск и откат в течение 15 минут, переключение на статическую страницу в течение часа, передача во внешнюю поддержку в течение 4 часов. Если положиться на человека не выходит, лучше ослабить порог P0 до «сбой длится 10 минут подряд», чем держать алерт, который сработает и останется без ответа.

В заключение

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

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