Карта зависимостей серверов и бизнес-сервисов показывает не просто где что установлено. Она объясняет, что произойдет с работой компании, если остановится конкретный сервер, база, сетевой узел, канал связи, облачный сервис или учетная система.
Главная польза такой карты проявляется перед изменениями и во время аварии. Если видно, какие сервисы зависят друг от друга, проще выбрать порядок восстановления, оценить риск плановой работы, подготовить rollback и объяснить бизнесу последствия.
Начинать нужно с бизнес-сервисов
Ошибка многих инвентаризаций в том, что они начинаются с серверов: имя, IP, операционная система, роль. Это полезно, но не отвечает на вопрос, какой процесс остановится. Поэтому первый слой карты лучше строить от сервисов, которые видит компания: бухгалтерия, склад, телефония, почта, файловые ресурсы, CRM, видеонаблюдение, VPN, сайт, обмен с внешними площадками.
Для каждого сервиса стоит указать владельца со стороны бизнеса и технического владельца. Бизнес-владелец отвечает за приоритет, допустимый простой и приемку результата. Технический владелец отвечает за схему, мониторинг, изменения и восстановление. Без этих ролей карта быстро превращается в справочник без управленческой силы.
| Слой | Что фиксировать | Зачем это нужно |
|---|---|---|
| Бизнес-сервис | Название, пользователи, владелец, критичность | Понять влияние на работу компании |
| Приложение | Серверы, службы, версии, точки входа | Видеть, что запускается и проверяется |
| Данные | Базы, файлы, очереди, хранилища | Связать сервис с backup и восстановлением |
| Инфраструктура | Сеть, DNS, авторизация, виртуализация, питание | Найти скрытые точки отказа |
| Внешние зависимости | Провайдеры, API, облака, сертификаты, почта | Не искать внутреннюю причину там, где зависимость внешняя |
Что считать зависимостью
Зависимость - это не только сервер, на котором запущено приложение. Сервис может зависеть от DNS, времени, доменной авторизации, сетевого маршрута, лицензирования, внешнего API, почтового шлюза, сертификата, хранилища backup, очереди обмена или доступности конкретного провайдера.
Важно разделять жесткие и мягкие зависимости. Жесткая зависимость останавливает сервис полностью: например, база данных недоступна, и приложение не открывается. Мягкая зависимость может оставить интерфейс доступным, но сломать важный сценарий: не отправляются уведомления, не проходит обмен с внешней системой, не формируется отчет, не работает поиск по архиву.
Такие мягкие связи часто и создают управленческие сюрпризы. Сервис формально работает, мониторинг показывает зеленый статус, но пользователи не могут завершить операцию. Поэтому карта должна описывать не только запуск приложения, но и ключевые пользовательские сценарии.
Порядок восстановления и запуска
Карта зависимостей особенно полезна после серьезного сбоя. Если восстановить приложения раньше инфраструктурных слоев, часть проверок даст ложные ошибки. Если поднять сервис без актуальных данных или без проверки интеграций, пользователи начнут работать в неполном контуре.
Для критичных сервисов стоит зафиксировать порядок: базовая инфраструктура, сеть и маршруты, хранилища, авторизация, базы данных, приложения, фоновые задания, интеграции, пользовательская проверка. Не все компании нуждаются в сложной CMDB, но порядок запуска должен быть понятен другому инженеру без устных объяснений.
| Вопрос | Что должно быть видно на карте |
|---|---|
| Что запускать первым? | Нижние инфраструктурные слои и сервисы, от которых зависят остальные |
| Что можно восстановить позже? | Некритичные отчеты, архивные обмены, вспомогательные панели |
| Что проверяет бизнес? | Ключевые операции, а не только открытие главной страницы |
| Где нужен rollback? | Узлы и интеграции, изменение которых влияет на несколько сервисов |
Как использовать карту перед изменениями
Перед обновлением сервера, переносом базы, заменой маршрутизатора или изменением схемы авторизации карта помогает задать правильные вопросы. Какие сервисы затрагиваются? Есть ли окно, когда пользователи могут работать без этой функции? Что нужно проверить после изменения? Кто принимает результат? Как быстро можно откатиться?
Если карта не используется перед изменениями, она устаревает быстрее. Хорошая практика - обновлять ее в том же процессе, где согласуется плановая работа: добавили интеграцию, изменили маршрут, перенесли базу, заменили сертификат, вывели старый сервер - карта должна получить новую связь или отметку об удалении зависимости.
Где проходит граница ответственности подрядчика
В модели системной интеграции и сопровождения один ответственный IT-подрядчик может вести карту, проверять технические связи, обновлять ее после работ и использовать при диагностике. Это не означает, что все решения замыкаются на одном человеке. Нормальная модель - команда подрядчика с единым процессом и прозрачными артефактами.
Границы нужно описывать честно. Подрядчик отвечает за техническую полноту карты, эксплуатационные проверки и предупреждение о рисках. Заказчик подтверждает критичность бизнес-сервисов, допустимые окна простоя, владельцев данных и приоритеты бюджета. Без участия владельцев сервисов даже технически точная карта не покажет реального влияния на бизнес.
Минимальный состав рабочей карты
Для небольшой компании достаточно таблицы или схемы, если она отвечает на практические вопросы. В ней должны быть бизнес-сервис, владелец, технический контур, данные, инфраструктурные зависимости, внешние зависимости, RTO/RPO или хотя бы допустимый простой, порядок проверки и дата последнего изменения.
Карту стоит проверять сценариями. Что будет, если выключить хост виртуализации? Если недоступен DNS? Если истек сертификат? Если провайдер потерял канал? Если старый сервер, который считался неиспользуемым, убрать из сети? Такие вопросы быстро показывают, где схема отражает реальность, а где она только красиво выглядит.
Итог: карта зависимостей полезна, когда связывает технические узлы с бизнес-сервисами, владельцами и сценариями отказа. Это рабочий инструмент для изменений, восстановления и приемки инфраструктуры, а не декоративная схема серверов.