Текст (PDF):
Читать
Скачать
Введение
Information Technology Service Management (ITSM) – это идеология управления ИТ как набором услуг. В рамках этой идеологии ИТ-отдел или аутсорсер предоставляет бизнесу услуги
с измеримыми характеристиками. Все параметры этой услуги подробно описаны в специальном соглашении – SLA (англ. Service Level Agreement – соглашение об уровне сервиса), которое составляют обе заинтересованные стороны – и ИТ, и бизнес. Идеология ITSM основана на ITIL (англ.
IT Infrastructure Library – библиотека инфраструктуры информационных технологий), библиотеке лучших практик. Библиотека ITIL описывает бизнес-процесс, который позволяет предоставлять услуги в соответствии с требованиями клиентов (предприятий) на основе реального опыта ведения бизнеса. Однако ITSM и ITIL являются различными понятиями. ITSM – это подход, а ITIL – практическое руководство [1–4].
В процессе оказания ИТ-услуг могут возникнуть различные проблемы: услуга может стать недоступной, выполняться с ошибками, может появиться возможность получения несанкционированного доступа к информации и т. д. Возможны отклонения от штатного предоставления услуги. ITIL определяет такие отклонения как инциденты. Таким образом, инцидент – это незапланированное прерывание или снижение качества ИТ-услуги. Сбой конфигурационной единицы (неисправность или вовремя не проведенное техническое облуживание аппаратной или программной части
ИТ-системы), который еще не повлиял на услугу, также является инцидентом.
Как правило, действия по устранению ИТ-инцидентов оказывают значительное влияние на общее восприятие ИТ пользователем. Чтобы эффективно управлять этой деятельностью, необходимо сформировать соответствующий план действий. В соответствии с рекомендациями ITIL для этого должен быть построен процесс управления инцидентами. В большинстве случаев организации используют собственные рукописные классификаторы (программы, написанные на любом языке программирования), основанные на поиске определенных слов в текстах запросов на основе логических операций (если-то-иначе). Соответственно, при добавлении ИТ-сервисов приходится вручную добавлять новые логические условия в код классификатора.
Для правильного устранения инцидента критически важна задача его классификации. Классификация – это назначение соответствующей категории инциденту диспетчерами дежурной службы инфотелекоммуникационной системы для его дальнейшей маршрутизации специалистам.
В данной работе рассматривается вопрос целесообразности внедрения алгоритмов машинного обучения в системы ITIL. Для этого рассмотрим структуру отдела и предполагаемую эффективность внедрения данного решения. Схематическая структура отдела представлена на рис. 1.
Специалисты по системам выполняют роль маршрутизатора для инцидентов и перенаправляют их специалистам ФГ (функциональных групп), отвечающих за функционирование сервисов.
Внедрение методов машинного обучения предполагает автоматизацию маршрутизации инцидентов, что уменьшит время реагирования и устранит неточность, связанную с человеческим фактором. Также это позволит оптимизировать рабочие места в отделах, отвечающих за непрерывное функционирование ИТ-сервисов, т. к. роль специалистов групп будет выполнять алгоритм машинного обучения.
Рис. 1. Схематическое представление подразделения информатизации: ФГ – функциональная группа
Fig. 1. Schematic representation of the informatization unit: ФГ – functional group
Использование разработанного классификатора, основанного на подходе градиентного бустинга, позволит уменьшить количество ошибок при классификации и маршрутизации заявок и позволит предсказать категории для инцидентов, которые не попали под рукописный классификатор.
Анализ методов машинного обучения
Машинное обучение – обширный раздел [5], использующий математические, статистические
и вычислительные методы для решения задач по определенному алгоритму. Существует множество методов машинного обучения, такие как метод ближайших соседей, дерево решений, случайный лес, байесовский классификатор, нейронные сети, сверточные нейронные сети, адаптивный бустинг, градиентный бустинг и др. [6, 7].
Нейронные сети представляют собой имитацию работы мозга. Они состоят из последовательности нейронов, соединенных между собой синапсами. Сети состоят из входного слоя, скрытого слоя и выходного слоя. Каждый из нейронов получает и обрабатывает данные, которые пере-даются нейронам на следующем уровне. Так как обработка сигналов у них идентичная, чтобы получить верное решение, необходимо правильно выбрать параметры синапсов, которые связывают нейроны. Существует множество разновидностей нейронных сетей, такие как сверточная нейронная сеть, импульсная нейронная сеть, хаотическая нейронная сеть и др. Пример нейронной сети представлен на рис. 2.
Рис. 2. Пример нейронной сети
Fig. 2. An example of a neural network
В данном примере первый слой (два нейрона) – это входной слой, второй слой (пять нейронов) – скрытый (вычислительный) слой, третий – (один нейрон) – выходной слой. Один из частных случаев нейронной сети – сверточная нейронная сеть. Особенностью сверточной нейронной сети является то, что в ней в операции свертки используется ограниченная матрица, двигающаяся по входному слою
и формирующая после каждого движения сигнал активации нейрона следующего слоя. Для всех нейронов используется одна и та же матрица, которую называют ядром свертки.
Бустинг – это метод, который заключается
в обучении слабых классификаторов для получения более сильного классификатора. Обычно при таком методе каждому объекту присваивается определенный вес, который связан с точностью обучения. После того как слабый классификатор добавлен, происходит перерасчет весовых коэф-фициентов – вес каждого из объектов пересчитывается таким образом, что неверно классифицированные объекты получают больший вес, а правильно – меньший вес. Далее идет процесс нормализации, чтобы все веса в сумме были равны единице, и процесс идет заново. Таким образом, в следующей итерации обучение в большей степени фокусируется на объектах, которые были ошибочно классифицированы.
В данной работе выполнено сравнение различных методов машинного обучения для выяснения наиболее эффективного подхода к задаче автоматической классификации инцидентов. Каждый инцидент состоит из перечня атрибутов, каждый из которых имеет вид «атрибут-значение». Так как список атрибутов очень велик, выбраны только самые основные, количество которых достаточно для эффективной векторизации (табл. 1).
Таблица 1
Table 1
Список выбранных атрибутов с примерами значений
List of selected attributes with example values
Статус Критичность Объект Класс объекта Показатель MSG
OPEN MINOR server.ru@vm-16401_server@Processor VSM_CPU_CNTR Total CPU Utilization VMware CPU Container Total CPU Utilization >= 80 % for 10 min.
OPEN MAJOR service:[service]: Errorsrequests ZabbixDefaultClass – Apiman: Errors request in API service more than 5 on server.ru
OPEN MAJOR service:[service]: Errorsrequests ZabbixDefaultClass – Apiman: Errors request in API
service/account-charges more than 5 on server.ru
OPEN MINOR server.ru@vm-3801_server@Processor VSM_CPU_CNTR Total CPU Utilization VMware CPU Container Total CPU Utilization >= 80 % for 10 min.
OPEN CRITICAL IS: – – Integration Service on ip:port is
disconnected.
OPEN CRITICAL IS: – – Integration Service on ip:port is
disconnected.
OPEN MAJOR ip|Application27 PIM_Port Portstatus Application ip|port ne
dostupennaservere
OPEN MAJOR service:[service]: Errorsrequests ZabbixDefaultClass – Apiman: Errors request in API service more than 5 on server.ru
OPEN MAJOR ip|Application31 PIM_Port Portstatus Application ip|Application31 ne dostupennaservereip
OPEN MAJOR service:[service]: Errorsrequests ZabbixDefaultClass – Apiman: Errors request in API service more than 5 on server.ru
OPEN MAJOR server.ru@vm-8790_vm-ora-odb-22@Processor VSM_CPU_CNTR Total CPU Utilization VMware CPU Container Total CPU Utilization >= 90 % for 10 min.
OPEN MINOR server.ru@vm-2659_infra@Processor VSM_CPU_CNTR Total CPU Utilization VMware CPU Container Total CPU Utilization >= 80 % for 10 min.
Кроме того, перечень данных атрибутов присутствует в пользовательских запросах, которые создаются в консоли инициатора инцидентов по-мимо систем оповещения, поэтому можно объединять разные системы мониторинга в единую систему с автоматизированной классификацией.
Рассмотрим более подробно атрибуты. «Статус» сообщает, актуален ли на данный момент инцидент или он уже устранен (статусы OPEN, CLOSE). «Критичность» отображает, насколько данный инцидент влияет на предоставляемую услугу или ИТ-сервис в целом. «Объект» настраивается вручную и необходим для уточнения вида параметра, по которому произошел инцидент,
а «Класс объекта» показывает модуль системы, по которому проходит проверка метрики. Показатель – конкретная метрика, по которой возник инцидент. «MSG» (сообщение) отображается в системе и необходим для краткого описания инцидента для лучшего восприятия.
Классификация инцидентов
Каждый инцидент можно классифицировать (категоризировать) по типу (превышение допустимых метрик допустимого значения, неработоспособность оборудования и т. д.), по группам, назначенным на устранение инцидента, а также по принадлежности к ИТ-сервису.
Категоризируем сервисы по выполняемой ими роли. Для этого введем иерархическую классификацию, позволяющую наглядно понять природу возникшего инцидента (рис. 3).
Рис. 3. Иерархическое представление сервисов
Fig. 3. Hierarchical representing of services
В качестве первого уровня выступают основные разделения сервисов по выполняемым ими ролям: транспортные системы, операционные системы, безопасность, функциональная доступность, внутренние проблемы системы (самомониторинг). На втором уровне проблемы начинают конкретизироваться – для операционной системы, к примеру, уточняется, относится ли инцидент к системе UNIX или Windows. Третий уровень необязателен для всех систем. Обычно он необходим для точного установления источника инцидента, если это возможно. Так, к примеру, если есть проблема в коммутаторе
в транспортной системе, 3 уровень будет указывать, какой конкретно коммутатор послужил источником проблемы. Для того чтобы исходные данные можно было использовать в машинном обучении, проведем трехуровневую классификацию инцидентов. Пример представлен в табл. 2.
Таблица 2
Table 2
Трехуровневая классификация инцидентов
Three-level classification of incidents
Описание инцидента Web-stranicaurl.ru nedostupna. (Ob''ekt: index.html)
Операционная категоризация (уровень 1) Транспортные системы
Операционная категоризация (уровень 2) Коммутатор
Операционная категоризация (уровень 3) Недоступен коммутатор (адрес)
В качестве операционной категоризации первого уровня служит назначение системы, которое дает общее представление об инциденте (в примере – «Транспортные системы»). В качестве второго уровня – более точный для классификации атрибут «Коммутатор», который указывает на неполадки
в работе сетевого оборудования. И в качестве третьего уровня выступает атрибут «Причина и адрес коммутатора», который позволяет точно определить источник неполадки. Таким образом, в решении задачи классификации инцидентов для первого уровня выделено 5 уникальных атрибутов, для второго – 10, для третьего – от 3 до 20.
Также для категоризации инцидентов введем дополнительное поле «ИТ-сервис». Инциденты будут классифицироваться по признаку предоставления услуги или же по принадлежности к какой-либо системе, к примеру, «Личный кабинет Ростелеком», «База данных SystemName», «Бухгалтерская система» и т. д.
В качестве системы, в которой будет проводиться классификация, выбрана BMCProactiveNet 9.6 [8]. Она имеет встроенный коллектор событий, который в реальном времени отображает открытые и закрытые инциденты. На рис. 4 представлен коллектор событий с примерами инцидентов, приходящих в систему.
Рис. 4. Коллектор событий с примерами инцидентов
Fig. 4 Event collector with examples of incidents
Подготовка обучающей выборки и параметров методов машинного обучения
В качестве обучающей выборки выступает выгрузка из данной системы, содержащей информацию о 10 000 инцидентов, зафиксированных системой и полностью или частично классифицированных. Все они имеют вид, указанный в табл. 1. Перед составлением обучающей выборки необходимо подготовить исходные данные. Для этого используется мера TF-IDF [9], с помощью которой можно получить оценку важности отдельного слова в контексте одного участка (в данном случае – инцидента) для всего остального потока инцидентов. Данная мера работает по следующему принципу: вес слова, которое несет смысловую нагрузку, пропорционален частоте употребления этого слова в инциденте и обратно пропорционален частоте употребления в остальных документах. Такими словами являются все слова, не являющиеся предлогами, цифрами, местоимениями, междометиями, частицами, именами числительными и т. д. С помощью такого подхода можно преобразовать исходные данные в вектор фиксированной длины. Каждому слову, которое имеет вес, будет присвоен собственный номер, что в итоге позволит получить длину вектора.
В табл. 3 представлены примеры расчета веса для некоторых слов.
Таблица 3
Table 3
Примеры расчета веса слов
Examples of calculating the weight of words
Слово IDF Количество вхождений
web-stranica 1,66 65
VMware 1,81 46
Zapros 1,5 96
Status 1,46 104
Server 0,86 413
Available 2,64 7
Cluster 2,52 8
kod 2,5 9
System 1,88 39
Container 2,9 4
Adapter 2,27 16
После расчета веса слов и последующей векторизации получили вектор длиной 250, который будет подаваться на вход всех исследуемых классификаторов. Это обусловлено количеством ИТ-сервисов (140 сервисов), а также наличием нескольких интегрированных систем, которые также отсылают инциденты в данную систему.
После того как была выполнена начальная подготовка данных, их можно использовать для обучения алгоритмов машинного обучения, в качестве которых будут выступать ранее описанная нейронная сеть [6, 7], сверточная нейронная сеть (CNN) [10] и градиентный бустинг [11].
Нейронная сеть построена в 5 слоев. Во вход-ном слое 250 нейронов, во втором, третьем и четвертом скрытом слое по 30 нейронов, и количество нейронов, равное количеству атрибутов на уровне классификации, – в выходном слое.
Для построения сверточной нейронной сети была выбрана следующая архитектура (рис. 5).
Рис. 5. Архитектура сверточной нейронной сети
Fig. 5. Convolutional neural network architecture
Операция свертки подразумевает, что каждый фрагмент входа поэлементно умножается на матрицу весов, а результат суммируется. Эта сумма является элементом выхода, который называется картой признаков. Взвешенная сумма входов пропускается через функцию активации.
Слой субдискретизации (пулинга) представляет собой нелинейное уплотнение карты признаков, выполняя нелинейное преобразование. Пулинг интерпретируется как разбиение карты признаков (элементы входного вектора, получившиеся после свертки) на более мелкие матрицы, нахождение из них максимальных элементов, т. е. происходит увеличение глубины значений.
Также используем параметр сategorical_crossentropy (категориальная перекрестная энтропия между выходным тензором и целевым тензором
в библиотеке TensorFlow) [12], применяемый при мультиклассовости меток, который вычисляет потерю кросс-энтропии между метками и прогнозами. Он необходим для измерения сходства между прогнозируемым атрибутом и истинным.
Для градиентного бустинга применим следующие параметры: максимальная длина древ – 10; objective='multi:softmax' – установка XGBoost [11] для выполнения мультиклассовой классификации, для которой также необходимо указать количество классов (зависит от уровня классификации, указанного в табл. 2); num_parallel_tree = 1 (увеличение случайного леса); subsample = 0,5 – отношение подвыборки обучающего экземпляра.
После обработки 10 000 инцидентов были построены графики метрик исследованных методов. Также была рассчитана точность рукописного классификатора, на данный момент использующегося в системе. Для оценки точности классификатора использованы метрики F-меры (F-score) [13], которые являются гармоническим средним между точностью и полнотой. Точность системы в пределах класса – это доля инцидентов, действительно принадлежащих данному классу относительно всех инцидентов, которые система отнесла к этому классу. Полнота системы – это доля найденных классификатором инцидентов, принадлежащих классу, относительно всех инцидентов этого класса в тестовой выборке. Оценка работы алгоритмов выполнялась с помощью четырех метрик (Accuracy, Sensitivity, Specifity, Precision) [7, 13]:
– Accuracy – определяет долю правильно классифицированных данных на основе обучающей выборки и тестовых данных;
– Sensitivity (recall) – определяет долю правильно классифицированных данных обучающей выборки относительно общего числа всех правильно классифицированных данных;
– Specifity – определяет долю правильно классифицированных тестовых данных к общему числу всех некорректно классифицированных данных;
– Precision – определяет долю правильно классифицированных данных на основе данных обучающей выборки.
Оценка работы классификаторов приведена
в табл. 4 и на рис. 6.
Таблица 4
Table 4
Результаты работы классификаторов
Classifier performance results
Метрики Градиентный бустинг Нейронная сеть Сверточная нейронная сеть Рукописный классификатор
TN 4 800 4 700 4 750 4 600
FP 250 450 400 500
FN 200 300 250 400
TP 4 750 4 550 4 600 4 500
Accuracy 0,955 0,925 0,935 0,91
Sensitivity 0,96 0,938 0,948 0,918
Specifity 0,95 0,913 0,92 0,902
Precision 0,95 0,91 0,92 0,9
Рис. 6. Оценка работы классификаторов на основе метрик F-меры
Fig. 6. Evaluating the performance of classifiers based on F-measure metrics
Рис. 6 (окончание). Оценка работы классификаторов на основе метрик F-меры
Fig. 6 (ending). Evaluating the performance of classifiers based on F-measure metrics
Лучшие результаты для обучающей и тестовой выборки показал градиентный бустинг – 95 % верно классифицированных инцидентов; в случаях
с нейронной сетью этот показатель составляет 91 %, у сверточной нейронной сети – 92 %. Более низкая точность рукописного классификатора, составляющая 90 %, обусловлена тем, что некоторые из инцидентов не подпадают под его условия и остаются неклассифицированными. Это, к примеру, инциденты по метрикам, которые на данный момент находятся на этапе постановки, или же системные оповещения, автоматически приходящие в систему.
Заключение
Результаты исследования демонстрируют возможность практического применения градиентного бустинга для автоматизированного создания заявок на отладку и устранение неисправностей путем интеграции его с такими системами, как OTRS – открытая система обработки заявок. Еще одним перспективным направлением является применение данной технологии для автоматизированного создания проблем (причину или потенциальную причину одного или нескольких возникающих инцидентов) в консоли управления проблемами