Ресурсно‑сервисная модель

Карта зависимостей, которая превращает алерты в инциденты с бизнес‑контекстом

Разрозненные алерты не складываются в картину

Без модели зависимостей непонятно, относятся ли 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.

Получить демонстрацию

Мы поможем с вопросами, поддержкой или расскажем, как Artimate может принести пользу вашему бизнесу. Заполните форму, и наша команда свяжется с вами в ближайшее время