Правильная реализация процессов управления конфигурацией позволяет не только решать проблемы путем идентификации причины «поломки» (какой элемент вышел из строя, и как его «починить»), но и полностью предотвращать их возникновение за счет оценки логики работы с данными. Грамотная оценка производимых изменений позволяет поддерживать системы в работоспособном состоянии, а неправильная - приводит к пустой трате денежных средств.

Помимо финансовых затрат, неверное управление конфигурацией ведет к расходованию иных ресурсов, например человеко-часов. Ресурсы приходится затрачивать и на работу с клиентами во время устранения неполадок с IT-инфраструктурой. Сложно управлять изменениями, если внедрение решений не подкрепляется CMS-системой. Поэтому сегодня мы расскажем, о внедрении процессов управления конфигурацией и на какие аспекты следует обратить пристальное внимание.

С чего начать

Прежде чем начинать внедрение, необходимо объяснить смысл CMS-системы всем участникам экосистемы: членам команды, клиентам и др. Это важно, поскольку в дальнейшем каждая сторона будет принимать участие в управлении конфигурацией - члены команды CMS должны предоставлять точную информацию своим коллегам, ответственным за инциденты и изменения, а действия, производимые IT-специалистами должны отображаться в базе данных управления конфигурацией (CMDB).

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

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

Составление плана

Мы рекомендуем начать планирование управления конфигурацией с наиболее критичных бизнес-процессов - обработки инцидентов и проблем. Служба технической поддержки всегда загружена заявками от пользователей, поэтому важно обеспечить их своевременное исполнение. Реализация проекта с этого класса услуг позволит оптимизировать работу технической поддержки, что непременно скажется на эффективности других отделов компании.

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

Определение исходного состояния

Этап определения исходного состояния - это следующий шаг после планирования, который нужен, чтобы понять из каких элементов состоит инфраструктура компании в настоящий момент. Такой снимок в будущем может быть использован для сравнения состояний, например, «в этом году объем имущества увеличился на 20%, что привело к появлению 2 тыс. новых изменений».

Как только исходное состояние определено, следует убедиться, что ему соответствуют соглашения об уровне услуг (SLAs), операционные соглашения (OLAs), внешние договоры (UCs), связанные с IT-инфраструктурой и сервисами организации.

Определение исходного состояния стоит начинать с какого-либо одного сервиса, расписав все его компоненты. При этом полученная информация должна заноситься в базу данных ITSM-платформы, например ServiceNow, или простую базу данных CMDB - это может быть таблица в Excel или Access.

Что касается платформы ServiceNow, то она предоставляет удобные инструменты для создания и ведения системы управления конфигурацией. Пользователю доступны двести типов конфигурационных единиц, таких как компьютеры, ноутбуки, серверы, оргтехника, программное обеспечение, интернет-ресурсы и др. Импортом в базу данных CMDB занимается приложение ServiceNow Discovery, которое автоматически сканирует сеть и добавляет найденные единицы.

Также отметим, что важно определить ответственное лицо за внесение информации в базы данных.

Контроль

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

Тесно сотрудничать с работниками, осуществляющими контроль изменений, дабы работа управления конфигурациями следовала корпоративным политикам об изменениях. Без контроля изменений CMS/CMDB быстро устареет.
Конфигурационные единицы, участвующие в процессе оказания услуги, должны быть с ней связаны. Это даст пользователю возможность быстро выбрать требуемый сервис. В этом случае все CI добавятся автоматически.
ИТ-специалисты, отвечающие за систему управления конфигурацией, должны участвовать в консультативных советах по изменениям (CAB), чтобы отображать в CMS и CMDB производимые с инфраструктурой изменения. При этом все вносимые изменения должны проверяться, перед закрытием тикета как успешного.

Учет состояния

Следующий этап - учет состояния, который нужен для отслеживания жизненного цикла всех конфигурационных единиц (CI) - «строительных блоков», включающих в себя серверы, маршрутизаторы, программное обеспечение и все системы, на которых оно построено - и их текущего состояния. Статусы жизненного цикла CI должны быть определены в политике CMS, чтобы гарантировать согласованность и документальное подтверждение всех стадий, через которые проходит конфигурационная единица. Среди таких этапов выделяют: запланировано, приоритет повышен, доставлено, тестовая среда, рабочая среда, не используется, удалена.

