В условиях экономической нестабильности ИТ-руководитель вынужден «балансировать» между растущими требованиями бизнеса к уровню ИТ-услуг и жесткими ограничениями финансирования. Могут ли помочь рекомендации 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, как бы грамотно она ни была спроектирована и какие бы комплексные системы ни лежали в основе ее функционирования, не даст положительного эффекта без реализации гибких и адаптируемых к условиям компании процессов управления ИТ. С другой стороны, грамотно выстроенные процессы управления ИТ в сочетании с комплексной системой управления конфигурациями позволяют получить значительное снижение трудозатрат на поддержку ИТ и повысить надежность и качество ИТ-услуг.

Сергей Лямуков (Lyamukov@arbyte.com) – менеджер по развитию бизнеса компании Arbyte (Москва).