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

■ Срочные исправления программного и аппаратного обеспечения, обычно содержащие исправления небольшого числа известных Проблем.

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

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

9.3.2 Политика и планирование Релизов.

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

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

Политика Релизов может указывать, например, что между формально запланированными Релизами, связанными с улучшениями или несрочными решениями, будут выпускаться только абсолютно необходимые «срочные решения».

«Единица Релиза» описывает часть ИТ-инфраструктуры, которая обычно изменяется одновременно. Такая единица может варьироваться в зависимости от типа(ов) или элемента(ов) программного и аппаратного обеспечения.

На Рисунке 9.2 приводится упрощенный пример, показывающий ИТинфраструктуру, состоящую из систем, которые включают в себя группы программ. Программы, в свою очередь, состоят из модулей.

Рисунок 9.2 - Упрощенный пример ИТ-инфраструктуры ПО.

Основная цель - выбрать наиболее подходящий уровень единицы Релиза для каждого элемента ПО или типа ПО. Организация может, например, решить, что обычная единица Релиза для их услуг по обработке транзакций (Transaction Processing, или TP-услуги) будет на уровне системы. Такая политика означает, что каждый раз, когда Учетный элемент (УЭ), участвующий в предоставлении услуги по обработке транзакций, изменяется, обычно будет выпускаться полный релиз всей этой системы. Та же самая организация может решить, что в отношении ПО рабочих станций наиболее подходящая единица Релиза будет на уровне группы программ, тогда как единица Релиза для пакетных приложений будет на уровне программ.

При выборе уровня единицы Релиза должны приниматься во внимание следующие факторы:.

■ объем необходимых Изменений на каждом возможном уровне;.

■ объем ресурсов и время, требуемое на сборку, тестирование, распространение и внедрение Релизов на каждом возможном уровне;.

■ простота внедрения;.

■ сложность интерфейсов между предлагаемой единицей и остальной ИТинфр аструктурой;.

■ доступное дисковое пространство в среде сборки, в тестовой среде, в среде распространения и в среде эксплуатации.

9.3.4 Идентификация Релиза.

Релизам следует присваивать уникальный идентификатор в соответствии со схемой, определенной в политике Релизов. Идентификация Релизов должна включать ссылку на УЭ, который этот Релиз представляет, и номер версии, который обычно состоит из 2 или 3 частей. Примеры названий Релизов:.

■ крупные Релизы: Система_зарплаты v.l, v.2, v.3 и т.д.;.

■ небольшие Релизы: Система_зарплаты v.1.1, v.l.2, v.1.3 и т.д.;.

■ срочные Релизы: Система_зарплаты v.l.1.1, v.l.1.2, v.l.1.3 и т.д.

9.3.5 Типы Релизов.

Комплексный релиз.

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

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

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

Примером комплексного Релиза может может являться Релиз новой версии всего клиентского ПО и/или АО для рабочей станции.

Дельта-релиз.

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

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

В каждом случае Консультативный комитет по изменениям должен на основании соответствующих фактов дать свои рекомендации, следует ли придерживаться политики Релизов в отношении данной единицы Релиза или лучше провести Дельта-релиз. При формировании своей рекомендации, САВ должен принять во внимание:.

■ размеры Дельта-релиза по сравнению с комплексным Релизом и, следовательно, требуемые ресурсы и усилия для его реализации;.

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

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

■ возможные риски для бизнеса, если в Релизе обнаружатся ошибки совместимости Предпочтительнее отложить изменения до комплексного Релиза, чтобы избежать риска столкновения с проблемами стыковки, которые могут возникнуть при Дельта-релизе;.

■ ресурсы, доступные для сборки, тестирования, распространения, внедрения Дельта-релиза (например, если внедрение должно проводиться не толькос помощью технического персонала, не будет ли проще внедрить полностью новый Релиз или Дельта-релиз?);.

■ полнота информации, полученной в результате анализа влияния, что позволит принять обоснованное и объективное решение.

Пакетный Релиз.

Для обеспечения более длительного периода стабильности среды эксплуатации благодаря уменьшению частоты Релизов рекомендуется, если есть такая возможность и если более масштабные Изменения гарантированно могут быть обработаны без проблем, группировка отдельных Релизов (полных единиц и/или Дельта-релизов) в так называемые «пакетные Релизы». Например, Изменения в одной системе или группе программ часто требуют проведения Изменений в других системах/группах программ. Если эти Изменения должны проводиться одновременно, их необходимо включать в один пакетный Релиз.

