Размещено на http://www.allbest.ru/

Информационная система мониторинга работы ИТ-инфраструктуры МБУЗ ГБ г. Армавира

Аннотация

информационный мониторинг инфраструктура

В дипломной работе разрабатывается информационная система мониторинга работы ИТ-инфраструктуры. Ее предназначение заключается в решении проблем с мониторингом работоспособности компонентов ИТ-инфраструктуры, который проводит системный администратор отдела АСУ МБУЗ ГБ г. Армавира. Выполнено исследование предметной области, формальное и визуальное моделирование процессов, сформулированы проблемы предметной области. Произведена оптимизация формальной модели и построена функциональная модель оптимизированных бизнес-процессов. Выполнено проектирование информационной системы, сделан выбор средств реализации и описан прототип интерфейса.

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

Реферат

ИНФОРМАЦИОННАЯ СИСТЕМА, DASHBOARD, СТАТИСТИКА, МОНИТОРИНГ, ПАНЕЛЬ ИНСТРУМЕНТОВ

Во введении рассматривается актуальность разработки проекта.

В первом разделе представлены результаты исследования предметной области, ее организационной и функциональной структуры. Рассматриваются процессы мониторинга работоспособности ИТ-инфраструктуры. Проводится формальное моделирование, выделяются проблемы, и формулируется задача работы.

Во втором разделе выполняется оптимизация формальной модели и функциональное моделирование оптимизированных бизнес-процессов с использованием CASE-средств.

В третьем разделе выполняется проектирование информационной системы мониторинга работы ИТ-инфраструктуры. Рассматривается архитектура и структура системы. Определяется структура данных и взаимосвязи между ними.

В четвертом разделе описывается процесс разработки прототипа информационной системы мониторинга работы ИТ-инфраструктуры. Проводится обоснование выбора средств реализации. Описывается прототип интерфейса.

В пятом разделе рассматривается социальный аспект.

В шестом разделе выполняется технико-экономическое обоснование проекта. Рассчитывается ожидаемый экономический эффект от внедрения разработки.

В седьмом разделе описывается безопасность и экологичность проекта.

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

Введение

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

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

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

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

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

Предназначение систем мониторинга, применяемых в МБУЗ ГБ г. Армавира заключается в эффективном достижении целей наблюдения за работоспособностью компонентов ИТ-инфраструктуры, определенных при его создании. Каждая система мониторинга наилучшим образом решает поставленную ей задачу, однако чем больше набор подобных систем, тем выше разрозненность данных и сложнее их обработка. Поэтому актуальной является проблема комплексного разностороннего мониторинга за работоспособностью компонентов ИТ-инфраструктуры.

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

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

Для решения этой проблемы предлагается создание информационной системы мониторинга работы ИТ-инфраструктуры.

1. Исследование деятельности системного администратора МБУЗ ГБ г. Армавира

1.1 Введение в предметную область

МБУЗ ГБ г. Армавира - одно из старейших лечебных учреждений города. Сегодня это многопрофильная клиническая больница, обеспечивающая все виды амбулаторно-поликлинической и стационарно-терапевтической помощи. На базе больницы размещены: городское психосамотическое отделение для инвалидов и ветеранов войны, центр апитерапии, центр прогрессивных медицинских технологий, открыты районные аллергологический и пульманологический кабинеты. В больнице работает 1800 сотрудников из которых половина имеют высшую и первую квалификационные категории (рис.1). В МБУЗ ГБ г. Армавира развернуто около 1000 коек. В составе больницы имеется поликлиника на 1500 посещений в смену, консультативно-диагностическая поликлиника.

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

В 2007 году МБУЗ ГБ г. Армавира подтвердила 1 категорию лечебно-профилактического учреждения по уровню организации оказания медицинской помощи населению.

В своей деятельностью больница руководствуется Конституцией Российской Федерации, Федеральными законами, нормативными документами Министерства здравоохранения и социального развития Российской Федерации, Министерства здравоохранения Краснодарского края.

Виды медицинской помощи, предоставляемой бесплатно в МБУЗ ГБ г. Армавира: первичная медико-санитарная, в том числе неотложная, медицинская помощь; скорая, в том числе специализированная (санитарно-авиационная), медицинская помощь; специализированная, в том числе высокотехнологичная, медицинская помощь.

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