Аудит

Заключительный этап внедрения CMS называется проверка и аудит. Его задача - гарантировать достоверность данных, представленных в CMDB: все рабочие CI должны соответствовать тому, что указано в CMS/CMDB, а документация поддержки должна точно описывать все CI. Чтобы удовлетворить эти требования, важно составить и утвердить план проверок, содержащий ответы на следующие вопросы:

Имеются ли специальные инструменты для проведения проверок?
Требуется ли физическая проверка?
Каковы нормативные требования?
Есть ли сертификация по стандарту ISO 20000 и должны ли выполняться IL3, BASEL 3 или NGN224, требующие вмешательства третьей стороны?

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

При этом, различные ITSM-системы (включая ServiceNow) позволяют проводить аудит в автоматическом режиме, используя для этого специальные дашборды, переводящие огромное количество информации в вид, понятный пользователю.

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

P.S. Другие материалы из нашего блога «ИТ Гильдия».

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

Цель процесса управления конфигурациями - сбор и актуализация информации о составляющих частях IT-инфраструктуры, обеспечение данной информацией прочих процессов Управления услугами.

Конфигурационная единица (сonfiguration item или CI ) – элемент инфраструктуры или объект, связанный с элементами инфраструктуры (например, RFC), который находится/ должен находиться под контролем процесса управления конфигурациями. Конфигурационными единицами могут являться любые элементы, которыми необходимо управлять с точки зрения жизненного цикла ИТ-услуги. Точных рекомендаций по тому, что считать конфигурационной единицей, не существует. Однако различные источники (в том числе ITIL ) дают подсказки: это может быть аппаратное и программное обеспечение, документация и даже персонал. То есть любой ИТ-актив, сервисный компонент или любой другой элемент, который задействован на протяжении жизненного цикла ИТ-услуги.

Конфигурационная база данных (Configuration Management Database или CMDB ) – база данных, содержащая все необходимые сведения по всем CI и о связях между ними. Все Конфигурационные Единицы должны быть включены в Конфигурационную Базу Данных (CMDB), которая отслеживает все ИТ-компоненты и взаимоотношения между ними. В самой примитивной форме Конфигурационная База Данных представляет собой набор бумажных форм или электронных таблиц.

Базисная конфигурация (сonfiguration baseline или CB ) – конфигурация продукта/ системы в определенный момент времени, отражающая структуру и детали этого продукта/ системы. Базисная конфигурация позволяет восстановить состояние продукта/ системы. По сути это актуальное состояние Конфигурационной Единицы.

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

Управление конфигурациями (Configuration Management) – процесс хранения технической информации о CI и связях между ними. Это процесс, который отвечает за необходимые конфигурационные элементы для оказания ИТ услуги и за их связи с управлением. Этой информацией управляют через конфигурационные элементы на протяжении всего жизненного цикла.

Управление конфигурациями не следует путать с Управлением активами .

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

Основные действия по управлению конфигурациями это:

Сбор информации о каждом конфигурационном элементе
Определение и анализ связей и взаимодействий между разными конфигурационными элементами
Накопление информации в специальные базы данных управления конфигурациями (CMDB Configuration Management Database), где хранятся записи о конфигурациях на протяжении всего их жизненного цикла.
Контроль целостности системы после каждого изменения конфигураций
Постоянное слежение за ИТ инфраструктурой и ее анализ

Процесс конфигурационного управления дает логичную модель ИТ инфраструктуры и услуг. Он определяет, следит, обеспечивает и контролирует развитие различных конфигурационных элементов в инфраструктуре.

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

разработка правил учета элементов ИТ-инфраструктуры;
осуществление учета в соответствии с разработанными правилами;
разработка правил получения/предоставления информации и проверки точности;
осуществление повседневной деятельности в соответствии с разработанными правилами.

При разработке правил учета особое внимание следует уделить разработке системы классификации конфигурационных элементов.

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

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

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

Существует несколько различных подходов к построению CMDB :

использование существующей в организации бухгалтерской системы;
создание собственной базы данных;
использование специализированного средства автоматизации.

