ИТ Сервис-менеджмент. Введение
Шрифт:
• организовать взаимодействие с Управлением Конфигурациями для гарантированного ввода изменений Конфигурационных Единиц в базу данных CMDB.
Глава 8. Управление Релизами
8.1. Введение
С повышением зависимости организаций от ИТ-процессов все большее значение приобретает их эффективный мониторинг и защита. С ростом количества изменений возрастает и потребность в контроле над процессом проведения изменений.
Изменения ИТ-инфраструктуры происходят в сложной распределенной среде. В современных приложениях клиент/сервер это часто отражается как на клиентской части, так и на серверной. В таких
Задачей Процесса Управления Релизами является обеспечение качества рабочей среды [124] за счет использования формальных процедур и проверок при вводе в работу новых версий. В отличие от Управления Изменениями, занимающегося верификацией, Процесс Управления Релизами занимается внедрением. Управление Релизами осуществляется в тесном контакте с Управлением Конфигурациями и Управлением Изменениями, что гарантирует обновление единой базы CMDB с учетом каждого нового релиза. Управление Релизами также обеспечивает обновление содержания релизов (программных кодов) в Библиотеке эталонного программного обеспечения [125] DSL. С помощью базы CMDB также отслеживаются спецификации аппаратных средств, руководства по инсталляции и сетевые конфигурации. Запас аппаратных средств, в частности стандартизованные базовые конфигурации, хранится на Складе эталонного аппаратного обеспечения [126] DHS. Однако, в первую очередь объектом Процесса Управления Релизами является программное обеспечение.
124
Production Environment.
125
Definitive Software Library – DSL.
126
Definitive Hardware Store – DHS.
В больших проектах Процесс Управления Релизами должен включаться в общий план проекта как его составная часть для обеспечения достаточного финансирования работы процесса. Определенная часть ежегодного бюджета может быть выделена на повседневные работы, такие как незначительные изменения. Расходы, возникающие при запуске процесса, не столь значительны по сравнению с потенциальными потерями, вызванными недостатками в планировании и контроле за программными и аппаратными средствами, к которым можно отнести следующие:
• большие перерывы в работе из-за плохого планирования выпуска релизов;
• дублирование работ из-за наличия копий различных версий;
• неэффективное использование ресурсов из-за отсутствия информации об их местонахождении;
• потеря исходных файлов, приводящая к повторной закупке программ;
• отсутствие защиты от вирусов, приводящее к необходимости «лечения» всей сети.
8.1.1. Основные понятия
Релизы
Релизы содержат одно или несколько авторизованных изменений. Они могут классифицироваться в первую очередь по уровню релиза. Часто релизы разделяют на:
• Значительные релизы – крупномасштабное развертывание новых аппаратных и программных средств, обычно со значительно расширенными функциональными возможностями. Такие релизы часто помогают в
• Малые программные релизы и модернизация аппаратного обеспечения (апгрейды) [129] – эти релизы обычно представляют собой незначительные усовершенствования и исправления известных ошибок. Среди них могут быть такие, которые внедрялись ранее в виде срочных исправлений и теперь окончательно проработаны и включены в данный релиз. За счет такого релиза обеспечивается обновление «Прежнего стабильного состояния [130] », являющегося отправной точкой для всех испытаний.
127
Work-arounds.
128
Quick Fixes.
129
Upgrades.
130
Previous Trusted State.
• Срочные исправления – обычно внедряются как быстрые исправления проблем и известных ошибок.
Релизные единицы
В отношении аппаратного обеспечения вопросы возникают только при полной замене ПК или при раздельной замене плат и дисководов жестких дисков (или даже оперативной памяти и процессоров). Для программного обеспечения изменения возможны на уровне системы, комплекса, программы или модуля. Хорошим примером может быть библиотека DLL (Dynamic Link Library) в среде Windows, часто используемая несколькими программами. Иногда в составе пакета поставляется новая версия DLL, что может потребовать нового тестирования и переустановки всех других программных пакетов. В данном процессе также прорабатывается принцип минимального содержания релиза.
Идентификация релизов
Копии программ могут распространяться из Библиотеки DSL по соответствующим средам:
• Среда разработки — разработка новых версий может вестись на основе более ранних версий из Библиотеки DSL. С каждой новой версией увеличивается ее номер. Изменение программного обеспечения возможно только в среде разработки.
• Среда испытаний – среда для тестирования версий. Часто тестирование разделяют на технические испытания разработчиками, функциональные испытания пользователями, испытания внедрения компоновщиками релизов и, возможно, окончательные приемочные испытания пользователями и руководством.
• Рабочая среда – активная среда, где информационные системы доступны для пользователей.
• Архив – служит для хранения старых версий программных единиц, которые больше не используются.
Так как возможно использование нескольких релизов, им присваиваются уникальные идентификаторы. В идентификационном номере релиза должна быть ссылка на соответствующую Конфигурационную Единицу, и он должен включать номер версии из двух или более цифр, например:
• Значительные релизы – система расчета зарплаты v.1, v.2, v.3 и т. п.
• Малые релизы – система расчета зарплаты v.1.1, v.1.2, v.1.3 и т. п.
• Релизы– срочные исправления – система расчета зарплаты v.1.1.1, v.1.1.2, v.1.1.3 и т. п.
На рис. 8.1 показаны тестирование и возможные модификации каждой новой версии перед ее выпуском. Старая версия архивируется как часть запуска нового релиза на случай возможного возврата.
На рис. 8.2 показан возврат.