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

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

Содержание

Введение

1. Архитектура IT сервисов и роль инженеров поддержки в обеспечении доступности систем

1.1 Связь качества IT сервисов и бизнес стратегии поставщика услуг

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

1.3 Шаблоны проектирования информационных систем

1.4 Уровни системы мониторинга информационной инфраструктуры

2. Моделирование мониторинга элементов информационной инфраструктуры

2.1 Архитектура системы мониторинга

2.2 Диаграмма состояний службы мониторинга

2.3 Структура приложения службы мониторинга

3. Тестирование сценариев взаимодействия со службой мониторинга

3.1 Диаграмма вариантов использования

3.2 Тестирование сценариев запуска и остановки службы

3.3 Тестирование сценария просмотра статуса проверки

3.4 Тестирование сценария отключения настроенной проверки

Заключение

Список использованной литературы

Приложения



Введение

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

Понятие «аутсорсинга ИТ» появилось в 70-х годах прошлого века и набрало значительную популярность после выпуска технологии Active Server Pages компанией Microsoft для создания Web приложений. Под аутсорсингом ИТ понимается передача функций по управлению информационной инфраструктурой сторонней организации.

Согласно исследованию, проведенному аналитическим агентством TAdviser рынок аутсорсинга ИТ в России является один из наиболее перспективных направлений и его рост в 2015 году составляет 15%. Наибольшей популярностью пользуются в России такие виды услуг, как офисная печать и видеонаблюдение, телекоммуникации. Также в последние годы наблюдается значительное повышение спроса на контракты «инфраструктура как сервис» и «инженерные системы» (корпоративные системы и центры обработки данных). К компаниям, занимающимся предоставлением аутсорсинговых услуг, относят консалтинговые предприятия, которые специализируются на автоматизации процессов за счет внедрения корпоративных систем; предприятия из сферы телефонии и Интернет-провайдеров; организации, предоставляющих «облачные» услуги и хранилища данных.

В последней версии библиотеки ITILv3 (IT Infrastructure Library) IT-услуга определяется как «совокупность информационных систем, обеспечивающих выполнение бизнес-процессов; IT-услуга включает в себя информационные технологии, процессы и людей».

Поставщик услуги берет на себя ответственность за качество работы сервиса для содействия в получении конечного результата заказчику. Обращаясь к терминологии ITIL, отношения между исполнителем и заказчиком регулируются на основе формального договора - Service Level Agreement (сокращённо SLA). Документ включает в себя требования по доступности сервиса, производительности при определенном количестве пользователей, а также сроки по разрешению обращений или инцидентов.

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

Сегодня существует ряд Open Source продуктов и готовых решений, которыми могут пользоваться системные администраторы для отслеживания сбоев на различных участках и уровнях ИС. Однако на практике чаще всего используется наиболее известное программное обеспечение компании Microsoft - System Center Operations Manager (SCOM) и программа Nagios с открытым кодом. Эти решения предназначены не только для мониторинга устройств, центров обработки данных (ЦОД), но и управления частными облаками, службами и обеспечения безопасности.

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

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

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

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

2. Модификация состава и настроек уже существующих командных «мониторов»;

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

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

Для достижения поставленной цели необходимо выполнить следующие задачи:

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

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

3. На основе полученного анализа выявить основные компоненты для мониторинга и составить требования к функционалу системы;

4. Разработать архитектуру системы мониторинга;

5. Разработать компоненты системы мониторинга: базу данных и сервис мониторинга;

6. Проверить работу компонентов системы на примере сценариев взаимодействия с системой.



1. Архитектура IT сервисов и роль инженеров поддержки в обеспечении доступности систем

1.1 Связь качества IT сервисов и бизнес стратегии поставщика услуг

Аутсорсинг информационных технологий является достаточно актуальной темой для исследования на сегодняшний день. Как заметил в одной из своих работ профессор Дж. Гу (Университет Флорида Атлантик, департамент информационных технологий и управления операциями) в 2007 году, научные работы, где объектом исследования выступают отношения между заказчиками и провайдерами ИТ услуг, можно разделить на три основных направления: изучение социальных, экономических и стратегических аспектов подобных взаимоотношений. Так, работы по стратегической концепции ставят перед собой в качестве основной цели исследование причин, по которым организации приходится выделять аутсорсинговую стратегию, а также самого процесса её разработки.

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

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