Создание собственной системы - наиболее гибкий и полный вариант. Основным его недостатками является высокая ресурсоемкость.

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

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

Часто внедрение подходов библиотеки ITIL приносит успех, если начинать внедрение с Управления конфигурациями и Управления изменениями (Configuration & Change Management). Такая связка логична, потому что эти процессы наиболее взаимозависимы и при этом сильно влияют на другие процессы. С одной стороны информация об актуальной конфигурации ИТ-сервисов, хранящаяся в CMDB , является необходимым условием для Управления инцидентами и других процессов, как оперативных (Управление проблемами, изменениями, релизами ), так и тактических (Управление уровнем сервиса, финансами, мощностью, доступностью, непрерывностью ). С другой – без эффективного Управления изменениями невозможно достичь главной цели Управления конфигурациями – актуальности данных в CMDB .

Управление конфигурациями – это метод систематического учёта и обработки изменений в продукте для поддержки целостности системы. Этот термин пришёл в программирование из других областей, теперь он широко используется для обозначения управления конфигурацией сервера.

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

Оркестровка – ещё одна важная составляющая продуктивного управления конфигурациями. Инструменты для оркестровки позволяют управлять огромным количеством серверов (до сотен) с помощью одного ведущего сервера.

Сегодня существует огромное количество инструментов для управления конфигурациями, самыми популярными являются Puppet, Ansible, Chef и Salt. Каждый инструмент имеет свои особенности и преимущества, однако все они объединены одной целью: обеспечить соответствие системы состоянию, описанному в сценариях.

Преимущества конфигурационного управления сервера

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

Быстрое добавление и запуск новых серверов. Когда возникает необходимость развернуть новый сервер, инструмент управления конфигурацией может выполнить большинство основных задач автоматически. Автоматизация может значительно ускорить и улучшить развёртывание сервера; инструменты автоматизации выполняют любой процесс развёртывания быстрее и точнее, чем администратор. К примеру, развёртывание веб-сервер вручную (даже с хорошей документацией) может занять несколько часов, а инструмент делает это за несколько минут.
Быстрое восстановление. Когда сервер по неизвестным причинам отключается, на полный аудит системы и выяснение этих причин может уйти несколько часов. Благодаря быстрому развертыванию серверов система может автоматически развернуть запасной сервер, который будет поддерживать все сервисы, пока восстанавливается поврежденный сервер.
Простота. На первый взгляд, администрирование системы вручную кажется очень простой задачей. Однако со временем администратору становится всё труднее запоминать все программы, установленные на сервер, и все внесённые изменения. Устранение неполадок, тонкая настройка и обновление программного обеспечения делает сервер настолько уникальным, что ним трудно управлять и еще труднее воспроизвести. Инструменты управления конфигурациями регистрируют все процедуры, необходимые для развёртывания нового или обновления существующего сервера, в своих сценариях.
Контроль версий окружения. Переписав окружение сервера в сценарии, вы можете управлять серверным окружением при помощи инструментов и рабочих процессов, которые обычно используют для исходного кода программы. Инструменты контроля версий (например Git) позволяют отслеживать изменения и поддерживать отдельные ветви сценариев. Также с их помощью можно внедрить политику контроля кода. При этом любое изменение будет восприниматься как pull запрос. Это позволяет улучшить консистентность данных инфраструктуры.
Репликация окружения. Конфигурационное управление позволяет быстро реплицировать окружение, благодаря чему можно создавать многоуровневые экосистемы, в которых будут поддерживаться серверы разработки, тестирования и развёртывания. Это позволяет использовать для разработки локальные виртуальные машины, созданные с помощью одних и тех же скриптов инициализации. Такой механизм позволяет свести к минимуму проблемы, вызванные конфликтом данных разных окружений, что часто происходит при развёртывании одного приложения на разных машинах (с разными операционными системами, версиями программного обеспечения и конфигурациями).

Инструменты управления конфигурациями

Каждый инструмент конфигурационного управления имеет собственную философию и экосистему, но при этом все они имеют много общих функций и характеристик.

