■ получение подробных коммерческих предложений и переговоры с поставщиками о закупке нового АО и ПО или услуг по инсталляции;.
■ составление планов отката;.
■ разработка плана обеспечения качества Релиза;.
■ планирование приемки группами поддержки и Заказчиком.
Входные параметры при планировании Релиза включают:.
■ жизненный цикл проекта;.
■ результаты, связанные с предоставлением услуг;.
■ авторизованные RFC;.
■ политика Релизов;.
■ обзор потребностей бизнеса;.
■ ограничения и зависимости;.
■ решения Консультативного комитета по принятию изменений (САВ);.
■ шаблоны.
Выходные параметры при планировании Релиза включают план этого Релиза, обобщенные планы тестирования и критерии приемки Релиза. Выходные параметры при планировании Релиза обычно документируются в плане Управления изменениями для соответствующего проекта.
Управление релизами должно работать совместно с Управлением изменениями для согласования точного содержимого каждого Релиза.
9.6.2 Проектирование, сборка и конфигурация Релиза.
Следует планировать и документировать процедуры для сборки Релизов ПО, стараясь, по возможности, использовать стандартные процедуры. Конфигурация какого-либо Релиза ПО или АО может быть основана на ряде доступных компонентов, некоторые из которых могут быть разработаны самостоятельно, а некоторые - куплены. Следовательно, инструкции по сборке Релиза должны считаться частью определения Релиза и рассматриваться как контролируемые УЭ.
Проведение действий по сборке включает, как минимум, компиляцию и связку модулей приложений, разработанных самостоятельно, и всего купленного ПО, хранящегося в виде исходного кода. Во всех случаях данные берутся из DSL. В эти действия может также входить включение в Релиз купленного ПО в объектном виде. Сбока может содеражть действия по созданию баз данных и наполнению их тестовыми данными или же статическими данными справочников (например, данными почтовых адресов) - для сборки в среде эксплуатации. Там, где возможно, эти действия включают генерацию (или, как минимум, копирование из DSL) операционной системы, СУБД-компоненты и т.д.
Довольно часто встречается написание автоматизированных инсталляционных программ, которые обеспечивают точное развертывание Релиза. Они могут включать однократно выполняемые программы для конвертации данных или инициализации баз данных. Любая автоматизация задач или одноразовая работа должна включать эквивалентные программы отката, чтобы обеспечить откат Релиза в случае возникновения проблем.
Персоналу центрального подразделения Управления релизами потребуются лицензии на ПО и обучение использованию средств поддержки. При Релизах нового или измененного оборудования необходимо рассмотреть обновление требований по технике безопасности и охране здоровья. Могут потребоваться обновленные или измененные механизмы подачи данных (например, EDI-связи), которые следует заказать и протестировать. Может потребоваться проведение переговоров по изменениям соглашений о поддержке АО или ПО.
Все программное обеспечение, параметры, тестовые данные, ПО поддержки исполнения программ, а также любое другое ПО, которое требуется для Релиза, должно находиться под контролем Управления конфигурациями. Проверка качества этого ПО должна проводиться до сборки конкретного приложения. Полная запись о результатах сборки должна регистрироваться в CMDB. Это обеспечит возможность повторения сборки, если возникнет такая необходимость.
Обобщенный план тестирования Релиза должен быть расширен, чтобы в него вошли специальные тесты для проверки успешного развертывания Релиза путем проверки соответствия критическим факторам успеха и критериям завершения. Например, для нового Релиза программного компонента может быть разработана программа автоматической инсталляции, и она должна быть протестирована отдельно от самого программного приложения.
Входные данные при проектировании, сборке и конфигурации:.
■ определение Релиза;.
■ план Релиза.
Выходные данные при проектировании, сборке и конфигурации:.
■ подробные инструкции по компоновке и сборке Релиза, включая точную последовательность операций;.
■ заказы на поставку, лицензии и гарантии на ПО и АО внешних поставщиков;.
■ автоматические инсталляционные скрипты и соответствующие им планы тестирования;.
■ мастер-копии инсталляционных носителей и инструкции по инсталляции, которые должны храниться в DSL;.
■ процедуры отката.
9.6.3 Приемка Релизов.
Тестирование Релиза должно проводиться независимым бизнес-персоналом и включать ИТ-персонал для проверки измененных процедур поддержки. Все процедуры отката должны быть протестированы в ходе этих работ, что позволит убедиться, что собранный Релиз может быть инсталлирован и эксплуатироваться согласно требованиям. Это включает как тестирование процедур инсталляции, так и функционирование готовой системы.
Тестирование должно включать процедуры инсталляции и функциональную целостность готовой системы. Следует проводить подтверждение завершения каждого этапа тестирования. Финальная проверка и подтверждение завершения Релиза для перевода его в среду эксплуатации должны быть согласованным этапом процесса Управления изменениями. В тестирование крупных Релизов должны быть вовлечены все уровни поддержки.
Приемка Релиза должна выполняться в контролируемой тестовой среде, которая может быть восстановлена по известной конфигурации ПО и АО. Эти конфигурации должны описываться в определении Релиза и храниться в CMDB вместе со всеми другими УЭ.
Если Релиз отклонен, он должен быть перепланирован на другое время Управлением изменениями. Отклоненные Релизы должны отслеживаться и фигурировать в отчетах Управления изменениями как неудачные Изменения. Неудавшиеся Релизы и их влияние на ресурсы персонала по эксплуатации и поддержке необходимо отслеживать.
Входные данные при приемке Релиза включают:.
■ контролируемые тестовые среды (повторяющие конфигурацию текущих версий приложений, находящихся в эксплуатации), включая документацию этой тестовой конфигурации;.
■ определение и план Релиза;.
■ планы тестирования Релиза и критерии приемки;.
■ копии инсталляционных носителей и инструкции по инсталляции;.
■ планы тестирования инсталляционных скриптов;.
■ документированные процедуры отката.
Конечным результатом действий по проверке должно быть подтверждение полного и точного завершения всего Релиза. Выходные данные должны включать:.
■ протестированные процедуры инсталляции;.
■ протестированные компоненты Релиза;.
■ протестированные процедуры отката;.
■ известные дефекты, которые перейдут в среду эксплуатации;.
■ результаты тестирования;.
■ поддерживающую документацию, включая обзор системы, обновленные процедуры поддержки, средства диагностики;.
■ операционные и административные инструкции;.
■ планы действий в чрезвычайных ситуациях и планы отката;.
■ график обучения для руководства процессами Управления услугами, персонала службы поддержки и Заказчиков;.
■ документацию приемочного тестирования, подписанную всеми задействованными сторонами;.
■ авторизацию внедрения Релиза (через Управление изменениями).
9.6.4 Планирование развертывания.
Планирование развертывания расширяет план Релиза, который до этого момента включал точные сведения о разработанном процессе инсталляции и согласованном плане внедрения. Планирование развертывания включает:.
■ подготовку точного и подробного расписания событий вместе с информацией о том, кто и какие задачи выполняет (т.е. план ресурсов);.
■ списки УЭ для инсталляции и списания, включая сведения о методе устранения всего лишнего оборудования и ПО;.
■ документирование плана действий для каждого офиса, в котором учитывается влияние различных часовых поясов на общие планы (например, международная организация может не иметь единого окна для проведения Релизов, во время которого во всем мире ни одна из ее систем не будет использоваться);.
■ формирование описания Релиза и коммуникаций с конечным пользователем;.
■ планирование коммуникаций;.
■ разработку плана закупок;.
■ приобретение АО и ПО. Поскольку это часто влечет за собой приобретение и развертывание множества дорогостоящих активов, план развертывания для этих АО и ПО должен включать процедуры по их безопасному хранению до начала развертывания, а также механизмы отслеживания их развертывания во время внедрения, что может повлечь за собой использование кодов или другой электронной маркировки активов;.
■ составление графика встреч с руководящим персоналом и группами, вовлеченными в Релиз.
Рисунок 9.5 - Варианты развертывания.
На Рисунке 9.5 показана типичная последовательность действий во времени.
Политика Релизов действует на все Релизы системы и определяет общий подход.
Последовательность действий следующая:.
1.
Начальный запуск «Релиза 1» системы на трех рабочих станициях (1-3).
2.
Две следующие рабочие станции (4+5) добавляются сразу после первых трех.
3.
После этого происходит развертывание «Релиза 2» системы в соответствии подходом, называемым «большой взрыв», сразу на все рабочие станции (1-5).
4.
Затем в два этапа добавляются следующие рабочие станции (6+7).
5.
Поэтапное внедрение модернизации до «Релиза 3» системы, первоначально модернизирующего только три рабочие станции (1-3) и потом оставшиеся четыре (4-7).
6.
После этого в систему добавляется следующая рабочая станция (8).
Этот сценарий иллюстрирует ряд важных моментов:.
■ Развертывание Релизов в среду эксплуатации может происходить «оптом» (с использованием так называемого подхода «большого взрыва») или по частям (что также известно как «поэтапный» подход). Могут встречаться различные типы «поэтапного» подхода, а именно:.
когда части функциональности переносятся в среду эксплуатации поэтапно, но эти действия влияют на всех конечных пользователей одновременно (например, пошаговые изменения в централизованном основном приложении);.
когда каждый Релиз выполняется постепенно для всего количества конечных Пользователей (например, по одному географически разделенному офису в одно и то же время);.
сначала могут быть проведены изменения в АО, после чего последуют изменения в ПО;.
комбинация всех этих типов.
■ На Рисунке 9.5 показан второй тип поэтапного внедрения из вышеуказанного списка. Следует заметить, что этот подход можно использовать, только если система была спроектирована таким образом, чтобы допускать сосуществование новых и старых версий приложений. Если это невозможно, тогда единственная альтернатива - провести модернизацию сразу всех задействованных частей (АО и ПО), используя подход «большого взрыва».
■ Как правило, лучше избегать высокого риска, связанного с подходом «большого взрыва», поскольку в случае сбоя во время внедрения это окажет воздействие на всех Пользователей ИТ-услуг, которых касаются эти действия. Примерами ситуаций, в которых может не быть выбора, являются замена значительной части аппаратного обеспечения и модернизация операционной системы на критическом сервере.
■ Небольшие Изменения можно провести в среде эксплуатации без необходимости создания нового Релиза системы (например, добавление рабочих станций). Это допустимо только тогда, когда такое дополнение еще один пример того, что уже было определено в рамках этого Релиза. Тем не менее почти всегда существуют операционные ограничения (например, максимальное количество Пользователей), которые могут выходить за рамки определения «небольшого Изменения». Следует заметить, что в любом случае, ни одно Изменение не проходит без оформления RFC.
Рисунок 9.6- Поэтапное развертывание в нескольких географически разделенных офисах.
На Рисунке 9.6 показан пример поэтапного развертывания системы в нескольких географически отделенных офисах. Предполагается, что новые версии системы смогут работать как минимум с одной предыдущей версией. Используемый пример предполагает, что новая функциональность внедряется сначала в головном офисе организации, затем в пилотном филиале и после этого во всех остальных филиалах.
Если число офисов, в которых необходимо проводить работы, очень велико, может потребоваться довольно много времени для внедрения начальной системы или последующих модернизаций во всех филиалах, что увеличивает вероятность необходимости одновременной поддержки большего количества версий системы в среде эксплуатации.
9.6.5 Коммуникации, подготовка и обучение.
Персонал, взаимодействующий с Заказчиком, персонал Заказчика и персонал службы поддержки - все должны знать о том, какие действия планируются и как эти действия могут на них повлиять. Это обычно реализуется посредством тренингов, периодов параллельной работы и привлечения этих людей на этапе приемки Релиза. О возникших Проблемах и Изменениях, которые планируется провести во время развертывания, необходимо сообщать всем сторонам, чтобы информировать их о происходящем и формировать их ожидания. Эти действия обычно включают в себя проведение серии встреч по планированию развертывания со всеми заинтересованными сторонами, чтобы обеспечить соответствующий анализ планов, установку контрольных точек и согласие всех сторон по поводу их зон ответственности.
Важно огласить механизм проведения Релиза. Также важно огласить все ограничения для конечных пользователей (например, в крупной организации может быть невозможно выполнить модернизацию всех ПК за одну ночь).
При инсталляции нового или измененного оборудования и его передаче Пользователям следует обратить внимание на требования по технике безопасности и охране здоровья. Необходимо проверить все АО, ПО, а также нерешенные вопросы, связанные с сетью, монтажом или мощностями. Могут потребоваться обновленные или измененные механизмы подачи данных (например, EDI-связи), которые следует заказать и протестировать.
Может потребоваться сообщить соответствующему персоналу об изменениях в соглашениях по поддержке АО или ПО. Ответственность за такие коммуникации однозначно лежит на службе Service Desk, но Управление релизами может быть в более выгодном положении, позволяющем осуществлять обмен более детальной информацией.
Входные данные для этой деятельности включают:.
■ подробное определение Релиза и план развертывания;.
■ копии инсталляционных носителей и инструкции по инсталляции;.
■ текущие версии документации для службы поддержки, Пользователей, а также по обучению;.
■ формы приемки.
Выходные данные должны включать:.
■ финальные версии Пользовательских и эксплуатационных учебных материалов и документации;.
9.6.6 Распространение и инсталляция.
Распространение Релизов ПО из среды сборки в контролируемую тестовую среду и потом в среду эксплуатации должно проходить одновременно со всеми изменениями в АО и сопутствующими изменениями.
Процессы закупки, хранения, отправки, получения и размещения товаров должны обеспечить безопасную доставку оборудования на место назначения в требуемом состоянии. Места хранения должны быть безопасными. Для Управления конфигурациями требуется проверка соответствия полученных товаров и сопроводительной документации. Следует спланировать и завершить проверку инсталляции, среды и электропитания до подключения к сети.
Распространение ПО должно быть спроектировано так, чтобы поддерживалась целостность программного обеспечения во время обработки, упаковки и доставки. Автоматическое распространение ПО в удаленных офисах сэкономит ресурсы и уменьшит время, необходимое для распространения. После распространения ПО через сеть и достижения Релизом своего места назначения требуется проверить полноту этого Релиза..
Перевод Релиза прикладного ПО в режим активного использования в среде назначения - завершающий этап проведения Изменения. Довольно часто новая версия приложения распространяется для целевой инсталляции, но делается это таким образом, что эта новая версия остается в состоянии ожидания до момента ее активации. Эти действия должны проводиться в соответствии с протестированными процедурами инсталляции. Они могут повлечь за собой запуск автоматизированных инсталляционных программ или утилит, однократно запускаемых, чтобы Изменение вошло в силу. Чтобы обеспечить беспрепятственное развертывание, требуется провести автоматическую проверку целевой платформы и убедиться, что она удовлетворяет требованиям АО и ПО. Для этого потребуется привлечение услуг аудита Управления конфигурациями, но в действие этот процесс приводит Управление релизами.
CMDB должна обновляться после инсталляции или устранения АО или ПО, что обеспечивает наличие в CMDB обновленных данных. Может понадобиться восстановить старые версии ПО, которые были заменены, чтобы не нарушать правила лицензирования.
В некоторых типах Релизов (например, модернизация рабочих станций) может быть полезно провести окончательный тест приемки инсталлированного ПО с участием конечных пользователей. Для значительных Изменений Заказчики должны разработать контрольную таблицу тестов, которые необходимо выполнить, или такая таблица должна быть им выдана. Для получения формальной оценки может проводиться изучение степени удовлетворенности Заказчиков относительно качества инсталляции.
После успешной инсталляции следует обновить учетные записи Управления конфигурациями, включив в них информацию о местоположении и владельце АО и ПО. Это поможет персоналу службы поддержки более эффективно находить оборудование и разрешать последующие Инциденты и Проблемы.
Входные данные для распространения и инсталляции:.
■ подробные планы развертывания;.
■ протестированные процедуры инсталляции;.
■ протестированные компоненты Релиза;.
■ протестированные процедуры отката.
Выходные данные распространения и инсталляции:.
■ обновленные ИТ-услуги, включая обновленную пользовательскую и эксплуатационную документацию;.
■ обновленные учетные записи CMDB, включающие новые компоненты, находящиеся в эксплуатации;.
■ отозванные УЭ (такие как лишнее ПО и АО);.
■ все Известные ошибки в эксплуатируемой системе, которые введены как часть нового Релиза.