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

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

CC BY
396
76
i Надоели баннеры? Вы всегда можете отключить рекламу.
Ключевые слова
СЛУЖБА ТЕХНИЧЕСКОЙ ПОДДЕРЖКИ / TECHNICAL SUPPORT SERVICE / ОБРАБОТКА ЗАЯВКИ / REQUEST PROCESSING / ТЕХНИЧЕСКАЯ ДИАГНОСТИКА / TECHNICAL DIAGNOSTICS / CMDB

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Гусарова Наталия Федоровна, Иванов Роман Владимирович, Михайленко Алексей Евгеньевич

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

i Надоели баннеры? Вы всегда можете отключить рекламу.

Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Гусарова Наталия Федоровна, Иванов Роман Владимирович, Михайленко Алексей Евгеньевич

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

INFORMATION MAINTENANCE OF REQUEST PROCESSING IN TECHNICAL SUPPORT SERVICE

The problems of technical support service of computer devices in middle size companies (or separate de-partments of large companies) are considered. Developed data storage structure for information maintenance system of request registration and processing is described.

Текст научной работы на тему «Информационное сопровождение обработки заявок в службе технической поддержки»

// Труды 16-ой Междунар. конф. по компьютерной графике и ее приложениям -Графикон-2006. - Россия, Новосибирск, 1-5 июля 2006 г. - С. 182-191. 12. Симоненко З.Г., Ткалич В.Л. Использование программ численного решения некоторых задач эллипсометрии в учебном процессе // Труды конф. «Оптика и образование». - СПб, 16-17 октября 2002 г.

Симоненко Зинаида Григорьевна

Студеникин Олег Леонидович

Елисеев Олег Валерьевич

Санкт-Петербургский государственный университет информационных технологий, механики и оптики,, кандидат технических наук, доцент, ZGSim@yandex.ru

Санкт-Петербургский государственный университет информационных технологий, механики и оптики, инженер, oleg-studenikin@yandex.ru Санкт-Петербургский государственный университет информационных технологий, механики и оптики,, аспирант, ov1983@yandex.ru

УДК 004.89; 681.3

ИНФОРМАЦИОННОЕ СОПРОВОЖДЕНИЕ ОБРАБОТКИ ЗАЯВОК В СЛУЖБЕ ТЕХНИЧЕСКОЙ ПОДДЕРЖКИ Н.Ф. Гусарова, Р.В. Иванов, А.Е. Михайленко

Рассмотрены проблемы организации службы технической поддержки компьютерного оборудования в фирмах среднего масштаба (или отдельных подразделениях крупных компаний). Описывается разработанная структура хранения данных для информационной системы сопровождения приема и обработки заявок. Ключевые слова: служба технической поддержки, обработка заявки, СМББ, техническая диагностика.

Введение

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

Анализ подходов к организации СТП

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

Рассматривая МС как сложную техническую систему (СТС) [1—3], правомерно ставить задачу построения СТП как задачу технической диагностики [4, 5]. Традиционной [1, 4] для таких задач является теоретико-множественная трактовка системы как отношения на множествах, т. е. в виде кортежа

В = <Т, X, У, 2, ¥, Ь >. (1)

Здесь T - множество моментов времени, в которые наблюдается система; X, Y -множество входных и выходных сигналов, соответственно; Z - множество состояний системы, а операторы переходов F и выходов L реализуют отображения

F: T х X х Z ^ Z; (2)

L: T х X х Z ^ Y. (з)

Для получения конструктивных результатов вводятся следующие допущения: (1.а) наблюдаемость МС - существование отображения (3), которое при фиксированных теТ (здесь T = {т} œ T ) и x(t)eX обеспечивает возможность на основе известного выходного процесса y(t)e Y определить неизвестные состояния объекта z(t)eZ; (1.б) агрегирование - возможность разбиения бесконечного, в общем случае, множества состояний Z МС на конечное и небольшое число классов Е - множество заданных видов технического состояния (ТС). При этих допущениях задача технической диагностики МС моделируется обобщенной диаграммой

L п у

TxXxZ—>Y—>Е—*- S

<Н VA . (4)

Y/Q

Здесь

П : Y^E (5)