Большинство таких инструментов использует модель «контроллер — мастер» и «нода – агент». По сути, контроллер управляет конфигурацией нод, используя ряд инструкций или задач, указанных в сценариях.

Ниже описаны наиболее распространённые функции, которые предоставляют большинство инструментов управления конфигурациями для серверов:

Автоматизация. Каждый инструмент имеет специальный синтаксис и набор функций для написания сценариев автоматизации. Язык большинства инструментов похож на несколько упрощённый язык программирования. Для создания более универсальных скриптов инициализации можно использовать переменные, циклы и условные выражения.
Идемпотентность. Средства управления конфигурацией отслеживают состояние ресурсов, чтобы избежать повторения задач, которые были выполнены ранее. К примеру, если пакет уже был установлен, инструмент не будет пытаться установить его снова. Суть состоит в том, что после каждого запуска развёртывания система достигает необходимого состояния (или сохраняет его), даже если вы запускаете его несколько раз. Это и есть идемпотентное поведение (его можно применять опционально).
Подробные данные о системе. Средства конфигурационного управления предоставляют подробную информацию о системе, с которой они работают. Доступ к таким данным можно получить с помощью глобальных переменных – так называемых фактов. Они включают в себя сетевые интерфейсы, IP-адреса, операционные системы, распределение и многое другое. Каждый инструмент предоставляет индивидуальный набор фактов. Их можно использовать для создания универсальных и адаптивных сценариев и шаблонов, которые можно применить в нескольких системах.
Система шаблонов. Большинство инструментов управления конфигурациями предоставляет встроенную систему шаблонов, которые можно использовать для быстрого создания конфигурационных файлов и сервисов. Шаблоны обычно поддерживают переменные, циклы и условные выражения. Например, шаблоны можно использовать для создания новых виртуальных хостов Apache или для установки серверов. Помимо статических значений, шаблон должен содержать значения, индивидуальные для каждого хоста (например NameServer и DocumentRoot).
Расширяемость. Любой сценарий для управления конфигурацией можно индивидуализировать, подогнать под самые строгие требования и нужды конкретного сервера. Однако часто возникает необходимость использовать одни и те же конфигурации (или их часть) на нескольких серверах. Большинство средств управления конфигурацией предоставляет возможность повторно использовать фрагменты сценариев в качестве модулей и плагинов.

Сторонние модули и плагины всегда можно найти в интернете, особенно много в сети модулей для общих конфигураций сервера (для PHP, веб-серверов и т.п.). Средства управления конфигурацией активно поддерживаются сообществами, где другие пользователи делятся своими плагинами и модулями. Это экономит много времени и позволяет быстро подобрать удачное решение общих проблем с конфигурациями.

Как выбрать инструмент управления конфигурациями

Очень важно выбрать правильный инструмент, который хорошо подойдёт вашему серверу. Сегодня существует огромное количество средств управления конфигурациями разной сложности, каждое из которых предоставляет индивидуальный набор функций. Самыми популярными инструментами являются Chef, Ansible и Puppet.

Сложность инфраструктуры

Большинство инструментов управления конфигурациями требуют минимальной иерархии, состоящей из ноды и контроллера, который будет управлять ею. К примеру, для работы Puppet на каждую ноду нужно установить агент, а на контроллер – приложение мастера. Ansible реализует децентрализованную модель управления, для этого не нужно устанавливать дополнительного ПО на ноды; однако для выполнения задач необходим постоянный доступ SSH. В маленьких проектах лучше использовать упрощённую инфраструктуру, но при этом важно учитывать такие аспекты как масштабируемость и безопасность.

Некоторые инструменты могут состоять из большего числа компонентов, а это может усложнить инфраструктуру и увеличить общую стоимость развёртывания.

Стоимость

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

Продвинутые функции

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

Сообщества и поддержка

Активное сообщество может стать чрезвычайно важным ресурсом поддержки и документации. Пользователи, как правило, с удовольствием делятся с другими своими знаниями и самостоятельно разработанными расширениями (модулями, плагинами и сценариями). Это может ускорить процесс обучения и избежать дополнительных затрат.

Краткий обзор популярных инструментов

Приведенная ниже таблица предлагает краткий обзор основных различий между тремя из самых популярных инструментов управления конфигурациями, Ansible, Puppet и Chef.

	Ansible	Puppet	Chef
