Geum.ru

Инновационная образовательная программа гу-вшэ «Формирование системы аналитических компетенций для инноваций в бизнесе и государственном управлении» Кафедра Управления информационными ресурсами предприятия

Вид материалаОбразовательная программа

Содержание


Системы управления рабочими местами
Системы Service Desk
В интересах бизнеса: системы управления ИТ-услугами
Назначение SLM-системы
Состав SLM-системы
Порядок внедрения SLM-системы
Требования к SLM-системе Александр Буйдов
Выбор продукта для реализации SLM-системы
Подобный материал:
1   ...   26   27   28   29   30   31   32   33   ...   36

Системы управления рабочими местами


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

Эти особенности отражаются на архитектуре агентов и управляющих программ систем управления АРМ – в частности, в отличие от сервера, ПК не требуется непрерывно контролировать, поэтому управление здесь происходит по запросу. Если требуется произвести, например, инвентаризацию, то с центрального сервера поступает команда, установленный на ПК агент загружает необходимый программный модуль, исполняет его, а после выгружает, тем самым высвобождая ресурсы системы.

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

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

Система управления АРМ Systems Management Server (SMS), разработанная Microsoft, включает инструменты для проведения инвентаризации программных и аппаратных средств, распространения приложений и обновлений. Неоспоримыми преимуществами SMS являются легкость развертывания и эксплуатации, а также высокая масштабируемость, которая позволяет наращивать уровень управления от небольшого количества АРМ до крупной территориально распределенной системы с сотнями тысяч конечных устройств. Как и в случае с модулем управления серверами и приложениями, для взаимодействия с платформами, отличными от Windows, Microsoft предлагает использовать ПО третьих фирм, которое интегрируется с SMS.

В целом системы управления АРМ в последнее время пользуются повышенным спросом. И в этой области среди относительно новых разработок довольно известны такие системы, как Altiris, Marimba и Novadigm (при этом вторая уже приобретена ВМС, а третья принадлежит НР). Эти решения поддерживают описанную выше базовую платформу систем управления АРМ. Корпорация Intel также продвигает свою систему управления АРМ (LanDesk Man), однако это решение нельзя отнести к новым разработкам, к тому же оно реализовано на совершенно иных принципах и на российском рынке сегодня почти не присутствует.


Системы Service Desk


Как уже говорилось выше, системы Service Desk ориентированы на работу персонала ИТ-службы, в которой существует разделение групп по функциональному признаку. Системы этого уровня реализуют ряд процессов, описанных в библиотеке ITIL (IT Infrastructure Library), где собраны лучшие мировые практики организации работы департаментов ИТ. На сегодняшний день в этой области наиболее автоматизированными считаются процессы управления уровнем обслуживания, управления инцидентами (сбои, неполадки и простои в ИТ-инфраструктуре), управления проблемами (определение причины инцидента и решение о его устранении), управления изменениями (т. е. все события, происходящие в ИТ-инфраструктуре, должны быть авторизованы и известны), а также стандартизация рабочих мест и контроль всех элементов ИТ-инфраструктуры и их взаимосвязи. При этом первый из них относится к сфере стратегического контроля, а остальные характеризуют функции оперативного контроля.

Сегодня в сегменте решений Service Desk наиболее известны системы BMC Remedy ITSM, HP Service Desk, CA ServicePlus Service Desk и Peregrine Service Center. Следует отметить, что до недавнего времени IBM также продвигала собственное решение Tivoli Service Desk, однако этот проект был продан компании Peregrine Systems. В свою очередь, нынешней осенью было объявлено о покупке уже самой Peregrine компанией НР, что в итоге значительно усилило позиции последней в данном сегменте.

Логическая архитектура всех программных решений Service Desk построена на двух основных подсистемах – организации данных и реализации логики обработки этих данных. Первая выполняет расширенные задачи СУБД и отвечает на вопросы о том, какие данные нужны для работы системы, какие данные необходимы для работы пользователям, какова структура и взаимные отношения этих данных, как эти данные хранятся, как обеспечивается их целостность и другие. Вторая подсистема выполняет функции сервера операций и контролирует, в частности, взаимодействие различных пользователей системы, механизмы автоматизации процедур и характер изменения данных.

С технической точки зрения базовой здесь является архитектура «сервер приложений-сервер баз данных», и в основном решения отличаются друг от друга тем, как распределены функции по обслуживанию структуры данных и обеспечена логика работы между сервером приложений и сервером баз данных. Рассмотрим с этих позиций решения HP Service Desk, Peregrine Service Center и BMC Remedy ITSM.