Специализированная, в том числе высокотехнологичная, медицинская помощь предоставляется гражданам в медицинских организациях при заболеваниях, требующих специальных методов диагностики, лечения и использования сложных, уникальных или ресурсоемких медицинских технологий. Медицинская помощь гражданам предоставляется: учреждениями и структурными подразделениями скорой медицинской помощи (скорая медицинская помощь); амбулаторно-поликлиническими учреждениями и другими медицинскими организациями или их соответствующими структурными подразделениями и дневными стационарами всех типов (амбулаторная медицинская помощь); больничными учреждениями и другими медицинскими организациями или их соответствующими структурными подразделениями (стационарная медицинская помощь). Амбулаторная медицинская помощь предоставляется гражданам при заболеваниях, травмах, отравлениях и других патологических состояниях, не требующих круглосуточного медицинского наблюдения, изоляции и использования интенсивных методов лечения, а также при беременности и искусственном прерывании беременности на ранних сроках (абортах). Стационарная медицинская помощь предоставляется гражданам в больничных учреждениях и других медицинских организациях или их соответствующих структурных подразделениях в следующих случаях, требующих круглосуточного медицинского наблюдения, применения интенсивных методов лечения и (или) изоляции, в том числе по эпидемическим показаниям: заболевание, в том числе острое; обострение хронической болезни; отравление; травма; патология беременности, роды, аборт; период новорожденности. Мероприятия по восстановительному лечению и реабилитации больных осуществляются в амбулаторных и больничных учреждениях, иных медицинских организациях или их соответствующих структурных подразделениях, включая центры восстановительной медицины и реабилитации, в том числе детские, а также санатории, в том числе детские и для детей с родителями. При оказании медицинской помощи осуществляется обеспечение граждан в соответствии с законодательством Российской Федерации необходимыми лекарственными средствами, изделиями медицинского назначения, а также обеспечение детей-инвалидов специализированными продуктами питания. Для получения медицинской помощи граждане имеют право на выбор врача, в том числе врача общей практики (семейного врача) и лечащего врача, с учетом согласия этого врача, а также на выбор медицинской организации в соответствии с договорами обязательного медицинского страхования.

Рассмотрим организационную структуру и органы управления организации.

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

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

Рисунок 1. Структура МБУЗ ГБ г. Армавира

Целью организационной структуры являются:

· Разделение и кооперация труда;

· Определение задач и обязанностей работников;

· Определение ролей и взаимоотношений.

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

1.2 Функции и задачи, выполняемые системным администратором МБУЗ ГБ г. Армавира

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

Системный администратор должен знать:

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

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

· Аппаратное и программное обеспечение сетей.

· Принципы простейшего ремонта аппаратного обеспечения.

· Языки программирования.

· Действующие стандарты, системы счислений, шифров и кодов

· Методы программирования.

· Системы организации комплексной защиты информации, способы предупреждения несанкционированного доступа к информации.

· Порядок оформления технической документации.

· Правила внутреннего трудового распорядка.

· Основы трудового законодательства.

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

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

Системный администратор подчиняется непосредственно начальнику отдела АСУ.

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

Системный администратор:

1.Устанавливает на серверы и рабочие станции сетевое программное обеспечение.

2. Конфигурирует систему на сервере.

3. Обеспечивает интегрирование программного обеспечения на файл-серверах, серверах систем управления базами данных и на рабочих станциях.

4. Ведет мониторинг показателей работоспособности компонентов ИТ-инфраструктуры и поддерживает рабочее состояние программного обеспечения сервера и рабочих станций.

5. Регистрирует пользователей, назначает идентификаторы и пароли.

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

7. Контролирует использование сетевых ресурсов.

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

9. Устанавливает ограничения для пользователей по:

-- использованию рабочей станции или сервера;

-- времени;

-- степени использования ресурсов.

10. Обеспечивает своевременное копирование и резервирование данных.

11. Обращается к техническому персоналу при выявлении неисправностей сетевого оборудования.

12.Участвует в восстановлении работоспособности системы при сбоях и выходе из строя сетевого оборудования.