- отношение идентификации, которое содержательно состоит из отношения классификации, т.е. разбиения (факторизации) множества Y на ряд непересекающихся классов (например, состояния, вызванные дефектом i-й подсистемы),

0 : Y^ Y/Q, (6)

и соотнесения полученного фактор-множества Y/Q с множеством Е, т.е.

к : E^Y/Q, (7)

у: Е ^ S (8)

- отношение, учитывающее вероятностные характеристики возможных ошибок при контроле, а - отображение, уточняющее сформированное фактор-множество Y/Q по результатам контроля. Задачи типа (4) решаются сравнительно легко, в том числе даже аналитически, в рамках сформулированных выше допущений (1.а) и (1.б) и при условии априорно известных отображений (6) и (7).

Альтернативу подходу технической диагностики предоставляет подход библиотеки ITIL (англ. Information Technology Infrastructure Library) [6], в которой деятельность СТП рассматривается как составная часть управления ИТ-инфраструктурой предприятия [7, 8]. Базовым понятием здесь является инцидент - любое событие, не являющееся частью стандартных операций по предоставлению услуги, которое привело или может привести к снижению качества этой услуги. Согласно ITIL, для управления инцидентами в состав системы управления ИТ-инфраструктуры предприятия должны входить: (2.а) база данных управления конфигурациями (Configuration Management Database, CMDB) - репозиторий технологических данных об объектах ИТ-инфраструктуры, их взаимосвязях и истории изменения, сущностями которой являются, в частности, ИТ-сервисы, компьютерное оборудование, программное обеспечение, ролевые функции акторов МС, используемые формы документации; (2.б) база знаний по проблемам/известным ошибкам, описывающая способ распознавания инцидентов, имеющиеся решения и обходные пути; (2.в) система регистрации, отслеживания и мониторинга инцидентов.

Очевидно, что компоненты (2.а)-(2.в) на концептуальном уровне призваны обеспечить механизм ведения метаданных об ИТ-инфраструктуре и построить интегрированную платформу управления МС. Однако на технологическом уровне такие обобщенные

системы оказываются чрезвычайно сложными, и, как показывает анализ решений ведущих компаний (Hewlett-Packard [9], IBM [10], Microsoft [11]), концепция ITIL практически реализуется с существенными ограничениями, в том числе:

(3.а) поддерживаемые ИТ-сервисы конфигурируются с точностью до терминальных сущностей CMDB (1), и отклонения от предписанной конфигурации не допускаются; (3.б) на всех системных уровнях (организационном, программном, аппаратном) пресекается активность акторов МС по внесению изменений в конфигурацию CMDB, а также по несанкционированному выходу во внешние сети.

По существу, тем самым реализуются рассмотренные выше допущения наблюдаемости (1.а) и агрегирования (1.б) МС, характерные для систем технической диагностики. Однако упомянутые условия и допущения для многих МС оказываются неправомерными, что связано, в первую очередь, с системной сложностью МС. Наиболее важные проявления системной сложности МС по их генезису можно разделить на две группы - системная сложность технологической среды и системная сложность человеческого фактора (поведения акторов) в составе МС. Рассмотрим их подробнее.

Системная сложность программных продуктов как технологической среды была констатирована еще в 1975 г. [12]. Факторы, обусловливающие эту сложность, специфичны для каждого программного продукта и для конкретной конфигурации МС, причем с развитием ИТ их номенклатура постоянно растет. Приведем некоторые примеры таких факторов:

- у программных продуктов число возможных состояний на порядки величин превышает число состояний компьютеров [12];

- подавляющее большинство компьютеров включены в сети, т. е. работают в режиме открытой системы;

- процессы, происходящие в среде проприетарных программных продуктов ниже уровня API, недоступны для контроля внешнему пользователю;

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

В результате отображение L (3) теряет инъективность, а МС в целом становится не вполне наблюдаемой, т.е. допущение (1.а) не выполняется.

