Все под контролем
Автор
Григорий Рудницкий
База данных управления конфигурации (CMDB) позволяет гибко и эффективно управлять изменениями, инцидентами, финансами и другими процессами
База данных управления конфигурации (Configuration management database, CMDB) —информационное хранилище, содержащее данные обо всех ИТ-компонентах компании. Этот инструмент позволяет гибко и эффективно управлять изменениями, инцидентами, финансами и другими процессами. Кому нужна CMDB, как ее грамотно спроектировать и использовать? На эти и другие вопросы ответил Георгий Ованесян, руководитель направлений «Консалтинг по ITIL/ITSM и «Мониторинг и управление ИТ» компании «КРОК».
Насколько важным элементом является CMDB в управлении ИТ-ресурсами компании?
Можно сразу же ответить: без CMDB управлять ИТ-ресурсами компании невозможно. CMDB позволяет получить информацию о том, какие ИТ-ресурсы есть в наличии, что ними нужно делать в соответствии с целями и задачами, стоящими перед компанией, а также существует ли возможность корректировать поставленные цели в процессе движения к ним.
Давайте посмотрим на проблему шире. Насколько интересно сегодня компаниям управлять своими ИТ-ресурсами в полном объеме? Далеко не все осознают такую необходимость. Вот почему к CMDB относятся как к некоему вспомогательному инструменту, который облегчает работу с другими процессами и данными, но является не обязательным, а скорее опциональным. Если говорить о процессах, связанных исключительно с эксплуатацией, с «затыканием дыр» и беготней по заявкам пользователей, то подобный подход тоже имеет право на существование. Но если со стороны руководства наблюдается заинтересованность в том, чтобы не только быстро бегать, но еще и считать деньги, подключать проактивные механизмы управления компанией, оценивать риски, то без CMDB уже не обойтись.
В каких процессах эффект от CMDB будет максимальным?
Основной базовый процесс, максимально связанный с CMDB, — управление изменениями. Если у вас достаточно статичная и стабильная инфраструктура, что в наше время практически уже не встречается, то вам повезло. Если же ваша инфраструктура подвержена изменениям, вводятся новые услуги и сервисы, компания растет, уменьшается, консолидируется и т.д., то с изменениями надо работать. Их необходимо, во-первых, планировать, во-вторых, согласовывать и отслеживать, в-третьих, быть уверенным в том, что изменения достигли нужного результата. Для всего этого требуется CMDB.
На второе место после управления изменениями я бы поставил управление проблемами. Для того чтобы проактивно искать узкие места в инфраструктуре, приложениях и процессах, необходимо знать, что у вас есть в наличии, а также иметь возможность моделировать поведение ваших систем. А далее идут процессы управление мощностями, доступностью, финансами.
Фактически, управление ИТ делится на две основные категории — эксплуатацию и развитие. Именно эксплуатация полностью построена на том, что есть сейчас, что мы обслуживаем, а развитие строится на планируемых изменениях и проектах по развитию. Для обеих категорий CMDB жизненно необходима
Какие факторы необходимо учесть при создании CMDB, как наполнить ее данными и хранить их в актуальном состоянии?
Весь опыт наших проектов свидетельствует о том, что надо исходить из целей компании. Если вы создаете CMDB исключительно как вспомогательный инструмент для других процессов, вам необходимо понять, какая информация будет максимально полезна для этих процессов. Например, если ваша цель — управление инцидентами, причем основная часть приходится на управление пользовательскими рабочими станциями, то CMDB следует наполнять информацией об этих станциях.
Другой вариант, если вы строите CMDB как основу всей системы управления ИТ. В таком случае вы должны смотреть намного шире, хотя, возможно, и не столь глубоко. Для управленческих задач не всегда бывает нужна тщательная детализация. Так что в первую очередь надо понять, вся ли инфраструктура или же какие-то отдельные области будут заложены в CMDB, а также определить, насколько глубоко «вниз», до специфики каждой конфигурационной единицы (КЕ), предстоит опуститься.
Что касается наполнения данными, как правило, какие-то источники данных у заказчика всегда имеются. Это могут быть таблицы, уже существующие финансовые и инвентаризационные системы, системы мониторинга и т. д. Все они хранят информацию, которую можно и нужно занести в CMDB, если данная цель входит в сферу ваших интересов. Если заказчик понимает, что в его распоряжении сегодня нет соответствующих целям средств автоматизации и актуализации CMDB, то нужно быть очень аккуратным и оставлять в CMDB только критически важные данные, которые будут обновляться вручную. Ручное обновление CMDB — худший вариант, который только можно себе вообразить, и оно имеет смысл лишь для отдельных, критически важных конфигурационных единиц. С него стоит начать, но вскоре средства автоматизации все равно потребуются. Чаще всего это система автоматической инвентаризации (discovery&inventory), которая анализирует физическое оборудование и программное обеспечение, а также финансовые системы, хранящие информацию об активах, ресурсах и их стоимости, как закупочной, так и остаточной. Они могут обогатить информацию, собранную системой discovery&inventory, финансовой составляющей.
Разумеется, необходимо настроить автоматическое обновление этих данных. Процесс лучше всего построить следующим образом. После единожды проведенной инвентаризации собирают данные, затем они выверяются и заносятся в CMDB. Впоследствии любое расхождение данных между тем, что есть в CMDB, и тем, что мы получили от систем автоматизации, должны быть проверены на релевантность и корректность. Напрямую перезаписывать данные CMDB в автоматическом режиме не рекомендуется. Современные системы CMDB обладают возможностью хранить несколько вариантов одной КЕ, чтобы проводить сверки и контроль обновлений конфигураций
Что нужно принять во внимание для эффективной интеграции CMDB с уже имеющимися в компании информационными системами, особенно если все они от разных производителей?
Если у вас большая номенклатура разных систем, то выбирать надо CMDB, поддерживающую интеграцию с различными решениями. Крупные промышленные CMDB интегрируются с чем угодно, а менее развитые и дорогостоящие системы не всегда на это способны.
Я уже называл основные системы, с которыми должна взаимодействовать CMDB. К перечню хотелось бы еще добавить ServiceDesk, как правило, уже включающий CMDB. Современные CMDB обладают свойством федеративности, то есть позволяют хранить не всю информацию о КЕ, а ссылки на нее. Часть информации по конфигурационной единице содержится в самой CMDB, а при запросе дополнительных сведений вступают в действие механизмы интеграции, то есть используется ссылка на внешнюю информационную систему, откуда и берутся дополнительные данные, причем все происходит из единой консоли CMDB. Это хорошая практика, она позволяет не дублировать и не переносить в CMDB мало или редко востребованную информацию.
Как реализовать взаимодействие человека с CMDB? Какие подходы и технологии вы считаете наиболее эффективными?
Как правило, реализуется два подхода. Первый — обеспечение доступа непосредственно из консоли CMDB. То есть в те системы, с которыми CMDB интегрируется, пользователи уже не заходят, а работают напрямую с ней. Причем сама CMDB при необходимости подтягивает данные из внешних систем. Звучит красиво, но используется нечасто, поскольку это не всегда удобно. Каждый сотрудник работает в своих процессах, в своих департаментах, в своих организационных единицах. Ему так привычнее и надежнее. Второй подход заключается в том, что CMDB представляет собой эталонную модель, в которой хранятся эталонные данные, верные для всех систем. Все остальные системы считают нормативным источником данные CMDB. Доступ к этим данным пользователи осуществляют уже через свои привычные инструменты — ServiceDesk, систему мониторинга, систему HR и т.д. Как уже отмечалось, современные системы CMDB могут интегрироваться со многими системами одновременно и предоставляют широкие возможности по согласованию (выверке) данных полученных из разных систем по одной КЕ. С точки зрения конечного пользователя подобный подход более привычный. Да, он требует более сложных настроек, зато является наименее болезненным вариантом при внедрении CMDB. Разумеется, один подход не отменяет другой. Допустим, большинство сотрудников может работать в своих системах, а нескольким обеспечивается прямой доступ к CMDB для конфигурационных и административных задач. Вместе с тем сильно смешивать первый и второй подход не рекомендуется.
И последний вопрос. Каковы наиболее распространенные ошибки при проектировании и использовании CMDB?
Все рекорды бьет желание заказчика загрузить в модель CMDB как можно больше информации, не думая о том, как ее наполнять и как актуализировать. На втором месте рейтинга ошибки, связанные с процессами, — непродуманные механизмы обновления, автоматическое обновление данных в CMDB без их предварительной сверки.
Также надо сказать, что CMDB — не панацея от ошибок эксплуатации. Это всего лишь инструмент. CMDB не живет сама по себе, она опирается на данные из внешних систем и взаимодействует с ними. Иначе никакого смысла в ней нет.
Источник: IT Manager №11, 2013
Опубликовано 03.12.2013