В своей работе «Исследование факторов, которые влияют на продолжительность отношений в ИТ аутсорсинге» («An investigation of factors that influence the duration of IT outsourcing relationships», 2007) Дж. Ку построил модель из семи ключевых аспектов, которые оказывают наибольшее влияние на такой показатель, как длительность взаимоотношений между заказчиком и исполнителем в области ИТ аутсорсинга. В модель вошли сбор знаний, стратегическая значимость ИТ, наличие специфических инвестиций, неопределенность требований, круг заменителей функций для передачи на аутсорсинг, оппортунистическое поведение и удовлетворенность клиента итоговым качеством. Все перечисленные переменные глобально могут быть разделены на два типа: известные заранее и постусловия. Например, клиент формирует свое отношение к сервису именно в момент его непосредственного использования, поэтому фактор удовлетворенности качеством относится ко второму типу. Процесс использования сервиса включает в себя обращения в службу поддержки. Отсюда, удовлетворенность уровнем обслуживания Service Desk напрямую влияет на репутацию провайдера и длительность взаимоотношений с заказчиками.

Позднее в 2014 году была опубликована статья «Уроки из Голландского ИТ аутсорсинга» («Lessons from Dutch IT outsourcing», G.P.A.J. Delen и другие). Работа была посвященная исследованию метрик и переменных, при помощи которых можно было определить вероятность успеха аутсорсинговой сделки на примере выборки из 30 реальных проектов. Авторы разделили все возможные факторы на два основных вида: неизменные и контролируемые. Под «неизменными» аспектами понимаются те, которые были определены в самом начале проекта и не могут быть преобразованы в последствие. Например, совместимость корпоративных культур организаций исполнителя и заказчика или мотивы обеих сторон к участию в сделке. «Контролируемые» показатели напротив могут меняться и принимать различные формы на протяжении всего проекта. Так, в качестве данных показателей в работе были исследованы процесс управления спросом, коммуникации внутри фирмы провайдера услуг и заказчика, выполнение работ в соответствии с планом передачи функций на аутсорсинг и т.д. Не смотря на утверждение исследователей о том, что тип выполняемых работ по аутсорсингу не оказывает ни положительное, ни негативное влияние на исход сделки, они отмечают необходимость исполнителя стремиться к построению долгосрочных отношений, а также уметь выявлять потребности и возможности своего клиента. Как уже было отмечено ранее, уровень удовлетворенности качеством поддержки предоставляемых услуг напрямую влияет на длительность контракта. Отсюда следует, что успех проекта по аутсорсингу информационной инфраструктуры также зависит от этой составляющей.

Не менее важное направление исследований в области аутсорсинга информационных технологий - процесс управления рисками. Филип де Са-Соарес (профессор Университета Миньо департамента программной инженерии) в своей работе «Навстречу теории рисков аутсорсинга информационных систем» («Towards a theory of information systems outsourcing risk», 2014) привел все возможные факторы, которые могут оказывать негативное влияние на организации, выступающие в качестве заказчиков ИТ услуг. В представленной им рисковой модели выделено пять основных компонентов: факторы риска, угрозы, действия по снижению негативного влияния, негативные исходы и нежелательные последствия. При помощи этой модели, автор объяснил природу возникновения рисков и связал их с аспектами, непосредственно характерными для проектов по аутсорсингу информационных технологий.

