Внешняя зависимость - это сервис или канал, без которого ваш бизнес-сервис не работает, хотя сам он находится за пределами вашей инфраструктуры. К таким зависимостям относятся интернет-канал, DNS-зона, домен, TLS-сертификат, почтовый провайдер, облачное хранилище, SaaS-система, API партнера и платежный шлюз.
Главная задача мониторинга внешних зависимостей - не доказать, что «виноват провайдер», а быстро отделить внешний сбой от внутренней аварии и собрать факты для правильной эскалации. Без этого пользователи видят один симптом, а команда тратит время на серверы, сеть и рабочие места, хотя отказ находится вне зоны прямого управления.
Что нужно описать до настройки проверок
Начните с карты зависимостей бизнес-сервисов. Для каждой критичной функции укажите, какие внешние элементы участвуют в работе: домен, DNS-провайдер, интернет-канал, облачная платформа, почтовый сервис, телефония, внешний API, сертификат, CDN или личный кабинет поставщика.
Для каждой зависимости полезно зафиксировать владельца договора, технический контакт, способ обращения в поддержку, критичность, ожидаемое время реакции, резервный сценарий и признаки отказа. Если это не описано заранее, мониторинг будет показывать красный индикатор, но не будет подсказывать, кто должен действовать.
Проверки должны быть независимыми
Проверка внешнего сервиса изнутри офиса показывает только точку зрения офиса. Если интернет-канал упал, все внешние проверки из этой сети тоже станут красными, хотя сам облачный сервис может быть исправен. Поэтому критичные зависимости лучше проверять минимум с двух точек: из офисной сети и с внешней площадки или облачного мониторинга.
Для DNS полезно проверять не только доступность сайта, но и корректность разрешения имени. Для сертификата важен не только факт HTTPS-ответа, но и срок действия, соответствие домену и корректная цепочка. Для облачного сервиса важны отдельные проверки входа, API, фоновых синхронизаций и операций, которые реально нужны бизнесу.
Что фиксировать в инциденте
Хорошая запись об инциденте содержит время начала, затронутый бизнес-сервис, пользовательский симптом, результаты независимых проверок, границу отказа и владельца следующего действия. Например: «сайт открывается из внешней проверки, но недоступен из офиса» - это один сценарий; «домен не разрешается у нескольких публичных резолверов» - другой.
Не все внешние сбои выглядят как полный отказ. DNS может отдавать устаревший адрес, сертификат может быть действительным для одного имени и ошибочным для другого, облачный сервис может принимать вход, но не выполнять синхронизацию. Поэтому мониторинг должен проверять именно пользовательский путь, а не только один HTTP-код.
Как не утонуть в уведомлениях
Внешние зависимости часто создают каскадные тревоги. Один отказ DNS может вызвать ошибки сайта, почты, API и мониторинга сертификатов. Чтобы команда не получила десятки равнозначных уведомлений, проверки нужно связывать с родительской зависимостью и группировать по бизнес-сервису.
Полезная схема: сначала сигнал о зависимости, затем список затронутых сервисов, затем владелец эскалации. Если у интернет-канала есть резерв, мониторинг должен показывать не только падение основного канала, но и факт перехода на резерв, его качество и возврат к штатному режиму.
Таблица ответственности
| Зависимость | Что проверять | Кто обычно владеет действием |
|---|---|---|
| Интернет-канал | доступность снаружи и из офиса, задержка, потери, переход на резерв | провайдер, сетевой подрядчик, ответственный за договор |
| DNS и домен | разрешение имен, срок регистрации, доступ к панели управления | владелец домена, DNS-провайдер, IT-ответственный |
| TLS-сертификат | срок, имя, цепочка, применение на нужных узлах | администратор сайта или подрядчик, выпускающий сертификаты |
| Облачный сервис | вход, ключевые операции, синхронизация, статус интеграций | владелец сервиса, SaaS-поставщик, IT-поддержка |
| Внешний API | доступность, ошибки, лимиты, очередь повторов | владелец интеграции и поставщик API |
Как использовать результат
Мониторинг внешних зависимостей должен попадать в процесс управления инцидентами. Если сигнал подтвержден, заявка получает владельца, бизнес-влияние, временный обход и критерий закрытия. Закрывать инцидент стоит не по исчезновению красного индикатора, а по восстановлению пользовательского сценария и фиксации причины.
Для ITSM-процесса это означает простую дисциплину: зависимость описана, проверка настроена, контакт известен, эскалация понятна, после сбоя остается запись с выводами. При такой модели ITSM-процесс помогает управлять даже теми рисками, которые находятся за пределами собственного оборудования.