- •Оглавление
- •Управление Инцидентами
- •4.1. Введение
- •4.1.1. Терминология
- •4.2. Цель
- •4.2.1. Преимущества использования процесса
- •4.3. Процесс
- •4.4.1. Прием и регистрация
- •4.4.2. Классификация
- •4.4.7. Мониторинг хода решения и отслеживание
- •4.5. Контроль процесса
- •4.5.1. Критические факторы успеха
- •Управление Проблемами
- •5.1. Введение
- •5.1.1. Определение — «проблема» и «известная ошибка»
- •5.1.2. Взаимоотношения с Процессом Управления Инцидентами
- •5.2. Цель процесса
- •5.3. Процесс
- •5.3.3 Управление Конфигурациями
- •5.4.2. Контроль ошибок
- •5.4.3. Проактивное Управление Проблемами
- •5.5.3. Функции и роли
- •5.6. Затраты и проблемы
- •5.6.2. Проблемы
- •Управление Конфигурациями
- •6.1.1. Основные понятия
- •6.2. Цель процесса
- •6.2.1. Преимущества использования процесса
- •6.3. Процесс
- •6.4. Виды деятельности
- •6.4.3. Мониторинг статуса
- •6.4.4. Контроль
- •6.4.5. Верификация и аудит
- •6.5. Контроль процесса
- •6.6. Затраты и проблемы
- •Управление Изменениями
- •7.1. Введение
- •7.3.1. Управление Инцидентами
- •7.3.1. Управление Инцидентами
- •7.4. Виды деятельности
- •7.4.1. Регистрация
- •7.4.4. Планирование
- •7.4.5. Координация
- •7.5 Контроль процесса
- •7.5.1 Отчеты для руководства
- •Управление Релизами
- •8.1.1. Основные понятия
- •8.2. Цель процесса
- •8.2.1. Преимущества использования процесса
- •8.3. Процесс
- •8.3.4. Виды деятельности
- •8.4. Виды деятельности
- •8.5.2. Проблемы
- •Служба Service Desk
- •9.1. Введение
- •9.3.3. Варианты организации Службы Service Desk
- •9.3.4. Персонал Службы Service Desk
- •9.3.5. Технологии для работы Службы Service Desk
- •9.5. Эффективность
- •Управление Уровнем Сервиса (Услуг)
- •10.1. Введение
- •10.1.1. Основные понятия
- •Управление финансами ит
- •Управление Мощностями
- •Управление Непрерывностью ит-сервисов
- •Управление Доступностью
Управление Релизами
8.1. Введение
С повышением зависимости организаций от ИТ-процессов все большее значение приобретает их эффективный мониторинг и защита. С ростом количества изменений возрастает и потребность в контроле над процессом проведения изменений.
Изменения ИТ-инфраструктуры происходят в сложной распределенной среде. В современных приложениях клиент/сервер это часто отражается как на клиентской части, так и на серверной. В таких случаях запуск и внедрение новых версий программных и аппаратных средств требует тщательного планирования. Релизом называется набор новых и/илн измененных Конфигурационных Единиц, которые вместе иепытываются и внедряются в рабочую среду. Релиз определяется Запросом на Изменения (RFC), для исполнения которого он вводится в работу. В Процессе Управления Релизами используется плановый проектный подход к проведению изменений в ИТ-услугах, и он затрагивает все, как технические, так и нетехнические аспекты изменений
Задачей Процесса Управления Релизами является обеспечение качества рабочей среды' за счет использования формальных процедур и проверок при вводе в работу новых версий. В отличие от Управления Изменениями, занимающегося верификацией, Процесс Управления Релизами занимается внедрением. Управление Релизами осуществляется в тесном контакте с Управлением Конфигурациями и Управлением Изменениями, что гарантирует обновление единой базы CMDB с учетом каждого нового релиза. Управление Релизами также обеспечивает обновление содержания релизов (программных кодов) в Библиотеке эталонного программного обеспечения2 DSL С номощыо базы CMDB также отслеживаются спецификации аппаратных средств, руководства по инсталляции и сетевые конфигурации. Запас аппаратных средств, в частности стандартизованные базовые конфигурации, хранится на Складе эталонного аппаратного обеспечения3 DHS. Однако, в первую очередь объектом Процесса Управления Релизами является программное обеспечение.
В больших проектах Процесс Управления Релизами должен включаться в общий план проекта как его составная часть для обеспечения достаточного финансирования работы процесса. Определенная часть ежегодного бюджета может быть выделена на повседневные работы, такие как незначительные изменения. Расходы, возникающие при запуске процесса, не столь значительны по сравнению с потенциальными потерями, вызванными недос татками в планировании и контроле за программными и аппаратными средствами, к которым можно отнести следующие:
большие перерывы в работе из-за плохого планирования выпуска релизов;
дублирование работ из-за наличия копий различных версий;
неэффективное использование ресурсов из-за отсутствия информации об их местонахождении;
потеря исходных файлов, приводящая к повторной закупке программ;
отсутствие защиты от вирусов, приводящее к необходимости «лечения» всей сети.
8.1.1. Основные понятия
Релизы
Релизы содержат одно или несколько авторизованных изменений. Они могут классифицироваться в первую очередь по уровню релиза. Часто релизы разделяют па:
Значительные релизы — крупномасштабное развертывание новых аппаратных и программных средств, обычно со значительно расширенными функциональными возможностями. Такие релизы часто помогают в устранении ряда известных ошибок, включая известные обходные решения и быстрые исправления.
Малые программные релизы и модернизация аппаратного обеспечения (анргрейды)— эти релизы обычно представляют собой незначительные усовершенствования и исправления известных ошибок. Среди них могут быть такие, которые внедрялись ранее в виде срочных исправлений и теперь окончательно проработаны и включены в данный релиз. За счет такого релиза обеспечивается обновление «Прежнего стабильного состояния», являющегося отправной точкой для всех испытаний.
Срочные исправления — обычно внедряются как быстрые исправления проблем и известных ошибок.
Релизные единицы
В отношении аппаратного обеспечения вопросы возникают только при полной замене ПК или при раздельной замене плат и дисководов жестких дисков (или даже оперативной памяти и процессоров). Для программного обеспечения изменения возможны на уровне системы, комплекса, программы или модуля. Хорошим примером может быть библиотека DLL (Dynamic Link Library) в среде Windows, часто используемая несколькими программами. Иногда в составе пакета поставляется новая версия DLL, что может потребовать нового тестирования и переустановки всех других программных пакетов. В данном процессе также прорабатывается принцип минимального содержания релиза.
Идентификация релизов
Копии программ могут распространяться из Библиотеки DSL по соответствующим средам:
Среда разработки — разработка новых версий может вестись на основе более ранних версий из Библиотеки DSL. С каждой новой версией увеличивается ее номер. Изменение программного обеспечения возможно только в среде разработки.
Среда испытаний — среда для тестирования версий. Часто тестирование разделяют на технические испытания разработчиками, функциональные испытания пользователями, испытания внедрения компоновщиками релизов и, возможно, окончательные приемочные испытания пользователями и руководством.
Рабочая среда — активная среда, где информационные системы доступны для пользователей.
Архив — служит для хранения старых версий программных единиц, которые больше не используются.
Так как возможно использование нескольких релизов, им присваиваются уникальные идентификаторы. В идентификационном номере релиза должна быть ссылка на соответствующую Конфигурационную Единицу, и он должен включать помер версии из двух или более цифр, например:
Значительные релизы — система расчета зарплаты v.l, v.2, v.3 и т. п.
Малые релизы — система расчета зарплаты v. 1.1, v. 1.2, v. 1.3 и т. п.
Релизы — срочные исправления — система расчета зарплаты v.l. 1.1, v. 1.1.2, v. 1.1.3 и т. п.
На рис. 8.1 показаны тестирование и возможные модификации каждой новой версии перед ее выпуском. Старая версия архивируется как часть запуска нового релиза на случай возможного возврата.
Типы релизов
Должна быть произведена оценка, какое количество изменений может быть разработано, испытано и внедрено за определенный период времени. Может оказаться, что пакетный релиз, представляющий собой комбинацию нескольких изменений для одного развертывания, может быть слишком сложным для безопасного внедрения.
Быстрая разработка и продвижение на рынок новых версий аппаратного и программного обеспечения может привести к тому, что релиз может устареть до его внедрения. С другой стороны, частые изменения могут оказать отрицательное воздействие на предоставление услуг.
В рамках Процесса Управления Изменениями принимается решение о количестве изменений, которое может быть включено в релиз, и о способе еш развертывания. Возможен выбор одного из следующих вариантов:
Рис. 8.1 Выпуск версии в Процессе Управления Релизами
Дельта-релиз — в дельта-релиз включаются только измененные аппаратные и программные средства. Это часто связано с экстренными и быстрыми исправлениями. Недостатком этого типа релизов является то, что часто невозможно проверить вес связи с остальной частью среды, в результате чего не удаляются модули, к которым программа больше не обращается. Дельта-релиз удобен в случае, если программное обеспечение может быть изолировано от остальной части ИТ-среды. Преимуществом дельта-релиза является то, что для создания тестовой среды требуется меньше усилий.Полный релиз — при полном релизе идет распространение полного комплекта ПО, включая неизмененные модули. Такой подход предпочтителен в случаях, когда точно не известно, что изменено в программном обеспечении. Более тщательные испытания программных и аппаратных средств обеспечивают в этом случае меньшее число инцидентов после внедрения. При подготовке полного релиза легче определить, достигается ли запланированный уровень производительности. Преимуществом полного релиза является возможность одновременного внедрения нескольких изменений. Подготовка облегчается благодаря возможности использования стандартных сценариев инсталляции
Также при инсталляции может быть «очищена» программная среда. Однако полный релиз требует большей подготовки и ресурсов, чем дельта-релиз.
Накегнын релиз — пакетный релиз, или комплект релизов, обеспечивает пользователям более длительные периоды стабильной работы. Исправление незначительных профаммных ошибок, с которыми пользователи могут мириться, п внедрение новых функции часто являются действиями, которые можно эффективно объединить. Так же плановые апгрейды, например системного программного обеспечения н офисных приложений от внешних разработчиков, могут включаться в i ia kcti i ые рел i га ы.
Библиотека эталонного программного обеспечения (DSL)
Библиотека эталонного программного обеспечения (DSL) — это надежное хранилище для эталонных авторизованных версий (мастер-копий) всех Конфигурационных Единиц программного обеспечения. Физически библиотека DSL может находиться в разных местах и состоять из нескольких надежных хранилищ и огнеустойчивых сейфов для носителей информации. Управление Релизами начинает контролировать жизненный цикл программ с момента их включения в библиотеку DSL Релизы конфигурируются из известного надежного программного обеспечения, хранящегося и DSL. После этого разрабатываются инсталляционные скрипты, а в децентрализованной среде могут быть записаны соответствующие компакт-диски .
В библиотеке DSL может храниться несколько версий одного и того же программного обеспечения, включая архивные версии, документацию и исходные коды. Поэтому необходимо создание резервных копий Библиотеки DSL, поскольку она содержит не только текущую версию программного обеспечения, но и копии на случай возврата к прежней версии. При наличии в компании нескольких территориальных объектов с локальным руководством, па каждом из них должна быть копия Библиотеки DSL на случай развертывания программного обеспечения.
Склад эталонного аппаратного обеспечения (DHS)
Склад эталонного аппаратного обеспечения предназначен для хранения запасных аппаратных средств. Это запасные компоненты и узлы, состояние которых поддерживается на том же уровне, что и у соответствующих им компонентов в активной среде. Аппаратные средства со склада DHS используются для замены или ремонта аналогичных Конфигураций в ИТ-инфраструктуре. Информация о составе этих Конфигураций должна содержаться в базе CMDB.
Конфигурационная База Данных (CMDB)
В рамках всего Процесса Управления Релизами рекомендуется проверять информацию о Конфигурационных Единицах в базе CMDB. Как только версии программного обеспечения добавляются в Библиотеку DSL, а версии аппаратных средств — на Склад DHS, производится обновление CMDB. Для поддержки Процесса Управления Релизами база данных CMDB должна содержать информацию по следующим вопросам:
содержание запланированных релизов, включая Конфигурационные Единицы аппаратного и программного обеспечения со ссылкой на исходный Запрос на Изменения (RFC);
аппаратные и программные Конфшурационные Единицы, на которые может повлиять релиз;
данные о физическом местонахождении аппаратных средств, имеющих отношение к релизу.