Обращаясь к компонентам представленной модели, угроза является причиной (или возможной причиной) какого-либо негативного исхода. Негативный исход можно определить как неблагоприятный (нежелательный) результат определённых действий, который далее перетекает в нежелательные последствия. Нежелательные последствия представляют собой явную потерю ценных ресурсов для организации. При этом первопричиной негативного исхода является фактор риска, то есть некоторая ситуация, усиливающая угрозы. Однако организация может снижать уровень причиненного вреда или размер потерь за счет применения определенных действий и инструментов на этапе возникновения негативного исхода. Для каждого из перечисленных компонентов автор собрал и представил возможные примеры, характерные для исследуемой предметной области. Так для составленных примеров, больший процент угроз для клиента составляют проблемы с производительностью и стабильностью информационной инфраструктуры провайдера услуг, плохое качество предоставляемых сервисов и низкий уровень взаимодействия между организациями. Одним из более конкретных примеров таких негативных аспектов является недостаточный уровень оказания технической поддержки, проблемы с телекоммуникационной сетью провайдера или сбои в компонентах информационной инфраструктуры провайдера. Перечисленных проблем можно частично избежать за счет внедрения метрик по контролю качества и закреплению данных показателей в формальном договоре об уровне оказываемых услуг - Service Level Agreement (SLA).

Не смотря на то, что термин «Соглашение об уровне услуг» (SLA) зачастую воспринимается лишь как формальный договор, описывающий инструкции и обязанности участников отношений, он имеет гораздо более широкое значение. Понятие «дополнительной валюты» появилось около века назад и может быть определено как ресурс, добавляющий ценность к национальной валюте или способный полностью её заменить. В 2012 году Иоаном Петри было проведено исследование возможности использовать SLA в качестве такой валюты, которое он описал в своей работе «Service level agreement as a complementary currency in peer-to-peer markets». Заключение в его работе было построено на основе тезиса о том, что соглашение между двумя сторонами в рамках подобных договоров направлено на результат в будущем. Этот результат может быть оценен лишь по истечении срока подобного договора.

Процесс внедрения соглашения и его жизненный цикл в работе разделены на несколько основных этапов. Во-первых, клиенту необходимо сформировать заявку на получение контракта (SLA). После обработки заявки, провайдер услуг формирует условия, которые он готов предложить клиенту, и направляет их в ответ. На третьем этапе клиент принимает решение о подписании договора, и далее участники действуют в соответствии с установленными положениями и сроками контракта. Также в исследовании сделана предпосылка, о том, что за клиентом остается возможность платить на основе моделей «плати перед использованием» (pay-before-use) или «плати после использования» (pay-after-use). Заключительным этапом жизненного цикла контракта является дата его истечения, при наступлении которого клиент принимает решение о проведении очередной итерации заключения соглашения с провайдером.

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

В последней версии библиотеки ITIL (IT Infrastructure Library), опубликованной в 2011 году, приводятся примеры структуры и положений Договора об уровне услуг в третьей книге серии IT Service Design. Особое место в договоре занимают положения о доступности сервиса. Под доступностью в данном случае понимается время, в рамках которого сервис должен предоставлять полный спектр своего функционала конечным пользователям на определенном соглашением уровне. Авторы книги рекомендуют использовать для этого показателя метрики в процентном выражении за определенный период. Однако, как уже было отмечено ранее, клиент может оценить уровень исполнения провайдером зафиксированных метрик лишь по истечении срока договора, поэтому чаще всего в первую очередь участники договора рассчитывают уровень «недоступности» сервиса. Помимо этого положения в приведенном примере договора выделяются разделы для показателей надежности - максимального количества сбоев в системе за период договора, - и производительности системы.

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

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

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

Одним из основных процессов управления ИТ услугами, согласно ITIL v3 2011 Edition, является управление эксплуатацией сервисов (IT Service Operations). Основной целью этого процесса является контроль над эффективностью и качеством предоставляемых услуг на уровне, согласованном между заказчиком и провайдером.

Авторы библиотеки выделяют три типа провайдеров услуг (service provider): внутренний поставщик услуг, объединенный центр обслуживания и внешний поставщик услуг. Под внутренним провайдером понимается поставщик, предоставляющий услуги в рамках одного бизнес подразделения, в то время как для второго типа провайдера характерно обслуживание нескольких департаментов. Последний тип провайдеров предполагает работу с внешними пользователями системы. На сегодняшний день для большинства организаций характерно наличие нескольких типов поставщиков услуг или их смесь, когда провайдер одновременно занимается обслуживанием внутренних и внешних пользователей системы напрямую. Особенно это характерно для компаний, занимающихся предоставлением онлайн сервисов.

