Мониторинг внешних зависимостей сайта начинают не с проверки чужого домена, а с карты: какой сервис обслуживает шаг клиента, какой симптом появится при отказе, чем его измерить и кто должен реагировать. Для каждой критичной зависимости нужна проверка результата на вашем сайте и заранее определённое нормальное состояние.
Главная может отвечать кодом 200, пока не работают оплата, вход, поиск, доставка, почта или файлы CDN. Задача мониторинга — не назначить виновника по одному сигналу, а быстро отделить полный отказ сайта от поломки отдельного сценария и дать команде понятный порядок действий.
Что считать внешней зависимостью
Внешняя зависимость — компонент вне основного приложения, без которого пользовательский путь полностью или частично ломается. Это может быть инфраструктура — DNS или CDN; функция — оплата, авторизация, карты, доставка, CRM или сторонний API; доставка результата — почта, SMS, webhook или очередь обмена.
Записывайте не только название поставщика, но и его функцию: «показывает форму оплаты», «подтверждает вход», «передаёт заявку в CRM». Тогда карта останется полезной и после смены сервиса.
Составьте карту от пользовательского сценария
Начните с трёх–пяти действий, потеря которых заметна клиенту или бизнесу. Для магазина это могут быть вход, поиск товара, расчёт доставки и переход к оплате. Для сайта услуг — открытие формы, её отправка и доставка заявки ответственному.
Для каждого действия заполните карточку:
| Поле | Что записать | |---|---| | Сценарий | Что пытается сделать пользователь | | Зависимость | Какой внешний компонент участвует | | Видимый симптом | Что увидит клиент при отказе | | Контрольная точка | Какой безопасный URL или результат проверять | | Норма | Код, текст, конечный адрес или допустимое время | | Реакция | Кто получает сигнал и какой есть резерв |
Например, страница с формой и контрольный текст показывают, что интерфейс доступен, но не подтверждают доставку заявки в CRM. В карте нужны два факта: «форма открылась» и «тестовая заявка дошла по безопасному сценарию».
Если непонятно, какие адреса выбрать, сначала определите, что мониторить кроме главной страницы. Для собственных сервисов отдельно пригодится руководство по выбору endpoint для мониторинга API.
Разделите проверки на четыре уровня
1. Результат на своём домене
Сначала проверяйте место, где зависимость влияет на пользователя: страницу входа, корзину, форму, поиск или загрузку файла. Фиксируйте точный URL, HTTP-код, конечный адрес после редиректов и ожидаемый текст.
Код 200 без нужного элемента может означать заглушку, пустой блок или страницу авторизации вместо рабочего результата.
2. Безопасный технический сигнал
Если у приложения есть публичный health endpoint без секретов и побочных эффектов, он может показывать готовность обязательных компонентов. Чужой API проверяйте напрямую только тогда, когда это разрешено условиями сервиса и не требует помещать токен в URL.
Главная страница провайдера не заменяет пользовательскую проверку: она может открываться, пока недоступен конкретный регион, аккаунт или метод API.
3. Время и содержимое ответа
Зависимость может не отключиться полностью, а начать отвечать медленно или возвращать неправильные данные. Опишите норму заранее: какой код ожидается, какой маркер должен присутствовать и какое время приемлемо для сценария.
Универсального порога нет. Его выбирают по требованиям действия и истории наблюдений, иначе жёсткая граница создаст шум, а слишком мягкая скроет деградацию.
4. Безопасный сценарий
Открытие страницы не доказывает, что заявка дошла, вход завершился или письмо доставлено. Для критичного процесса нужен отдельный синтетический тест либо ручная контрольная проверка по расписанию.
Такой тест не должен создавать реальные списания, заказы или обращения. Если безопасный сценарий сделать нельзя, честно зафиксируйте этот пробел в карте.
Сопоставляйте сигналы
Одна тревога показывает симптом, но редко доказывает первопричину. Смотрите на сочетание проверок:
| Сигналы | Рабочая гипотеза | |---|---| | Главная и несколько сценариев недоступны | Проверить DNS, CDN, хостинг и приложение | | Главная работает, один сценарий сломан | Проверить его код, данные и зависимость | | Своя страница работает, техническая точка нестабильна | Уточнить влияние на пользователей | | Статус-страница сообщает об инциденте, свои проверки успешны | Наблюдать, но не объявлять свой сайт недоступным | | Endpoint восстановился, а сценарий нет | Проверить очереди, callback и отложенные операции |
Статус-страница поставщика даёт контекст, но не заменяет проверку вашего URL. Логи приложения, прокси и интеграции нужны для подтверждения причины.
Как уменьшить ложные тревоги
- подтверждайте единичную ошибку повторной проверкой, если задержка допустима;
- проверяйте критичный URL снаружи, а не только из сети сервера;
- не опрашивайте чужой сервис чаще разрешённого;
- отличайте 401 или 403 из-за настроек проверки от реального отказа;
- группируйте одновременные сигналы одного сценария;
- направляйте уведомление человеку, который знает зависимость и резерв.
Не скрывайте устойчивый сбой длинной серией повторов. Цель подтверждения — убрать случайный сетевой шум, а не отложить реакцию.
Что делать после сигнала
- Зафиксируйте время, URL, код и затронутый пользовательский шаг.
- Сравните страницу, техническую точку, логи и статус поставщика.
- Проверьте недавние релизы, настройки DNS, сертификата, CDN и доступа к API.
- Если влияние подтверждено, включите резерв или покажите понятное сообщение вместо бесконечного ожидания.
- После восстановления повторите сценарий и проверьте отложенные заявки, уведомления или callback.
Мониторинг не заменяет логи и функциональные тесты и не доказывает вину поставщика. Тот же симптом могут вызвать ваша конфигурация, истёкший ключ, блокировка по адресу или ошибка обработки ответа.
Минимальный план на первый день
Возьмите один самый важный сценарий и заполните для него карточку. Добавьте проверку собственного URL, задайте ожидаемый код или текст, назначьте получателя уведомления и запишите резервный путь.
Проведите учебную проверку: убедитесь, что сигнал приходит, контрольная точка понятна, а ответственный знает следующий шаг. Затем добавляйте остальные зависимости по влиянию на клиента, а не по длине списка поставщиков.
Чтобы не проверять выбранные URL вручную, можно настроить автоматический мониторинг в Web-Puls. Начните с критичной страницы, проверьте ожидаемый результат и добавьте её в мониторинг; прямые проверки чужих сервисов подключайте только по разрешённому и безопасному сценарию.