Системная сложность поведения акторов в составе МС является ответом на неполную наблюдаемость технологической среды, в силу которой полная и объективная интерпретация имеющих место технологических ситуаций актору недоступна. Для работы в такой среде каждый актор строит свою систему интерпретаций, которая зависит от текущего контекста, квалификации и предыдущего опыта актора, «встроена в его культурную матрицу» [12] и во многом формируется на уровне глубинных знаний и навыков [14], т.е. является неявной (имплицитной) даже для него самого. Например, типичная фраза пользователя «Не работает Интернет» может соотноситься с огромным спектром возможных технических состояний МС. В результате отношение классификации (6) реализуется не на уровне разбиения, а только на уровне покрытия (с возможностью пересечений), отношение (7) перестает быть взаимно однозначным и, соответственно, диаграмма (4) в целом также теряет однозначность. Кроме того, для многих МС требования (3.а)-(3.б) могут оказаться неприемлемыми по экономическим или организационным соображениям.

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

мулировала опыт квалифицированных специалистов и на этой базе позволила осуществлять большинство операций ТП специалистам более низкой квалификации и/или даже (в определенных пределах) самим акторам МС.

Разработка структуры СМББ для СТП

Приведенные соображения позволяют сформулировать требования к структуре СМОБ для СТП с учетом характерных для фирм факторов неопределенности: (4.а) логическая модель объектов ИТ-инфраструктуры, их взаимосвязей и истории изменения должна быть максимально обобщенной (нейтральной) относительно текущих технологий их использования; (4. б) структура хранения данных должна быть удобна для использования в качестве декларативной части базы знаний создаваемой ИС СТП и в то же время легко адаптироваться к возможным изменениям процедурной части ИС СТП (механизма логического вывода), отражающим специфику поддерживаемого бизнес-процесса; (4.в) структура хранения данных должна быть адаптируемой к текущим изменениям политики ограничений и уровня неопределенностей, принятых в конкретном бизнес-процессе.

Контрагент ]||_Хранит персональную информацию /_ Персона

^ Определяет Роли и Права

ВнешниеПользователи

ВнутрениеПользователи

Подают заявки /

Хранение и

Формирование решений/

Хранение информа

ции об исполнении

Формировани Хранение инф

нформации

е и обработка заявок/ ормации

Заявка

Определяет задачу/

Хранит варианты решений*! Ф°рмир°ваниРешения

Решения 1

Фиксирует задач|и и исполнителя /

Хранит описания решений

Содержит/

Являются частью

План

Участвует в плане /

Хранит информацию о контрагенте

Контрагент

Входит /

Содержит

ИзделиеПрограммаСеть

ПредметЗаявки

Содержит информацию /

Составляется

Создает/

Хранит информацию

Входит /

^ Содержит БазовоеИзделие

Определяет важность/ Приоритеты

Содержит Определяет состояние /

Статусы

Содержит

б

Рис. 1. а - БР-диаграмма базовых сущностей относительно акторов, работающих с заявками; б - БР-диаграмма базовых сущностей, связанных с жизненным циклом

заявки

В соответствии с указанными требованиями разработана структура СМББ. На рис. 1, а, б, представлена логическая структура СМББ верхнего уровня, на рис. 2 - ин-фологическая модель СМОБ разрабатываемой системы.

Требование (4.а) обеспечивается (рис. 1, а, рис. 2) за счет возможности задания любой Персоне, с одной стороны, любого статуса и/или Должности, с другой стороны, Роли. При этом поддерживается иерархия должностей и ролей и их динамическая смена в процессе функционирования ИС СТП. Кроме того, система хранения данных о сущностях ИзделиеПрограммаСеть и БазовоеИзделие (рис. 1, б) поддерживает как ие-

2

2

Р

а

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

Рис. 2. Инфологическая модель базы данных

Рассмотрим обеспечение требования (4.б). В структуре CMDB выделена декларативная часть, обеспечивающая хранение информации о Персонах, Фирмах, изделиях, программах, сетевых настройках (ИзделиеПрограммаСеть) (рис. 2). Процедурная компонента ИС СТП поддерживается частью CMDB, в которую входят такие сущности, как Заявка, ПредметЗаявки, План, БазаЗнаний/проблем, КлючевыеСлова, причем эта часть CMDB может функционировать и модифицироваться независимо от декларативной части. Кроме того, структура CMDB поддерживает различные типы связей, в том числе иерархические, ассоциативные и каузальные [15].

