Jan van Bon - ИТ СЕРВИС–МЕНЕДЖМЕНТ. Вводный курс на основе ITIL
? Дельта-релиз – в дельта-релиз включаются только измененные аппаратные и программные средства. Это часто связано с экстренными и быстрыми исправлениями. Недостатком этого типа релизов является то, что часто невозможно проверить все связи с остальной частью среды, в результате чего не удаляются модули, к которым программа больше не обращается. Дельта-релиз удобен в случае, если программное обеспечение может быть изолировано от остальной части ИТ-среды. Преимуществом дельта-релиза является то, что для создания тестовой среды требуется меньше усилий.
? Полный релиз – при полном релизе идет распространение полного комплекта ПО, включая неизмененные модули. Такой подход предпочтителен в случаях, когда точно не известно, что изменено в программном обеспечении. Более тщательные испытания программных и аппаратных средств обеспечивают в этом случае меньшее число инцидентов после внедрения. При подготовке полного релиза легче определить, достигается ли запланированный уровень производительности. Преимуществом полного релиза является возможность одновременного внедрения нескольких изменений. Подготовка облегчается благодаря возможности использования стандартных сценариев инсталляции[131]. Также при инсталляции может быть «очищена» программная среда. Однако полный релиз требует большей подготовки и ресурсов, чем дельта-релиз.
? Пакетный релиз – пакетный релиз, или комплект релизов, обеспечивает пользователям более длительные периоды стабильной работы. Исправление незначительных программных ошибок, с которыми пользователи могут мириться, и внедрение новых функций часто являются действиями, которые можно эффективно объединить. Так же плановые апгрейды, например системного программного обеспечения и офисных приложений от внешних разработчиков, могут включаться в пакетные релизы.
Рис. 8.3. Типы релизов
Библиотека эталонного программного обеспечения[132] (DSL)
Библиотека эталонного программного обеспечения (DSL) – это надежное хранилище для эталонных авторизованных версий (мастер-копий) всех Конфигурационных Единиц программного обеспечения. Физически библиотека DSL может находиться в разных местах и состоять из нескольких надежных хранилищ и огнеустойчивых сейфов для носителей информации. Управление Релизами начинает контролировать жизненный цикл программ с момента их включения в библиотеку DSL. Релизы конфигурируются из известного надежного программного обеспечения, хранящегося в DSL. После этого разрабатываются инсталляционные скрипты[133], а в децентрализованной среде могут быть записаны соответствующие компакт-диски.
В библиотеке DSL может храниться несколько версий одного и того же программного обеспечения, включая архивные версии, документацию и исходные коды. Поэтому необходимо создание резервных копий[134] Библиотеки DSL, поскольку она содержит не только текущую версию программного обеспечения, но и копии на случай возврата к прежней версии. При наличии в компании нескольких территориальных объектов с локальным руководством, на каждом из них должна быть копия Библиотеки DSL на случай развертывания программного обеспечения.
Склад эталонного аппаратного обеспечения[135] (DHS)
Склад эталонного аппаратного обеспечения предназначен для хранения запасных аппаратных средств. Это запасные компоненты и узлы, состояние которых поддерживается на том же уровне, что и у соответствующих им компонентов в активной среде. Аппаратные средства со склада DHS используются для замены или ремонта аналогичных Конфигураций в ИТ-инфраструктуре. Информация о составе этих Конфигураций должна содержаться в базе CMDB.
Конфигурационная База Данных (CMDB)
В рамках всего Процесса Управления Релизами рекомендуется проверять информацию о Конфигурационных Единицах в базе CMDB. Как только версии программного обеспечения добавляются в Библиотеку DSL, а версии аппаратных средств – на Склад DHS, производится обновление CMDB. Для поддержки Процесса Управления Релизами база данных CMDB должна содержать информацию по следующим вопросам:
? содержание запланированных релизов, включая Конфигурационные Единицы аппаратного и программного обеспечения со ссылкой на исходный Запрос на Изменения (RFC);
? аппаратные и программные Конфигурационные Единицы, на которые может повлиять релиз;
? данные о физическом местонахождении аппаратных средств, имеющих отношение к релизу.
8.2. Цель процесса
Процесс Управления Релизами занимается управлением и распространением (дистрибуцией) используемых в рабочей среде версий программного и аппаратного обеспечения, находящихся на поддержке ИТ-подразделения для обеспечения необходимого уровня услуг.
Задачами Процесса Управления Релизами являются:
? Планирование, координация и внедрение (или организация внедрения) программных и аппаратных средств.
? Разработка и внедрение рациональных[136] процедур для распространения и инсталляции изменений в ИТ-системах.
? Обеспечение отслеживаемости и безопасности программных и аппаратных средств, подвергшихся изменениям, и гарантирование того, что в рабочей среде находятся только корректные, авторизованные и тестированные версии.
? Коммуникации и оповещение пользователей, учет их ожиданий при планировании и развертывании новых релизов.
? Определение состава релизов и планирование их развертывания совместно с Процессом Управления Изменениями.
? Внедрение новых версий программных и аппаратных средств в рабочую инфраструктуру под контролем Управления Изменениями и при поддержке Управления Конфигурациями. Релиз может включать любое количество Конфигурационных Единиц, а также не только программные и аппаратные средства, но и документацию, например, отчеты, планы, руководства по поддержке.
? Обеспечение сохранности оригинальных копий программ в Библиотеке эталонного программного обеспечения (DSL) и регулярного обновления базы данных CMDB; то же касается аппаратных средств на Складе DHS.
8.2.1. Преимущества использования процесса
Вместе с эффективными Процессами Управления Конфигурациями и Управления Изменениями Процесс Управления Релизами способствует тому, чтобы:
? Использовалось программное и аппаратное обеспечение высокого качества, которое разрабатывалось и тестировалось с проведением процедур контроля качества.
? Сводилась к минимуму возможность возникновения ошибок в программно-аппаратных комплексах, или ошибок выпуска некорректных версий.
? Бизнес-подразделения внимательно контролировали инвестиции в программное обеспечение, от которых во многом зависит бизнес.
? Уменьшалось общее количество отдельно взятых внедрений, и проводились серьезные испытания каждого внедрения.
? Уменьшалась опасность возникновения инцидентов и известных ошибок за счет тестирования и контроля внедрения.
? Пользователи больше привлекались к участию в тестировании релизов.
? Заранее публиковалась программа ввода релизов для улучшения координации ожиданий пользователей с политикой и практикой появления новых релизов.
? Для целей бизнеса существовали структуры централизованного проектирования и компоновки программных и аппаратных средств или структуры для их закупки с последующим распространением по пользователям.
? Бизнес-подразделения могли стандартизировать версии программного и аппаратного обеспечения в своих подразделениях для облегчения их поддержки.
? Уменьшалась опасность использования пиратских программ, а также опасность возникновения инцидентов и проблем из-за интегрирования в активную среду дефектных или зараженных вирусом версий программного и аппаратного обеспечения.
? Облегчалось обнаружение неавторизованных копий и некорректных версий.
8.3. Процесс
Процесс Управления Релизами состоит из следующих видов деятельности:
? разработка политики в отношении релизов и их планирование;
? компоновка и конфигурирование релизов;
? тестирование и приемка релизов;
? планирование развертывания релизов;
? оповещение, подготовка и обучение;
? распространение и инсталляция релизов.
В действительности эти виды деятельности не располагаются в хронологическом порядке. Определение политики и планирование релизов могут проводиться раз в полгода или в год, в то время как другие действия могут проводиться ежедневно.
Рис. 8.4. Управление Релизами
Успешное проведение Управления Релизами зависит от входной информации, поступающей из других процессов ITIL, и от взаимодействия с этими процессами (рис. 8.4). Главными являются интерфейсы со следующими процессами.
8.3.1. Управление Конфигурациями
