Методическое пособие 719

Литература

1.Пашуева, И.М. Моделирование и анализ подсистемы управления центрами быстрого реагирования с помощью сетей Петри / И.М. Пашуева, С.М. Пасмурнов // Вестник Воронежского государственного технического университета. 2011. Т. 7. № 9. С.106-109.

2.Пашуева, И.М. Применение сетей Петри в моделировании подсистемы управления центрами быстрого реагирования / И.М. Пашуева, С.М. Пасмурнов // Системы управления и информационные технологии: научно-технический журнал. 2011. №4.1(46). С. 162-166.

3.Пашуева, И.М. Моделирование работы распределенной сети служб быстрого реагирования с использованием функции агрегирования / И.М. Пашуева // Физико-математическое моделирование систем: материалы XIII междунар. семинара. Воронеж, 2015. Ч. 2. С.65-68.

4.Пашуева, И.М. Моделирование процессов принятия оперативных управленческих решений в системе управления центрами служб быстрого реагирования/ И.М. Пашуева // Физико-математическое моделирование систем: материалы XIII междунар. семинара. Воронеж, 2015. Ч. 2. С.69-73.

5.Пашуева, И.М. Имитационной моделирование системы управления центрами служб быстрого реагирования с использованием многокритериальных оценок / И.М. Пашуева // Физико-математическое моделирование систем: материалы XIII междунар. семинара. Воронеж, 2015. Ч. 2. С.74-78.

6.Пашуева, И.М. Моделирование процессов перераспределения экипажей служб быстрого реагирования при возникновении чрезвычайной ситуации на отдельном участке обслуживания // Интеллектуальные информационные системы: материалы конференции, Воронеж, 2018. Ч2. С. 33-36.

7.Пашуева, И.М. Описание и оценка эффективности подсистемы поддержки принятия управленческих решений в условиях неопределенности с применением математической модели на основе оценки рисков на примере работы центра бы-

строго реагирования / И.М. Пашуева, С.М. Пасмурнов, А.В. Бондарев // Вестник Воронежского государственного технического университета, 2017. Т. 13. Вып.

6.С.7-12.

8.Пашуева, И.М. Моделирование процессов управления центром быстрого реагирования в GPSS / И.М. Пашуева // Математическое и компьютерное моделирование, информационные технологии управления: сб. тр. Школы для студентов, аспирантов и молодых ученых «МКМИТУ-2016». Воронеж, 2016. С. 147-152.

9.Пашуева, И.М. Особенности разработки программного комплекса управления центром догоспитальной медицинской помощи. / И.М. Пашуева // Математическое и компьютерное моделирование, информационные техноло-гии управления: сб. тр. Школы для студентов, аспирантов и молодых ученых «МКМИТУ2016». Воронеж. 2016. С. 144-147.

ФГБОУ ВО «Воронежский государственный технический университет», Россия

40

УДК 519.16

Н.В. Старостин, И.Н. Хапаев

ПРОГНОЗ ТРУДОЕМКОСТИ ИНДИВИДУАЛЬНЫХ ЗАДАЧ КОММИВОЯЖЕРА НА ОСНОВЕ МЕТОДОВ МАШИННОГО ОБУЧЕНИЯ

Для современных наукоемких технологий проблема прогнозирования затрачиваемых вычислительных ресурсов при поиске решений сложных задач является актуальной. В работе на примере классической задачи поиска минимального гамильтонова цикла (задачи коммивояжера) на ориентированном графе сделана попытка спрогнозировать трудоемкость решения задачи классическим алгоритмом Литтла [1]. Под трудоемкостью решения индивидуальной задачи будем понимать число порожденных алгоритмом ветвей и границ поискового дерева решений [2]. В работе [3] на основании масштабного вычислительного эксперимента была сформулирована гипотеза о том, что вид распределения трудоемкости на семействах множеств индивидуальных задач не зависит от размера задач. Это дает основание для поиска обобщающих характеристик (набора признаков) классов индивидуальных задач, которые позволят распределить «сложные» задачи от «простых».

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

Реализация первого этапа предполагает вовлечение исследователя, в задачу которого входит определение возможных обобщающих характеристик. Такими признаками являются, например, размер задачи, распределение значений коэффициентов в исходной матрице расстояний, интервалы значений коэффициентов в строках и столбцах матрицы и т.д. Эти данные и будут явля ться признаками, которые предлагается описывать в виде вещественных векторов (векторы-признаки). В качестве первоначального набора признаков были выбраны векторы-признаки, которые вычислялись по матрице расстояний: 1) вектор минимальных элементов по строкам матрицы расстояний; 2) вектор минимальных элементов по столбцам; 3) вектор дисперсии по строкам; 4) вектор дисперсии по столбцам; 5) вектор, описывающий распределение приведенных значений матрицы расстояний.

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