13. Выявляет ошибки пользователей и сетевого программного обеспечения и восстанавливает работоспособность системы.

14. Проводит мониторинг сети, разрабатывает предложения по развитию инфраструктуры сети.

15. Обеспечивает:

-- сетевую безопасность (защиту от несанкционированного доступа к информации, просмотра или изменения системных файлов и данных);

-- безопасность межсетевого взаимодействия.

16. Готовит предложения по модернизации и приобретению сетевого оборудования.

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

18. Сообщает своему непосредственному руководителю о случаях злоупотребления сетью и принятых мерах.

19. Ведет журнал системной информации, иную техническую документацию.

Системный администратор имеет право:

1. Устанавливать и изменять правила пользования сетью.

2. Запрашивать от руководителей и специалистов подразделений института необходимые документы и информацию.

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

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

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

Системный администратор несет ответственность за:

1. Нарушение функционирования сети вследствие некорректного управления маршрутизацией и некорректного администрирования базовыми сетевыми сервисами.

2. Несвоевременное уведомление руководства об изменениях в маршрутизации.

3. Несвоевременную регистрацию выделенных IP-адресов.

4. Несвоевременное уведомление руководства о случаях злоупотреблений сетью.

2. Системный администратор привлекается к ответственности:

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

2. За правонарушения, совершенные в процессе своей деятельности, -- в пределах, установленных действующим административным, уголовным и гражданским законодательством Российской Федерации.

3. За причинение материального ущерба института -- в пределах, установленных действующим трудовым и гражданским законодательством Российской Федерации.

1.3 Инструменты мониторинга работы компонентов ИТ-инфраструктуры в МБУЗ ГБ г. Армавира

Одной из функций (функция 4) системного администратора является мониторинг работоспособности компонентов ИТ-инфраструктуры. Рассмотрим его более подробно, так как по мнению руководства и самого системного администратора МБУЗ ГБ г. Армавира данный процесс составляет наибольшую трудность.

Концепция ИТ-инфраструктуры МБУЗ ГБ г. Армавира показана на рисунке 2.

Рисунок 2 - Концепция ИТ-инфраструктуры МБУЗ ГБ г. Армавира

В МБУЗ ГБ г. Армавира по общей программе закупок были поставлены, установлены и приняты к использованию следующие системы мониторинга работоспособности компонентов ИТ-инфраструктуры:

1. HP Storage Essentials - мониторинг хранилищ данных;

2. IBM Tivoli Monitoring - мониторинг работоспособности серверного оборудования;

3. HP Diagnostics/TransactionVision - мониторинг работы шин передачи данных;

4. HP Service Health Reporter - мониторинг работоспособности средств виртуализации;

5. IBM Tivoli Netview - мониторинг работоспособности сетевой инфраструктуры;

6. HP End User Management - мониторинг работы критических приложений конечного пользователя.

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

1.4 Сценарий бизнес-процесса мониторинга работы компонентов ИТ-инфраструктуры

Рассмотрим то, как системный администратор отдела АСУ МБУЗ ГБ г. Армавира справляется с контролем работоспособности компонентов ИТ-инфраструктуры. На рисунке 3 изображен сценарий бизнес-процесса мониторинга.

Рисунок 3 - Сценарий бизнес-процесса мониторинга работоспособности компонентов ИТ-инфраструктуры

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

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

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

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

1.5 Разработка формальной модели бизнес-процесса мониторинга работоспособности компонентов ИТ-инфраструктуры

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

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

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

1. Нормальный режим работы

2. Сбор статистики

3. Нештатная ситуация

4. Мониторинг

5. Устранение нештатной ситуации

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

Рисунок 4 - Граф конечного автомата формальной модели бизнес-процесса мониторинга

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



Согласно формуле, время восстановления работоспособности компонента складывается от времени передачи сообщения об ошибке системе мониторинга (Т_п.с.), времени доставки сообщения об ошибке системному администратору (Т_д) и времени устранения неисправности (Т_уст.).

Рассмотрим каждый из показателей в отдельности.

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

