Что такое ресурсно сервисная модель

Роль технической поддержки в работе облачного провайдера

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

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

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

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

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

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

Основные обязанности специалистов службы технической поддержки:

Рассмотрим подробнее эти обязанности.

Как сотрудники технической поддержки узнают о сбоях в инфраструктуре

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

Ресурсно-сервисная модель и служба технической поддержки

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

В состав облачных услуг IaaS или VPS входя следующие компоненты:

Услуги IaaS или VPS зависят от работоспособности физических серверов, систем хранения, услуг Интернет-провайдеров и дата-центров, где размещается оборудование провайдера.

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

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

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

Системы мониторинга

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

Система SCOM

Средства мониторинга Zabbix

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

В случае появления инцидента эта система мониторинга также позволяет немедленно информировать администраторов через e-mail или telegramm.

Оповещение клиентов о сбоях

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

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

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

Help Desk и работа с запросами пользователей

Запросы пользователей могут приходить по различным каналам: телефону, e-mail, через форму обратной связи. Каждому обращению, как и в случае с инцидентами, присваивается номер и создается соответствующий тикет в системе Help Desk. Цель Help Desk системы, помимо исключения потери заявок от клиентов, максимально быстро решить возникшую проблему или выполнить запрос пользователя. Это в первую очередь влияет на конечную удовлетворенность клиентов. Если заявки решаются в соответствии с ожиданиями потребителей услуг, то клиенты будут довольны и не будет искать другого провайдера.

Таким образом, Help Desk система напрямую влияет на срок взаимодействия клиента с провайдером. Как показывают различные исследования, это критически важно, потому что:

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

Все системы Help Desk можно разделить на 3 основных класса:

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

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

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

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

Источник

Зачем строить ресурсно-сервисную модель ИТ-услуг

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

Что такое ресурсно-сервисная модель

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

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

Ресурсно-сервисная модель услуги «Корпоративная Электронная почта»

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

Как группируются активы в ресурсно-сервисной модели

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

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

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

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

Принцип организации классификации активов

Каждый элемент классификации и его дочерний компонент определяет:

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

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

Пример классификации ресурсно-сервисной модели для услуги «Корпоративная Электронная почта»

В практике NAUMEN роль классификатора выполняет услуга и ее сервисные компоненты (составные части). Помимо выполнения функциональных требований к классификатору это позволяет:

Схематично это объединение выглядит следующим образом.

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

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

Ресурсно-сервисная модель для каждой услуги должна располагать горизонтальные группы (типы активов) в зависимости от связей между активами. Организация взаимосвязей между активами и управляющими ими услугами — тема отдельной статьи.

Зачем строить ресурсно-сервисную модель услуг и настраивать связи между активами

1. Оптимизируется работа специалистов по поддержке

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

2. Повысится скорость изменений ИТ-активов

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

3. Станет легче найти причину сбоя и сократить простои оборудования

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

4. ИТ-инфраструктура компании станет наглядной

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

Источник

Уровни и связи в ресурсно-сервисной модели

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

Что такое ресурсно-сервисная модель

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

Чтобы предоставить пользователям услугу «Электронная почта», потребуется определенное ПО, которое работает на нескольких виртуальных серверах. Каждый из них в свою очередь расположен на физических серверах. Чтобы разместить их в компании, понадобятся стойки и специальное помещение — центр обработки данных (ЦОД). В ресурсно-сервисной модели эти связи визуально отражены.

Ресурсно-сервисная модель, отражающая зависимость услуги «Электронная почта» от активов

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

Как группируются активы в ресурсно-сервисной модели

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

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

Горизонтально активы объединяются по типам.

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

Не существует универсального расположения «уровней». В модели одной услуги оборудование поддерживает ПО, тогда как в другой услуге ПО координирует работу оборудования. В третьей услуге может не быть «уровня» оборудования, т.к. она поставляется «из облака».

Ресурсно-сервисная модель для каждой услуги должна располагать горизонтальные группы (типы активов) в зависимости от связей между активами. Организация взаимосвязей между активами и управляющими ими услугами — тема отдельной статьи.

Зачем строить ресурсно-сервисную модель услуг и настраивать связи между активами

1. Оптимизируется работа специалистов по поддержке ИТ-инфраструктуры

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

2. Повысится скорость изменений ИТ-активов

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

3. Станет легче найти причину сбоя и сократить простои оборудования

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

4. ИТ-инфраструктура компании станет наглядной

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

Источник

Ресурсно-сервисные модели (РСМ). Упражнение

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

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

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

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

Дубль №114. Мотор!

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

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

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

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

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

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

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

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

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

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

Интересным объектом схемы является сервисный актив «Данные о КЕ и их группах обслуживания». Без предоставления этой информации выполнение работ по преобразованию услуг и их компонент невозможно, т.к. либо отсутствует информация об объекте изменения, либо доступ к тем «рукам», которые это самое изменение будут реализовывать. Очевидно, что полнота этой информации будут определять границы охвата процесса или ответственности поставщика услуг в нем.

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

Хорошей мыслью «на обдумать» является вопрос, а где же тут ITSM система? Может ли она быть представлена одним кубиком? Может ли » ITSM система » быть услугой, и если да, то как обозначать нашу зависимость от отдельных её компонент, таких как форма подачи RFC. Что означает для нее «доступность»?

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

Почем фунт лиха?

«Нет, все это просто прекрасно! И это интеллектуальное упражнение нас так увлекло, что мы потратили на это половину рабочего дня! Нам понравилось это все рисовать!» – можете воскликнуть вы.

Но зачем нам нужна эта схема?

Используя знания об архитектуре услуги вы сможете:

На мой взгляд – совсем не мало.

Спасибо за то, что прочитали. Комментарии и критика приветствуются!

Источник

Применение сервисно-ресурсной модели как эффективного инструмента ИТ-службы

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

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

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

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

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

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

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

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

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

Проект по построению системы управления ИТ

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

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

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

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

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

В библиотеке ITIL v3 2011 Edition в книге Service Strategy приведено определение модели сервиса, на наш взгляд, наиболее близкое к СРМ: модель сервиса (service model) — модель, показывающая, как сервисные активы взаимодействуют с активами заказчика для создания ценности. Модели сервиса описывают структуру сервисов (взаимодействие конфигурационных единиц друг с другом) и сервисы в динамике (деятельность, потоки ресурсов, взаимодействия). Модель сервиса может быть использована как шаблон для нескольких сервисов.

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

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

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

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

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

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

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

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

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

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

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

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

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

В области управления финансами использование СРМ может помочь в учете затрат на предоставление сервисов, а также в определении себестоимости сервиса, которая включает:

• затраты на персонал, обслуживающий компоненты сервиса;

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

• затраты на поддерживающие сервисы (каналы связи, резервное копирование и т. д.);

• затраты на расходные материалы.

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

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

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

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

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

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

Рисунок

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

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

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

• формирование каталога ИТ-сервисов, включая выбор бизнес-процесса, разделение его на бизнес-функции и определение ИТ-сервисов;

• определение параметров качества ИТ-сервисов и целесообразности создания СРМ;

• проектирование СРМ и методов расчета показателей качества сервисов;

• контроль параметров качества сервисов.

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

Поделитесь материалом с коллегами и друзьями

Источник