Язык сценариев	YAML	DSL на основе Ruby	Ruby
Инфраструктура	Контроллер, управляющий нодами через SSH	Puppet Master синхронизирует конфигурации на нодах (Puppet Node)	Рабочая станция Chef передаёт конфигурации на Chef Server, который в свою очередь обновляет данные на нодах.
Специальное ПО для нод	Нет	Да	Да
Централизованное управление	Нет; по сути, любая машина может быть контроллером.	Да (Puppet Master)	Да (Chef Server)
Терминология сценариев	Playbook / роли	Манифесты/модули	Рецепты/кукбуки
Выполнение задач	Последовательное	Непоследовательное	Последовательное

Заключение

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

Tags: , 6 марта 2009 в 11:10

Конфигурационный менеджмент (часть1, вступительная)

Управление проектами

Как разрабатывать большое ПО? Ни для кого не секрет, что потребность в разработке больших и сложных программных продуктов была всегда и также всегда была независимой от уровня технологий, существующих на тот или иной момент времени. Но исследуя и анализируя существующие подходы к девелопменту, я так и не смог ответить на самые простые вопросы, связанные с «правильной» разработкой качественных программ. Одним из простейших вопросов, который я перед собой ставил, был вопрос о том, как назначать номера версий выпускаемому программному продукту. Наверняка многие согласятся, что это касается не только больших корпоративных приложений, но и самых простых приложений, которые выходят из под пера начинающих программистов, школьников и студентов. Смысл назначения версий возникает тогда, когда программа перестает быть экспериментом и начинает делать что-то полезное. Но стоит заметить, что даже экспериментальным версиям программ есть смысл назначать уникальный идентификатор. Изменение номеров версий отображает последовательный подход к разработке и, с одной стороны, представляет собой соответствие выдвигаемым к разрабатываемой программе требованиям, а с другой стороны – связь с предыдущими версиями в виде общей базовой функциональности или базы исходного кода (source codebase). Мы уже не задаем вопрос о том, как разрабатывать большое ПО, а пытаемся представить себе то, как назначать версии своим программам. Да, но какая между этими вопросами связь? На самом деле очень большая.

Перед началом разработки какого либо программного проекта должно быть решено довольно много вопросов: где взять финансирование, сколько людей будет работать над проектом, какие установить сроки, какие есть риски и много-много других. Но это с менеджерской позиции. С позиции программиста решаются вопросы другого рода: проектирование архитектуры, базы данных, рисование UML-диаграмм и прочее. Но это в теории – потратить день, чтобы за 5 минут долететь. Если считать все вышеуказанные шаги этапом «0» в разработке проекта, то на практике программный проект начинается с этапа номер «1» – с разработки. Пусть это не совсем правильно, но что делать тогда, когда ни на один из вопросов, которые ставятся перед началом разработки ответить с большой степенью вероятности нельзя? Даже если такие ответы есть, в том или ином виде любой программный продукт претерпевает эволюционные изменения - требования имеют тенденцию меняться. Таким образом, любой программный проект подвергается трудно формализуемым влияниям, которые своим результатом имеют разные версии продукта, от этого никуда не деться.

Гибкие методологии (agile methodologies) известны тем, что пытаются организационными мерами решить подобного рода проблемы, и это, надо сказать получается довольно успешно. Но это организационный уровень. Программистский уровень предполагает немного другие задачи и проблемы. Нельзя сказать, что они не решаются совсем, но недостаток таких решений, на мой взгляд, заключается в том, что всеми они решаются по-разному. Даже одними и теми же людьми, но для разных проектов одни и те же задачи решаются по-разному. Для того, чтобы понять что я имею в виду и для того, чтобы выделить суть подходов к гибкой разработке с точки зрения программиста я перечислю подходы, которые обычно используются:

Контроль версий (version control)
Автоматизированные сборки (build management)
Юнит-тестирование (unit-testing)
Статический анализ кода (static source code analysis)
Генерация документации на основе исходного кода (javaDoc, phpDoc, Doxygen итп)
Непрерывная интеграция (continuous integration)