Время доставки сообщения об ошибке системному администратору складывается из времени записи сообщения об ошибке в набор статистических данных (Т_з.с.), времени запуска средства мониторинга (Т_с.м.) и времени поиска сообщения об ошибке в наборе статистических данных (Т_п). Путем наблюдений было выяснено, данный показатель в среднем составляет 45 минут, причем наибольшее время относится к времени запуска средства мониторинга - порядка 40 минут. Здесь дело не в «медлительности» приложений, отвечающих за мониторинг, а в интервалах их проверки.

Время устранения неисправности складывается из времени диагностирования причины возникновения (Т_диаг.) и времени ремонта (Т_рем). По результатам наблюдений среднее время, затрачиваемое на устранение составляет порядка 30 минут. Безусловно, имеются и поломки, требующие и одного рабочего дня на их устранение, но их доля мала. Большинство же поломок связано с программными сбоями, устранение которых происходит не более чем за 10-15 минут.

1.6 Описание проблем, выявленных на этапе исследования предметной области

Системному администратору требуется проверить до 6 систем сбора статистической информации, при этом в каждой выполнить поиск ошибок, что в купе со временем запуска системы и загрузки статистических данных составляет порядка 5 минут. Можно утверждать, что минимальное время между просмотрами статистики в одной системе составит 30 минут при условии постоянном циклическом просмотре. Поскольку эта ситуация практически нереальна, фактическое время доставки возрастает до 45 минут.

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

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

1.7 Постановка цели и задач дипломной работы

Целью дипломной работы является решение проблемы роста времени восстановления работоспособности компонентов ИТ-инфраструктуры МБУЗ ГБ г. Армавира. Необходимо на порядок сократить время доставки сведений о возникновении ошибки (Параметр Т_д). Достижение цели требует решения следующих задач:

· Нахождение оптимальных значений параметров математической модели - времени восстановления работоспособности компонента ИТ-инфраструктуры МБУЗ ГБ г. Армавира

· Нахождение способа и алгоритма работы системного администратора МБУЗ ГБ г. Армавира, которые обеспечивают достижение оптимальных значений выбранных параметров.

· Разработка модели оптимальных бизнес-процессов мониторинга работоспособности компонентов ИТ-инфраструктуры МБУЗ ГБ г. Армавира

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

2. Оптимизация деятельности системного администратора МБУЗ ГБ г. Армавира

2.1 Нахождение оптимальных значений параметров формальной модели

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

Обоснованность выбора следует из следующей диаграммы (см. рисунок 5):

Рисунок 5 - Диаграмма соотношения временных затрат в процессе мониторинга работоспособности компонентов ИТ-инфраструктуры

Как мы видим из диаграммы, на процесс доставки сообщения администратору, который напрямую не относится к устранению ошибки, затрачивается свыше 55% всего времени восстановления работоспособности компонента ИТ-инфраструктуры. Сократив время доставки, мы не теряем качество работ по восстановлению.

При сокращении на порядок времени доставки мы получим следующее значение параметра Т_д



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

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

Рисунок 6 - Граф конечного автомата оптимизированной формальной модели процесса мониторинга

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

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

2.2 Нахождение способа и алгоритма работы механизма уведомления системного администратора

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

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

Рисунок 7 - Блок-схема алгоритма работы механизма уведомления системного администратора

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

Выбор механизма будет произведен из следующих альтернатив:

- Агрегирующий сервис, который собирает сведения со всех систем мониторинга и представляет их в удобочитаемом виде на одном экране;

- Самостоятельные службы уведомления для каждой системы мониторинга;

- Наем дополнительного сотрудника, отвечающего за непрерывный мониторинг;

1. Выберем критерии, по которым будем сравнивать механизмы и упорядочим их по важности:

1. Скорость доставки сведений о возникновении ошибки;

2. Стоимостные затраты на создание механизма;

3. Затраты на эксплуатацию механизма;

4. Сложность создания.

2. Присвоим наиболее важному критерию оценку 100 баллов. Исходя из попарного отношения критериев по важности, дадим в баллах оценку каждому из критериев (таблица 1):

Таблица 1 - Оценка критериев

Критерии	Баллы
Скорость доставки	100
Затраты на создание	85
Затраты на эксплуатацию	65
Сложность создания	40

3.Сложить полученные баллы. Произведём нормировку весов критериев, разделив присвоенные баллы на сумму весов:

W_i = ,

