Сервисно-ресурсная модель. От теории к практике

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

— понятия и термины, используемые при построении СРМ: сервис, ресурс, сервисно-ресурсная модель, качество и т. д.;

— назначение и цели создания СРМ: каковы функции моделей и для каких целей они могут быть использованы;

— определение ключевых принципов и правил построения СРМ, в частности определение формата построения (в виде документа, схемы или рисунка), правил автоматизации, типов компонентов и их связей и т. д.;

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

Сформулированные в статье принципы и рекомендации построения СРМ основываются на проектном опыте авторов. Для иллюстрации сформулированных принципов методика описывается на базе одного из проектов, выполненных авторами (см. врезку).

Терминология СРМ

На данный момент в литературе по ITSM нет устоявшегося описания термина СРМ. Поэтому в первую очередь необходимо определиться и зафиксировать используемые термины, что мы и сделали в рамках нашего проекта. В библиотеке ITIL v3 2011 Edition в книге Service Strategy [1] приведено определение модели сервиса, на наш взгляд, наиболее близкое к СРМ:

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

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

Перейдем к определению модели.

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

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

Назначение СРМ

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

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

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

1. В рамках стратегического процесса формирования портфеля сервисов СРМ может быть использована для идентификации заказчиков, их требований и для определения возможностей поставщика сервисов по удовлетворению данных требований.
2. В рамках процесса управления уровнем обслуживания (SLM) СРМ позволит уже на начальных этапах жизненного цикла сервиса при сборе требований и согласовании проекта сервиса выделить его компоненты, их характеристики, а также связи между собой и со смежными сервисами и компонентами, за счет чего может быть оценена стоимость внедрения нового сервиса.
3. В рамках операционных процессов СРМ может помочь при оценке влияния инцидентов на предоставляемые ИТ-сервисы, анализе и диагностике проблем в разрезе компонентов модели.
4. В рамках процесса управления доступностью СРМ позволяет осуществлять мониторинг параметров качества ИТ-сервисов как в оперативном режиме в визуальном представлении, так и для построения отчетности за выбранный период.
5. В рамках процесса управления конфигурациями создание сервисно-ресурсных моделей является своеобразной надстройкой над CMDB и позволяет структурировать конфигурационные единицы и учитывать их влияние на ИТ-сервисы.
6. В рамках процесса управления изменениями СРМ позволяет планировать и анализировать влияние изменений, проводимых в ИТ-инфраструктуре, на смежные сервисы и компоненты. Такие действия полезно выполнять для сервисов, предоставление которых требует отлаженной работы сложного взаимосвязанного набора компонентов.
7. В рамках процесса управления финансами использование СРМ может помочь в учете затрат на предоставление сервисов, а также в определении себестоимости сервиса, которая включает:

• амортизацию основных средств – компонентов сервиса (серверное оборудование, ПО, оргтехника и т.д.);
• затраты на поддерживающие сервисы (каналы связи, резервное копирование и т. д.);
• затраты на расходные материалы;

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

Как видим, применение СРМ возможно не только в процессах эксплуатации сервисов, таких как управление инцидентами, проблемами, доступом, но и в процессах стратегии, проектирования и преобразования сервисов (в терминах ITIL v3).

Однако необходимо четко понимать, что создание СРМ целесообразно далеко не для всех компаний, а также не для всех сервисов. Простые с технологической точки зрения сервисы (сервис формируется на базе единого программно-аппаратного комплекса «коробочного» типа, в котором большинство параметров и взаимосвязей заданы жестко) часто не имеет смысла разбивать на компоненты; легче представлять сервис в виде «черного ящика» с определенными макрохарактеристиками. Например, сервис «Обеспечение функционирования системы Service Desk», имеющий стандартизованные компоненты, определенные вендором, часто имеет смысл учитывать только с точки зрения «работает – не работает», а сервис «Обеспечение функционирования автоматизированной банковской системы» – разбивать на компоненты и оперативно контролировать связи между ними.

Одной из ключевых целей использования СРМ является мониторинг параметров качества ИТ-сервиса, который может выполняться в рамках процесса управления доступностью. Что подразумевается под качеством сервиса? Для начала приведем определение термина «качество» согласно ISO 20000.

Качество – это способность набора неотъемлемых характеристик продукта, системы или процесса удовлетворять требованиям заказчиков и других заинтересованных сторон.

На практике под качеством ИТ-сервиса мы предлагаем понимать комплекс измеримых характеристик ИТ-сервиса, отвечающих ожиданиям заказчика. В качестве таких измеримых характеристик ITIL в разделе описания процесса управления доступностью приводит следующие показатели:

• доступность (availability);
• производительность (performance);
• надежность (reliability);
• сопровождаемость (maintainability);
• обслуживаемость (serviceability);
• безопасность (security).

Порядок создания СРМ

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

Мы используем в проектах общую методику построения СРМ, состоящую из следующих пяти шагов:

