Управление конфигурацией (configuration management) -- это про связь наших ожиданий (проектов) с реальностью.

Как всегда, "управление чем-то" ни разу не "управление", а обозначает "всё необходимое, чтобы это что-то было в приличном состоянии".

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

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

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

Управление конфигурацией включает в себя "истинную теорию", ибо имеет собственные понятия: базис (baseline) -- утвержденная конфигурация, версия/ревизия (version/revision). Конечно, наличествует и "управленческиконфигурационный шовинизм", когда в состав управления конфигурацией записывают и много чего другого. Из этого "многого другого" нужно прежде всего выделить общую теорию учёта/регистрации. Это ведь общее знание для бухгалтерского, депозитарного, складского, регистрационного, конфигурационного учёта: каким образом обеспечивать взаимное соответствие реальности и записей о реальности.

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

1. Идентификация -- поддержка инженерных разбиений (классификаций, кодировок) и именования/кодировки отдельных конфигурационных единиц (configuration items). Именно тут обсуждаются PBS, GBS, WBS и разные системы кодировок типа RDS-PP, KKS, RTM, S1000D и т.д.

2. конфигурационный (т.е. специализированный -- так же, как бухгалтерский, депозитарный, складской и т.д.) учет/регистрация -- административное обеспечение взаимного соответствия: 1. проекта (включая требования), 2. исполнительной документации (as built, "что мы думаем о реальной системе"), 3. самой системы "в железе и бетоне". Обычно обеспечивается наличием конфигурационной базы данных (CMDB -- сonfiguration management data base) и административными процедурами по её ведению. Учёт включает в том числе и административные процедуры по назначению ведущего учёт (регистратора), передаче ведения учёта от регистратора регистратору, делегированию полномочий по учёту в порядке распределенной учётной деятельности и т.д.

3. контроль версий (version/revision control): обеспечение того, что базис (утвержденная для каких-то целей конфигурация) собирается из взаимно соответствующих версий частей системы (будь то версии проектной или исполнительной документации, или же версии самой системы "в железе и бетоне"). Софтверщикам с их CVS и SVN против git и Mercurial должно быть понятно, о чем это.

Управление конфигурацией очень просто, когда есть один административный центр, который вводит
а) обязательную идентификацию
б) обязательный регламент учёта
в) централизованное версионирование

Проблемы возникают при распределенной разработке (collaborative engineering, concurrent engineering), где каждая из участвующих в проекте организаций имеет собственные предпочтения по управлению конфигурацией (кодировки, учётные регламенты, версионирование). Собрать из этого распределенного конфигурационного месива базис обычно представляет собой непростую задачу. Так, любая PLM-cистема поддерживает управление конфигурацией. Но вот если у вас в расширенной организации (extended enterprise) используется несколько разных PLM-систем, то у вас немедленно начнутся проблемы. Еще бОльшие проблемы будут, если нет полноценной (организация+софт) системы управления жизненным циклом (СУЖЦ), а есть только неподдержанный организационными решениями (необходимым для управления конфигурацией workflow) софт PLM.

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

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

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

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

Задача процесса управления конфигурациями - предотвратить неконтролируемое развитие проекта. Для регламентации процесса управления конфигурациями в различных отраслях принят ряд международных и национальных стандартов.

08.08.2013 Никита Налютин

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

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

Объект конфигурации (Configuration Item, CI): исходные тексты, скомпилированные программы, исходные коды программ, документация, элементы аппаратуры, процедуры и материалы обучения и т.п. - базовое понятие процесса управления конфигурациями Однако обычно под управление конфигурациями попадают только результаты проектной деятельности: программное обеспечение и сопутствующая документация, требования к интерфейсам и документация, выходные файлы, полученные при использовании инструментов проекта, технико-экономические документы и записи пользовательских требований, планы управления проектом, инструменты и руководства пользователя, записи об истории проекта, тест-планы, процедуры и отдельные тестовые примеры.

