Aspects of modernization of ITSM class information system in software development companies: microservice architecture of the search module of the system

Full Text

ВВЕДЕНИЕ

Одним из важнейших компонентов IT-архитектуры в компаниях, занимающихся разработкой программного обеспечения, является информационная система класса ITSM (ITSM-ServiceDesk, SCCM, Asset Management), далее ITSM-система [6]. Данные решения позволяют эффективно выполнять бизнес-процессы, связанные как с разработкой, так и с сопровождением программного обеспечения. Все сотрудники, задействованные в этих процессах, в большей или меньшей степени взаимодействуют с компонентами ITSM-систем. Производительность и удобство использования решений данного класса имеет доказанную прямую корреляцию с общей эффективностью решений инцидентов, и, вследствие этого, играют решающую роль в росте продаж программного обеспечения и формировании положительной репутации всей организации.

ФУНКЦИОНАЛ ТИПОВЫХ ITSM-СИСТЕМ

В современном мире эффективное решение бизнес-задач зависит от надежности функционирования ИТ-отделов. Для оптимизации и упрощения управления такими подразделениями, в большинстве ITSM-систем используется методология Information Technology Infrastructure Library (ITIL). Как правило, это руководство, целиком или частично является источником технического задания для разработки или модернизации ITSM-систем в компании разработчике программного обеспечения [7; 8]. Следует дополнительно отметить, что из всего обширного функционала, декларируемого стандартом ITIL, исследовательская группа проекта сосредоточилась на изучении функций бизнес-анализа и управления инцидентами. Цель практики бизнес-анализа состоит в том, чтобы проанализировать процессы организации (в данном случае – компании по разработке программного обеспечения) и рекомендовать решения для удовлетворения этих потребностей и/или решения выявленных бизнес-проблем, что должно способствовать созданию ценности для заинтересованных сторон [9]. Цель практики управления инцидентами состоит в том, чтобы свести к минимуму негативное воздействие инцидентов (отклонений, выявленных в ходе исполнения функций ITSM) путем восстановления нормальной работы сервиса как можно быстрее.

В качестве первого этапа исследования были осуществлены мероприятия в рамках функции «бизнес-анализ». На базе полученных в ходе исследования процессов по обработке инцидентов предприятия разработчика программного обеспечения данных был проведен анализ текущих бизнес-процессов, построение модели бизнес-процесса в соответствующей нотации с выявлением перспектив по модернизации полученной модели.

МОДЕЛИРОВАНИЕ И АНАЛИЗ БИЗНЕС-ПРОЦЕССА «ОБРАБОТКА ИНЦИДЕНТОВ ITSM»

В рамках проведенного инжиниринга бизнес-процесса «Решение инцидентов», был получен ряд моделей, а также существенные выводы и рекомендации.

Для общего понимания предмета исследования, составлена схема жизненного цикла инцидента (рис. 1).

 

Рис. 1. Жизненный цикл инцидента

Fig. 1. Incident life cycle

 

Бизнес-процесс «Управление инцидентами», как результат проведенного инжиниринга, показан на приведенных ниже схемах (рис. 2–4).

 

Рис. 2. Бизнес-процесс «Управление инцидентами. Прием заявок и организации команды инцидента. Эскалация инцидента»

Fig. 2. Business process “Incident management. Receiving requests and organizing the incident team. Incident escalation”

 

Рис. 3. Бизнес-процесс «Управление инцидентами. Воспроизводство инцидента»

Fig. 3. Business process “Incident management. Incident reproduction”

 

Рис. 4. Бизнес-процесс «Управление инцидентами. Решение инцидента. Рецензирование инцидента»

Fig. 4. Business process “Incident management. Incident resolution. Incident review”

 

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

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

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

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

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

Проведенный анализ бизнес-процесса привел к пониманию о наличии существенного недостатка реализуемой в рамках эксплуатации ITSM-системы функции «Управление инцидентами».

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

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

В проведенном исследовании было определено, что главной причиной обнаруженной проблемы практически во всех случаях ее возникновения является низкое качество и слабый функционал модуля «Поисковая система инцидентов» современных ITSM-систем. После составления запроса и отправки его в базу знаний модуля, сотрудник получает информацию о неоправданно большом количестве похожих инцидентов, что серьезно затрудняет изучение этих инцидентов с целью принятия объективного решения в каждом конкретном случае. Эта выявленная проблема поиска вызвана тем, что поисковой модуль, встраиваемый производителями в ITSM-системы, не учитывает ключевые слова в комментариях к инциденту, а также не индексирует описание инцидента.

Таким образом, в основу практической части исследования было положено техническое задание на перепроектирование модуля «Поисковая система инцидентов» на базе одной из самых распространенных ITSM-систем в мире Jira Service Management с целью сокращения влияния на бизнес-процесс «Управление инцидентами» выявленного существенного недостатка. Помимо этого, по результатам опроса, проведенного среди сотрудников службы поддержки компаний разработчиков программного обеспечения, эксплуатирующих ITSM-системы и реализующих бизнес-процесс «Управление инцидентами», был сделан вывод о том, что перепроектирование и модернизация поискового модуля используемой ITSM-системы Jira Service Management с большой долей вероятности сократит количество отмененных и «мусорных» инцидентов, что еще больше улучшит (сократит) исследуемую метрику «Время выполнения бизнес-процесса».

