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

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

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

    Архитектура


    image

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

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


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


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

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

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

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


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

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


    Шаг 1


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

    image

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

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

    Шаги 2-3


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

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

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


    image

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

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

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

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

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

    Шаги 4-5


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

    image

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

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

    Шаг №6


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

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


    Такая вот концепция. Хотелось бы услышать вашу критику, предложения, возражения, указания на возможные применения и т.п. –?
    ProLAN
    0.00
    Company
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 3

      0
      Если есть хорошая автоматизированная диагностическая система, то никакой оператор с хелпдеском, полагаю, уже не нужен. Пользователи сами станут формализовывать жалобы, автоматически получать список возможных решений и сразу применять их:)
        0
        Ну да, но это идеал, а на практике операторы с хелпдеском никуда не деваются. Важно также не только чтобы система была хорошая, но и чтобы настроена была правильно.
          0
          И с приятным голосом!

      Only users with full accounts can post comments. Log in, please.