При объединении объектов конфигурации образуется их конфигурация - любая структурированная совокупность объектов разработки программной системы, представленных в виде CI, или совокупность процессов и технологических цепочек проекта по разработке программной системы, описания которых также могут быть представлены в виде CI. Процесс управления конфигурациями в различных отраслях регламентируется международными и национальными стандартами: ГОСТ Р 51904, DO-178, AS9100, AS9006, ISO10007, ISO/IEC TR 15846, ISO/IEC 15408, IEEE 1042 и пр. При разработке высококритичных систем применение процесса управления конфигурациями строго обязательно - цена исправления дефектов в таких системах может быть очень высока.

Стандарт ГОСТ Р 51904 был принят Госстандартом России в 2002 году и регламентирует требования к разработке и документированию встроенных систем. В нем процесс управления конфигурациями отнесен к группе интегральных процессов, необходимых для обеспечения качества выполнения процессов разработки и их выходных данных. Интегральные процессы выполняются одновременно с процессами разработки и обеспечивают непрерывную поддержку разработки. Основные цели процесса управления конфигурациями согласно ГОСТ 51904 состоят в том, чтобы обеспечить:

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

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

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

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

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

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

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

Практически все процессы управления конфигурациями, определенные стандартом ГОСТ Р 51904, требуют отслеживания состояний жизненного цикла объектов, помещенных в конфигурацию. Так, контроль конфигурации подразумевает, что режим доступа к CI может изменяться в зависимости от их состояния. Создание базовых линий происходит только по достижении всех входящих в нее CI определенного состояния. Управление отчетностью о дефектах производится на основании информации о том, в каком состоянии находится отчет о дефекте и сам дефект, устранен ли он. Отчет о состоянии конфигурации в обязательном порядке включает в себя информацию о состояниях CI. Архивирование конфигураций также может изменять их состояние. Процесс контроля загрузки ПО автоматизируется при помощи создания базовой линии из CI, достигших определенного состояния. Контроль среды жизненного цикла производится на основании информации о том, в каком состоянии находятся инструменты проекта, не требуется ли их обновление.

По своей сути ГОСТ Р 51904, область применения которого - любые встроенные системы, базируется на международном стандарте DO-178, используемом при разработке авиационных систем. Системы, разработанные в соответствии с этим стандартом, могут быть сертифицированы согласно требованиям летной годности.

В целом процесс управления конфигурациями, охватываемый стандартом DO-178, направлен на поддержку целостности данных, создаваемых в ходе всех стадий жизненного цикла продукции. Основная специфика процесса управления конфигурациями, регламентируемого данным стандартом, состоит в учете аспектов сертификации на летную годность, которую должно проходить все программное обеспечение, используемое в бортовых авиационных системах. Данные процесса управления конфигурациями используются в качестве основных данных, интересующих сертифицирующие органы, которым предоставляются индексы конфигураций - списки уникальным образом идентифицированных элементов (исходных текстов, файлов данных, объектного и исполняемого кода), входящих в программное обеспечение. Для подтверждения соответствия качества программного обеспечения заданному уровню критичности бортового ПО, представляются результаты его тестирования, проведенного в соответствии с требованиями к данному уровню. Конфигурация включает в себя связи между требованиями, исходными текстами, тестами, их результатами и другими объектами разработки, чем обеспечивается их трассируемость.

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

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

Существуют также стандарты AS 9100/AS9006, специально адаптирующие требования системы менеджмента качества ISO к авиационной отрасли.

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

Никита Налютин ([email protected]) - менеджер по обеспечению качества, компания Experian (Москва).

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

Помимо финансовых затрат, неверное управление конфигурацией ведет к расходованию иных ресурсов, например человеко-часов. Ресурсы приходится затрачивать и на работу с клиентами во время устранения неполадок с 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. Другие материалы из нашего блога «ИТ Гильдия».

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). Отличие использования данного подхода к именованию в моем методе заключается в том, что зависимости изменений каждой цифры в системе именования от некоторого момента времени описываются формально.

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