Delist.ru

Автоматизация процессов обработки заявок в системах поддержки пользователей корпоративных информационных систем (22.10.2010)

Автор: Талызин Дмитрий Геннадьевич

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

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

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

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

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

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

Содержание работы

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

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

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

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

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

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

Для моделирования сетей Петри существует множество программ, например PN Editor, Tina, CPN Tools. Они предоставляют разные возможности для разных целей. В диссертации для создания временной модели раскрашенной сети Петри использована программа CPN Tools, представляющая собой специальную моделирующую систему, которая использует язык сетей Петри для описания моделей.

В предложенной модели запрос – это множество, состоящее из трех элементов типа INT. Эти элементы обозначены: src – важность запроса, dst - обработчик и d – тип запроса. Напомним, что переменная src может принимать значения от 0 до 4. Пользователь при оформлении запроса выбирает степень важности 0-автоматический выбор, 1-чрезвычайно важно, 2-высокая, 3-средняя, 4-обычная. Так же пользователь выбирает обработчика, к которому он хочет направить свой запрос. Значения переменной dst лежит в диапазоне 0 – 4 и означает: 0-автоматический выбор, 1-администратор, 2-экспертная система, 3-система обновлений, 4-система устранения неполадок. Что же касается переменной d – это тип запроса, переменная лежит в диапазоне 0 – 4, и имеет значения 0-автоматический выбор, 1-вопрос, 2-обновление ПО, 3-неполадки ПО, 4-неполадки оборудования.

В модели запросы обозначены фишками вида (src,dst,d). На вход (input) нашей модели поступают запросы, далее регистрируются переходом registr. В зависимости от важности запросы передаются в ту или иную позицию. Например, src=1 запрос попадает в позицию first и так далее по аналогии.

На рис.1 фишки изображаются в виде: 1` (0,2,4) – это обозначает, что системе будет направлена одна фишка типа (0,2,4).

Рис.1 Схема построения очереди запросов.

Далее из позиции first запрос передается в буфер. Так же на рис.1 показано построение очереди на обработку. К примеру позиция запрос из позиции third не может быть обработан раньше, чем запрос из позиции second потому, что пока позиция second не освободится переход send to second не передаст запрос.

Далее из буфера запросы передаются обработчикам, в зависимости от значения переменной dst.

Из позиции choose запросы передаются переходам в зависимости от их типа. Из d=0 перехода auto choose запрос идет в буфер запросов администратора. При d=1 из перехода question запрос передается экспертной системе – expert buf. При d=2 из перехода soft update запрос идет к системе обновлений – update buf. При d=3 из перехода soft bug запрос идет к системе устранения неполадок – un buf. При d=4 из перехода hard defects запрос идет к администратору – admin buf.

Запросы попадают в позицию admin buf, далее передаются переходу search – он моделирует поиск и подготовку ответа для пользователя. Далее ответ отсылается пользователю – переход receive. А пользователь уже либо удовлетворяется ответом администратора, тогда срабатывает переход success или не удовлетворяется, тогда работает переход bad result и запрос направляется заново к администратору. Выбор перехода success или bad result в модели происходит случайным образом. Все успешно обработанные и закрытые запросы от администратора попадают в позицию finish1. Оставшиеся три обработчика – экспертная система, система устранения неполадок, система обновлений работают по одинаковому принципу. Рассмотрим более детально на примере системы устранения неполадок:

Рис.2 Обработка запроса системой устранения неполадок.

Далее, запрос поступает в буфер системы устранения неполадок, которая ищет по своей базе случай соответствующий текущему. Если находит, то запрос передается в переход found, если не находит, то в переход not found, откуда он попадает уже к администратору. Из перехода found – т.е. когда найдет соответствующий инцидент в базе нашей системы, запрос передается на обработку и выполнение.

После окончания действий система оповещает об этом пользователя и он в интерфейсе ситемы, либо закрывает свой запрос (success2) – если его все устраивает – либо, если инцидент не исчерпан, передает его администратору – это переход bad result. Успешно решенные инциденты накапливаются в переходе finish4. Далее, при помощи построенной временной модели определяется среднее время обработки запроса каждым нашим обработчиком, для этого проведено 15 экспериментов на каждого обработчика.

Таблица 1

12 302 74 880 1266

13 818 762 460 1137

14 539 223 354 777

15 536 753 733 587

Среднее время обработки 1-го инцидента, [сек] 543,8666667 370,7333333 566,0666667 780,066667

Представим эти данные графически, рис.4

Рис.3 Среднее время обработки каждым обработчиком

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

Тобр = tср.адм+tср.эксп.сис.+tср.сис.обн.+

+tср.сис.устр.неисп./4 = 564 сек. (1)

За день система в среднем может успешно обработать N= 86400/564 = 153 заявок от пользователей. Учитывая, что обработчики могут работать в параллельном режиме реальное количество обработанных заявок будем считать по формуле:

Np=N*4*Kсис., (2)

где Kсис. – это коэффициент качества обработки запросов всей системой.

Этот показатель и среднее время обработки запроса системой будут расти с ростом базы знаний экспертной подсистемы, подсистемы устранения неисправностей, подсистемы обновлений.

загрузка...