1. Формирование каталога ИТ-сервисов, включая выбор бизнес-процесса, разделение его на бизнес-функции и определение ИТ-сервисов.
2. Определение параметров качества ИТ-сервисов и целесообразности создания СРМ.
3. Проектирование СРМ и методов расчета показателей качества сервисов.
4. Автоматизация СРМ.
5. Контроль параметров качества сервисов.

Рассмотрим эти шаги подробнее на примере проекта, выполненного в банке.

Шаг 1. Формирование каталога ИТ-сервисов: выбор бизнес-процесса, разделение его на бизнес-функции и определение ИТ-сервисов

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

Например, в банке при проектировании СРМ был выбран ключевой бизнес-процесс выдачи потребительского кредита и выделены основные бизнес-функции: регистрация анкеты на потребительский кредит, печать анкеты на кредит, подготовка договора на его выдачу (рис. 1). Проектирование каталога сервисов выполнялось совместно с ответственными за сервисы (роль «владелец сервисов» в терминологии ITIL) со стороны банка. Также в проектировании моделей участвовали менеджер каталога сервисов, менеджеры процессов управления конфигурациями, изменениями и уровнем сервисов. Если существуют другие процессы, в ходе исполнения которых требуется использование СРМ, необходимо также принять решение об их участии.

При проектировании был выделен бизнес-сервис «Обеспечение работы АРМ кредитного работника», который поддерживает выбранные бизнес-функции. Сервис обеспечивает безопасные каналы для обмена информацией между локальными клиентскими рабочими станциями пользователей с централизованными бизнес-приложениями, предоставляя доступ к сетевым ресурсам.

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

Рис. 1. Бизнес-функции, бизнес-сервисы и технические сервисы

Шаг 2. Определение параметров качества ИТ-сервиса и целесообразности создания СРМ

Сформировав каталог ИТ-сервисов, необходимо определить основные параметры качества входящих в него сервисов и принять решение о целесообразности создания СРМ-сервисов. Определение параметров сервисов подразумевает согласование с заказчиком сервиса показателей, которые необходимо исполнять и контролировать. Шаг включает определение параметров качества выбранных на шаге 1 бизнес-функций, которые должны быть обеспечены работой бизнес-сервисов, их поддерживающих. Данный шаг обычно выполняется в рамках процесса управления уровнем обслуживания (SLM), а согласованные показатели качества закрепляются в виде соглашений об уровне сервисов (SLA).

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

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

— скорость открытия формы анкеты на потребительский кредит;

— скорость открытия реестра зарегистрированных заявок;

— скорость открытия справочников;

— скорость формирования бланка отчета о регистрации заявки.

Характеристика «Скорость открытия формы анкеты на потребительский кредит» явным образом определяет количество поступающих на рассмотрение кредитным работником заявок и косвенно влияет на объем положительных решений о выдаче потребительских кредитов и выручку банка. В рамках проекта было принято решение о том, что данные параметры требуют точного и оперативного контроля для обеспечения возможности быстрого реагирования. Как следствие, было принято решение о создании СРМ для критичных сервисов.

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

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

— автоматизированная банковская система (включая сервер приложений, подсистему хранения данных, СУБД);

— терминальный сервис, данный компонент был внесен в CMDB с категорией «технический сервис» и названием «терминальный сервис»;

— локальная вычислительная сеть.

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

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

Так, для расчета показателя качества сервиса в банке была выбрана характеристика технического сервиса «Терминальный сервис», а под доступностью сервиса «Обеспечение АРМ кредитного работника» понималось поддержание определенного согласованного количества параллельных пользовательских терминальных сессий (например, 1000) в течение оговоренного времени. При этом установленный целевой показатель доступности 99,9% в месяц означает, что в течение месяца число одновременных терминальных сессий в рабочее время должно быть не менее 999.

При расчете того или иного показателя необходимо обратить внимание на такой важный нюанс, как периодичность отчетности. От выбранного периода отчетности по показателю сервиса зависит его выполнение или невыполнение. Для примера, доступность 99,9% круглосуточно предоставляемого сервиса означает, что простой сервиса не может быть более 8,76 часа в год, то есть 43,2 минуты в месяц или 10,1 минуты в неделю. Если за отчетный период взять неделю, а не месяц или год, то простой сервиса в 11 минут будет означать нарушение SLA, даже если в последующие дни месяца простоев не будет.

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

Шаг 3. Проектирование СРМ и методов расчета показателей качества сервисов

После того как на шаге 2 принято решение о построении СРМ для выбранных сервисов и определены параметры качества сервисов, необходимо спроектировать непосредственно сами СРМ. Мы советуем проектирование СРМ начинать с определения ключевых правил проектирования, единых для каждой модели ИТ-сервиса.

В своих проектах наша компания предлагает заказчикам брать за основу следующие правила проектирования СРМ:

1. Проектирование начинать сверху вниз, то есть от сервиса к элементам ИТ-инфраструктуры, определив логические уровни модели. Под логическими уровнями модели понимаются категории конфигурационных единиц (КЕ) и технические сервисы, определенные в CMDB, которые располагаются в иерархической последовательности при составлении бизнес-сервиса. До начала проектирования СРМ должен быть формализован процесс управления конфигурациями, который предоставит CMDB и актуальную информацию о КЕ.
2. Связи устанавливаются только между элементами, оказывающими непосредственное влияние на параметры качества вышележащих элементов, что обеспечивает формирование показателя качества бизнес-сервиса, для которого строится СРМ.
3. Между элементами модели могут быть только иерархические связи, что обеспечивает однозначное влияние показателей компонентов на выбранный показатель качества бизнес-сервиса.

Для визуализации структуры СРМ мы рекомендуем использовать единый шаблон, который представляет собой графическое отображение уровней с примерами КЕ и всех типов связей на каждом уровне (рис. 2). Шаблон позволяет согласовать общие принципы и состав СРМ с проектной командой, на шаге 4 построения модели он будет оперативно заполнен для каждого сервиса, а в ходе эксплуатации обеспечит возможность унифицированной поддержки разработанных моделей. Для оформления шаблона можно использовать специализированные программные средства, например Microsoft Visio.

Рис. 2. Фрагмент шаблона СРМ, заполненного для сервиса «Терминальный сервис»

Шаг 4. Автоматизация СРМ

На основании шаблона и общих правил, определенных на шаге 3, составляется СРМ и производится ее автоматизация. Автоматизация СРМ подразумевает перенесение модели на программную платформу и интеграцию с существующими системами. Обычно для этого привлекаются специалисты, ответственные за обслуживание компонентов соответствующего сервиса.

Для независимого выбора ПО заказчикам необходимо понять возможности и особенности продуктов, представленных на рынке, и принять осознанное решение еще до выбора поставщика сервисов. Например, банк определился с ПО в пользу платформы IBM Tivoli, с помощью которой будет выполнена автоматизация СРМ, еще до выбора исполнителя в проекте. Для автоматизации СРМ был выбран продукт IBM Tivoli Business Service Manager (TBSM), который обладает функциями наглядного представления информации о СРМ в визуальном виде и позволяет «из коробки» интегрироваться с широким набором систем мониторинга, учитывать параметры качества при отображении состояния сервиса и его компонентов в реальном времени.

При выборе ПО автоматизации СРМ стоит обратить внимание на следующие характеристики продукта:

• соответствие всем целям построения СРМ, которые определены на шаге 2;
• возможность тесной интеграции с системой автоматизации процессов управления ИТ-сервисами;
• возможность тесной интеграции с системами мониторинга;
• возможность автоматизированного наполнения СРМ новыми КЕ с помощью средств обнаружения;
• имеющиеся ограничения.

Одним из наиболее важных критериев выбора ПО для автоматизации СРМ являются ограничения выбираемого продукта. Как правило, базовые элементы СРМ (категории КЕ, их атрибуты, а также связи между КЕ) присутствуют в наборе функций ПО, предназначенного для автоматизации CMDB (например, IBM Tivoli CCMDB, HP uCMDB и т. д.). Такое ПО можно использовать в том числе для автоматизации СРМ, но часто набор его функций не позволяет в полной мере решить задачи, поставленные перед моделью. Например, для визуализации или фиксации в реальном времени момента, когда нарушается доступность ИТ-сервиса, требуется специализированное ПО с функциями оперативного мониторинга доступности сервиса.

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

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

Шаг 5. Контроль параметров качества сервисов

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

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

Помимо этого, руководство ИТ-службы, а также ответственные за сервис имеют возможность визуального контроля состояния сервисов. Интерфейс Tivoli Business Service Manager (рис. 3) позволяет вывести список ИТ-сервисов, оперативную информацию о доступности сервисов, показать фрагмент СРМ для одного сервиса и список событий (инцидентов), влияющих на состояние сервиса.

Рис. 3. Пример реализации СРМ в IBM Tivoli Business Service Manager

В рамках аналитического контроля создание СРМ позволяет ИТ-службам накапливать статистику о качестве предоставляемых сервисов и впоследствии на ее основе определять целевые значения показателей и включать их в SLA (рис. 4).

Рис. 4. Отчет о доступности сервиса «Терминальный сервис» за отчетный период с детализацией по каждому дню и отображением доступности в виде графика

Заключение

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

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

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

Вариант статьи опубликован в «Альманахе ITSM 2012» itSMF России

Литература.

1. ITIL Service Strategy, – Norwich, UK: TSO, 2011. – 359, 453 p.

Вадим Голубцов (VGolubtsov@computel.ru) — ITSM-консультант, Computel System Management

Михаил Федоренко (MFedorenko@computel.ru) — руководитель ITSM-практики, Computel System Management