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

Конфигурационные единицы, которых нет

Опубликовано 4 февраля 2011
Рубрики: CMDB, конфигурации и активы, ITIL, ITSM, Обо всём на свете, Управление доступностью, Управление изменениями, Эксплуатация ИТ
Комментарии

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

Давайте рассмотрим пример.

Ниже привожу тоже самое, но в текстовом виде.

Для примера предлагаю рассмотреть следующую схему:

  1. Есть ИТ-сервис (например, электронная почта)
  2. ИТ-сервис зависит от работы ИТ-системы (например, "Почтовый сервер")
  3. ИТ-система установлена на сервер 
  4. Теперь представим, что ИТ-системы две и они располагаются на двух серверах, при этом сервера расположены на разных площадках.
  5. При этом, для нормальной работы ИТ-сервиса необходимо, чтобы ИТ-системы обменивались данными.
  6. Т.к. сервера, на которых стоят ИТ-системы, расположены на разных площадках, то для работы ИТ-сервиса важно, чтобы работала связь между площадками.

Вопрос: как отразить эту зависимость ИТ-сервиса от канала связи?

Вариантов несколько:

  1. Напрямую связать ИТ-сервис и канал связи. Не нравится, т.к. таких компонентов будет много и ясности картинке это не добавит. Мы получим ИТ-сервис, связанный напрямую с кучей ресурсов, что не только ненаглядно, но и трудоемко в актуализации. Нам придется каждый чих в инфраструктуре отражать в связях ИТ-сервиса (если есть детальная спецификация, то и в ней).
  2. Сказать, что канал связи влияет на работу ИТ-систем и как следствие на ИТ-сервис. Не нравится, т.к. это не всегда будет соответствовать действительности. ИТ-системы могут прекрасно продолжать работать и без канала связи, но при этом ИТ-сервис будет предоставляться со сниженным качеством, причем снижение качества может стать заметно очень не сразу.
  3. Ввести некую несуществующую конфигурационную единицу "App. Data Exchange", которую связать с каналом, сетевым оборудованием и остальными компонентами, которые будут необходимы для обмена данными между ИТ-системами. И уже ее связать с ИТ-сервисом.
ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Управление поддержкой ИТ-услуг
Строим эффективную ИТ-поддержку, оптимизируем существующую

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

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

  • Анатолий Павлюченко

    “как отразить эту зависимость ИТ-сервиса от канала связи?”
    В чём отразить и для каких целей? О каком уровне абстракции мы говорим?

    • Евгений Шилов

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

      Цели простые – надо иметь возможность оценивать влияние выхода из строя компонент инфраструктуры на ИТ-сервисы.

      • Анатолий Павлюченко

        Тогда вариант 1. Канал связи – это полноправный “компонент инфраструктуры” (даже с провайдером в ролике). Что до наглядности и актуализации, то это вопрос применяемых инструментов. Разве нет?

        • Евгений Шилов

          Такой вариант, конечно возможен. Но чем он не нравится лично мне, это тем, что:
          1. Придется от канала связи, сетевого оборудования, и всего что на пути между серверами площадки А и B тянуть связи до ИТ-сервиса.
          2. Если протянуть такие связи, то каждый раз при обновление инфраструктуры связи между сайтами, придется обновлять эти связи опять-таки на уровне ИТ-сервиса.
          3. Теперь представьте, что таких ИТ-сервисов несколько. Мы получим абсолютно непроходимую и нечитаемую схему из которой будет не очень понятно почему и как влияет канал связи на ИТ-сервис.

          • Анатолий Павлюченко

            Если мы говорим о рисовании маркером на доске, то да, это нереально. 🙂
            А я себе представляю модель здоровья сервиса, спроектированную и актуализируемую (автоматически, почти в реальном времени) в инструменте мониторинга инфраструктуры, которая, также автоматически слинкована в инструменте управления сервисам и дополнена атрибутами, которых нет в мониторинге.
            Не рекламирую продукт, но я это сам трогал ручками. Эта часть выглядит очень здорово!

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

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

              Чтобы проверить предложенное Вами решение давайте ответим на несколько контрольных вопросов:

              1. С кого спрашивать, если система мониторинга не угадала, связь не поставила, канал остановили, о системе не позаботились? Специалисты тут же скажут: “Это не мы – система дурацкая, не разобралась”.
              2. Как система отдискаверит не факт связи между системами (сетевой обмен отследить нетрудно), а факт зависимости услуг от этого обмена? Я не знаю ни одного модуля инвентаризации, который умеет дискаверить такие связи. А Вы?
              3. Как на схеме появятся связи, которые отображают не синхронный обмен, а, например, регулярный обмен на уровне репликации файлов? Я не знаю ни одного модуля инвентаризации, который умеет дискаверить такие связи. А Вы?

              • Анатолий Павлюченко

                Вначале маленькое уточнение №1. “Слинковать” не равно “импортировать”. Имеется в виду связь на постоянной или регулярной основе, которая не требует частых возвратов и дополнительной настройки.
                Уточнение №2. Любое предложенное техническое решение не есть ответ на вопрос автора, а лишь вопрос настройки и использования инструментов.
                Уточнение №3. Для обсуждения технического решения будем использовать предложенный уровень детализации.
                А теперь вернёмся к вопросам по билету. 🙂
                1. и 2. Система мониторинга инфраструктуры строится на регулярном опросе доступных показателей здоровья компонент и соответствующей реакции на отклонения от установленных целевых значений. Для современных систем мониторинга доступно построение так называемых “комплексных моделей здоровья”, которые позволяют строить деревья зависмости одних показателей от других. Существую готовые коммерческие и бесплатные наборы таких моделей для различных компонентов инфраструктуры, включая практически все платформы и операционные системы (естественно, есть исключения).
                “Факт зависимости услуг от сетевого обмена” устанавливается на этапе проектирования услуги и зависит от способа реализации. Наличие или отсутствие связей проверяется в тестовой либо прмышленной эксплуатации. Вопрос поиска “крайних” я бы вынес из этой ветки.
                3. Для проверки статуса репликации файлов обычно используют соответствующий опрос статуса сервиса или программы репликации или проверку наличия и/или актуальности копии файла. Это задача мониторинга. Модуль мониторинга должен уметь обновлять статус КЕ в модуле инвентаризации и выдавать предупреждение при необходимости, которые должны быть преобразованы в соответствующие инциденты или аварийные сигналы (trouble tickets) для службы поддержки.
                ———–
                Повторюсь: “Не рекламирую продукт, но я это сам трогал ручками.” Это комплекс продуктов, который практически полностью покрывет рассматриваемые нами задачи инветаризации и мониторинга инфраструктуры, построения полноценной базы данных конфигурационных единиц путём дополнения и расширения инфраструктурной модели здоровья элементами и связями для описания услуг. Также в наличии есть неплохой модуль работы с инцидентами, проблемами и изменениями. На мой взгляд, самая сильная сторона этого решения в тесной интеграции всех модулей.
                ————-
                Получилось очень пафосно, я вижу.:-)

  • Лялеко Владимир

    Вариант 1

    Но при этом канал связи эта инфраструктурная услуга (отдельный КЭ). Ресурсно-сервисная модель по данной услуге экспортируется из систем мониторинга. При этом на уровне системы мониторинга, закладываются правила сбоя в предоставлении услуги и деградации услуги.

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

    • Анатолий Павлюченко

      Угу. Ключевое слово “система мониторинга”.

      • Евгений Шилов

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

        • Анатолий Павлюченко

          “не очень доверяю системам мониторинга”?!
          Ваша альтернатива в той же “весовой категории” для той же задачи (“адекватно отразить факт взаимодействия ИТ-систем”)?
          Повторюсь: системы мониторинга инфраструктуры и визуализации (контроля) конфигурационных единиц (или СРМ) – это только инструмент. Как вы его настроите и будете использовать, так и будет.
          Идея использовать синтетическую КЕ «App. Data Exchange» вместо реального канала данных и реальной связи имеет несколько слабых мест:
          – необходимость “ручной” актуализации состояния (auto vs manual);
          – внесение компонент, смысл которых надо объяснять некоторым заинтересованным лицам (простота vs сложность);
          – необходимость создания целого класса КЕ со своими свойствами и методами (default vs custom).

          • Евгений Шилов

            Давайте по порядку:
            1. “auto vs manual”.
            Если речь идет об управлении конфигурациями, а не об установке “шайтан-тулы”, которая за нас все соберет, всегда имеет место ручное (контролируемое, обоснованное) обновление информации в CMDB. Обновление может осуществляться как результат производимых изменений (описанных, согласованных, спланированных). В итоге никто конечно не запрещает собирать некоторые данные автоматически. НО, во-первых, всю информацию не собрать (что вы, например, будете делать с местом в стойке, инвентарным номером, источником питания). Во-вторых, в адекватности некоторой информации можно усомниться, не каждое взаимодействие ИТ-систем можно отследить даже самыми умными агентами. В-третьих, если вам потом понадобится понять, на основании чего было выполнено изменение конфигурации системы, то автоматический сбор информации вам этого не позволит сделать.
            В автоматическом сборе конечно есть свои плюсы, например, вы можете сравнивать фактическое и плановое (прошедшее через CHG) состояние инфраструктуры по тем атрибутам КЕ, которые адекватно могут быть собраны системой.
            Традиционно CMDB содержит лишь информацию, которая востребована и в качестве которой нужно быть уверенным. Поэтому трудозатраты на ручное обновление и контроль качества информации будут оправданы, при правильном проектировании CMDB и деятельности по ее обновлению.
            2. “простота vs сложность” Заинтересованные лица обычно как раз и предъявляют требования к CMDB, а то и участвуют в проектировании структуры CMDB. Остальные потребители информации знакомятся со структурой CMDB по плану управления конфигурациями и это не сложнее, чем разобраться в информации, которую выдает автоматизированная система мониторинга и инвентаризации.
            3. “default vs custom” Очень похожие рассуждения часто звучат из уст, компаний которые продают и внедряют системы автоматизации. Многие заявляют о гибкости систем, но при этом их бросает в дрожь при мысли, что в их CMDB появятся новые категории КЕ, связи и т.д. Так вот, очень хочется верить, что мы создаем CMDB под свои задачи, а не подгоняем задачи под возможности продукта.

            • Анатолий Павлюченко

              1. «auto vs manual».
              Супер. Вы практически подтвердили преимущества автоматического способа сбора и обновления информации. Необходимость ручной настройки и контроля никто и не отрицал.
              Нюанс использования синтетических КЕ как раз и заключается в сложности связывания их с _уже автоматизированными_ интерфейсами обновления.
              2. «простота vs сложность».
              Вы перевели аргумент в плоскость “это не сложнее, чем разобраться в …”. Сложнее. Именно это я и хотел сказать. Если мы используем понятие, которое уже введено в обращение некоторое время назад и где-то кем-то опробовано, описано и используется, его намного легче использовать повторно, а не придумывать новое.
              3. «default vs custom».
              Аргумент приведён из эргономических соображений и личного опыта по “кастомизации” довольно больших систем. Опять же, никто не говорит о том, что настройка под себя не нужна. Просто, чем её меньше, тем лучше.
              Небольшое резюме. Я исповедую принципы простоты, автоматизации и унификации. На мой взгляд, это особенно актуально для больших систем и больших объёмов данных. Т.е. там, где есть смысл в CMDB.
              Что до систем, в которых находится время и ресурсы на бесконечную ручную настройку и актуализацию информации, то они либо недостаточно большие (целесообразность CMDB под вопросом), либо процесс создания CMDB в них так никогда не будет реализован до конца (как пишет наш любимый ИТ Скептик).

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

                Уважаемые коллеги. Возможно из этой дискуссии у вас складывается впечатление, что Евгений и я призываем отказаться от систем автоматизации. Это не так 🙂 Безусловно, построение федеративной CMDB со ссылками на специализированные системы управления (инвентаризации, мониторинга, финансового учета и так далее) – это практика последних лет, наша практика в том числе.

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

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

                Еще одна “болезненная тема”, затронутая здесь – это отождествление услуг с CI. Но повторюсь – об этом лучше не здесь, т.к. формат этого сайта просто неудобен для ведения нескольких дискуссий в одном топике.

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

      Такой вариант мне нравится (и так я поступал на практике). В частности, он мне нравится тем, что:

      1. Этот вариант не обязательно зависит от умной системы – такие связи можно нарисовать руками. Не в теории, а на практике.
      2. В таком варианте хорошо распределяется ответственность за актуальность информации: сетевики отвечают за актуальность “начинки” связи между площадками (каналы, оборудование, VLAN’ы и так далее), прикладники – за факт отражения зависимости систем и услуг от связи между площадками. Т.е. если, например, поменяется маршрутизатор, через который подключается канал, связи придется менять только на уровне сетевых компонент, не создавая “синтетических” связей с услугами.

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

      • Лялеко Владимир

        Все от заказчика зависит как мне кажеться. 🙂 В частности если в компании есть специфические соглашения по поддержке сетевого оборудования, либо ещё страшнее поддержка отдана на аутсорсинг. Определение услуги «Канал Связи» поможет упростить взаиморасчеты по данным соглашениям.

        Если необходимости а этом нет, безусловно плодить новые сущности смысла нет.

        Единственного верного ответа на возникший вопрос нет 🙂 Поэтому и холивары рождаются :))

      • Николай

        “Ведь можно, не придумывая никаких лишних сущностей, просто сделать CI, которая будет называться «Сетевая связь между площадками»” – классно: “мы не придумываем миф, мы просто сделаем миф”)))

        А что это за CI, позвольте спросить, будет?
        “Типичными примерами КЕ являются ИТ-услуги, оборудование, программное обеспечение, здания, люди и документы, такие как Процессная документация и Соглашения об уровне услуг”.
        Надо очень сильно не любить “инфраструктурные услуги”, чтобы их здесь не использовать 🙂

        А если серьезно, то “underlying service” (или инфраструктурная услуга, как здесь было названо), в данной ситуации полезна не только практически, но и методически. Поскольку создает “бизнес-сущность”, а не ИТшную шайтан-арбу “несуществующая КЕ”.

        “проверено практикой” (с)

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

          Таки понесся холивар 🙂

          • Евгений Шилов

            Как без этого 🙂

            Выше была правильная мысль: “Все зависит от Заказчика”. Я бы ее дополнил: все зависит от задачи, ресурсов и прочего имеющегося окружения.

          • Николай

            А мне кажется, никакой “войны” нету – есть “взгляд снизу” (технарский) – от CMDB и “взгляд сверху” (управленческий) – от договоренностей, вот и вся разница.

            Но я привык прислушиваться к экспертам… выше сказано: “Еще одна «болезненная тема», затронутая здесь — это отождествление услуг с CI”. Позволено ли будет поинтересоваться что это за тема такая и для кого конкретно она “болезненная”. Что-то я раньше таких “тараканов” не встречал… ))

  • Андрей Волков

    Ну а почему бы и нет? У нас ведь есть несуществующие CI такие, как Документация, ИТ инфраструктура, Сеть. Только что они родительские, а здесь дочерние.
    Мне больше всего представляется такая связь между серверами как свойство каждого сервера (например, используются следующие элементы), либо дополнение в комментарии. Это позволит при переносе сервера или модема для невидимой связи увидеть заввисимость и избежать сбой в работе. В случае переноса сервера CI “App. Data Exchange” куда денется?

    • Евгений Шилов

      В данном случае “App. Data Exchange” указывает на необходимость взаимодействия двух ИТ-систем. В частности именно в этой КЕ можно описать как именно взаимодействуют ИТ-системы, порты и т.д.
      В случае переноса сервера с ИТ-системой на другую площадку, необходимо будет обновить связь “App. Data Exchange” с той инфраструктурой, которая обеспечивает связь.
      В случае переноса ИТ-системы на другой сервер в пределах этой же площадки, нужно только установить связь ИТ-системы с новым сервером и разорвать со старым. App. Data Exchange при этом никак не затрагивается.

  • Павел Солопов

    Ломаю голову на похожую тему сейчас, как раз.
    У меня сформровалась следующая концепция:
    В CMDB должны быть только нереальные элементы.
    Реальные должны жить в БД активов. 🙂

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

    Далее, каждый “функциональный элемент” связан уже с конкретным активом (активами) или другим сервисом. В вашем случае ФЭ сервер эл. почты на площадке 1 и серврер эл. почты на площадке 2 будут связаны с соответствующими ПО почтового сервера, сервером, как железкой, ОС установленной на сервер. А канал связи будет связан с сервисом “сеть передачи данных” или что-то в этом роде.

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

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

  • Notabenna

    Коллеги, приветсвую!)

    Сейчас занимаюсь актуализацией процесса управления конфигурациями, но это пол беды, его еще нужно без "травм" для ИТ и руководства внедрить). Есть один пробел, верю, что поможете его заполнить. Какие виды свзяей существуют, какие из них предложить для ИТ подразделения компании,  где как таковой процесс не внедрен, CMDB не заполнена. Не хочу мудрить, внедрить по минимуму, а там уже по мере заполнения базы КЕ дорабатывать и сам процесс и виды связей.  Знаю про "Логические" и "Физические".

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

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

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