41

ментах генерировались задачи на 30 городах, расстояния между городами задавались целочисленными значениями от 1 до 3000. Множество размеченных данных включало 50000 индивидуальных задач с рассчитанными признаками.

Третий этап реализован на базе технологии машинного обучения – проверка прогнозной способности выбранного набора обобщающих характеристик заключается в выборе модели обучения, тренировки, тестирования и оценки качества функционирования прогнозной модели. В качестве моделей обучения были использованы [4]: Fast Tree, Fast Forest, Fast Tree Tweedie, Poisson Regression, Stochastic Dual Coordinate Ascent(SDCA), Generalized Additive Models(GAM). Все размеченные данные были разделены на две группы: обучающая (49000 задач) и контрольная (1000 задач). В качестве метрик оценки обучения были использованы следующие метрики [4]: R2 Score, Absolute Loss, Squared Loss, Root Square Mean Loss (RMS Loss).

Описанный инструментарий реализован на базе .NET Core Framework на языке C#. В качестве хранилища индивидуальных задач выбрана база данных PostgreSQL. Для обучения и тестирования моделей использована библиотека

ML .NET [4].

Результаты вычислительных экспериментов

По результатам проведенных экспериментов (см. таблицу) в качестве модели обучения выбрана модель Fast Tree с абсолютной ошибкой 185,5. При тестировании обученной модели на 1000 примерах индивидуальной задачи коммивояжера точность предсказания составила 54%. Тестирование с использованием остальных моделей показывало результаты с точностью менее 50%.

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

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

42

Литература

1.Little J.D.C., Murty K.G., Sweeney D.W., Karel C. An algorithm for the traveling salesman problem // Operation Research. 1963. №11. P. 792-989.

2.Knuth D.E. Estimating the efficiency of backtracking programs // Mathematics of Computing. 1975. V. 29. P.121-136

3.Головешкин, В.А. Вероятностный прогноз сложности индивидуальных задач коммивояжера на основе идентификации распределения сложности по экспериментальным данным / В.А. Головешкин, Г.Н. Жукова, М.В. Ульянов, М.И. Фомичев // Автоматика и телемеханика. 2018. № 7. C. 149–166.

4.Ресурсы по машинному обучению. Руководство по ML.NET. (web page). – https://docs.microsoft.com/ru-ru/dotnet/machine-learning (accessed April, 2019).

ФГБОУ ВО «Национальный исследовательский Нижегородский государственный университет им. Н.И. Лобачевского», Россия

УДК 681.3

Э.И. Воробьев, А.Н. Корякин

РАЗРАБОТКА АЛГОРИТМА ОБРАБОТКИ ВХОДЯЩИХ ОПОВЕЩЕНИЙ В ПОДСИСТЕМЕ МОНИТОРИНГА И АНАЛИЗА РАБОТЫ ОБОРУДОВАНИЯ

ВРАСПРЕДЕЛЕННОЙ СЕТИ ТЕЛЕКОММУНИКАЦИОННОЙ КОМПАНИИ

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

Каждая современная телекоммуникационная компания не может обходиться без подсистемы мониторинга и анализа работы оконечного оборудования своей сети. Такие системы обычно делятся на «Performance management» и

«Fault management». Performance management включает в себя централизованное отслеживание и использование метрик, полученных с отслеживаемого оборудования [1]. Fault management представляет из себя комплекс программных и аппаратных средств, предназначенных для выполнения действий в случаях отказа. Важнейшей частью подсистемы fault management является механизм оповещений, основная задача которого является довести до сведения системных инженеров о каких-либо аномалиях, произошедших на сети. Большинство современных мониторинговых систем имеют встроенный механизм оповещений.

Источниками оповещений могут являться как правила в Performance management, так и оповещения от внешних систем [2]. Кроме того, источником может являться само устройство, которое отсылает специальный пакет по протоколу SNMP, называемый SNMP-трап. Таким образом, подсистема может полу-

43

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

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

Алгоритм необходимо выполнять каждый раз при приходе оповещения перед добавлением его в базу данных. Разработанный алгоритм показан на рисунке.

Структурная схема алгоритма анализа входящих угроз

На рисунке показана схема, состоящая из 15 блоков. Входными данными для алгоритма является угроза. Ее ввод показан в блоке 2.

44

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

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

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

Если связь установлена, тогда необходимо исследовать тип угрозы. Это исследование показано на рисунке в блоке 6.

Если угроза не имеет тип «очистка», то принято обновлять время последнего воспроизведения проблемы. Это обновление показано в блоках 7 и 8.

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

