Управление конфигурациями: Подводные камни

Управление Сервисными Активами и Конфигурациями (Service Asset and Configuration Management), как данный процесс правильно называется в ITILv3, – один из самых трудных для понимания и внедрения процессов ITIL, во всяком случае, такая оценка следует из опросов наших слушателей.

Попробуем понять эти трудности, разобрав некоторые риски, которые сопутствуют практикам данного процесса.

Для начала (как всегда) разберемся с основными понятиями рассматриваемого процесса. В процессе Управления Сервисными Активами и Конфигурациями появились новые понятия, которых не было в ITIL второй версии. Кратко углубимся в основные понятия, используя определения из Глоссария.

  • Система управления конфигурациями (Configuration Management System, CMS) — набор инструментов и баз данных, которые используются для управления данными о Конфигурациях Поставщиком ИТ услуг.
  • CMS также содержит информацию об инцидентах, проблемах, известных ошибках, изменениях и релизах. Может содержать данные о сотрудниках, поставщиках, местоположениях, бизнес-единицах, заказчиках и пользователях
  • CMS включает в себя инструменты для сбора, хранения, управления, обновления и представления информации о всех CI и их взаимоотношениях

  • База данных управления конфигурациями (Configuration Management Database, CMDB) — база данных, используемая для хранения записей о конфигурациях на всем протяжении их жизненного цикла. Система управления конфигурациями (Configuration Management System, CMS) управляет одной и более CMDB и каждая CMDB содержит атрибуты CI и их связи другими CI.
  • Запись о CI (Сonfiguration Record) — запись, содержащая детальную информацию о CI. Каждая запись документирует жизненный цикл единственной CI. Запись о конфигурации хранятся в CMDB.
  • Конфигурационная единица (configuration item, CI) — актив, компонент сервиса или другой элемент, который находится или будет находиться под контролем процесса управления конфигурациями. Могут быть:
    • CI жизненного цикла сервиса
    • Сервисные CI
    • Организационные CI
    • Внутренние CI
    • Внешние CI
    • Интерфейсные CI

Проиллюстрируем данные положения небольшой схемой, взятой из книги Service Transition:

Из схемы и определений мы видим, что:

  • CMS – более широкое понятие, чем CMDB и может содержать в себе объекты, не являющиеся CI.

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

  • Перечень того, что может быть CI, значительно расширен и в него могут входить как физические, так и логичекие CI, как IT, так и бизнес объекты.

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

Неверно или нечетко определены цели и задачи процесса

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

  • Установление контроля над основными элементами ИТ инфраструктуры, определение связей как между частями ИТ инфраструктуры, так и между ними и основными бизнес сервисами для проведения критичных для бизнеса изменений

  • Учет ценных активов, контроль сохранности, поддержка требований по безопасности, интеграция с системами мониторинга

  • Оперативная и точная инвентаризация ИТ активов по запросам бухгалтерии

  • Лицензионный контроль ПО

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

Подход: «собираем все данные, которые возможно», что ведет к перегрузке процесса, а также к невозможности его поддерживать

Типичная ошибка в начале строительства данного процесса: все зачарованы возможностью собрать в CMDB максимально возможное количество информации. Как следствие, ужасно напрягаются все силы, проводится тотальная инвентаризация, в базу забивается все вплоть до последней дохлой мыши и – вот оно, счастье! Но нет, счастья, как всегда, нет, потому что мало все собрать один раз, надо все это богатство поддерживать в актуальном состоянии, отображая в CMDB все изменения, реально происходящие с многочисленными CI. Поскольку об этом заранее никто не подумал и сил на поддержку не запасал, наступает быстрая деактуализация части (а если не повезет, то и большей части) данных в CMDB и как следствие – ужасное разочарование и неверие в могущество ITIL. А вот и второй подводный камень, тесно связанный с первым:

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

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

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

  • Они должны быть актуальными (четко отображать состояние дел в реальной инфраструктуре на текущий момент)

  • Они должны быть достоверными (отсутствие ошибок в самих данных)

  • Они должны быть востребованными (нужными потребителям CMDB)

И здесь уместно рассмотреть следующее положение, которое также требует аккуратного и продуманного подхода. Это:

Установление обоснованного уровня точности, т.е. корреляции между моделью и реальной конфигурацией

Решить данную задачу нелегко, потому что здесь нужно верно решить уравнение с несколькими неизвестными:

  • Определить охват CMDB – например, что будет CI, какие будут категории CI?

  • Определить уровень детализации — например, какие атрибуты будут у CI, что будет только атрибутом, а что – достойно быть настоящей CI?

  • Определить необходимые связи как между CI, так и между CI и сущностями — например, между CI и сервисами, между CI и инцидентами, проблемами, RFC, релизами.

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

  • Добавление в CMDB данных, которые были нужны потребителям, но которых не оказалось в CMDB

  • Удаление из CMDB данных, которые не были востребованы потребителями базы

  • Изменение (расширение) охвата категорий CI, например, в результате изменения политик процесса по охвату

При всех итерациях необходимо определять ресурсы, необходимые для поддержки данных CMDB в актуальном состоянии. Наличие (отсутствие) таких ресурсов является критически важным.

Выводы

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

Автор: Владимир Аношин, IT Expert

Источник: www.itexpert.ru

Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий

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