Введение

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

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

Существует огромная возможность использования машинного обучения для улучшения процесса управления инцидентами и возможностей для автоматизации нескольких задач, включая назначение инцидентов.

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

Набор данных содержит 24985 инцидентов с общим количеством строк 141725 с различными состояниями инцидента в их жизненном цикле и имеет 35 различных функций, связанных с этим конкретным инцидентом.

Я проанализировал эти данные об инциденте, чтобы увидеть, какие данные имеют шаблон, и посмотреть, какие функции могут быть важны для прогнозирования кода закрытия для предстоящего инцидента.

Если мы сможем предсказать код закрытия, то, как только будет получена заявка, мы будем знать, что потребуется, чтобы закрыть этот инцидент, и какой процесс автоматизации или команда лучше всего решат эту проблему за минимально необходимое время, обеспечивая наилучшее качество обслуживания клиентов.

Часть I: - Почему билеты открываются повторно?

В данном наборе данных мы можем видеть на рисунке 1, что инцидент может находиться в 8 различных состояниях в течение заданного времени, прежде чем он будет закрыт.

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

Сначала я посмотрел коды закрытия для всех билетов, которые были переоткрыты хотя бы 1 раз (есть инциденты, которые открываются более 8 раз). Как мы видим на Рисунке 2, другой схемы нет, так как большинство инцидентов закрываются по кодам 6, 7, 8, 9, хотя есть и код 1, но здесь нет четкой схемы.

Затем я посмотрел на SLA, там есть поле, например, made_sla, которое фиксирует логический атрибут, который показывает, превысил ли инцидент целевое SLA.

Основываясь на данных, я обнаружил, что более 75% повторно открытых инцидентов не соответствуют SLA, поэтому существует четкая закономерность, согласно которой, если заявки открываются повторно, существует высокая вероятность нарушения SLA.

Я также просмотрел колонку симптомов, в которой есть описание восприятия пользователем доступности услуги. Я обнаружил, что симптомы также очень похожи на другие инциденты, что касается повторного открытия, поэтому нет четкого шаблона с закрытым кодом и симптомами, но мы можем видеть, что в случае повторно открытых инцидентов SLA пропускаются.

Часть II: Какие инциденты не соответствуют SLA?

Поскольку мы видим, что SLA обычно упускаются из-за повторно открытых инцидентов, я решил более подробно изучить инциденты, в которых SLA не было выполнено.

Когда я просмотрел все закрытые инциденты, я обнаружил, что примерно в 63% случаев SLA не выполняется.

Затем, глядя на приоритет, который рассчитывается системой на основе «воздействия» и «срочности», становится ясно, что из Таблицы 1 SLA в основном не выполняются для критических и высокоприоритетных инцидентов, тогда как SLA выполняются для инцидентов со средним и низким приоритетом.

Мы видим, что SLA являются важным фактором, и видим, что это четкая закономерность в поле SLA как для повторно открытых, так и для высокоприоритетных инцидентов.

Часть III: Какие функции важны для прогнозирования закрытого кода?

Основываясь на нашем анализе, мы видим, что в данных есть шаблоны и различия, и вариант использования машинного обучения, который, по моему мнению, предсказывал закрытый код с использованием всех других функций, поскольку это поможет в назначении билетов для более быстрого разрешения.

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

Для подгонки модели RF я определил все категориальные признаки и выполнил фиктивное кодирование для них и подгонял модель RF, как показано на рисунке 4.

После подгонки модели я проверил важность функций, как показано на рисунке 5.

Наиболее важной функцией, которая поможет нам в нашем прогнозе, является sys_mod_count, то есть количество обновлений инцидентов до этого момента, что имеет смысл, поскольку на основе обновлений системы будет некоторый шаблон, который поможет определить наилучшее возможное решение для данных инцидентов. . Следующими важными функциями являются количество повторных назначений, и независимо от того, соответствует ли инцидент соглашению об уровне обслуживания или нет, различные симптомы и местоположение также являются важными функциями.

Это показывает, что, используя эти функции с дополнительным проектированием функций и оптимизацией гиперпараметров, мы можем разработать модель машинного обучения для прогнозирования возможного разрешения предстоящего инцидента.

Вывод

В этой статье мы проанализировали данные журнала событий инцидентов и увидели, какие различные шаблоны можно извлечь из данных об инцидентах.

  1. Мы просмотрели данные, чтобы увидеть, что заставляет инцидент открываться повторно и влияет ли это на процесс управления инцидентами. Мы видим, что нет четкого шаблона с закрытым кодом и симптомами для повторно открытых инцидентов, и большинство повторно открытых инцидентов не соответствуют SLA.
  2. Проанализировали SLA для всех инцидентов и обнаружили, что существует четкая закономерность с приоритетом инцидента вокруг отсутствующего SLA.
  3. Наконец, чтобы увидеть возможность использования машинного обучения для прогнозирования закрытого кода для нового инцидента, мы проанализировали важные функции из предоставленных данных. Мы видим возможность и возможности для использования машинного обучения здесь, а затем — построить модель с продвижением в разработке функций и оптимизации параметров.

Выводы здесь являются наблюдательными, а не результатом анализа всех данных. Так что реальный вопрос остается

Какие другие варианты использования машинного обучения можно применить в процессе управления инцидентами с использованием данных журнала событий инцидентов?

Чтобы узнать больше об этом анализе, см. ссылку на мой Github, доступную здесь.