Обычно разработка не обходится без использования какой-нибудь системы контроля версий. Все остальные подходы могут применяться или не применяться в отдельных проектах. Это уже зависит от специфики разрабатываемой системы, многих других факторов, главными из которых, на мой взгляд, являются возможность управления всеми подходами, наличие необходимых для этого навыков и ресурсов, а также необходимость обеспечения качества разрабатываемой системы.

Как оказалось, существует отдельная дисциплина инженерии программного обеспечения, которая занимается подобного рода организационными задачами без привязки к методологиям – это конфигурационный менеджмент (configuration management). Управление конфигурациями является основной дисциплиной в определении того, каким образом управляются и контролируются рабочие материалы программного проекта, внесенные в него изменения, а также информация про состояние отдельных задач и всего проекта в целом. Успех проекта в большой мере зависит от того, насколько налажен процесс управления конфигурациями и это может как спасти проект, так и похоронить его в том случае, если управление конфигурациями работает плохо.

Глоссарий IEEE 610 описывает управление конфигурациями как дисциплину применения технических и административных указаний (инструкций) и контроля (наблюдения) для: идентификации и документирования функциональных и физических характеристик элементов конфигураций; контроля (управления) над изменениями этих характеристик; записи (сохранения) и ведения отчетности по обработке изменений и статуса их реализации; проверки (верификации) соответствия выдвинутым требованиям.

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

Subversion; CVS; Git; Mercurial; Bazaar; Microsoft Visual SourceSafe; ClearCase; Perforce
Ant; Nant; Maven; Phing; make; nmake; Cmake; MSBuild; Rake
JUnit; NUnit; CPPUnit; DUnit; PHPUnit; PyUnit; Test::Unit; vbUnit; JsUnit
PMD; FxCop; PHP_CodeSniffer; PyChecker, lint
JavaDoc; phpDocumentor; CppDoc; RDoc; PyDoc; NDoc; Doxygen
CruiseControl; CruiseControl.NET; TeamCity; xinc; Atlassian Bamboo; Hudson
Jira, Trac, Mantis, Bugzilla, TrackStudio

Так сложилось, что я увлекся данным вопросом настолько, что даже написал целую дипломную работу, в которой исследовал методы и средства управления конфигурациями. Также получилось разработать метод, который позволяет объединить все используемые средства (если точнее, то их подмножество) конфигурационного менеджмента в одну платформу. Если сообществу покажется интересным, то я планирую написать цикл статей, в котором планирую изложить то, как я пришел к формализованному методу управления версиями и попробовать передать хотя бы частично его суть. Думаю, это будет полезно по двум причинам:

Я немного расскажу об упомянутых средствах и инструментах так сказать «с высоты птичьего полета» в разрезе управления конфигурациями, попробую привести описание их места в общей мозаике средств разработки.
Покажу наконец, какими принципами нужно руководствоваться при назначении релизам программных продуктов номеров версий, попытаюсь сделать этот вопрос более прозрачным, чем он есть (подозреваю для многих) сейчас.

Для того, чтобы подогреть интерес к последующим статьям, расскажу немного о сути метода. Так как управление конфигурациями базируется в основном на ведении репозитория исходного кода, вполне логично было бы предположить, что для того, чтобы согласовать работу всех инструментов управления конфигурациями, нужно формализовать правила ведения репозитория. Это должно быть сделано в таком виде, чтобы принятые соглашения могли использоваться в любом из составных элементов платформы управления конфигурациями – в инструментах сборок, инструментах непрерывной интеграции, и, конечно же, людьми. Таким образом, репозиторий структурируется (каждой директории репозитория соответствует определенный класс содержимого, который может в этой директории находиться), а также определяются шаблоны именования директорий. Одним из шаблонов директорий и есть шаблон вида х.х.х, где х – это число. Если более точно, то шаблон описывается регулярным выражением вида \d+\.(\d+|x)\.(\d+|x)(_.*)? . Такой шаблон соответствует наиболее распространенной системе именования сборок и релизов, к которой все привыкли (примеры: 1.0.2, 2.3.5, 3.10.23). Отличие использования данного подхода к именованию в моем методе заключается в том, что зависимости изменений каждой цифры в системе именования от некоторого момента времени описываются формально.

