smdb что это за программа
CMDB: что это и как может помочь бизнесу
Чем больше становится компания, тем сложнее понять ее внутреннюю структуру. То же относится и к ИТ-инфраструктуре. Чем больше к ней добавляется серверов, пользователей и лицензий на ПО (программное обеспечение), тем сложнее становятся процессы. В таких условиях легко упустить что-то важное из виду и допустить ошибку из-за того, что нужная информация затерялась или оказалась недоступна. Избежать этого поможет CMDB (Configuration Management Database, база данных управления конфигурацией). Впервые этот термин появился в первой версии библиотеки ITIL (IT Infrastructure Library). Подробнее о CMDB — в этой статье.
Что такое CMDB
CMDB, или база данных управления конфигурацией — это репозиторий, который содержит необходимую информацию об аппаратных и программных компонентах ИТ-инфраструктуры, которые используются ИТ-подразделениями компании. К этим элементам относятся не только серверы, ПО и сетевые соединения, но и данные о местоположении и пользователях, а также лицензии и гарантии. Эта часть методологии ITIL помогает контролировать и управлять ресурсами компании, они также известны как CI (Configuration Item, конфигурационный элемент). Также CMDB обеспечивает глубокое понимание того, как эти компоненты связаны друг с другом, и позволяет рассматривать их под разным углом.
Как центральный репозиторий всех активов компании, база данных управления конфигурацией помогает принимать бизнес-решения и управлять ITSM-процессами. Она помогает выявлять и устранять проблемы, быстрее реагировать на инциденты, лучше планировать бюджет, а также облегчает процесс принятия решений.
Еще одно преимущество CMDB: даже если отдельные компоненты ИТ-инфраструктуры рассредоточены и связанные с ними данные поступают из большого массива источников, база данных позволяет управлять ими в одном месте.
Типы CIs
Тип конфигурационного элемента — это ITIL-термин. Он описывает те виды CIs, которые компания хочет сохранить в базе данных. На самом базовом уровне все типы сетей, программного и аппаратного обеспечения хранятся и отслеживаются в CMDB. По мере роста компании она может добавить в нее больше типов CI. К их числу могут относиться люди, рынки, продукты, партнеры и продавцы. Чем больше активов отслеживает компания, тем большей информацией она располагает.
CMDB как основа ITSM
Базу данных управления конфигурацией часто рассматривают как центральный элемент ITSM (IT Service Management, управление ИТ-услугами). В основном это связано с тем, что ITSM-подход опирается на методологию ITIL, в которой термин CMDB был впервые использован. В библиотеке лучших практик по управлению ИТ-услугами управление конфигурацией представлено как важнейший аспект ITSM.
CMDB практически незаменима, когда компания решает внедрить управление ИТ-услугами. Сотрудники и руководство могут извлечь пользу из информации, которая содержится в этом обширном репозитории. Это, в свою очередь, помогает в достижении долгосрочных целей компании.
Разница между ИТ-документацией и CMDB
Эти два понятия различаются по нескольким причинам:
ИТ-документация касается только фактического состояния инфраструктуры: отношения и зависимости между ее компонентами в ней практически не представлены. Это — особенность CMDB. База данных управления конфигурацией отображает как физические, так и логические связи между CIs. Таким образом, она дает полное представление об ИТ-инфраструктуре. Кроме того, она также может отображать целевые состояния объектов, которые с физической точки зрения еще не находятся в компании.
Например, CI может быть «В доставке» или со статусом «Заказано». Часто это важная информация для своевременной интеграции устройств в ИТ-инфраструктуру. Эти состояния — часть жизненного цикла каждого компонента инфраструктуры, а CMDB помогает их задокументировать.
Характеристики CMDB
В базе данных управления конфигурацией хранятся следующие виды информации:
Но что такое CMDB на практическом уровне? Вот ее основные функциональные характеристики.
Несколько десятилетий назад реализация CMDB была дорогостоящей, громоздкой в обслуживании и сложной в использовании. Современные же базы данных — основа большинства ITSM-решений. Компаниям полезно использовать CMDB по нескольким причинам:
Inventory Monitoring System или CMDB на коленке
Много лет назад работал я системным администратором в одной не очень большой, но хорошей компании. Все стандартно: несколько серверов, простенький документооборот, почта, интернет, бухгалтерия, файловые ресурсы, рабочие места пользователей. Да, ох уж эти рабочие места. Поддержка пользователей всегда занимает особое место в сердце любого системного (да и не системного тоже) администратора.
В одно прекрасное утро я получил довольно внушительный «втык» от руководства за неожиданно ставший неработоспособным компьютер главного бухгалтера. Ничего экзотического – неожиданно закончилось место на системном диске. ОС «упала» и отказалась подниматься самостоятельно. Быстренько устранив инцидент, я подумал, неплохо бы было получать информацию о том, что тот или иной пользователь заполонил своими фотками весь диск C немного раньше, чем откажет его компьютер.
Я написал и запустил с помощью Task Sheduler-а на одном из серверов несколько простеньких скриптов на VBS, которые регулярно подключались к рабочим станциям пользователей по WMI и собирали информацию о томах на всех доступных рабочих станций в домене (ActiveDirectory).
Получилось прикольно. Аппетит разгорелся . Через пару месяцев в базе данных (MS SQL Server) новорожденной Inventory Monitoring System (IMS) было вполне приличное описание практического всего ИТ-оборудования компании, а на внутреннем сайте (IIS + ASP) можно было эту информацию в удобном виде посмотреть или выгрузить в MS Excel.
Кроме сбора информации о конфигурации и состоянии различного оборудования было настроено сканирование и контроль внутренних IP-сетей, сбор данных производительности серверов (загрузка CPU, использование памяти, производительность сети и дисков) и доступности различных ИТ-ресурсов (страничек внутреннего и внешнего сайтов, доступа в интернет и т.п).
Что удивило – вроде делалось это, чтобы освободить побольше времени для творчества и отдыха , а на самом деле автоматизированный сбор данных об ИТ-ресурсах обнаружил большое количество скрытых мелких проблем, которые мне же и пришлось решать.
В компанию МТС я пришел в подразделение, которое занималось серверами Windows. Только сервера — никаких рабочих станций, принтеров, пользователей. Красота! Только серверов этих было несколько сотен, и каждые полгода их количество удваивалось.
Через пару дней после выхода на работу я понял, что без IMS мне и моим коллегам здесь придется трудновато. Выпросил старенький сервер и поднял IMS.
Сбор данных с оборудования происходит преимущественно удаленно. На серверах платформы запускается множество отдельных процессов, подключающихся к серверам и оборудованию (WMI, SSH, SNMP, SOAP), которые собирают и отправляют в базу платформы полученную информацию. Процессы запускаются с помощью штатного планировщика TaskSheduler. Весь процесс добавления/удаления задач в TaskSheduler тоже автоматизирован. План сбора метрик, указанный в карточке объекта, автоматически реализуется в конкретные задачи в TaskSheduler на конкретных серверах платформы.
План метрик может быть назначен объекту с помощью набора профилей вручную или автоматически (в зависимости от типа оборудования, местоположения и т.п.) и дополнен собственным персональным набором «штатных» метрик.
Кроме этого, можно подготовить и назначить к сбору комплект своих, особенных метрик, характерных только для конкретного объекта. Для этого нужно воспользоваться специальным конструктором и создать метрики для получения данных одним из стандартных предопределенных методов, например, через WMI, SNMP, командой SSH и т.п. (всего полтора десятка разных методов получения данных).
Результатами работы процессов являются параметры сервера. В карточке объекта (веб-интерфейс) можно посмотреть их в виде списка последних собранных значения или проанализировать исторические значения в виде графиков и таблиц (с возможностью выгрузки в Excel).
Кроме динамических параметров собирается различная инвентаризационная информация: сведения об оборудовании, ОС, локальных пользователях, дисковых томах, интерфейсах, установленных приложениях, сессиях RDP и SSH, установленных системных обновления и т.п.
Происходящие с объектом изменения фиксируются в журналах: сообщения от систем мониторинга можно увидеть в журнале сообщений, информация о плановых и аварийных работах – в журнале событий, изменения, вносимые в карточку объекта – в журнале изменений.
Жизненный цикл оборудования можно довольно подробно описать на специальной вкладке «Эксплуатация». Можно распечатать и наклеить на оборудование этикетку c QR-ссылкой на карточку в IMS.
IMS имеет развитую систему поиска и отображения информации об объектах, хранящихся в системе. Позволяет искать нужный набор объектов по большому количеству критериев, составным условиям и по списку значений. Для отображения полученного набора объектов можно воспользоваться стадартными формами с определенным набором характеристик объектов или собственной формой с произволным наборм характеристик. Есть также возможность подготовки динамических отчетoв (dashboard).
Преимущества текущей реализации
Сразу было понятно, что система будет полезна и окупит потраченные на нее силы только если будет содержать нужные и актуальные сведения. Если за актуальность данных, которые собираются автоматически, можно было, в принципе, не беспокоиться, то обеспечение актуальности информации, вносимой пользователями вручную (системными администраторами), организовать было гораздо сложнее. Их необходимо было заинтересовать и мотивировать использовать IMS как инструмент для оперативной повседневной работы.
Исходя из этого, определилось несколько ключевых целей:
Как показал опыт, простая открытая архитектура ASP и VBScript, возможность быстрого и наглядного исправления ошибок и внесения правок позволяла быстро и эффективно дополнять и перестраивать процессы получения, управления и отображения данных с учетом текущих потребностей и пожеланий коллег. Это и дало возможность создать этот удобный и практичный (как мне кажется) инструмент для системного администратора.
Вендерных CMDB-продуктов много. Каждый имеет свои плюсы и минусы. И основной минус – это стоимость решения, лицензий и кастомизация. IMS же позволять легко интегрироваться с любыми решениями и выступать в роли поставщика инвентаризационных данных.
Владимир Наумов (v_naumov), старший эксперт-куратор отдела автоматизации ITSM процессов МТС.
Что такое CMDB и как это связано с управлением ИТ-активами?
Опубликовано: Март 10, 2021
Обновлено: октябрь 15, 2021
Амартья Гупта
Менеджер по маркетингу продукции
Как организация, мы стараемся учиться у наших клиентов и переносить это обучение на создание лучшего продукта. Это непрерывный цикл, который держит нас впереди наших конкурентов.
Итак, какая у вас организация? Фантазия или кошмар.
Что мы можем сказать, так это то, что CMDB может быть ценным инструментом, если вы начинаете рано и у вас есть стратегия того, что включать и как им управлять.
Почему ваша организация должна заботиться о CMDB?
Это широкие темы, которые будут освещены в этом блоге:
1. Что такое CMDB?
Как вы знаете, CMDB означает «База данных управления конфигурациями», которую часто называют сердцем любой системы ITSM.
Как правило, CMDB включает в себя список CI, их атрибутов и отношений между ними.
2. Как развивалась CMDB?
Необходимо было хранить информацию о настраиваемых элементах, которые имели решающее значение для предоставления ИТ-услуг. По этой причине ITIL разработала процессы управления активами и конфигурациями. Как часть этих процессов, информация CI управляется как список элементов вместе с их отношениями друг с другом.
В настоящее время CMDB играют все более важную роль в компаниях, охватывающих Agile и DevOps, чтобы люди могли иметь среду, в которой они могут решать проблемы, связанные с проблемами и изменениями, в режиме реального времени.
Будущее CMDB не ограничивается ИТ-операциями, скорее, оно будет играть важную роль и в бизнес-операциях.
3. Как работает CMDB?
Как указывалось ранее, CMDB является базой данных. Что делает его уникальным, так это то, что он содержит информацию и отношения КИ, часто представляемые в виде списков.
Технические возможности, необходимые для управления такими CI, обеспечиваются системой управления конфигурацией (CMS), которая представляет собой логическую модель данных, которая может иметь несколько CMDB.
В организациях CMDB часто оказываются частью ITSM решение, предоставляя поддержку для управления активами и конфигурациями.
CMDB предоставляет общее место для просмотра и работы с активами и настраиваемыми элементами. Информация часто используется в сочетании с другими процессами ITSM (инцидент, проблема и изменение) для создания значимых отношений.
Данные в CMDB заполняются с помощью инструментов обнаружения и экспорта. В платформе Motadata ServiceOps ITSM мы поддерживаем как безагентное, так и основанное на агентах обнаружение для заполнения CMDB.
Из-за огромного количества данных в форме строк люди редко получают прямой доступ к CMDB. В Motadata ServiceOps ITSM пользователи могут использовать модуль отчетов для содержательной организации своих данных CMDB в отчеты.
4. Каковы преимущества использования CMDB?
Во всей схеме управления ИТ-инфраструктурой CMDB играет важную функцию. Вот некоторые из этих функций:
4.1 CMDB является ориентиром для всех ИТ-активов
4.2 CMDB обеспечивает прозрачность и прозрачность при управлении ИТ-активами
Организация имеет характеристики органического объекта, она растет и очень сложна. С ростом ИТ-инфраструктуры также становится все труднее отслеживать.
4.3 CMDB позволяет отслеживать изменения в ИТ-инфраструктуре
Как обсуждалось ранее, CMDB часто существует как часть ITSM-решения. В Motadata ServiceOps ITSM, управление изменениями тесно интегрирован с CMDB, что позволяет отслеживать изменения с использованием модели изменений.
4.4 CMDB помогает в процессе управления знаниями
Надежное управление знаниями требует качественного ввода данных. При наличии надлежащей CMDB в базе знаний достаточно данных для построения решений, потому что:
4.5 CMDB помогает в процессах ITSM
Когда тикет создается для актива, он обычно ассоциируется с записью CI в CMDB. Ассоциация продолжает играть решающую роль, поскольку она продолжает решать проблемы и управлять изменениями.
5. Проблемы использования CMDB
Вот некоторые из проблем наличия CMDB:
6. CMDB против управления активами
Разговоры о CMDB и управлении активами вызывают большую путаницу, потому что эти два термина концептуально связаны. Но есть очевидные отличия.
CMDB концентрируется на информации, используемой для управления активами, когда они активны в ИТ-среде. Он включает в себя определение компонентов актива, для чего он используется и как он связан с другими активами.
Ключевое различие между CMDB и управлением активами состоит в том, что CMDB включает активы в качестве элементов конфигурации (CI), в то время как активы управления активами представляют собой отдельные элементы, которые имеют базовую финансовую ценность для бизнеса.
7. Почему CMDB так важен для эффективного управления активами?
Поскольку CMDB хранит все данные CI, все компоненты ITSM полагаются на него для получения любой информации, связанной с активами. Управление активами является одним из компонентов ITSM, для которого требуется CMDB для выполнения некоторых из следующих функций
Заключение
Всегда имейте в виду, что CMDB и управление активами играют определенные роли, но они также взаимозависимы. Без надлежащей CMDB у вас не будет надежного управления активами.
По-прежнему испытываете трудности с управлением активами? Пора переключиться на Motadata ServiceOps ITSM, который даст вам полный опыт управления активами. Попробуйте Motadata ServiceOps бесплатно в течение 30 дней.
CMDB в системе управления ИТ-услугами
Несмотря на интерес к ITSM и понимание преимуществ централизованного хранилища данных о конфигурации ИТ-инфраструктуры, практическая реализация данных подходов зачастую сталкивается с рядом трудностей. Стоит ли сейчас заниматься внедрением систем управления конфигурациями? А если стоит, то как?
В условиях экономической нестабильности ИТ-руководитель вынужден «балансировать» между растущими требованиями бизнеса к уровню ИТ-услуг и жесткими ограничениями финансирования. Могут ли помочь рекомендации ITIL в создавшихся условиях и надо ли сейчас думать о системах управления конфигурациями? Чтобы помочь в поиске ответов, рассмотрим рекомендации второй и третьей версий библиотеки ITIL и приведем некоторые практические советы по подходам к реализации базы данных управления конфигурациями (Configuration Management Data Base, CMDB) и связанных с ней процессов.
Управление конфигурациями
В России сегодня очень популярны рекомендации библиотеки ITIL v2, в которой CMDB занимает важное место для процессов, связанных с поддержкой ИТ-услуг (на рис. 1 выделены синим). К основным функциям CMDB в соответствии с ITIL v2 относятся: хранение информации по объектам ИТ-инфраструктуры в форме конфигурационных единиц (КЕ); поддержка связей между КЕ, связей КЕ с инцидентами, проблемами, изменениями и релизами; контроль версий КЕ; поддержка «базовых линий» КЕ и «снимков состояния» CMDB. Все это позволяет получить ряд преимуществ, ключевыми из которых являются: улучшение отчетности по ИТ-инфраструктуре, сокращение сроков устранения инцидентов и сокращение количества сбоев ИТ (таблица 1).
Версия ITIL v2 была не лишена недостатков, в частности, каталог услуг вынесен за пределы CMDB, что сказывается на качестве расчета их стоимости. Кроме того, недостаточно внимания уделено управлению жизненным циклом ИТ-активов (движение активов между материальноответственными лицами и т.д.).
ITIL на российских предприятиях
Реализация рекомендаций ITIL у нас в стране зачастую наталкивается на специфику отечественных предприятий.
Процессы не определены на стороне бизнеса. Это характерно для крупных промышленных предприятий, унаследовавших функциональную модель управления еще со времен плановой экономики. Сложно формализовать ИТ-услуги и оценить степень их влияния на бизнес.
Нехватка кадров. Процессные методы управления требуют наличия выделенных ответственных лиц, курирующих функционирование процессов. В случае отсутствия таких лиц регламенты процессов будут существовать только на бумаге.
Нехватка средств. Бизнес в ряде случаев не заинтересован в управлении ИТ-услугами (исключение – компании, предоставляющие ИТ-услуги внешним заказчикам), поэтому каталоги услуг, и особенно соглашения об уровне сервисов, приобретают формальный характер. Внедрение средств управления конфигурациями и изменениями считается «внутренним делом ИТ» и не находит поддержки со стороны бизнеса.
ИТ-специалисты не заинтересованы в управлении конфигурациями/изменениями. Данные процессы (в отличие, например, от процесса «Управление инцидентами») требуют от ИТ-специалистов соблюдения определенных бюрократических процедур, снижают их статус «незаменимых», а преимущества от внедрения этих процессов, особенно на ранней стадии, не очевидны.
ИТ-руководитель не заинтересован в реализации процессов ITIL. В ряде случаев политика «затыкания дыр» отнимает все время ИТ-руководителя, и на внедрение передовых практик не хватает времени и ресурсов.
В результате многие проекты в области ITSM ограничиваются реализацией службы Service Desk, процесса «Управление инцидентами» и части процесса «Управление уровнем услуг» (Каталог услуг без стоимости и без привязки услуг к инфраструктуре) (рис. 1). Реже внедряется процесс «Управление конфигурациями», который зачастую вырождается в «Управление активами» и занимается исключительно задачами учета техники. При этом вследствие низкого уровня зрелости процесса «Управление изменениями» актуальность данных по ИТ-активам, как правило, остается низкой, что требует значительных трудозатрат на инвентаризацию и подготовку отчетов по ИТ-инфраструктуре. В данном случае достигаются (в той или иной степени) цели, связанные с улучшением качества учета в сфере ИТ (таблица 1, строка 1), но не достигаются цели, связанные с повышением качества ИТ-услуг (таблица 1, строки 2, 3).
ITIL v3
В новой версии ITIL процессы управления ИТ сгруппированы в соответствии с жизненным циклом услуг, предоставляемых бизнесу. При этом обеспечивается непрерывный цикл улучшения ИТ-услуг, от их замысла и планирования до проектирования, преобразования и эксплуатации (рис. 2).
В соответствии с ITIL v3, процессы управления ИТ на каждой стадии жизненного цикла услуги взаимодействуют с центральным хранилищем данных, называемым «Система управления знаниями по услугам» (Service Knowledge Management System, SKMS) (рис. 3).
SKMS представляет собой комплексную систему, включающую в себя как записи, связанные с различными процессами: заявки на предоставление доступа к услугам, инциденты, проблемы, ошибки, изменения, релизы и т.д., так и сведения о различных типах каталогов услуг, соглашения: SLA, OLA (Operational Level Agreement – «соглашение операционного уровня»), UC (Underpinning Contracts – «внешние договоры») и сведения о поставщиках внешних услуг. В состав SKMS может входить одна или несколько CMDB, каждая из которых наследует все свойства и функциональные возможности, регламентированные для CMDB ITIL v2. Совокупность технических средств (инструментов, баз данных), обеспечивающих хранение и обработку информации в составе SKMS, называется системой управления конфигурациями (Configuration Management System, CMS). Источники информации, используемой в рамках SKMS, могут относиться к различным системам и приложениям, включая CRM, ERP и SCM. Консолидацию данных различных систем в рамках SKMS обеспечивает «интеграционный уровень» (рис. 3). При этом основным принципом интеграции является минимизация дублирования информации при сохранении ее полноты и обеспечении «прозрачности» и оперативности доступа. Уровень обработки данных предоставляет средства моделирования, анализа, мониторинга и отчетности. На этом уровне обеспечиваются логические связи между данными из различных источников. На уровне представления знаний с системой взаимодействуют конечные пользователи, осуществляющие выполнение поиска, обновление и публикацию информации.
За счет более комплексной интеграции данных в рамках SKMS и выделения нескольких новых процессов, более точно и полно отражающих реалии работы ИТ-подразделений (в частности, добавлены процесс, регламентирующий доступ пользователей к ИТ-услуге, процесс обработки событий, которые не относятся к инцидентам, и т.д.), библиотека ITIL v3 позволяет устранить часть недостатков второй версии и получить дополнительные преимущества (таблица 1): обеспечить «прозрачную» структуру стоимости ИТ-услуги; обеспечить «прозрачную» структуру связей между заявками, услугами и другими КЕ в сочетании с более гибкой системой анализа информации в рамках SKMS. Это позволяет в большей степени сократить сроки устранения инцидентов и сроки обработки заявок других типов, а также в большей степени сократить количество сбоев в работе ИТ-инфраструктуры.
К недостаткам ITIL v3 можно отнести слабое отражение вопросов, связанных с управлением жизненным циклом ИТ-активов (таблица 1). Несмотря на то что процесс «Управление конфигурациями» (ITIL v2) в ITIL v3 переименован в процесс «Управление активами и конфигурациями», практические рекомендации затронули главным образом жизненный цикл ИТ-услуги. Жизненные циклы других ИТ-активов, практическое значение которых как минимум не ниже ИТ-услуг, отражены слабо.
Библиотека лучших практик
Реализацией более комплексной по сравнению с ITIL методологии по управлению ИТ-активами занимается Международная ассоциация по управлению жизненным циклом ИТ-активов (International Association of Information Technology Asset Management, IAITAM). Силами ассоциации, объединяющей несколько десятков компаний, разработана библиотека лучших практик IBPL, состоящая из 12 книг, которые регламентируют все основные процессы, связанные с управлением ИТ-активами: управление активами, программами, проектами, документацией, политиками, коммуникациями, финансами и т.д. Часть процессов, регламентированных в IBPL, «пересекается» с процессной моделью ITIL, уточняя и дополняя последнюю.
Жизненный цикл ИТ-актива состоит из статусов и переходов. Статус отображает фиксированное состояние актива на схеме жизненного цикла, например «Запланировано», «Заказано», «Получено», «Утилизировано». Переходы между статусами представляют собой цепочки действий (которые могут быть автоматическими) или работ (выполняемых вручную), обеспечивающие соответствующее изменение статуса. Например, оплата счета поставщику, приемка техники на склад, инсталляция операционной системы и т.д. Вся информация об активе, о схеме его жизненного цикла, связанных с ним активах, поставщиках, история всех действий и работ хранится в CMDB, которая может быть включена в состав SKMS в рамках комплексной системы управления ИТ-услугами.
Разработка требований к CMDB и CMS
Сформулируем рекомендации ИТ-менеджерам, планирующим внедрение или оптимизацию сервис-ориентированных подходов к управлению ИТ, а также предложим упрощенную методологию, направленную на снижение затрат на всех стадиях эксплуатации CMDB и CMS.
Общий принцип методики звучит так: «Движемся от требований бизнеса к выбору системы, а не наоборот», а сама методика состоит из пяти шагов.
Шаг 1. Определение основных услуг, предоставляемых бизнесу. На данном шаге перечисляются ИТ-системы, наиболее критичные для бизнеса (см. пример в графе 2 таблицы 2), и для каждой из них формулируется ответ на вопрос: «Что будет, если система прекратит работать на некоторое время?» Интервал времени можно задать исходя из статистики подобных сбоев (если она есть) или исходя из экспертной оценки максимального срока восстановления системы от ИТ-специалистов. Результат заносится в графу 3 таблицы 2 в виде названия процесса или услуги в терминологии, понятной бизнесу. Затем по каждой услуге определяется наиболее полный список ИТ-систем, которые также могут привести к сбою. Далее заполняется графа 4 таблицы 2, куда вносится стоимость остановки предоставления соответствующей услуги на максимальный из возможных интервалов времени. Такую оценку можно получить у бизнес-пользователей соответствующей услуги, например, это могут быть штрафные санкции за задержку отчета в налоговую инспекцию. В результате в графе 2 формируется заготовка каталога технических услуг, а в графе 3 – заготовка каталога бизнес-услуг, предоставляемых ИТ-службой (рис. 4). Кроме того, получается стоимостное выражение рисков, связанных с работой ИТ-систем, а на основании полученной стоимости рисков можно принять решение о целесообразности дальнейших работ.
Шаг 2. Определение процессов, подлежащих оптимизации средствами CMS. На данном шаге перечисляются процессы, которые планируется оптимизировать за счет применения CMS, и цели, которых надо достичь по каждому процессу (таблица 3). Кроме того, по каждому процессу необходимо зафиксировать куратора – человека, обладающего достаточными полномочиями, авторитетом и временем для контроля выполнения процедур процесса на стадии его эксплуатации. Если мы затрудняемся указать куратора по процессу или не можем четко сформулировать цели реализации процесса, то с большой вероятностью он не будет работать на практике.
Шаг 3. Определение требований к CMDB. На данном шаге определяется «охват» CMDB: классы объектов, которые будут учитываться в рамках автоматизируемых процессов, и зона учета (площадки, ЦОД, подразделения и т.д., по которым будет производиться учет) (рис. 4). Охват CMDB может изменяться с течением времени, поэтому рекомендуется определить этапы расширения охвата. На первом этапе целесообразно включать в CMDB только те КЕ, информация по которым необходима для повышения качества (скорости обработки заявок, снижения количества сбоев после изменений) по наиболее критичным услугам, перечисленным в таблице 2.
Результаты работы сводятся в «Классификатор конфигурационных единиц» (таблица 4) при дополнении каждого класса КЕ описанием принципа присвоения ему уникального имени. Это имя впоследствии будет использоваться для идентификации КЕ в CMDB и для маркировки физического объекта, связанного с КЕ (например, идентификатор ПК, проставляемый на его корпусе). Сведения о зоне охвата и этапе реализации заносятся в графу «Примечания» таблицы 4.
Сформируем теперь требуемый набор связей между КЕ в виде логической модели данных CMDB, пример которой приведен на рис. 5. Модель должна содержать все классы CMDB, перечисленные в классификаторе (таблица 1), и все связи между КЕ. При формировании связей необходимо руководствоваться принципом «Замкнутая цепочка влияния»: двигаясь по цепочке связей, всегда нужно иметь возможность получить полный перечень КЕ, на которые повлияет изменение (остановка) текущего КЕ. В результате работы над логической моделью данных может быть изменен состав классов КЕ в таблице 4. Связи между КЕ могут иметь различные типы (например: «Содержит в составе», «Материально ответственный» и т.д.). Связи могут отражать влияние одной КЕ на работу другой КЕ, в этом случае их можно будет учитывать при анализе последствий изменений. Перечень полученных связей сводится в классификатор.
Сформируем перечень атрибутов для каждого класса конфигурационных единиц в форме, приведенной в таблице 5. Для каждого атрибута определим источник (источники) актуальных данных (например, LANDesk Inventory manager – для ПК и серверов, Cisco Works – для сетевого оборудования, MS Active Directory + Кадры – для пользователей и т.д.). Не следует дублировать всю информацию внешнего источника в CMDB. Набор атрибутов должен быть минимально необходимым для обеспечения оперативной обработки инцидентов и анализа изменений. Кроме того, обязательно должны быть атрибуты, однозначно идентифицирующие каждый КЕ во всех внешних источниках информации по нему и атрибуты-связи в соответствии с рис. 5. Если автоматизированных средств заполнения информации по атрибуту или связи нет, то необходимо указать процедуру процесса, в рамках которой актуальность значения данного атрибута будет поддерживаться вручную. Следует учитывать, что чем больше атрибутов, поддерживаемых вручную, тем выше трудоемкость (и стоимость) эксплуатации системы, тем ниже актуальность данных в CMDB и тем меньше эффект от реализации CMS. В случае если нельзя определиться с источником данных по какому-либо атрибуту (или по целому классу КЕ), его следует исключить из CMDB, так как неактуальная информация дискредитирует систему в глазах пользователей на стадии эксплуатации.
Шаг 4. Составление перечня требований к системе. На этом шаге формулируются требования к системе, посредством которой планируется автоматизировать процессы управления ИТ в форме таблицы. Требования целесообразно группировать по автоматизируемым процессам. Следует учитывать требования по интеграции с имеющимися системами, требования к отчетности, к пользовательским интерфейсам и т.д. Таблицу описания можно дополнить столбцами для указания источника требования (для какой группы специалистов или менеджеров требование актуально) и его весового коэффициента (обязательное/желательное). Требования к системе должны быть направлены на повышение качества услуг, которые мы сформировали на первом шаге.
Шаг 5. Формулировка критериев выбора системы. На предыдущих шагах мы получили подробный перечень требований к СMS и описание CMDB. Процесс сравнения большого количества систем по полному перечню требований может занять много времени, поэтому целесообразно сформировать набор наиболее общих и важных критериев для получения «короткого списка» систем на основании полученной на предыдущем шаге таблицы и провести первоначальный выбор по этим критериям. В качестве дополнительных критериев отбора могут быть использованы: гибкость (возможность изменения глубины и охвата CMDB на стадии эксплуатации, гибкость настройки пользовательских интерфейсов и т.д.), цена (включая лицензии, внедрение, поддержку, обновление версий, обучение), надежность регионального поставщика и разработчика системы. На российском рынке представлены как комплексные системы (Service Desk + CMDB) наподобие Axious Systems assyst, BMC Remedy, LANDesk Service Desk, Naumen Service Desk, OmniNet Omnitracker, так и специализированные решения: HP Universal CMDB (CMS c гибкими интеграционными возможностями) и LANDesk Asset Lifecycle Manager (CMDB и средства реализации методологии IBPL).
Любая методология, будь то ITIL или IBPL – это лишь набор общих рекомендаций, основанных на передовых практиках, и от того, насколько грамотно данные рекомендации применены в условиях конкретной компании, во многом зависит эффективность и жизнеспособность полученных процессов управления ИТ. В статье был рассмотрен один, хотя и немаловажный, элемент системы автоматизации данных процессов – CMDB. Следует понимать, что CMDB, как бы грамотно она ни была спроектирована и какие бы комплексные системы ни лежали в основе ее функционирования, не даст положительного эффекта без реализации гибких и адаптируемых к условиям компании процессов управления ИТ. С другой стороны, грамотно выстроенные процессы управления ИТ в сочетании с комплексной системой управления конфигурациями позволяют получить значительное снижение трудозатрат на поддержку ИТ и повысить надежность и качество ИТ-услуг.