Портал №1 по управлению цифровыми
и информационными технологиями

Услуги – CI или не CI?

Опубликовано 25 декабря 2013
Рубрики: CMDB, конфигурации и активы, Вопрос из зала, Практика и опыт, Технологии, автоматизация, ПО для ITSM
Комментарии

Продолжается обсуждение непростой темы управления конфигурациями. Андрей спрашивает:

Коллеги,

кто нибудь может внятно объяснить, зачем стоит заводить в CMDB CI типа "Услуга" ?  

Рассмотрим случай, когда в информационной системе есть сущности типа "услуга" за рамками CMDB (например отдельная папка SLM и отдельная папка CMDB в OMNITRACKER). Понятно, что каждая CI должна быть связана с услугой, но для этого не обязательно связывать СI типа "сервер" с CI типа "услуга". Проставили в карточке CI в поле услуга нужную услугу и все. На деле же часто вижу примеры CMDB как дерево CI-ев, где есть CI в традиционном понимании (ПО, Железо, конфигурации серверов и тд) и CI типа "услуга". Есть ли ответ на мой вопрос, отличный от "а зависит от важего желания, инструментария etc"? 

 

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Управление изменениями и конфигурациями в ИТ
Повысить долю успешных изменений, снизить риски, знать всё про конфигурации

Также по теме:

Комментариев: 14

  • Yury

    Услуга как CI полезна, как минимум, для того чтобы указать влияние того или иного CI на сервис, а потом с помощью симулятора влияния (если инструмент умеет), моделировать ущерб для сервиса(ов) от конкретного CI (при оценке изменения или инфраструктурном сбое).

  • Дмитрий Исайченко

    Это очень хороший и глубокий вопрос, спасибо! Ответ надо разделить на две части – на услуги, которые мы предоставляем (busness services), и на услуги, которые мы потребляем (supporting services).

    На мой взгляд Supporting services (особенно внешние) – отличный кандидат на учет именно в CMDB, поскольку это компоненты, которые мы используем при предоставлении своих услуг. Например, каналы передачи данных – в чистом виде услуги. Где же мы их учитываем, если не в CMDB? То есть эта часть ответа – методическая.

    Что касается business services, то ответ скорее технический. Все зависит от того, какие возможности предоставляет ваша ITSM-система. Например, если она умеет моделировтаь влияние только между CI, а вам необходимо моделировать влияние CI на услуги, услуги также придется завести в CMDB. Или, например, если система умеет заключать SLA только в привязке к объектам ыделенного радела "Каталог услуг", а вам необходимы SLA, придется завести услуги в каталог услуг. В некоорых ITSM-продуктах, повинуясь этой логике, услуги придется дублировать – и в CMDB, и в каталоге (это в первую очередь касается внутренних supporting services).

    • Alexey Yusov

      Дмитрий, не соглашусь с Вами по первой, методической, части. Во-первых пример, приведенный Вами не удачный. Канал передачи данных в реальности состоит из многих, вполне себе отдельных КЕ. А услуга "Передача данных" может предоставляться с помощью 1-го основного и 2-х резервных каналов. А во-вторых, потому что по факту общий ответ на  вопрос как раз технический.

      А вот с технической стороной соглашусь полностью, отнеся сюда же и Supporting services. Всё действительно зависит от возможностей средства автоматизации. Понятно, что если ITSM-система не умеет задавать связи Услуга-КЕ типа "Зависит от" или "Требуется для", то придется Услуги вместо каталога услуг помещать в CMDB. Жизнь заставит, и не так придётся фантазировать. Я видел, когда из клиентов делали КЕ 🙂

      Но фактически это либо незнание возможностей системы, либо их (возможностей) отсутствие.

      В некоорых ITSM-продуктах, повинуясь этой логике, услуги придется дублировать — и в CMDB, и в каталоге (это в первую очередь касается внутренних supporting services).

      А это в каких, не подскажете?

      • Дмитрий Исайченко

        Дмитрий, не соглашусь с Вами по первой, методической, части.

        Если канал не Ваш, а предоставляется Вам внешним провайдером, то:

        1. Вы не знаете состав CI, образующих канал.

        2. Вы не контролируете изменение состава CI и их характеристик.

        В силу пунктов 1-2 учитывать структуру канала в рамках CMDB (Вашей) и не нужно, и не удастся (к слову в книгах ITIL есть прямое указание, что в область охвата CMDB могут попадать только те объекты, в отношении которых Вы обладаете должным уровнем контроля). Учитывать же канал целиком – напротив – и есть зачем (во многих случаях – и с финансовой, и с технической точек зрения, и  для учета влияния на предоставление услуг), и вполне реалистично. И даже если Вы для хранения канала в CMDB будете использовать категорию CI "Network channel", по смыслу это будет именно внешняя поддерживающая услуга. Это методически.

        Теперь, почему на практике каналы все-таки учитывают как каналы, а не как услуги. На мой взгляд, по двум причинам:

        1. В силу наличия у CI соответствующей категории специфичного атрибутного состава и, возможно, некоторой бизнес-логики.

        2. Во многих случаях в рамках одного договора с ISP предоставляется сразу несколько каналов и сетей. Индивидуальные каналы и сели учитываютя как CI, но дополнительно учитывается договор на оказание соответствующей услуги, связанный с отдельными CI. То есть индивидуальные каналы и сети предоставляются Вам в качестве ресурсов (о ресурсах, которые предоставляются в виде услуги, см. здесь: http://www.cleverics.ru/ru/subject-field/articles/400-computer-as-a-service). Это технически.

  • Alexey Yusov

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

    Я бы лично воспринимал внешний канал передачи исключительно как инфрастуктурную услугу-сервис. Меня не интересуют риски владения составными частями самого канала, меня интересуют только конечные характеристики – скорость и надежность, как параметры количественные, и время доступности сервиса – SLA

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

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

  • Oleksandr Vinnytskyi

    Я в своей практике всегда использовал CI как сервис по следующим причинам:

    1. В продуктах, которые приходилось внедрять, Каталог сервисов предназначен для размещения Предложений (Offerings), по сути это бизнес-представление описания услуги или запроса в рамках услуги, выполнение которого регламентировано (Standart Change). А Потфеля сервисов как отдельного функционала (сущности) нет, соответственно, для описания полного жизненного цикла Услуги использовались CI.

    2. Как уже упоминал Yury, для использования связей выделенного типа, чтобы отслеживать именно взаимное влияние Услуг друг на друга, а не компонентов на работу конкретной услуги.

    3. CI типа "Сервис" позволяет представить в ITSM-системе связь Технического представления услуги с Бизнес-представлением в виде такой сущности как SDP (Service Design Package), с возможностью отслеживания последних изменений

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

    • Alexey Yusov

      Очень интересные продукты Вам приходилось внедрять. Чтобы не сочли за рекламу, не буду говорить, что внедряю я, но по всем 4 пунктам я могу оставить сервис сервисом, а CI – CI`ем в их истинном значении.

      С нетерпением жду комментария Дмитрия.

      • Дмитрий Исайченко

        С нетерпением жду комментария Дмитрия.

        Алексей, я не хочу здесь упоминать имен продуктов (помню и в других ветках у нас были подобные "неотвеченные" вопросы про названия конкретных продуктов). Такие продукты действиьельно есть, но речь здесь больше не о них, а о вариантах учета CI и услуг. Ну а здесь вроде бы определились – и с вариантами, и с поюсами / минусами.

      • Vladimir Lyaleko

        Алексей, а не могли бы вы пояснить, что понимается под "истинным  значением CI"?

        Глядя на глоссарий ITIL и описание типов CI в книжке ST, появление CI с типом "Услуга" кажется вполне логичным. 

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

        т.е. вопрос  был бы сформулирован так:

        Кто нибудь может внятно объяснить, зачем стоит заводить  отдельную сущность в системе если в CMDB есть CI типа "Услуга" ?  

        Ответы были бы аналогичны :))

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

         

         

         

         

         

         

         

         

         

         

         

         

         

        • Дмитрий Исайченко

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

          Владимир, не могу с Вами согласиться. Не проталкивал "своих решений" ни там, ни здесь. Можете указать на пример проталкивания?

          • Vladimir Lyaleko

            Не правильно выразился 🙁  Имел ввиду, что все мы подвластны привычкам, которые сформированы определенными технологиями…. Вот вы создали свою систему автоматизации, но сколько в ней от HP OV?! Заказчики не готовы отказываться от своих привычек… я скорее об этом 🙂

        • Alexey Yusov

          В книгах много чего написано. Но определение CI как некоего компонента для предоставления Услуги и пример, что CI может юыть Услугой, это классическая логическая ошибка, известная как "idem per idem". Так что если на клетке со слоном будет написано "буйвол", я буду доверять своим ощущения и понятиям.

          Под влияением каких производителей ПО писался ITIL – известно, даже без называния имен. Может они и не умеют по другому. Вот автор вопроса привел в пример OMNITRACKER. Там судя по описанию все верно с моей точки зрения (особо прошу отметить, что OT не "мой "продукт). Хотя и тут может сильно зависить от желания клиента или внедренца сделать некий сервис как CI.

          Так что моя позиция близка к позиции Дмитрия, что он и подвердил, отметив сближение :). Но все-таки я предпочитаю инфструктурные по сути своей элементы не считать как CI типа "Сервис". Может я и отродоксален, но я буду перед клиентом отстаивать свою точку зрения, пока клиент не скажет "Хочу инфраструктурные сервисы были CI`ями и точка!". Наше дело предложить – ваше дело отказаться. Что поделаешь, так бывает. Ведь смена тактильных, визуальных и понятийных ощущений у человека – это всегда стресс. А мы должны сделать нашего клиента счастливым!

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.