Несколько странно и немного досадно наблюдать за этим. Дело в том, что я проработал в SCM в общем сложности около 5 лет, из них 3 года - интегратором в Motorola, на одном из проектов по разработке софта для сотовых телефонов. По ходу дела прочитал кучу материалов по этой теме и получил большой практический опыт - в том числе по работе с одной из мощнейших систем контроля версий IBM Rational ClearCase (см. linkedin в профиле). В итоге в голове сформировалась некоторая целостная картина того, что же это на самом деле - software configuration management.
А потом увидел статью от камрада altern , в которой он начал рассказывать про СМ. Речь у него пошла несколько в другом ключе - о конкретных инструментах и именовании конфигураций. Поэтому, списавшись с ним, чтобы не пересекаться по тематике наших статей, решил написать об основах того, что называется управлением конфигурацией программных средств.
Сейчас у меня уже написан материал примерно на 50 тысяч знаков - это приблизительно 5-7 среднего размера постов для Хабра. И процесс написания продолжается. Я собираюсь выкладывать написанное с небольшой периодичностью сюда и, по мере исчерпания вопросов и обсуждений, постить новые заметки.
Задача - дать обзор того, чем же вообще является CM, какие задачи он решает и какие техники при этом используются. Речь не будет идти о конкретных системах контроля версий или вообще инструментах - этого добра навалом в сети. Задача - показать универсальные для всех инструментов основы.
Итак, поехали.
Что такое CM и зачем он нужен
Управление конфигурацией
Для начала определимся, что такое configuration , ведь это слово выведено в заголовок. Конфигурация – это совокупность версий рабочих продуктов. Ключевые слова – «версий продуктов».В любом проекте есть рабочие продукты – это может быть маркетинговая документация, требования к конечному продукту, исходные коды, тесты, вспомогательные инструменты. Что считать рабочим продуктом, зависит от проекта (определение будет дано в следующей заметке). Далее, каждый продукт изменяется во времени (в этом ведь смысл разработки), и эти изменения надо как-то учитывать – кто, когда, что именно внёс и зачем он это сделал. Иными словами, учитывать, как появлялись версии продуктов.
Версия – это состояние рабочего продукта, которое может быть восстановлено в любой момент времени независимо от истории изменения.
Соответственно, управление конфигурацией – это управление наборами рабочих продуктов и их версиями. Этот процесс и есть область действия CM.
В англоязычной литературе используется термин Software Configuration Management , сокращенно SCM . Далее для простоты изложения будет использован термин управление конфигурацией и сокращение CM (читается: «сиэм»).
Схема 1. Элементы, их версии и срезы-конфигурации.
CM является одной из базовых практик любой методологии разработки ПО. Достаточно сказать, что в модели SEI CMM/CMMI (Capability Maturity Model Integration) наличие налаженного процесса управления конфигурацией – необходимое условие для получения организацией сертификата CMM/CMMI Level 2.
Замечу, что Level 2 – это самый минимальный, начальный уровень зрелости, согласно модели CMM. Level 1 получает «автоматом» организация, завершившая успешно хотя бы один проект по разработке. Поэтому и наличие CM – это минимальное требование для сертификации. Кстати, на втором уровне необходимо иметь, в числе прочего, налаженный процесс тестирования и управления требованиями. Это говорит о том, что с точки зрения стандарта CMMI, правильный configuration management так же важен, как грамотное тестирование и управление требованиями.
Так в чем же заключается такая ценность CM?
Направления ответственности CM
Управление конфигурацией работает на всех этапах жизненного цикла проекта. Появился рабочий продукт (например, файл с исходниками) – он попадает в поле деятельности CM’а. Продукт начал изменяться (мы пишем функциональность) – значит CM должен предоставить средства для контроля над изменениями и автоматически провести сам контроль, где это требуется. Потребовалось разбить работу на команду разработчиков, а то и на несколько – проектный CM предоставляет правила и инструменты для работы. Есть, что предложить заказчику – тогда CM определяет правила стабилизации продуктов разработки и их выпуска. Надо откатиться на произвольный релиз – опять в работе CM. Понадобились метрики по изменениям или документированные политики – ну, вы поняли, к кому обратиться.Итак, в первую очередь, CM отвечает за идентификацию рабочих продуктов, т.е. отвечает за определение того, что же будет в дальнейшем контролироваться. В следующей заметке будет подробнее про это рассказано.
Продукты выделили, дальше команда начинает работу. По ходу работы нужно периодически стабилизировать полученные результаты, подводить некоторую черту под наработками, а также определять тот базис, на основе которого будет идти разработка. Это всё также входит в сферу деятельности CM’а.
Кроме того, CM отвечает за то, что в общем случае называется отслеживанием запросов на изменения. Большинству эта область известна как системы отслеживания ошибок. Ведь никакие изменения не должны проходить спонтанно – каждое из них нужно регистрировать и затем правильным образом назначать и отслеживать – вплоть до попадание в конечный продукт. Вот тут опять остается крайним CM. Изменения в продукты вносим, надо их отслеживать – начинает работать контроль версий. Ничто не будет потеряно – CM на страже.
Средства контроля изменений и обеспечения версионности создают условия для распараллеливания разработки в больших командах. Это достигается благодаря тому, что, описав эти средства, мы даем разработчикам документированные процедуры, позволяющие разделять ответственность и ограничивать области деятельности каждого из разработчиков.
Ну и, как всегда, «нельзя контролировать то, что нельзя измерить» - (с) Де Марко. Метрики – о них тоже будет сказано пару слов. Где измерения – там и формализация. Другими словами, всё, что связано с CM, хорошо бы документировать. Об этом тоже вкратце будет упомянуто.
Итак, каковы задачи управления конфигурацией?
- идентификация рабочих продуктов;
- стабилизация результатов работы и определение базы для дальнейшей работы;
- отслеживание запросов на изменение;
- контроль версий;
- обеспечение параллельности разработки;
- сбор метрик и формализация применяемых методов.
Для начала - достаточно. Следующая часть будет посвящено тому, как же определяются продукты и конфигурации, которыми мы будем управлять. Также коснусь вопроса о компонентной разработке, продуктовых линейках и их связи с СМ.
Управление конфигурациями – это метод систематического учёта и обработки изменений в продукте для поддержки целостности системы. Этот термин пришёл в программирование из других областей, теперь он широко используется для обозначения управления конфигурацией сервера.
В конфигурационном управлении очень важную роль играет автоматизация и связанные с ней инструменты. Этот механизм позволяет серверу достичь необходимого заранее определённого состояния (использовать конкретный язык, инструмент или функции). Автоматизация, пожалуй, является важнейшим аспектом управления конфигурациями сервера.
Оркестровка – ещё одна важная составляющая продуктивного управления конфигурациями. Инструменты для оркестровки позволяют управлять огромным количеством серверов (до сотен) с помощью одного ведущего сервера.
Сегодня существует огромное количество инструментов для управления конфигурациями, самыми популярными являются 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
- Я немного расскажу об упомянутых средствах и инструментах так сказать «с высоты птичьего полета» в разрезе управления конфигурациями, попробую привести описание их места в общей мозаике средств разработки.
- Покажу наконец, какими принципами нужно руководствоваться при назначении релизам программных продуктов номеров версий, попытаюсь сделать этот вопрос более прозрачным, чем он есть (подозреваю для многих) сейчас.
Продолжение следует
Если вашей команде успешно удалось завершить хотя бы один проект, то согласно модели CMMI , процессу, который вы использовали для создания продукта, может быть присвоен первый уровень зрелости из пяти. Последующие уровни зрелости достигаются постановкой определенных процессов, связанных с разработкой программного обеспечения, одним из которых является управление конфигурацией (configuration management).
"The purpose of Configuration Management (CM) is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits."
Процесс управления конфигурацией программных продуктов заключается в следующем:
- Идентификация конфигураций рабочих продуктов, которые представляют собой некоторую основу (baseline) в некоторый момент времени, где под рабочим продуктом понимаются любые артефакты, создаваемые или используемые в процессе разработки: дефекты, коды, сборки, планы, тесты, пользовательская документация и т.п.
- Контроль за изменениями, произошедшими с элементами конфигурации, например изменения в требованиях, программном коде и т.п. Обеспечение возможности создания рабочих продуктов (спецификаций, исходного и исполняемого кода) с использованием только системы управления конфигурациями.
- Обеспечение целостности и согласованности каждого из выделенных baselines, позволяющих относительно свободно перемещаться между различными baselines, то есть, получить согласованный срез конфигурации рабочих продуктов (требований, доработок, исходного кода, исполняемого кода) на некоторый момент времени.
- Предоставление текущего состояния и данных конфигурации программного продукта для разработчиков, конечных пользователей, заказчиков и др.
Если перевести этот высокоуровневый процесс на конкретные практики, которые используются при разработке программного обеспечения, то получится следующих список практик, реализующих управление конфигурацией:
- Идентификация версий разрабатываемого продукта, где номер версии и является основой (baseline) для конфигураций.
- Управление скоупом будущих версий, то есть фиксация бизнес требований в рамках некоторой версии продукта.
- Производство исполняемого кода на основе исходного кода, что достигается использованием сборочных станций или серверов.
- Тестирование работы исполняемого кода (программ) с целью выявления согласованности с исходными функциональными требованиями и различными критериями качества (нефункциональными требованиями).
- Подготовка заметок к релизу (release notes), которые описывают состав некоторой версии продукта, с указанием реализованных требований, выполненных доработок, исправленных ошибок, проверенных тестовых сценариев, места расположения исполняемых файлов и т.д.
- Трассировка одних артефактов в другие: доработок в требования, требований в тестовую и пользовательскую документацию, доработок и дефектов в исходный код, исходный код в исполняемый код и т.д. Тем самым обеспечивается возможность аудита и контроля за целостностью конфигурации некоторой версии продукта.
- Сохранение истории изменений и контроль версий каждого артефакта, например, требований, исходного кода, исполняемого кода. Типичные системы контроля версий как раз реализуют данную часть процесса управления конфигурацией.
DEVPROM совместно с системой контроля версий, инфраструктурами автотестирования и выпуска сборок, реализует полноценную систему управления конфигурацией:
- Все артефакты, создаваемые при разработке продукта, имеют свой уникальный идентификатор в системе, позволяя тем самым идентифицировать конфигурационные элементы.
- Этапы разработки программного продукта неразрывно связаны с версиями продукта, к которым привязываются все артефакты: пожелания, требования, тестовая и пользовательская документация, тесты, файлы и т.д.
- , управление требованиями, тестовой и пользовательской документацией позволяют создавать весь необходимый набор артефактов для заданной версии продукта, то есть определять конфигурацию для заданного baseline.
- Автоматическое создание связей между пожеланиями, задачами, требованиями, тестовой и пользовательской документацией, позволяет организовать согласованную конфигурацию программного продукта и выполнять аудит с целью выявления рассогласований. DEVPROM автоматически отслеживает неактуальные связи и предлагает выполнить согласование (приведение в соответствие) артефактов между собой.
- Все изменения в системе протоколируются, что позволяет контролировать любые изменения в конфигурации, выполненные участниками проекта.
- Формирование заметок к релизу (release notes) для определенной версии продукта, включающих в себя список реализованных доработок и исправленных ошибок.
Управление конфигурациями – процесс, отвечающий за управление информацией о конфигурационных единицах (включая их взаимоотношения), необходимой для предоставления ИТ-услуг.
Цель процесса управления конфигурациями - сбор и актуализация информации о составляющих частях 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 .