Продолжение следует

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

В большинстве случаев после принятия решения об управлении основными элементами ИТ-инфраструктуры все силы бросают на наполнение CMDB, в которую заносится максимальное количество информации об CI. Через некоторое время информация начинает терять актуальность, разрушаются связи между объектами, появляется нехватка описания не физических, а логических объектов инфраструктуры – все это приводит к отказу от дальнейшего развития. Причина неудач кроется в неправильной оценке внедрения процесса управления конфигурацией, ведь он включает в себя не только базу данных, но и логику в ее заполнении, актуализации и развитии.

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

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

Важность управления конфигурацией

Порой старшие менеджеры говорят, что у них нет денег на покупку дорогостоящих систем для управления конфигурацией (CMSs). Но, принимая такое решение, они не получают контроля над всеми расходуемыми средствами, связанными с восстановлением ИТ и бизнес-услуг; над внесением изменений, без контроля последствий их применения и возможных неблагоприятных последствий для бизнеса; над управлением и оптимизацией затрат на ИТ-имущество и управлением релизами без связи с другими процессами.

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

А также время, которое вы вынуждены тратить на отчеты для руководства о снижении ключевых бизнес-сервисов, так как изменили систему управления; на объяснение клиентам о задержке устранения инцидента с ИТ-инфраструктурой из-за отсутствия системы CMS; на устранение дефектов релиза из-за плохого управления имуществом.

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

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

С чего стоит начать

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

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

В целом внедрение управления конфигурацией можно разделить на 5 этапов:

планирование,
определение (в том числе исходного состояния),
контроль,
учет состояния,
проверка и аудит.

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

Составление плана

Мы рекомендуем начать планирование управления конфигурацией с наиболее критичных и важных для бизнеса процессов, таких как управление инцидентами и проблемам. Служба технической поддержки всегда загружена заявками от пользователей, и их своевременное исполнение – одна из головных болей руководства. Если вы начнете реализацию проекта именно с этих услуг, это поможет снизить нагрузку и оптимизировать работу специалистов Service Desk и результат заметят другие подразделения компании. Руководство обратит внимание на более быстрое разрешение инцидентов, уменьшение времени простоя, снижение числа неудачных изменений и обеспечит вас поддержкой для дальнейшей реализации.

Условно можно выделить 3 основных элемента (уровня) конфигурации:

конфигурация;
актив;
материально-технический ресурс.

Их распределение отображено на представленной ниже диаграмме.

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

Последовательность – ключ к планированию

При грамотном планировании важна последовательность действий и внимание к мелочам. Например, план может содержать описание способа формирования имен CI. Имя каждой единицы для CMDB должно быть уникально и содержать ключевую информацию, которая помогает ее идентифицировать. Примером может служить такая маска: Тип CI – расположение – служба поддержки. Имя CI «MSserver-Moscow-Level3» говорит оператору Service Desk о том, что Windows Server на московской площадке недоступен и нуждается в технической поддержке третьей группой. Такой уровень информации при регистрации инцидента позволяет сразу предупредить всех пользователей сервера о проблеме, а также назначить тикет именно той группе поддержки, которая за него отвечает, что сокращает время реакции за счет сокращения стадий эскалации.

Это не единственный способ присвоения уникальных имен CI, вы можете называть их даже по именам персонажей любимой книги, главное, чтобы при планировании эта система была заранее прописана в SLA и в процессе работы соблюдалась последовательность.

План конфигурации должен быть масштабируемым

При планировании вы составляете список только критических служб и сервисов, которые необходимы для управления и поддержки предоставления услуг. Затем при расширении зоны охвата управления конфигурации можно просто добавлять новые элементы вашей инфраструктуры – это более простая задача, которую можно осуществить позже. Масштабировать систему можно бесконечно (все зависит от роста вашей компании и набора предоставляемых услуг), но заложить основу необходимо сразу при планировании до начала внедрения.

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

Это все, что касается планирования управления конфигурацией. В следующей статье мы рассмотрим определение, контроль, учет состояния, проверку и аудит. А также покажем, как реализован этот процесс на платформе ServiceNow.

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

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