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

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

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

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

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

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

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

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

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

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

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

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

Инвестиции

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

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

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

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

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

Александр Буйдов — директор по ИТ компании «Крок», Buydov@croc.ru

Требования к 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.