АСПЕКТЫ ПЕРЕПРОЕКТИРОВАНИЯ (МОДЕРНИЗАЦИИ) ПОИСКОВОГО МОДУЛЯ ITSM-СИСТЕМЫ

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

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

Для удобства разработки и поддержки разрабатываемого решения было принято решение спроектировать ряд микросервисов (табл. 1):

• корпоративный чат-бот;
• подсистема прослушивания входящих сообщений;
• подсистема определения намерений пользователя;
• обработчик события;
• сервисы извлечения данных;
• подсистема хранения данных.

 

Таблица 1

Описание микросервисов разрабатываемого модуля [Description of microservices of the module under development]

Микросервис [Microservice]	Назначение [Destination]	Внешние зависимости (3rd party) [External dependencies (3rd party)]	Среда реализации [Implementation environment]
Корпоративный чат-бот [Corporate chatbot]	Взаимодействие конечного пользователя с разрабатываемым модулем [End-user interaction with the module]	Webex	–
Микросервис прослушивания входящих сообщений [A microservice for listening to incoming messages]	Websocket, который прослушивает все входящие события и перенаправляет их в подсистему определения намерений пользователя [Websocket, which listens to all incoming events and forwards them to the user intent detection subsystem]	–	JavaScript
Микросервис определения намерений пользователя [User Intent Detection Microservice]	Используется для анализа произошедших событии и направляет его на соответствующий обработчик. В рамках опытной эксплуатации для данной подсистемы используется строго определенное соответствие между ключевыми действиями пользователя и обработчиками [Used to analyze the occurred events and directs it to the appropriate handler. In the framework of pilot operation for this subsystem a strictly defined correspondence between the key user actions and handlers is used]	Rasa, Flask	Python
Обработчик события [Event handler]	Микросервис отвечает за обработку конкретного события, которое инициировал пользователь [The microservice is responsible for handling a specific event that the user initiated]	–	Python
Микросервис извлечения данных [Data extraction microservice]	К микросервису относятся все внешние зависимости, с помощью которых возможен поиск, извлечение и распознавание данных из внешних систем [A microservice includes all external dependencies that can be used to search, retrieve and recognize data from external systems]	Elastic Search	–
Микросервисы хранения данных [Data storage microservices]	Отвечают за хранение и обработку данных [Responsible for data storage and processing]	PostgreSQL, MinIO	–
Оркестратор [Orchestrator]	Необходим для планирования и масштабирования вызовов отдельных функций системы для разных пользователей в многопользовательском режиме работы [Required for scheduling and scaling calls to individual system functions for different users in a multi-user operation mode]	Airflow	–

 

В процессе проектирования микросервисной архитектуры для модуля было использовано следующее программное обеспечение:

• Jenkins – информационная система, позволяющая обеспечить процессы непрерывной интеграции и доставки программных решений [10];
• Git – система контроля версий [11];
• Kubernetes – информационная система для автоматизации развертывания, масштабирования и управления контейнерными приложениями [12].

В качестве демонстрации результатов проведенного проектирования, ниже будет показана схема взаимодействия интерфейсов спроектированного модуля (рис. 5). Помимо упомянутых в табл. 1 микросервисных компонентов и дополнительных программных средств микросервисной архитектуры, в схеме приведены еще два объекта: Подсистема логирования и Подсистема мониторинга. Экземпляры этих объектов присутствуют в каждом микросервисе приведенной архитектуры. Данные компоненты предоставляют ограничения и правила, которыми руководствуются все связанные модули, с целью унификации команды и процессов внутри архитуктуры.

 

Рис. 5. Схема взаимодействия микросервисов разрабатываемого модуля и внешних систем

Fig. 5. Scheme of interaction between microservices of the developed module and external systems

 

В качестве следующего этапа проекта модернизации модуля планируется развертывание и опытное тестирование спроектированной микросервисной архитектуры с замером и оценкой динамики изменения, выявленной в ходе исследования бизнес-процесса ключевой метрики «Время выполнения бизнес-процесса».

ВЫВОДЫ

В ходе проведенного исследования реализации одной из ключевых функций ITSM-систем (Управление инцидентами) при эксплуатации в предприятии разработчике программного обеспечения был выявлен существенный недостаток. Он связан с неприемлемым временем выполнения поиска решения инцидента средствами современных ITSM-систем. Причина возникновения этого недостатка – недостаточно качественный поисковой модуль ITSM-систем. Глубокая модернизация существующего подхода к поиску решений инцидентов может качественно улучшить всю функцию управления инцидентами в рамках ITSM-систем.

ЗАКЛЮЧЕНИЕ

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

About the authors

Mikhail V. Smirnov

MIREA – Russian Technological University

Author for correspondence.
Email: mikhaelsmirnov@gmail.com
ORCID iD: 0000-0001-5018-2963
SPIN-code: 4990-7320

Cand. Sci. (Econ.); associate professor, KB-9 Department

Russian Federation, Moscow

Evgenii S. Mityakov

MIREA – Russian Technological University

Email: mityakov@mirea.ru
ORCID iD: 0000-0001-6579-0988
SPIN-code: 5691-8947

Dr. Sci. (Econ.), Professor, KB-9 Department

Russian Federation, Moscow

Anton G. Makhov

NetCracker LLC

Email: antonmahov@yandex.ru
ORCID iD: 0009-0003-0107-6293

software engineer

Russian Federation, Moscow

References

Supplementary files