Эксплуатация ИТ услуг включает в себя такие операции, как управление событиями, инцидентами, запросами на обслуживание, проблемами и доступом к системам. Все перечисленное является частью функций службы технической поддержки и управления приложениями. Авторы библиотеки называют службу поддержки (service desk) «единой точкой контакта между поставщиком услуг и пользователями». Основной целью службы поддержки является оказание помощи пользователям с возникшими проблемами во время использования сервиса и выполнение запросов на обслуживание. Процесс обработки инцидентов и запросов состоит из следующих этапов:

1. Пользователь заводит обращение в системе при помощи специальной онлайн системы, звонка и сообщения;

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

3. Сотрудник первой линии выполняет инструкции для данного типа обращения: предоставляет пользователю поддержку самостоятельно или передает (эскалирует) заявку в соответствующую команду на второй линии поддержки;

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

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

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

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

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

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

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

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

2. Проведение сетевой диагностики при возникновении инцидентов доступности сервиса;

3. Чтение и модификации данных в БД поддерживаемого приложения;

4. Проведение анализа проблем и исследования логики обработки запросов за счет доступ к Web API поддерживаемого приложения;

5. Анализ логов отдельных компонентов для исследования проблем и сбоев в работе системы;

6. Получение информации из веб интерфейса системы;

7. Предоставление доступа пользователей к участкам системы, если это требует конфигурации настроек безопасности системы;

8. Передача кейсов в команды разработки, если это требует исправления ошибок в программном коде, аппаратной части сервиса или анализа кода приложения;

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

1.3 Шаблоны проектирования информационных систем

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

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

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

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

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

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

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

В современной среде разработки пользовательских сервисов и приложений перед специалистами в основном стоит задача написания объектно-ориентированного кода и создания такой архитектуры. Множество современных технологий, платформ и языков программирования построены именно на принципах ООП. В первую очередь такой подход позволяет масштабировать системы, а также в большинстве случаев упрощает анализ кода и процедуры пополнения функциональности сервиса, кроме того такие системы являются более производительными и эффективными. Одним из основных аспектов ООП является разделение системы на части и назначение функционального наполнения каждой из них, то есть ответ на вопросы «что?» и «для чего?». За более чем сорокалетнюю историю технологии было разработано множество готовых решений наиболее распространенных задач, которые возникают перед разработчиками. Для моделирования и определения функциональности службы мониторинга необходимо рассмотреть следующие шаблоны проектирования:

1) Подписчик-издатель (pub-sub pattern)

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

b) Принцип работы: в системе выделяются «издатель» (publisher) и «подписчик» (subscriber). Издатель публикует сообщения в виртуальные очереди или разделы. Сообщения делятся на классы. Подписчики забирают сообщения из одного или нескольких разделов и обрабатывают их.

c) Реализация в службе мониторинга: чаще всего такой подход подразумевает использование готовых шин (интеграторов) между подписчиками и издателями. Примером такого решения является технология компании Microsoft - Azure Service Bus. Отправители и подписчики могут обмениваться информацией, как посредством очередей, так и при помощи разделов. Необработанные сообщения помещаются в специальную очередь - Dead-Letter Queue. Служба мониторинга получает количество сообщений и их класс из этой очереди.

2) Фасад (Faзade)

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

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

c) Реализация в службе мониторинга: взаимодействие с системой может осуществляться при помощи очереди событий или отправки SOAP запросов к сервису. Мониторинг может осуществляться за счет проверки количества и типов событий в очередях в БД. Также возможна генерация SOAP запросов, отправка их на сервис и проверка возвращаемого значения или кода ошибки.

3) Адаптер (Adapter)

a) Описание: шаблон Adapter, как и Faзade, предполагает создание «обертки» для подсистем с целью обеспечения доступа к их компонентам. Основное отличие между этими шаблонами заключается в том, что Adapter не предусматривает создание нового интерфейса, а лишь преобразование существующего к необходимому виду. Этот шаблон применяется в случае, если нет возможности повторно использовать ранее созданный код.

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

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

