Мониторинг бизнес-сервисов

Как определяется здоровье

Система автоматически проверяет наличие открытых мониторинговых инцидентов по узлам, входящим в сервис:

1. Система извлекает список всех узлов сервиса
2. Проверяет, есть ли по этим узлам открытые мониторинговые инциденты
3. Если найден хотя бы один открытый инцидент — сервис помечается как нездоровый
4. Если инцидентов нет — сервис здоров

Особые случаи

• Сервис без узлов: Если в сервисе нет добавленных узлов, он считается здоровым
• Обычные тикеты: Пользовательские тикеты (не мониторинговые инциденты) НЕ влияют на статус здоровья
• Закрытые инциденты: Инциденты со статусом "Done" не учитываются при расчёте

Колонки таблицы

• Здоровье — индикатор состояния (✅ или ❌)
• Название — название сервиса, кликабельное
• Обновлено — дата и время последнего изменения

Возможности таблицы

• Фильтрация: Поиск по названию, фильтр по дате обновления
• Сортировка: По названию и дате обновления
• Пагинация: По умолчанию отображается 20 записей на страницу
• Клик по строке: Открывает карточку редактирования сервиса

Информация в окне подробностей

• Название сервиса
• Количество узлов — например: "Узлов: 8"
• Статус здоровья — индикатор с текстом "Сервис здоров" или "Сервис имеет проблемы"
• Описание — полное текстовое описание сервиса (если заполнено)
• Узлы сети — таблица всех узлов сервиса с названиями и путями
• Открытые инциденты — таблица инцидентов с номерами, названиями, статусами и датами

Вкладка "Инциденты" в карточке редактирования

1. Откройте карточку сервиса для редактирования (клик по названию в таблице)
2. Перейдите на вкладку "Инциденты" — в заголовке указано количество открытых инцидентов
3. Отобразится список инцидентов, связанных с узлами данного сервиса
4. Кликните по любому тикету для открытия его карточки

Автоматическое определение затронутых сервисов

При работе с тикетом система автоматически:

1. Находит узлы, связанные с тикетом
2. Определяет бизнес-сервисы, которые включают эти узлы
3. Добавляет информацию о сервисах в контекст ИИ-помощника

Контекст для ИИ-помощника

Для каждого затронутого сервиса ИИ получает:

• Название и описание бизнес-сервиса
• Полный список серверов сервиса с их характеристиками
• Роли каждого узла в архитектуре сервиса
• Историю инцидентов по этому сервису

Улучшение диагностики

Благодаря информации о бизнес-сервисе, ИИ может:

• Анализировать проблему в контексте всей архитектуры сервиса
• Предлагать решения с учётом взаимосвязей между компонентами
• Выявлять каскадные проблемы, затрагивающие несколько узлов
• Учитывать роли серверов при формулировке рекомендаций

Отображение в карточках тикетов

В карточках тикетов отображается информация о затронутых бизнес-сервисах:

• Пользователь видит, какие критически важные сервисы затронуты инцидентом
• Можно оценить масштаб влияния проблемы на бизнес
• Можно перейти к подробностям сервиса для получения полной картины

Сценарий 1: Проактивный мониторинг

Ситуация: Администратор открывает дашборд мониторинга утром.

Действия:

1. Система автоматически вычисляет статус всех бизнес-сервисов
2. Нездоровые сервисы показываются первыми в списке
3. Администратор видит, что сервис "CRM Битрикс24" имеет проблемы
4. Клик по сервису открывает подробности с списком открытых инцидентов
5. Администратор сразу видит масштаб проблемы и приступает к устранению

Сценарий 2: Диагностика с ИИ

Ситуация: Пользователь создал тикет о недоступности корпоративного портала.

Действия:

1. Тикет создаётся и связывается с соответствующим узлом
2. Система находит бизнес-сервис "Корпоративный портал", включающий этот узел
3. При вызове ИИ-помощника ему передаётся полная информация об архитектуре портала
4. ИИ анализирует проблему в контексте всего сервиса и предлагает комплексное решение
5. Администратор получает рекомендации по проверке всех связанных компонентов

Сценарий 3: Анализ влияния на бизнес

Ситуация: Открыто несколько инцидентов по разным серверам.

Действия:

1. В каждом тикете отображаются затронутые бизнес-сервисы
2. Руководитель IT видит, что три инцидента относятся к одному критически важному сервису
3. Приоритет этих инцидентов повышается
4. Ресурсы перераспределяются для срочного восстановления сервиса