Диагностика инцидентов «на лету»

Можно предположить, что большинство инцидентов, регистрируемых в Service Desk, являются типовыми. В таком случае представляется как вполне возможным, так и небесполезным, автоматизировать процесс не только регистрации, но и диагностики инцидентов, чтобы Служба поддержки получала не только диагностическую информацию, но и наиболее вероятный диагноз, который осталось бы только подтвердить (или отвергнуть, если система ошиблась).

Эту концепцию – диагностику инцидентов «на лету» – мы и предлагаем вам обсудить.

Архитектура

Диагностика на лету рис 1

Для диагностики инцидентов на лету необходимы:

  • Формальное описание инцидента со стороны пользователя (Снимок Инцидента). Предполагается, что Снимок Инцидента формируется Красной Кнопкой ProLAN.
  • Система мониторинга. Предполагается использование системы мониторинга ProLAN.
  • Агрегатор Информации. Агрегатор Информации должен уметь принимать Снимки Инцидентов, сохранять их в базе данных, в режиме реального времени обрабатывать содержимое базы данных и взаимодействовать с Системой мониторинга, Диагностической базой знаний и Service Desk.
  • Диагностическая база знаний.
  • Service Desk – система.

Диагностическая база знаний

Диагностическая База Знаний – это база данных, содержащая информацию о корневых причинах инцидентов.

Наличие Диагностической базы знаний существенно повысит эффективность Service Desk вне зависимости от того, выполняется диагностика инцидентов «на лету» или как обычно. Многие компании в том или ином виде уже имеют базы знаний, поэтому Диагностическая база знаний может стать дополнением того, что уже есть. В большинстве случаев никакой существенной переделки имеющейся базы знаний не потребуется.

Следует выделить два основных (принципиальных) отличия Диагностической базы знаний от баз знаний, которые обычно используются службами технической поддержки:

    1. Ключевыми элементами для определения диагноза являются описания инцидентов «глазами пользователей». Поэтому задачей №1 является систематизация инцидентов, как их видят пользователи ИТ-Сервисов.
    2. Значимыми параметрами являются Оценки качества компонентов ИТ-инфраструктуры. Поэтому задачей №2 является правильное определение пороговых значений метрик здоровья ИТ-инфраструктуры, которые необходимы для получения Оценок Качества.

Обе задачи могут быть решены, в том числе, внедрением решения Красная Кнопка.

Алгоритм диагностики инцидентов «на лету»

Шаг 1

На стороне пользователя создаётся формальное описание инцидента (Снимок Инцидента). Сделать это можно вручную (при помощи правильно разработанной веб-формы) или автоматически с использованием Красной Кнопки. Второе, конечно же, лучше, потому что позволяет получить данные более полные и более точные (например, точное время инцидента). Состав Снимка Инцидента в сокращенном виде показан на рисунке (см. ниже).

Диагностика на лету рис 2

Состав Снимка Инцидента в сокращённом виде

Снимок Инцидента принимается Агрегатором Информации и его содержимое записывается в консолидированную базу данных, расположенную там же.

Шаги 2-3

На Агрегаторе Информации работает экспертная система, которая с использованием специальных тестов (Экспертиз) в режиме реального времени анализирует содержимое консолидированной базы данных. Обнаружив появление нового Снимка Инцидента, Экспертиза формирует Запрос оценок качества ИТ-Инфраструктуры, который направляется в Систему мониторинга.

Параметры запроса:

  • Параметры Где и ИТ-Сервис определяют, Оценки качества каких компонентов ИТ-Инфраструктуры необходимо получить из Системы мониторинга (см. рисунок ниже). Например, если Снимок Инцидента поступил от пользователя SAP CRM, находящего в Санкт-Петербурге, то необходимо получить: Оценку качества канала связи «Питер-Москва», Оценку качества сервера приложений SAP CRM, Оценку качества базы данных SAP CRM.
  • Параметр Когда определяет, за какой момент времени необходимо получить Оценки качества компонентов ИТ-инфраструктуры.

Диагностика на лету рис 3

Рисунок 3. Оценки Качества ИТ-инфраструктуры.

Оценка качества компонента ИТ-инфраструктуры – это синтезированный показатель, получаемый в результате объединения оценок всех значимых метрик, характеризующих работу оцениваемого компонента ИТ-инфраструктуры.

Оценка метрики – это сравнение её значений с пороговыми значениями.

При использовании Системы мониторинга, поддерживающей сервисно-ресурсную модель, получить Оценки Качества ИТ-Инфраструктуры большого труда не составит. Если сервисно-ресурсная модель не поддерживается, то задача решается добавлением в Агрегатор Информации соответствующего справочника. В любом случае Система мониторинга и Агрегатор Информации должны быть интегрированы друг с другом.

В продуктах ProLAN Оценки качества компонентов ИТ-Инфраструктуры имеют пять значений: хорошо, допустимо, требует внимания, на грани, плохо.

Шаги 4-5

Получив Оценки Качества, Экспертиза формирует запрос в Диагностическую Базу Знаний. В упрощенном виде диагностическую Базу Знаний можно представить в виде таблицы, показанной ниже.

«Что случилось»

Список значимых параметров

Диагноз

Параметр

Диапазон значений

Элемент 1 из справочника «Что случилось» в составе снимка Инцидента

Параметр 1

1-3

Диагноз 1

Параметр 2

Более 16

Оценка Качества 1

Лучше 4

Оценка Качества 2

Лучше 3

Оценка Качества 3

Лучше 3

Элемент 2 из справочника «Что случилось» в составе снимка Инцидента

Параметр 1

27-99

Диагноз 2

Параметр 2

4.1, 4.4,5.1

Оценка Качества 1

Лучше 4

Оценка Качества 2

Лучше 4

В качестве ключевых элементов используются элементы справочника «Что случилось» (входят в состав Снимка Инцидента). В качестве значимых параметров, определяющих вероятный диагноз, используются, во-первых, параметры окружения пользователя (входят в состав Снимка Инцидента), во-вторых, Оценки качества, получаемые из Системы мониторинга.

Чем полнее определён список значимых параметров, и чем точнее определен диапазон их значений, тем выше вероятность получения единственного, правильного диагноза.

Шаг №6

Получив из Диагностической базы знаний вероятный диагноз (или диагнозы), Экспертиза включает его в состав Агрегированного Снимка Инцидента, который автоматически отправляет в Service Desk. (Кроме диагноза, в состав Агрегированного Снимка Инцидента включаются значения соответствующих значимых параметров и Снимки Инцидентов, инициировавших его появление.)

Внимание, вопрос

Такая вот концепция. Хотелось бы услышать вашу критику, предложения, возражения, указания на возможные применения и т.п. – ?

Комментарии запрещены.