4) Push и Pull модель (push and pull patterns)

a) Описание: наиболее распространенные модели взаимодействия пользователя с сервисом. При использовании pull-модели пользователь самостоятельно опрашивает сервис и получает от него ответ. При использовании push-модели сервис обрабатывает события и уведомляет клиента об изменениях без пользовательского запроса.

b) Принцип работы:

i) Pull-модель. Клиент отправляет запрос на сервер. Сервер обрабатывает сообщение и возвращает синхронный ответ.

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

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

5) Распределение нагрузки на систему (workload distribution)

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

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

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

6) Сервисно-ориентированная архитектура (SOA)

a) Описание: в основе сервисно-ориентированной архитектуры лежит набор компонентов, которые осуществляют взаимодействие при помощи стандартизированных протоколов. Чаще всего такой подход используется для реализации веб-сервисов.

b) Принцип работы: основными составляющими в SOA являются пользователь, поставщик и реестр сервисов. Пользователь обращается в реестр при помощи запроса - SOAP, HTTP, WSDL и т.д. Реестр обрабатывает запрос на основе соглашения об интерфейсе и перенаправляет его к нужному компоненту сервиса. Сервис обрабатывает событие и передает ответ обратно в реестр. Реестр возвращает пользователю результат обработки его сообщения. Поставщик отвечает за поддержку веб интерфейсов сервисов для интеграции и регистрацию сервиса в реестре.

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

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

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

1.4 Уровни системы мониторинга информационной инфраструктуры

В своей книге «Проектирование высокопроизводительных, масштабируемых и доступных бизнес Web приложений» Кумар Ш. («Architecting High Performing, Scalable and Available Enterprise Web Applications», 2015) приводит рекомендации по проектированию системы мониторинга, в основе которой лежат наиболее распространенные практики и подходы к обеспечению доступности и производительности систем. Автор акцентирует внимание на том, что часто один и тот же паттерн может одновременно применяться для обеспечения производительности, доступности и масштабируемости веб приложения. Например, при использовании подхода «распределенной нагрузки» и внедрении «балансировщиков» нагрузки (balancers) архитектор сервиса решает задачу повышения производительности и уровня доступности при обработке запросов. При выходе из строя какого-либо из компонентов, пользователи могут быть временно переключены на работу с одним из доступных компонентов без потери основного функционала системы и нарушения бизнес-процессов.

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

На этапе внутреннего анализа система мониторинга может посылать запросы веб-приложению, серверу или базе данных и анализировать полученный ответ. Например, любой HTTP-response код, отличный от 200, может стать сигналом о наличии ошибок в приложении и сбоях. Также пользователи системы мониторинга могут следить за использованием памяти серверами, базами данных и веб приложениями, и, в случае превышения порогового значения, получать нотификацию. Уведомления системы, отчеты о производительности сервисов и отложенные задания (scheduled jobs) являются неотъемлемыми компонентами службы мониторинга на внутреннем уровне, так как предоставляют пользователям возможность интегрировать её с процессами конкретной организации или команды.

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

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

1. Google analytics для анализа времени загрузки страницы, ответа страницы и проходящего через сервис трафика;

2. Инструменты мониторинга производительности приложения (Application Performance Monitoring, APM), которые построены на базе географически распределённых ботов мониторинга;

3. Инструменты real-user monitoring (RUM), основанные на подходе пассивного мониторинга системы.

На сегодняшний день выделяют две основных группы методов мониторинга трафика в сети: активные и пассивные. При активном мониторинге происходит анализ передачи пакетов, пропускной способности канала обмена данными и маршрутов, по которым идут пакеты, между двумя точками. Активные методы применяют такие утилиты сетевой диагностики, как ping, tracert и iperf. Пассивные методы напротив анализируют информацию об одной точке в сети, перехватывая идущие по каналу пакеты, и не создают дополнительную нагрузку и трафик к тем, что уже есть в сети. Они занимаются сбором информации о времени между прохождением пакетов, трафике, количестве переданных битов и протоколах передачи данных. Обе группы методов в отдельности имеют ряд существенных недостатков. Например, активные методы создают лишнюю нагрузку и трафик в сети, не всегда можно гарантировать точность таких измерений, в то время как пассивные методы могут производить только оффлайн анализ собранных измерений и не имеют инструментов эффективного анализа больших данных. Именно по этой причине на практике чаще всего применяются комбинации описанных методов.

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