Если ни одно из текущих оповещений не соответствует пришедшей угрозе, тогда необходимо создать новое оповещение на основе данных, полученных из угрозы. Этот процесс показан на рисунке в блоках 11, 12, 13.

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

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

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

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

45

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

Простейшим примером применения этой технологии является root-cause- analysis. Это специальные алгоритмы, предназначенные для построения зависимостей между отдельными оповещениями. Таким образом, система может делать предположения о том, что, например, скорость на интерфейсе А устройства Б равна нулю потому что интерфейс А переведен в положение «выключено». С точки зрения классической системы эти два оповещения не связаны, так как у них не совпадают индикаторы. Пользователь в этом случаи получит два несвязанных оповещения и может потратить время на поиск неисправности основываясь на оповещении, говорящем о нулевой скорости, а не о том, что интерфейс выключен.

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

Особенно полезен root-cause-analysis, когда выполняется работа с оповещениями на основе SNMP-трапов от устройств. Очень часто, именно такие оповещения содержат в себе самую полезную информацию и указывают на корень проблемы.

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

Литература

1.Самуйлов, К. Е. Сети и телекоммуникации: учебник и практикум для академического бакалавриата / К. Е. Самуйлов, И. А. Шалимов, Д. С. Кулябов.

—Москва: Юрайт, 2018. – 363 с.

2.Уилсон, Эд. Мониторинг и анализ сетей. Методы выявления неисправностей / Эд. Уилсон Лори, 2002. – 350 с.

3.Комашинский, В.И. Нейронные сети и их применение в системах управления и связи / В.И. Комашинский, Д.А. Смирнов. – М.: Горячая линия – Телеком, 2002. – 268 с.

ФГБОУ ВО «Воронежский государственный технический университет», Россия

46

УДК 681.3

Д.В. Романов

РАЗРАБОТКА АЛГОРИТМА ОБНАРУЖЕНИЯ МОШЕННИЧЕСКИХ ДЕЙСТВИЙ ДЛЯ ЛОГИСТИЧЕСКОЙ ПОДСИСТЕМЫ МОНИТОРИНГА АКТИВНОСТИ КЛИЕНТА

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

Первоначально такие системы строились на простейших эвристиках (правилах), при срабатывании которых действие клиента блокировалось. Количество таких эвристик может достигать порядка 200, однако зачастую некоторые из них оказываются ничем не подкреплены, часть – дублируют или являются следствие одного из другого [1]. А из-за того, что с каждым годом количество типов махинаций возрастает, их становится все труднее поддерживать, более того идет тенденция к снижению качества подобных проверок, вследствие чего заведомо мошенническая транзакция не отлавливается, а безопасная – попадает на проверку.

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

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

Опишем алгоритм работы облачного веб-сервиса. Клиент взаимодействует в сети с некоторым логистическим сайтом, который частично запоминает все совершаемые действия, а также общедоступные сетевые данные клиента. На определенные действия может потребоваться проверка, и при возникновении

47

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

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

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

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

Рис. 1. Схема проверки данных клиента

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

1)страны авторизации пользователя;

2)страны, заблокированные для операций с лицевым и банковским сче-

том;

3) страны адресов доставки.

48

Простые эвристики – некоторые условия по принципу продукционной модели «ЕСЛИ-ТО», при выполнении хотя бы одной из них транзакция отмечается как небезопасная и тут же блокируется. Эвристики с жесткой логикой не должны быть слишком сложными, упрощение позволит сделать их более прозрачными. Примеры подобных эвристик:

1)добавление большого количества адресов;

2)частый заход из разных мест (по IP-адресу);

3)достижение лимита по денежным средствам;

4)оплата различными способами;

5)несоответствие плательщика карты и данных профиля.

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

Создавая модель подсистемы, необходимо определить, какие именно данные будут участвовать в анализе. Был определен список основных критериев, которые прямым образом влияют на подозрительность транзакций [1]:

1)reg_country – 2-буквенный код страны клиента;

2)auth_false – кол-во неуспешных попыток авторизации;

3)auth_total – кол-во авторизаций;

4)addr_diff – кол-во адресов, не из региона проживания;

5)addr_false – кол-во адресов в запрещенные страны;

6)addr_total – общее кол-во адресов на аккаунте;

7)pack – успешно доставленных посылок;

8)soc – есть привязка социальных сетей (да/нет в формате 1/0);

9)ph – есть привязанный мобильный телефон (да/нет);

10)card_country – страна банка эмитента;

11)card_ip – страна совершения платежа;

12)pay_false – неудачных попыток оплаты;

13)pay_total – общее кол-во платежей на аккаунте;

14)result – является ли транзакция подозрительной (да/нет).

Рис. 2. Фрагмент тестовой выборки

Для примера расшифруем строку данных:

RU,4,57,1,0,2,0,1,0,USA,DE,1,1,1

49