где A_i - баллы критерия,

n - количество критериев.

Результаты нормировки приведены в таблице 2.

Таблица 2 - Нормирование оценки критериев

Критерии	Баллы	Нормированный балл
Скорость доставки	100	0,344827586
Затраты на создание	85	0,293103448
Затраты на эксплуатацию	65	0,224137931
Сложность создания	40	0,137931034
Сумма баллов	290	1

4. Измерить значение каждой альтернативы по каждому из критериев по шкале от 0 до 100 баллов.

Таблица 3 - Измерение альтернатив по каждому критерию

Альтернативы	Критерии
	Скорость доставки сообщений об ошибке	Затраты на создание	Затраты на эксплуатацию	Сложность создания
Службы уведомления	70	50	70	80
Агрегирующий сервис	85	80	85	90
Дополнительный сотрудник	30	85	85	95

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

где В_i оценка альтернативы по каждому критерию (таблица 4)

Таблица 4 - Общие оценки альтернатив

Альтернативы	Критерии
	Скорость доставки сообщений об ошибке	Затраты на создание	Затраты на эксплуатацию	Сложность создания	Общая оценка
Службы уведомления	24,1379	14,65517	15,68965	11,03448	65,51724
Агрегирующий сервис	29,3103	23,44827	19,05172	12,41379	84,22413
Дополнительный сотрудник	10,3448	24,91379	19,05172	13,10344	67,41379

6.Выбрать как лучшую альтернативу, имеющую наибольшую общую оценку.

Вывод: лучшей альтернативой является Агрегирующий сервис.

2.3 Разработка модели оптимальных бизнес-процессов мониторинга

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

1. Выберем методологию моделирования;

2. Выберем CASE-средство для построения модели

3. Построим модель оптимизированного бизнес-процесса с использованием выбранной методологии и CASE-средства.

Выбор методологии моделирования

Методология моделирования должна отвечать следующим требованиям:

1. Графический способ представления модели;

2. Возможность отображения последовательности действий с условиями переходов;

3. Отображение механизмов на диаграммах;

4. Выразительная мощность диаграмм;

5. Простота использования в небольших проектах.

Под такие требования могут быть отнесены следующие методологии:

? Структурный анализ и проектирование (IDEF0, DFD, IDEF3)

? eEPC от ARIS

? BPMN (Business Process Modeling Notation).

Дадим характеристику каждой методологии.

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

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

- каждый черный ящик должен реализовывать единственную функцию системы;

- функция каждого черного ящика должна быть легко понимаема независимо от сложности ее реализации (например, в системе управления ракетой может быть черный ящик для расчета места ее приземления: несмотря на сложность алгоритма, функция черного ящика очевидна - "расчет точки приземления");

- связь между черными ящиками должна вводиться только при наличии связи между соответствующими функциями системы (например, в бухгалтерии один черный ящик необходим для расчета общей заработной платы служащего, а другой для расчета налогов - необходима связь между этими черными ящиками: размер заработанной платы требуется для расчета налогов);

- связи между черными ящиками должны быть простыми, насколько это возможно, для обеспечения независимости между ними.

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

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

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

- IDEF0 применяется для определения требований для разработки системы, реализующей выделенные функции;

- DFD (Data Flow Diagrams) диаграммы потоков данных;

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

На стадии моделирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.

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

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

eEPC от ARIS. Нотация ARIS eEPC расшифровывается следующим образом - Extended Event Driven Process Chain - расширенная нотация описания цепочки процесса, управляемого событиями. Нотация разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Шеером.

Применение большого числа различных объектов, связанных различными типами связей значительно увеличивает размер модели и делает ее плохо читаемой. Для понимания смысла нотации eEPC достаточно рассмотреть основные используемые типы объектов и связей. Связи между объектами имеют определенный смысл и отражают последовательность выполнения функций в рамках процесса. Нотация eEPC построена на определенных семантических правилах описания:

1. каждая функция должна быть инициирована событием и должна завершаться событием;

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

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

Таким образом, при помощи нотации eEPC ARIS можно описывать бизнес-процесс в виде потока последовательно выполняемых работ (процедур, функций).