Адаптация структуры хранения данных (требование 4.в) обеспечивается в CMDB посредством различных механизмов. За счет введения сущности Контрагент парируются текущие изменения политики ограничений и изменений структурных связей с привязкой по времени. Адаптация CMDB по уровню неопределенности бизнес-процесса и первоначальной информации о нем производится за счет разделения декларативной и процедурной частей ИС СТП (см. выше). Кроме того, предусмотрена возможность удобного динамического расширения номенклатуры характеристик сущности Базовое-Изделие/Программа на различных иерархических уровнях.

В качестве задач дальнейшего исследования авторы видят:

- изучение возможных эвристических методов и механизмов обработки заявок на младших уровнях поддержки СТП [16];

- обоснование механизмов и критических параметров заполнения CMDB;

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

- формирование технологий портирования CMDB на другие бизнес-процессы;

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

Заключение

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

Литература

1. Охтилев М.Ю., Соколов Б.В., Юсупов Р.А. Интеллектуальные технологии мониторинга и управления структурной динамикой сложных технических объектов. - М.: Наука, 2006. - 410 с.

2. Перегудов Ф.И., Тарасенко Ф.П. Введение в системный анализ. - М.: Высш. шк., 1989. - 367 с. ил.

3. Иванов Р.В., Маятин А.В., Михайленко А.Е. Моделирование процесса обработки заявок в службе технической поддержки сложных технических систем // Научно-технический вестник СПбГУ ИТМО. - 2007. - Вып. 44. - С. 268-274.

4. Дмитриев А.К., Мальцев П.А. Основы теории построения и контроля сложных систем. - Л.: Энергоатомиздат, 1988. - 192 с.

5. Иванов Ю.П., Никитин В.Г., Чернов В.Ю. Контроль и диагностика измерительно-вычислительных комплексов. - СПб: СПбГУАП, 2004. - 98 с.

6. The Official ITIL ® Website [Electronic resource]. - Electronic data. - APM Group Ltd., cop. 2007-2008. \- Режим доступа: http://www.itil-officialsite.com/, своб.

7. Service Support Book - ITIL® Version 2. - London: Office of Government Commerce (OGC): TSO (The Stationery Office), 2000. - 312 p.

8. Service Delivery Book - ITIL® Version 2. - London: Office of Government Commerce (OGC): TSO (The Stationery Office), 2001. - 382 p.

9. Колесов А. HP ITSM и эффективность обслуживания информационных систем предприятий. - Режим доступа: http://www.bytemag.ru/?ID=602758, своб.

10. Система управления ИТ-услугами BMC Remedy IT Service Management. - Режим доступа: http://www.bmc.com/ru, своб.

11. MOF - Microsoft Operations Framework. - Режим доступа: http://www.itsmportal.rU/articles/it-control/2003-12-15%2000:00:00-26.html/, своб.

12. Брукс Ф. Мифический человеко-месяц, или Как создаются программные системы. -М.: Символ-Плюс, 2006. - 304 с.

13. Гусарова Н.Ф., Маятин А.В., Смирнов Ф.А. Обратные задачи в компьютеризированных технологических средах // Научно-технический вестник СПбГУ ИТМО. - 2007. - Вып. 44. - С. 284-294.

14. Гаврилова Т.А., Хорошевский В.Ф. Базы знаний интеллектуальных систем. - СПб: Питер, 2000. - 384 с.

15. Джексон П. Введение в экспертные системы. - М.: Вильямс, 2001. - 624 с.

16. Иванов Р.В., Михайленко А.Е., Гусарова Н.Ф. ITSM в ITIL - структурно-образующий подход к проектированию, внедрению и управлению ИТ-системами класса Help (Service) Desk // Научно-технический вестник СПбГУ ИТМО. - 2008. -Вып. 48. - С. 217-226.

Гусарова Наталия Федоровна

Иванов Роман Владимирович Михайленко Алексей Евгеньевич

— Санкт-Петербургский государственный университет информационных технологий, механики и оптики, кандидат технических наук, доцент, natfed@list.ru

Санкт-Петербургский государственный университет информационных технологий, механики и оптики, ассистент, roman@nevsky30.ru

— Санкт-Петербургский государственный университет информационных технологий, механики и оптики, студент, alexey@mikhaylenko.net

i Надоели баннеры? Вы всегда можете отключить рекламу.