Введение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). Таблица 1Table 1Список выбранных атрибутов с примерами значенийList of selected attributes with example valuesСтатусКритичностьОбъектКласс объектаПоказательMSGOPENMINORserver.ru@vm-16401_server@ProcessorVSM_CPU_CNTRTotal CPU UtilizationVMware CPU Container Total CPU Utilization >= 80 % for 10 min.OPENMAJORservice:[service]: ErrorsrequestsZabbixDefaultClass–Apiman: Errors request in API service more than 5 on server.ruOPENMAJORservice:[service]: ErrorsrequestsZabbixDefaultClass–Apiman: Errors request in API service/account-charges more than 5 on server.ruOPENMINORserver.ru@vm-3801_server@ProcessorVSM_CPU_CNTRTotal CPU UtilizationVMware CPU Container Total CPU Utilization >= 80 % for 10 min.OPENCRITICALIS:––Integration Service on ip:port is disconnected.OPENCRITICALIS:––Integration Service on ip:port is disconnected.OPENMAJORip|Application27PIM_PortPortstatusApplication ip|port ne dostupennaservereOPENMAJORservice:[service]: ErrorsrequestsZabbixDefaultClass–Apiman: Errors request in API service more than 5 on server.ruOPENMAJORip|Application31PIM_PortPortstatusApplication ip|Application31 ne dostupennaservereipOPENMAJORservice:[service]: ErrorsrequestsZabbixDefaultClass–Apiman: Errors request in API service more than 5 on server.ruOPENMAJORserver.ru@vm-8790_vm-ora-odb-22@ProcessorVSM_CPU_CNTRTotal CPU UtilizationVMware CPU Container Total CPU Utilization >= 90 % for 10 min.OPENMINORserver.ru@vm-2659_infra@ProcessorVSM_CPU_CNTRTotal CPU UtilizationVMware 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 представлены примеры расчета веса для некоторых слов. Таблица 3Table 3Примеры расчета веса словExamples of calculating the weight of wordsСловоIDFКоличество вхожденийweb-stranica1,6665VMware1,8146Zapros1,596Status1,46104Server0,86413Available2,647Cluster2,528kod2,59System1,8839Container2,94Adapter2,2716 После расчета веса слов и последующей векторизации получили вектор длиной 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. Таблица 4Table 4Результаты работы классификаторов Classifier performance results МетрикиГрадиентный бустингНейронная сетьСверточная нейронная сетьРукописный классификаторTN4 8004 7004 7504 600FP250450400500FN200300250400TP4 7504 5504 6004 500Accuracy0,9550,9250,9350,91Sensitivity0,960,9380,9480,918Specifity0,950,9130,920,902Precision0,950,910,920,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 – открытая система обработки заявок. Еще одним перспективным направлением является применение данной технологии для автоматизированного создания проблем (причину или потенциальную причину одного или нескольких возникающих инцидентов) в консоли управления проблемами