В решении НР для размещения данных, а также их структуры и логики обработки используются ресурсы промышленных СУБД. Сервер приложений в этом случае используется лишь как средство визуализации данных и частично для балансировки нагрузки, то есть фактически HP Service Desk является СУБД-ориентированной системой.

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

В архитектуре Remedy ITSM реализовала прямо противоположную концепцию: БД выступает в качестве простого хранилища данных, а вся информация об их структуре, а также логика обработки перенесены на сервер приложений. Основой же решения является многофункциональная платформа разработки систем автоматизации процессов Remedy Action Request System (ARS), которая обеспечивает создание как централизованных, так и распределенных систем. И наличие в качестве ядра мощного средства разработки обеспечивает широкие возможности по интеграции с различными внешними системами и модернизации ПО под уникальные требования заказчика. В то же время подобная гибкость имеет и свои отрицательные стороны, поскольку всегда есть опасность автоматизировать неэффективные ИТ-процессы или же бесконечно затянуть проект внедрения, постоянно внося различные дополнения и улучшения. В этом случае успех во многом зависит от четкой проработки будущих ИТ-процессов, квалификации команды инсталляторов и твердой позиции руководителя ИТ-службы. К тому же на управление проектом накладываются требования жесткого контроля уровня и числа переделок и доделок. Вместе с тем эффект от внедрения решения Remedy может значительно перекрывать подобные издержки.

Компания Peregrine Systems реализовала компромиссный вариант, разместив данные и их структуру на сервере БД, а логику – на сервере приложений. Таким образом, изменения структуры данных оказывают слабое влияние на логику их обработки. Поэтому риски, связанные с адаптацией этого программного продукта в соответствии с условиями заказчика, значительно ниже, чем в HP Service Desk, хотя и выше, чем у Remedy. В то же время у Peregrine Service Center опасность впасть в бесконечные переделки ниже, чем в случае с Remedy, поскольку создание распределенных конфигураций обеспечивается специальными модулями синхронизации данных между различными компонентами. К слову, те же средства используются и для интеграции с внешними системами.

Системы Service Desk набирают популярность, спрос на них растет и этот сегмент привлекает новых игроков. В частности, относительно недавно на этот рынок вышла отечественная компания Naumen со своим продуктом Naumen Service Desk. Довольно серьезную конкуренцию ведущим производителям сегодня в данном сегменте составляет и корпорация Microsoft, которая создала собственный вариант библиотеки ITIL, модифицированный под Windows-продукты, – MOF (Microsoft Operations of Framework). При этом корпорация пускает в ход различные инструменты увеличения рыночной доли и укрепления своих позиций, в частности, по сравнению с другими игроками, она имеет возможность более агрессивно регулировать свою ценовую политику.

В интересах бизнеса: системы управления ИТ-услугами


Александр Буйдов

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

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

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

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

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

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

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

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

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

Приведем простой пример. Пусть SLO — время обслуживания бизнес-пользователя приложением Х — равно, например, одной минуте. В течение дня каждый пользователь делает хотя бы один запрос к приложению Х и ждет ответа, чтобы сделать следующую операцию. Пользователей в сети насчитывается 1200 человек. Соответственно, в течение дня потери рабочего времени составляют 20 человеко-часов. С учетом, скажем, средней почасовой ставки 80 руб./час получаем прямые финансовые потери: 1600 руб. в день, 40 тыс. руб. в месяц. или 480 тыс. руб. (около 16 тыс. долл.) в год. Таким образом, усредненные инвестиции в аппаратную платформу сервера приложения Х в размере 8 тыс. долл. в год при условии сокращения времени обслуживания бизнес-пользователя до 30 секунд выглядят с точки зрения бизнеса как минимум обоснованно.

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

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

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

Назначение SLM-системы


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

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

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

Состав SLM-системы


SLM-система — это очень сложная технологическая и организационная вертикаль. Очевидно, что отчеты о качестве предоставляемых ИТ-услуг (в терминах SLA) не появляются сами собой. Подготовить и проанализировать их помогают три ключевых компонента SLМ-системы.

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

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

Третий ключевой компонент — средства подготовки и представления отчетов о текущем уровне SLA и его изменении, а также система биллинга для взаиморасчетов между потребителем и поставщиком ИТ-услуг.

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

При построении SLM-системы, как и в большинстве других подобных случаев создания комплексных ИТ-систем, обычно применяют один из двух подходов. Наиболее часто применяется подход, при котором второй и третий ключевые компоненты системы «надстраиваются» над уже существующим первым компонентом — распределенной системой мониторинга и управления (возможно, все эти компоненты разработаны разными поставщиками).

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

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

Порядок внедрения SLM-системы