BPMN (Business Process Modeling Notation) - это нотация для моделирования бизнес-процессов. BPMN ориентирована как на технических специалистов, так и на бизнес-пользователей. Для этого язык использует базовый набор интуитивно понятных элементов, которые позволяют определять сложные семантические конструкции. Кроме того, спецификация BPMN определяет, как диаграммы, описывающие бизнес-процесс, могут быть трансформированы в исполняемые модели на языке BPEL. Спецификация BPMN 2.0 так же является исполняемой и переносимой (т.е. процесс, нарисованный в одном редакторе от одного производителя может быть исполнен на движке бизнес-процессов совершенно другого производителя, при условии если они поддерживают BPMN 2.0).

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

1. Объекты потока управления: события, действия и логические операторы

2. Соединяющие объекты: поток управления, поток сообщений и ассоциации

3. Роли: пулы и дорожки

4. Артефакты: данные, группы и текстовые аннотации.

Элементы этих четырёх категорий позволяют строить простейшие диаграммы бизнес процессов. Для повышения выразительности модели спецификация разрешает создавать новые типы объектов потока управления и артефактов. Чтобы выбрать подходящую нотацию, применим метод экспертных оценок. Для каждого критерия определяем методику оценки выполнения критерия. Возможные результаты: 1, если критерий выполняется и 0, если не выполняется. Затем для каждого критерия определяем коэффициент значимости. Коэффициенты распределяются на отрезке от 0 до 1.

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

,

где

O_зn - интегральная оценка заявленной методологии;

n - количество критериев сравнения заявленных методологий согласно таблице критериев;

Z_i - значение оценки степени выполнения критерия.

K_i - коэффициент значимости критерия сравнения (от 0 до 1).

На основании сделанного мною обзора можно дать оценки рассмотренным методологиям по указанным выше критериям. Для наглядности сведем эти оценки в таблицу (см. таблицу 5)

Таблица 5 - Оценка рассматриваемых методологий моделирования

Оценка Критерий	Ki	Структурный анализ и проектирование	eEPC ARIS	BPMN
		Zi	Zi·Ki	Zi	Zi·Ki	Zi	Zi·Ki
Графический способ представления модели;	0,1	5	0,5	5	0,5	5	0,5
Возможность отображения последовательности действий с условиями переходов;	0,2	4	0,8	5	1	5	1
Отображение механизмов на диаграммах;	0,1	4	0,4	4	0,4	1	0,1
Выразительная мощность диаграмм;	0,2	4	0,8	3	0,6	5	1
Простота использования в небольших проектах	0,4	5	2	2	0,8	3	1,2
Интегральная оценка, Q		4,5	3,3	3,8

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

Выбор CASE-средств моделирования

CASE-средство моделирования должно отвечать следующим требованиям:

1. Поддержка методологии структурного анализа и проектирования;

2. Возможность русификации интерфейса;

3. Поддержка процедуры декомпозиции;

4. Наличие бесплатной или ознакомительной версии.

Под указанные критерии попадают следующие CASE-средства:

? All Fusion ERWin Process modeler (бывший BPWin);

? Ramus;

? График-студио Лайт.

Дадим характеристику каждому CASE-средству.

All Fusion Process Modeler (BPwin). Данный программный продукт относится к малым интегрированным средствам моделирования, которые поддерживают несколько типов моделей и методов.

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

Из существующих CASE-средств, ориентированных на построение моделей по методологии IDEF0, BPwin является наиболее известным и распространенным, а удобный интерфейс пользователя облегчает работу с программой

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

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

Основными возможностями Ramus являются:

? Моделирование процессов (согласно методологий IDEF0, IDEF3 и DFD);

? Разработка систем классификации и кодирования предприятия с внутренними перекрёстными связями, которая также тесно увязывается и с моделями процессов;

? Формирование отчётности по моделям и системе классификации, в том числе и отчётности в форме такой регламентирующей документации как должностные инструкции и регламенты процессов;

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

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

"Лайт" также может использоваться независимо от программного продукта Бизнес-инженер и распространяется бесплатно. Основными пользователями продукта являются неспециалисты по бизнес-моделированию.

В типовую конфигурацию программного продукта График-студио Лайт включены 15 График-студио диаграмм, соответствующих наиболее часто применяемым на практике методологиям и нотациям процессного описания:

