Опубликован: 17.05.2012 | Доступ: свободный | Студентов: 11140 / 3003 | Оценка: 4.29 / 4.17 | Длительность: 17:00:00
Лекция 9:

Управление релизами и развертыванием в рамках Внедрения услуг

< Лекция 8 || Лекция 9: 12 || Лекция 10 >
Аннотация: В лекции рассматривается процесс Управления релизами и развертыванием в рамках этапа Внедрения услуг: цели, входы и выходы процесса, основные деятельности в его рамках.

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

Основные цели Управления релизами и развертыванием:

  1. формирование и согласование планов релизов и развертывания с заказчиками и инвесторами;
  2. гарантия того, что каждый пакет для релиза состоит из набора связанных и совместимых компонентов;
  3. осуществление управления релизом и его компонентами в рамках процессов Внедрения;
  4. гарантия того, что все пакеты для релизов могут быть протестированы, отслежены, проверены, установлены или устранены (при необходимости);
  5. гарантия того, что все изменения управляются в рамках деятельностей по управлению релизами и развертыванием;
  6. ведение отчетов и управление рисками, проблемами, расхождениями, связанными с новой или измененной услугой. Осуществление корректирующих действий при необходимости;
  7. обеспечение доступа к информации для заказчиков и инвесторов, чтобы они могли эффективно использовать новую или измененную услугу;
  8. обеспечение доступа к информации для операционного персонала, чтобы он мог предоставлять, поддерживать и управлять услугой.

Управление релизами и развертыванием отвечает за выпуск релизов и их эффективное использование заказчиками.

Единица релиза (Release Unit) - компоненты услуги, которые обычно компонуются вместе и выпускаются в рамках одного релиза. Единица релиза обычно включает в себя компоненты, необходимые для выполнения какой-либо полезной функции. Например, Единицей релиза может быть настольный компьютер, включающий в себя программное, аппаратное обеспечение, лицензии, документацию и т.п. Другим примером Единицы релиза может служить целое приложение для расчета зарплаты, включая процедуры операционного управления IT и тренинги пользователей[1].

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

  • простота и количество изменений, необходимых для релиза и развертывания;
  • количество ресурсов и времени, необходимое для сборки, тестирования и развертывания;
  • сложность взаимосвязей между единицей и остальными услугами и компонентами;
  • хранение, доступное в рамках сборки, тестирования, распространения и эксплуатации[16].

Подход преобразования новой или измененной услуги определяется в рамках этапа Проектирования. Существует две опции внедрения:

  1. "большой взрыв" - новая или измененная услуга развертывается сразу для всех пользователей в рамках одной операции;
  2. пофазовый подход - услуга развертывается поэтапно. Сначала одной части пользователей, затем остальным.

На рис. 9.1 представлено применение двух подходов.

Два подхода к развертыванию услуг

увеличить изображение
Рис. 9.1. Два подхода к развертыванию услуг
  1. Релиз 1 - начальная установка на три рабочие станции (1-3). Две другие станции добавляются в тот же период времени (4-5);
  2. Релиз 2 - использование подхода "большой взрыв" для развертывания. Релиз устанавливается сразу на пять рабочих станций (1-5). На другом шаге на две дополнительные станции (6-7);
  3. Релиз 3 - пофазовый подход для развертывания. Сначала обновляется только три рабочие станции (1-3), затем оставшиеся четыре (4-7). Еще одна станция добавляется на следующем этапе (8).

Пофазовый подход имеет следующие вариации:

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

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

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

Для развертывания релиза необходимо разработать различные планы, в частности, Планы релизов и развертывания. Они должны определять:

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

В рамках Внедрения должны быть определены критерии, которые позволят установить успешность выполнения каждой стадии релиза и развертывания. Результат выполнения либо принимается - pass, либо отклоняется - fail. Отсюда критерии называются прием/отклонение (pass/fail) критерии.

Пример, когда результат принимается:

  • Все тесты завершены успешно; отчет по оценке и RFC для сборки и тестирования подписаны.

Примеры, когда результаты отклоняются:

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

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

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

Среды, необходимые для релиза:

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

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

Планирование сборки пакета релизов содержит следующие процедуры:

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

В рамках составления планов развертывания необходимо ответить на следующие вопросы:

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

Далее разрабатываются Планы снабжения и предоставления. Они определяют следующее:

  • как и когда релиз и его компоненты будут предоставляться?
  • какие имеются команды сопровождения, и что будет в случае задержки?
  • как отследить прогресс в предоставлении и необходимость его завершения?
  • есть ли возможность защищенного хранения, если потребуется?

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

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

Если изменение утверждено, наступает этап сборки и тестирования. Ключевые аспекты, которыми необходимо управлять в рамках этого этапа:

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

В ITIL вводится понятие "базовое состояние". Базовое состояние (Baseline) - зафиксированное состояние, используемое как ориентир (контрольная точка)[1]. Трактовка зависит от контекста. В контексте Внедрения базовое состояние может быть использовано для возврата инфраструктуры к исходной конфигурации в случае, если внедрение релиза оказалось неудачным. Информация о базовых состояниях конфигураций хранится в CMS.

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

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

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

< Лекция 8 || Лекция 9: 12 || Лекция 10 >
Александр Колотов
Александр Колотов

Прошу вас уточнить по курсу ITIL. IT Service Management по стандартам V.3.1 вопрос о количестве версий ITIL.
Судя по названию и по материалу лекции версий 3. По факту версий 4. Т.е. как ответчать как правильно (4) или как по курсу который чуть устарел? Система оценки скорее всего будет согласно материала лекции.

Грета Березовская
Грета Березовская