Очевидно, что задача управления качеством ИТ-услуг не решается, скажем, закупкой одного программного продукта. Более того, без предварительного создания всех нижележащих слоев SLM-архитектуры внедрить такой продукт попросту невозможно. На наш взгляд, оптимальная последовательность разработки и внедрения комплексной SLM-системы состоит из следующих шести этапов.
  1. Построение подсистемы инвентаризации и управления конфигурациями с целью определения реальной картины, сложившейся в ИТ-инфраструктуре, а также построение элементарных технических и организационных процедур централизованного управления базовыми компонентами инфраструктуры — рабочими станциями пользователей, серверами и сетевым оборудованием.
  2. Построение подсистемы распределенного мониторинга, предназначенной для мониторинга и управления определенными классами элементов ИТ-инфраструктур (сетевые устройства, прикладные системы, системные сервисы, базы данных, ПО промежуточного слоя, Web-приложения, средства безопасности и др.), а также средств корреляции событий мониторинга.
  3. Построение подсистемы Service Desk. Это необходимо для поддержки рабочих процессов по обслуживанию ИТ-инфраструктуры, взаимодействию ИТ-службы с пользователями, управлению конфигурациями, изменениями и модернизацией компонентов ИТ-инфраструктуры, для разрешения возникающих проблем, а также для мониторинга некоторых параметров SLA, например времени разрешения проблем пользователей.
  4. Построение системы мониторинга бизнес-систем. Внедрение подсистемы мониторинга процессов взаимодействия различных компонентов ИТ-инфраструктуры, задействованных в обеспечении функционирования отдельных бизнес-процессов (технологических цепочек), необходимо для более качественного анализа работы ИТ-инфраструктуры и относится к данным мониторинга «второго уровня».

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

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

Инвестиции


По оценкам некоторых западных аналитиков, стоимость SLM-систем в среднем составляет до 30% стоимости собственно информационных систем. Такие значительные инвестиции вызваны как высокой базовой стоимостью самих SLM-продуктов, так и значительными объемами предпроектной аналитической проработки решения и большими затратами на сопровождение системы.

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

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

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

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


Требования к SLM-системе

Александр Буйдов


Среди обязательных требований к программному инструментарию SLM-системы можно выделить следующие:
  • встроенная поддержка стандартов ИТ-управления (прежде всего ITIL/ITSM);
  • мониторинг максимально возможного количества технических параметров компонентов ИТ-инфраструктуры: сетевого оборудования, аппаратных платформ, прикладных систем и др.;
  • возможность и простота разработки программных адаптеров (мониторов) для отслеживания тех компонентов ИТ-инфраструктуры, для которых не предлагается адаптеров в коммерческом продукте поставщика (приложения собственной разработки, программные продукты третьих производителей и др.);
  • наличие специализированных продуктов мониторинга и управления наиболее распространенными на рынке элементами ИТ-систем: серверы приложений (например, SAP R/3, Siebel), СУБД (Microsoft SQL Server, Oracle), операционные системы, сетевые устройства, средства защиты информации и др.;
  • возможность отслеживания технических метрик прохождения типовых транзакций в ИТ-инфраструктуре — от рабочей станции пользователя через все элементы информационной системы к бизнес-приложению и данным и назад к пользователю;
  • встроенная реализация процедур поддержки принятия решений по изменению конфигураций элементов ИТ-инфраструктуры, а также их модернизации;
  • анализ тенденций развития отдельных элементов ИТ-инфраструктуры и их совокупностей с целью прогнозирования отказов или снижения качества предоставляемых ею ИТ-услуг;
  • интеграция с внешними системами мониторинга, формирования отчетов, OLAP-средствами, системами Service Desk и Help Desk, системами бизнес-аналитики и др.

Главным требованием к SLM-системе является ее способность однозначным образом связывать изменение какого-либо атрибута отдельного элемента ИТ-инфраструктуры с соответствующими метриками SLA. Чем полнее и развитее будет картина таких связей, тем прозрачнее будет сам процесс управления для поставщика ИТ-услуг.

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


Выбор продукта для реализации SLM-системы


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

По данным Ассоциации управления предприятиями (Enterprise Management Association), сегодня в мире насчитывается порядка 70 поставщиков SLM-продуктов. Однако наиболее полнофункциональные продукты по-прежнему предлагают только представители «большой четверки» в области ИТ-управления — IBM, BMC, CA и HP. Вот список этих продуктов:
  • HP OpenView от Hewlett-Packard;
  • Tivoli Service Level Advisor от IBM;
  • Unicenter Service Level Manager от Computer Associates;
  • Remedy IT Service Management Suite от BMC Software.



/document_for_print.asp?d_no=11091&p=1