Такой пакетный Релиз может содержать, например, начальную версию новой услуги по обработке транзакций (TP-услуге), несколько новых версий пакетных программ, ряд новых и начальных версий отдельных модулей вместе с Релизом полностью новой системы рабочих станций (включающей как аппаратное, так и программное обеспечение). Могут включаться как полные, так и Дельта-релизы.

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

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

9.3.6 Библиотека эталонного ПО.

Библиотека эталонного ПО (Definitive software library, или DSL) - термин, используемый для описания безопасного хранилища, в котором безопасно хранятся эталонные авторизованные версии всех учетных элементов типа ПО. Это хранилище в действительности может состоять из одной или нескольких библиотек ПО или хранилищ файлов, которые отделены от хранилищ файлов для разработки, тестирования или эксплуатации. Оно содержит мастер-копии всего ПО, контролируемого в организации. DSL должна включать эталонные копии закупленного ПО (вместе с лицензионными документами или лицензионной информацией), а также ПО, разработанное в организации. Мастеркопии контролируемой документации систем также должны храниться в DSL в электронном виде.

Точная конфигурация DSL, требуемая для Управления релизами, должна быть определена до начала разработки. DSL составляет часть политики Релизов или плана Управления изменениями и конфигурациями в организации. Определение DSL должно включать:.

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

■ договоренности по присвоению имен для файловых хранилищ и физических носителей;.

■ поддерживаемые среды, например тестовая среда и среда эксплуатации;.

■ меры безопасности для оформления Изменений и выпуска ПО, плюс процедуры резервирования и восстановления;.

■ рамки DSL: например, исходный код, объектный код из контролируемых сборок и связанная с ними документаця;.

■ период хранения старых Релизов ПО;.

■ план развития мощностей для Библиотеки DSL и процедуры по мониторингу ее роста;.

■ процедуры проведения аудита;.

■ процедуры обеспечения защиты DSL от ошибочных или неавторизованных Изменений (например, критерии входа и выхода для элементов, находящихся в Библиотеке).

Рисунок 9.3 - Связь DSL и CMDB.

На Рисунке 9.3 показана тесная связь между DSL и CMDB. Там также показано, что CMDB хранит защищенные записи или указатели точного содержимого каждого Релиза.

9.3.7 Склад эталонного аппаратного обеспечения (DHS).

Необходимо выделить место для безопасного хранения запасного эталонного аппаратного обеспечения, называемое Складом эталонного аппаратного обеспечения (Definitive Hardware Store, или DHS). Это - запасные компоненты и собранные модули, которые поддерживаются на том же уровне, что и сходные системы в среде эксплуатации. Сведения об этих компонентах, их сборке и содержимом должны быть полностью записаны в CMDB. Потом они могут быть использованы при возникновении необходимости дополнительных систем или при восстановлении после крупных Инцидентов с учетом того, что они соответствующим образом контролируются. После окончания их (временного) использования они должны быть возвращены в DHS или заменены.

9.3.8 Конфигурационная база данных учетных элементов (CMDB).

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

■ описание планируемых Релизов, включая составляющие их УЭ аппаратного и программного обеспечения, вместе со ссылками на исходные запросы на Изменение;.

■ записи об УЭ, на которых воздействуют планируемые и прошлые Релизы, включая Релизы АО и ПО;.

Я информацию о целевом месте назначения компонентов Релиза.

(например, физическое местоположение АО или сервера, на котором пройдут Изменения в ПО).

9.3.9 Управление сборкой.

Сборка компонентов ПО и/или АО, которые составляют новый Релиз какой-либо ИТ-услуги, должна проходить под соответствующим контролем, чтобы обеспечить повторяемость процесса. Стандартный подход для ПО - получение нового исходного кода от разработчиков и потом генерация исполняемого файла, используя контролируемые процедуры на АО, выделенном для проведения сборки. Эти процедуры называются «управлением сборкой» и находятся в зоне ответственности процесса Управления релизами. Довольно часто процедуры сборки автоматизированы, чтобы уменьшить зависимость от человеческого вмешательства и сделать их более надежными. Процедуры сборки и автоматизация должны сами контролироваться как отдельные УЭ. Они могут быть общими или отдельными для каждого Релиза.

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

Управление сборкой переходит под ответственность Управления релизами с момента перехода в контролируемую тестовую среду.

9.3.10 Тестирование.

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

9.3.11 План отката.

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

Существует два основных подхода, также может использоваться их сочетание:.

■ Неудачное развертывание может быть полностью возвращено в исходное состояние для полного восстановления ИТ-услуг к их предыдущему известному состоянию. Это критично для комплексного релиза и предпочтительно для Дельта-релиза.

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

Примеры:.

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

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

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

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

Планы отката должны быть протестированы как часть процесса по проверке процедур развертывания.