Однако из всего перечисленного функционала в своей работе инженеры технической поддержки чаще сталкиваются с задачами осуществления сетевой диагностики и недоступности страниц и их контента. Утилиты сетевой диагностики, перечисленные для активных методов, удобнее использовать из командной строки Windows, а не стороннего интерфейса, для анализа пакетов в сети также существуют удобные готовые решения (например, wireshark). Для автоматизации получения данных по доступности веб страниц реализуемая система мониторинга должна уметь отправлять HTTP запросы к веб станицам и анализировать полученный ответ, распознавать ошибки при загрузке JavaScript'ов и уведомлять об этом пользователей службы в интерфейсе.

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

Отсюда, функционал службы мониторинга может быть дополнен следующим образом:

1. Измерение времени обработки запроса в базе данных и сравнение с пороговым значением метрики;

2. Измерение времени загрузки веб страницы и сравнение с пороговым значением метрики;

3. Поиск значения в файле с логами приложения и нотификация пользователя о наличии значения в интерфейсе;

4. Отправка HTTP запроса к веб ресурсу и анализ кода ответа веб ресурса;

5. Анализ ошибок при загрузке JavaScript'ов на веб странице приложения;

6. Анализ значений элементов в формате XML и JSON на различных ресурсах для работы с выходными данными основных систем мониторинга.



2. Моделирование мониторинга элементов информационной инфраструктуры

2.1 Архитектура системы мониторинга

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

