CC BY
75
// Труды 16-ой Междунар. конф. по компьютерной графике и ее приложениям -Графикон-2006. - Россия, Новосибирск, 1-5 июля 2006 г. - С. 182-191. 12. Симоненко З.Г., Ткалич В.Л. Использование программ численного решения некоторых задач эллипсометрии в учебном процессе // Труды конф. «Оптика и образование». - СПб, 16-17 октября 2002 г.
Симоненко Зинаида Григорьевна
Студеникин Олег Леонидович
Елисеев Олег Валерьевич
Санкт-Петербургский государственный университет информационных технологий, механики и оптики,, кандидат технических наук, доцент, [email protected]
Санкт-Петербургский государственный университет информационных технологий, механики и оптики, инженер, [email protected] Санкт-Петербургский государственный университет информационных технологий, механики и оптики,, аспирант, [email protected]
УДК 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;
- формирование технологий портирования 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.
Гусарова Наталия Федоровна
Иванов Роман Владимирович Михайленко Алексей Евгеньевич
— Санкт-Петербургский государственный университет информационных технологий, механики и оптики, кандидат технических наук, доцент, [email protected]
Санкт-Петербургский государственный университет информационных технологий, механики и оптики, ассистент, [email protected]
— Санкт-Петербургский государственный университет информационных технологий, механики и оптики, студент, [email protected]
