Ресурсно-сервисная модель
Карта зависимостей, которая превращает алерты в инциденты с бизнес-контекстом
Технические алерты живут сами по себе, бизнес — сам по себе
Мониторинг видит хосты и метрики, но не видит, какой бизнес-сервис стоит за упавшим сервером, а именно этот разрыв мешает быстро понять масштаб инцидента.
Разрозненные алерты не складываются в картину
Без модели зависимостей непонятно, относятся ли 12 алертов с разных hostname к одному сбою или к 12 разным проблемам — correlation engine группирует наугад или не группирует вовсе.
Нет связи «техника → бизнес»
Инженер видит, что упал конкретный сервер, но не может быстро определить, какой бизнес-сервис пострадал, какая у него критичность и кого эскалировать.
Ручное и фрагментированное ведение CMDB
Данные размазаны по Proxmox, Zabbix, сканерам и Excel, модель быстро устаревает.
Низкое качество корреляции без эталона
Нет актуальной карты зависимостей и внешних идентификаторов для сопоставления.
Потеря контекста при изменениях модели
Без аудита и архивирования теряется история изменений.
Неконтролируемое качество модели
Битые связи, циклы и неполные карточки снижают доверие к автоматической корреляции.
Единое хранение модели ИТ-ландшафта и контекста для корреляции событий и обогащения инцидентов
Продукт не заменяет систему мониторинга и не подменяет систему корреляции событий — он строит и хранит эталонную модель зависимостей, а окончательное решение о группировке событий остаётся за внешней системой.
Преимущества решения
Единый источник правды о топологии
Элементы ИТ-ландшафта и типизированные направленные связи между ними хранятся в одном месте — вместо разрозненных CMDB, таблиц и знаний в головах инженеров.
Correlation API с batch-операциями
Внешняя система мониторинга через готовый API с OpenAPI-спецификацией пакетно сопоставляет технические алерты с объектами модели и получает граф зависимостей.
Богатая модель сопоставления идентификаторов
Hostname, IP, serviceCode, Proxmox ID, Zabbix host ID, CMDB ID и другие идентификаторы связывают алерты из разных систем с одним объектом модели.
Автоматическое наполнение из Proxmox, Zabbix и Network Scanner
Модель синхронизируется с реальной инфраструктурой автоматически, а не только вручную или из файлов — снижается риск устаревания данных.
Impact analysis «снизу вверх»
От сбоя на конкретной VM, базе данных или сервере строится цепочка вверх до затронутых бизнес-сервисов — понятно, что реально пострадало, а не только какой хост недоступен.
Визуализация графа и валидация модели
Веб-интерфейс показывает граф зависимостей визуально и проверяет модель на циклы, битые ссылки и архивные объекты, повышая надёжность автоматической корреляции.
Мягкое удаление вместо потери контекста
Объекты архивируются, а не удаляются безвозвратно — исторический контекст сохраняется для расследования и аудита.
Ролевая модель доступа
Роли VIEWER, EDITOR, ADMIN и CORRELATION_CLIENT разграничивают, кто может просматривать, редактировать модель или подключаться к ней как внешняя система через API.
Import/Export в JSON, CSV, XLSX
Модель можно загрузить из существующей CMDB или Excel-таблицы и выгрузить обратно — миграция и первичное наполнение не требуют кастомных коннекторов.
Операционный контур: очередь реагирования и аудит
Оператор разбирает исключения и конфликты в очереди «Реагирование», а система контролирует полноту инвентаризации и ведёт аудит изменений.
Юзер-сценарии
Сценарий 1. Корреляция всплеска алертов
Участник: Correlation engine / система мониторинга.
Контекст: за 5 минут пришло 12 алертов с разных hostname и IP после сбоя на уровне СХД. Мониторинг сопоставляет алерты с объектами РСМ, получает граф зависимостей, затронутые бизнес-сервисы, критичность и владельцев, после чего correlation engine объединяет связанные события в инциденты.
Результат: один инцидент вместо двенадцати; в тикете указаны бизнес-сервис, критичность и ответственная команда.
Сценарий 2. Автоматическое наполнение модели из инфраструктуры
Участник: администратор и редактор модели.
Контекст: инфраструктура на Proxmox, мониторинг в Zabbix, сетевое оборудование в Network Scanner, ручной CMDB устарел. Настраиваются интеграции и автосинхронизация, создаются элементы VM/CONTAINER и связи HOSTED_ON, события обрабатываются в очереди «Реагирование», контролируется полнота инвентаризации.
Результат: актуальная модель без полного ручного переноса; оператор контролирует исключения и конфликты.
Сценарий 3. Impact analysis при плановых работах
Участник: инженер эксплуатации или архитектор.
Контекст: планируется перезагрузка гипервизора или патч PostgreSQL в production. Инженер находит ресурс, просматривает граф зависимостей, выполняет impact analysis и при необходимости экспортирует затронутую часть модели для согласования.
Результат: согласованное окно обслуживания, уведомлены владельцы зависимых бизнес-сервисов, модель остаётся актуальной.
Сценарий 4. Импорт модели при миграции или подготовке MVP
Участник: администратор.
Контекст: требуется стартовое наполнение РСМ из legacy Excel/CMDB или подготовка демо. Администратор загружает JSON/CSV/XLSX, система валидирует данные и формирует отчёт, после чего связи дорабатываются в интерфейсе и подключается Correlation API.
Результат: быстрый старт MVP без кастомных коннекторов, прозрачный отчёт о качестве загрузки.
Бизнес-выгоды
Сокращение информационного шума
Меньше дублирующих тикетов, связанные алерты группируются по одной цепочке РСМ.
Ускорение RCA и MTTR на 30%
Оператор сразу видит цепочку «БД → приложение → бизнес-сервис» и зону вероятной первопричины.
Приоритизация по бизнес-влиянию
Инциденты обогащаются критичностью, окружением и владельцами, проще решать, что чинить первым.
Снижение стоимости сопровождения модели
Автосинхронизация из Proxmox, Scanner и Zabbix уменьшает ручной труд.
Прозрачность для стейкхолдеров
Service owners видят, какие технические ресурсы лежат под их бизнес-сервисом
Контроль качества данных
Аудит, валидация и метрики полноты снижают риск ошибочной корреляции.
Масштабируемая интеграция
Стандартный API подключается к существующему мониторингу без замены всей платформы — внедрение не требует пересборки инфраструктуры.
Соответствие процессам ITSM
Модель становится основой для impact assessment, change management и планирования мощностей.
Для кого
Команды эксплуатации и мониторинга (NOC, L1/L2, инженеры инфраструктуры) — ведут модель, синхронизируют данные из Proxmox, Scanner и Zabbix, разбирают очередь реагирования, контролируют качество инвентаризации.
Архитекторы и системные аналитики — проектируют цепочки «техника → приложение → бизнес-сервис», задают типы связей и атрибуты.
Владельцы бизнес-сервисов и ITSM — понимают, какие бизнес-сервисы затронуты при сбое на конкретном ресурсе.
Команды разработки платформы мониторинга (интеграторы correlation engine, SIEM, AIOps) — потребляют Correlation API для сопоставления алертов и построения корреляционного контекста.
Администраторы CMDB и модели — управляют справочниками, пользователями, импортом/экспортом и интеграциями.
Product Owner и бизнес-заказчик — получают формализованную модель зависимостей как основу для сокращения шума в инцидентах и ускорения RCA.