Тип (категория) проверки	Описание	Дополнительные свойства
Проверка времени выполнения SQL запроса на сервере	Система выполняет заданный запрос на базе данных MS SQL Server и получает статистические данные о результатах выполнения. В качестве итогового значения система анализирует значение времени выполнения запроса.	Свойства запроса: Не учитываются. Дополнительные параметры: В качестве дополнительных параметров могут быть получены другие статистические значения выполнения запроса на сервере. Список таких значений и их ключей описан в статье библиотеки MSDN - «Статистика поставщика для SQL Server» [URL: https://msdn.microsoft.com/ru-ru/library/7h2ahss8(v=vs.110).aspx].
Проверка итогового значения SQL запроса на сервере	Система выполняет запрос к базе данных MS SQL Server, получает значение параметра из определенного столбца по его имени и анализирует результат. Запрос должен возвращать не более одной строки (значения последующих строк не анализируются).	Свойства запроса: Для выполнения запроса пользователь указывает имя столбца, значение которого необходимо проанализировать и путь к файлу со скриптом для выполнения. Файл должен храниться на той же машине, с которой запускается инструмент мониторинга. Дополнительные параметры: Запрос пользователя может возвращать несколько столбцов. Для анализа значений дополнительных параметров необходимо указать имена столбцов.
Значение атрибута XML из файла	Система загружает данные в формате XML из файла на файловом сервере или локальном компьютере пользователя. В полученной структуре данных выполняется поиск необходимого элемента XML и анализ его значения.	Свойства запроса: Для поиска элемента в структуре XML пользователь указывает путь в формате XPath и перечисляет namespaces. Необходимо указать явно все namespaces, которые присутствуют в элементах документа на пути к искомому атрибуту. Дополнительные параметры: В качестве дополнительных параметров может выполняться поиск других атрибутов в полученной XML структуре. Для этих атрибутов также требуется указать путь в формате XPath.
Значение атрибута XML с веб страницы	Система загружает данные в формате XML с веб страницы. В полученной структуре данных выполняется поиск необходимого элемента XML и анализ его значения.	Свойства запроса и дополнительные параметры аналогичны категории «Значение атрибута XML из файла».
Значение атрибута JSON из файла	Система загружает данные в формате JSON из файла на файловом сервере или локальном компьютере пользователя. В полученной структуре данных выполняется поиск необходимого элемента и анализ его значения.	Свойства запроса: Для поиска элемента в структуре JSON пользователь указывает путь к элементу формате JSONPath. Дополнительные параметры:

Подобные документы

• Разработка модели системы мониторинга пользовательских запросов в крупной социальной сети Рунета — ООО "В Контакте"

  Маркетинговая составляющая сферы социальных сетей. Описание системы мониторинга запросов потребителей. Общая характеристика систем технической поддержки (Service desk, Help desk). Начальная страничка интерфейса поддержки при возникновении проблемы.
  
  дипломная работа [2,5 M], добавлен 25.10.2015
  

• Web-ориентированная система тьюторской поддержки

  Анализ и сравнение существующих систем тьюторской поддержки. Методологии разработки программного обеспечения. Разработка web-ориентированной системы тьюторской поддержки самостоятельной работы студента. Выбор архитектуры программных средств разработки.
  
  курсовая работа [1,1 M], добавлен 05.01.2013
  

• Разработка системы поддержки принятия решений в сфере банковского кредитования

  Классификация систем поддержки принятия решений. Сравнительный анализ методик для оценки рисков розничного кредитования. Структура системы поддержки принятия решений, формирование начальной базы знаний. Проектирование базы данных информационной системы.
  
  дипломная работа [1,9 M], добавлен 10.07.2017
  

• Служба поддержки пользователей Service Desk

  Значение Информационных технологий. Традиционные проблемы взаимодействия. Принципы организации и возможности автоматизированной Диспетчерской службы. Основные преимущества компьютеризированной реализации службы Service Desk. Классификация, учет обращений.
  
  лекция [2,0 M], добавлен 04.12.2014
  

• Разработка службы Windows "Контроль приложений"

  Разработка на языке C++ службы, осуществляющей контроль набора выполняющихся приложений. Проектирование, кодирование, отладка, тестирование и сопровождение службы Windows. Взаимодействие службы и приложения. Интерактивность разрабатываемой службы.
  
  курсовая работа [964,9 K], добавлен 01.06.2013
  

• Разработка обеспечения для поддержки принятия решений и выпуска новой продукции

  Разработка алгоритмического и программного обеспечения для решения задачи поддержки принятия решений о выпуске новой продукции. Математическое обеспечение задачи поддержки принятия решений о выпуске новой продукции, основные входные и выходные данные.
  
  дипломная работа [943,0 K], добавлен 08.03.2011
  

• Разработка ПМК для информационной поддержки деятельности системного администратора машиностроительного техникума

  Обзор существующего программного обеспечения для информационной поддержки деятельности системного администратора машиностроительного техникума. Анализ выбора средств разработки. Требования к разработке. Экономическая эффективность разработанной системы.
  
  дипломная работа [108,5 K], добавлен 27.03.2013
  

• Решение задач мониторинга и контроля параметров обрабатываемых угодий, учета и анализа информации о статусе поля и выполняемых на нем работах

  Общая характеристика и функциональные возможности, внутреннее устройство и принцип работы спутниковых систем мониторинга, особенности их применения в сфере сельского хозяйства. Технология решения задачи мониторинга. Разработка программного обеспечения.
  
  дипломная работа [5,3 M], добавлен 15.05.2014
  

• Разработка системы информационной поддержки формирования и контроля прохождения заказа рекламного агентства

  Проектирование системы информационной поддержки рекламного агентства. Технико-экономический анализ и характеристика деятельности предприятия ООО "Артмосфера". Основные проблемы фирмы, подлежащие решению с помощью современных информационных технологий.
  
  дипломная работа [1,8 M], добавлен 05.12.2011
  

• Технологии поддержки процесса принятия решений

  Рассмотрение понятия и истории возникновения систем поддержки принятия решения. Приспособленность информационных систем к задачам повседневной управленческой деятельности. Понятие термина "интеллектуальный анализ данных". Методика извлечения знаний.
  
  реферат [79,8 K], добавлен 14.04.2015
  

• главная
• рубрики
• по алфавиту
• вернуться в начало страницы
• вернуться к началу текста
• вернуться к подобным работам