? БИТЕК Диаграмма бизнес-процесса

? IDEF0

? Data flow diagram в нотации Гейна-Сарсона

? Data flow diagram в нотации Йордона-Де Марко

? IDEF3

? ORACLE diagram

? BAAN diagram

? Swimmer lanes

? Process variant matrix diagram

? ARIS Function tree

? ARIS Value-added chain diagram

? ARIS Process selection diagram

? ARIS eEPC

? ARIS Information flow diagram

? ARIS Material flow diagram

а также включены 20 График-студио диаграмм, которые используются для моделирования стратегии, продуктов и услуг, системы BSC, ключевых показателей - KPI, оргструктуры, ИТ-системы, моделирования и анализа других элементов организации.

Чтобы выбрать подходящее CASE-средство, применим метод экспертных оценок. Для каждого критерия определяем методику оценки выполнения критерия. Возможные результаты: 1, если критерий выполняется и 0, если не выполняется.

Затем для каждого критерия определяем коэффициент значимости. Коэффициенты распределяются на отрезке от 0 до 1.

Производим расчет аддитивной суммы интегральной оценки для каждого сравниваемого CASE-средства по следующей формуле:

,

где

O_зn - интегральная оценка заявленного CASE-средства;

n - количество критериев сравнения заявленных CASE-средств согласно таблице критериев;

Z_i - значение оценки степени выполнения критерия.

K_i - коэффициент значимости критерия сравнения (от 0 до 1).

На основании сделанного мною обзора можно дать оценки рассмотренным CASE-средствам по указанным выше критериям. Для наглядности сведем эти оценки в таблицу (см. таблицу 6)

Таблица 6 - Оценка рассматриваемых CASE-средств моделирования

Оценка Критерий	Ki	BPWin	Ramus	График-студио лайт
		Zi	Zi·Ki	Zi	Zi·Ki	Zi	Zi·Ki
Поддержка методологии структурного анализа и проектирования;	0,4	5	2	4	1,6	4	1,6
Возможность русификации интерфейса;	0,1	2	0,2	5	0,5	5	0,5
Поддержка процедуры декомпозиции;	0,2	5	1	5	1	3	0,6
Наличие бесплатной или ознакомительной версии	0,3	3	0,9	4	1,2	5	1,5
Интегральная оценка, Q		4.1	4,3	4,2

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

Моделирование бизнес-процессов

Выполним моделирование бизнес-процессов в выбранной среде Ramus.

Начнем с контекстной диаграммы, отображающей черный ящик «Мониторинг работы компонентов ИТ-инфраструктуры» (рисунок 8).

Рисунок 8 - Контекстная диаграмма

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

Рассмотрим подробно работу данного черного ящика, для чего будет произведена декомпозиция на четыре функциональных блока IDEF0 (рисунок 9).

Рисунок 9 - Декомпозиция контекстной диаграммы

Черный ящик «мониторинг работоспособности компонентов ИТ-инфраструктуры» раскрывается четырьмя функциональными блоками:

Сбор статистических данных. Система мониторинга согласно алгоритму ее работы собирает показатели работоспособности компонентов ИТ-инфраструктуры и сообщения об ошибках и генерирует статистические данные на выходе

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

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

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

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

Рисунок 10 - Модель процесса уведомления об ошибках

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

Затем полученное сообщение расшифровывается. В 99% случаев ошибка передается в виде соответствующего буквенно-числового кода. Данный код в соответствии с классификатором расшифровывается для упрощения восприятия и ускорения работы по восстановлению работоспособности компонента ИТ-инфраструктуры.

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

Сгенерированное для выдачи сообщение помещается в тело уведомления, которое генерируется агрегирующим сервисом для передачи непосредственно на рабочее место администратора.

Таким образом можно утверждать, что мы построили модель оптимизированного бизнес-процесса, отражающую основные нововведения в работе системного администратора отдела АСУ МБУЗ ГБ г. Армавира по мониторингу работоспособности компонентов ИТ-инфраструктуры.

3. Проектирование информационной системы мониторинга работы ИТ-инфраструктуры

3.1 Сравнительный анализ информационных систем сбора и просмотра статистической информации

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

...