Можно предположить, что большинство инцидентов, регистрируемых в Service Desk, являются типовыми. В таком случае представляется как вполне возможным, так и небесполезным, автоматизировать процесс не только регистрации, но и диагностики инцидентов, чтобы Служба поддержки получала не только диагностическую информацию, но и наиболее вероятный диагноз, который осталось бы только подтвердить (или отвергнуть, если система ошиблась).
Эту концепцию – диагностику инцидентов «на лету» – мы и предлагаем вам обсудить.
Архитектура
Для диагностики инцидентов на лету необходимы:
- Формальное описание инцидента со стороны пользователя (Снимок Инцидента). Предполагается, что Снимок Инцидента формируется Красной Кнопкой ProLAN.
- Система мониторинга. Предполагается использование системы мониторинга ProLAN.
- Агрегатор Информации. Агрегатор Информации должен уметь принимать Снимки Инцидентов, сохранять их в базе данных, в режиме реального времени обрабатывать содержимое базы данных и взаимодействовать с Системой мониторинга, Диагностической базой знаний и Service Desk.
- Диагностическая база знаний.
- Service Desk – система.
Диагностическая база знаний
Диагностическая База Знаний – это база данных, содержащая информацию о корневых причинах инцидентов.
Наличие Диагностической базы знаний существенно повысит эффективность Service Desk вне зависимости от того, выполняется диагностика инцидентов «на лету» или как обычно. Многие компании в том или ином виде уже имеют базы знаний, поэтому Диагностическая база знаний может стать дополнением того, что уже есть. В большинстве случаев никакой существенной переделки имеющейся базы знаний не потребуется.
Следует выделить два основных (принципиальных) отличия Диагностической базы знаний от баз знаний, которые обычно используются службами технической поддержки:
- Ключевыми элементами для определения диагноза являются описания инцидентов «глазами пользователей». Поэтому задачей №1 является систематизация инцидентов, как их видят пользователи ИТ-Сервисов.
- Значимыми параметрами являются Оценки качества компонентов ИТ-инфраструктуры. Поэтому задачей №2 является правильное определение пороговых значений метрик здоровья ИТ-инфраструктуры, которые необходимы для получения Оценок Качества.
Обе задачи могут быть решены, в том числе, внедрением решения Красная Кнопка.
Алгоритм диагностики инцидентов «на лету»
Шаг 1
На стороне пользователя создаётся формальное описание инцидента (Снимок Инцидента). Сделать это можно вручную (при помощи правильно разработанной веб-формы) или автоматически с использованием Красной Кнопки. Второе, конечно же, лучше, потому что позволяет получить данные более полные и более точные (например, точное время инцидента). Состав Снимка Инцидента в сокращенном виде показан на рисунке (см. ниже).
Состав Снимка Инцидента в сокращённом виде
Снимок Инцидента принимается Агрегатором Информации и его содержимое записывается в консолидированную базу данных, расположенную там же.
Шаги 2-3
На Агрегаторе Информации работает экспертная система, которая с использованием специальных тестов (Экспертиз) в режиме реального времени анализирует содержимое консолидированной базы данных. Обнаружив появление нового Снимка Инцидента, Экспертиза формирует Запрос оценок качества ИТ-Инфраструктуры, который направляется в Систему мониторинга.
Параметры запроса:
- Параметры Где и ИТ-Сервис определяют, Оценки качества каких компонентов ИТ-Инфраструктуры необходимо получить из Системы мониторинга (см. рисунок ниже). Например, если Снимок Инцидента поступил от пользователя SAP CRM, находящего в Санкт-Петербурге, то необходимо получить: Оценку качества канала связи «Питер-Москва», Оценку качества сервера приложений SAP CRM, Оценку качества базы данных SAP CRM.
- Параметр Когда определяет, за какой момент времени необходимо получить Оценки качества компонентов ИТ-инфраструктуры.
Рисунок 3. Оценки Качества ИТ-инфраструктуры.
Оценка качества компонента ИТ-инфраструктуры – это синтезированный показатель, получаемый в результате объединения оценок всех значимых метрик, характеризующих работу оцениваемого компонента ИТ-инфраструктуры.
Оценка метрики – это сравнение её значений с пороговыми значениями.
При использовании Системы мониторинга, поддерживающей сервисно-ресурсную модель, получить Оценки Качества ИТ-Инфраструктуры большого труда не составит. Если сервисно-ресурсная модель не поддерживается, то задача решается добавлением в Агрегатор Информации соответствующего справочника. В любом случае Система мониторинга и Агрегатор Информации должны быть интегрированы друг с другом.
В продуктах ProLAN Оценки качества компонентов ИТ-Инфраструктуры имеют пять значений: хорошо, допустимо, требует внимания, на грани, плохо.
Шаги 4-5
Получив Оценки Качества, Экспертиза формирует запрос в Диагностическую Базу Знаний. В упрощенном виде диагностическую Базу Знаний можно представить в виде таблицы, показанной ниже.
В качестве ключевых элементов используются элементы справочника «Что случилось» (входят в состав Снимка Инцидента). В качестве значимых параметров, определяющих вероятный диагноз, используются, во-первых, параметры окружения пользователя (входят в состав Снимка Инцидента), во-вторых, Оценки качества, получаемые из Системы мониторинга.
Чем полнее определён список значимых параметров, и чем точнее определен диапазон их значений, тем выше вероятность получения единственного, правильного диагноза.
Шаг №6
Получив из Диагностической базы знаний вероятный диагноз (или диагнозы), Экспертиза включает его в состав Агрегированного Снимка Инцидента, который автоматически отправляет в Service Desk. (Кроме диагноза, в состав Агрегированного Снимка Инцидента включаются значения соответствующих значимых параметров и Снимки Инцидентов, инициировавших его появление.)
Внимание, вопрос
Такая вот концепция. Хотелось бы услышать вашу критику, предложения, возражения, указания на возможные применения и т.п. –?
Автор: prolanrus
