■ более высокая доля успешных Релизов АО и ПО и, следовательно, повышение качества услуг, предоставляемых бизнесу;.
Я согласованность процессов, связанных с Релизами аппаратных платформ или программных сред;.
■ минимизация прерываний в предоставлении услуг бизнесу благодаря синхронизации Релизов в пакетах, включая компоненты АО и ПО для различных платформ и сред;.
■ гарантирование того, что АО и ПО, находящиеся в эксплуатации, обладают хорошим (или известным) уровнем качества благодаря правильной сборке их компонентов, которые прошли контроль качества и эффективное тестирование, и которые составлялись под контролем процесса Управления изменениями;.
■ стабильность тестовой среды и среды эксплуатации в результате того, что Изменения обычно компонуются в Релизы и уменьшается количество отдельных внедрений;.
■ улучшение использования ресурсов Пользователей благодаря совместным усилиям при тестировании новых Релизов - это также помогает оправдать затраты на регрессионное тестирование всей системы;.
■ минимизация требований регрессионного тестирования благодаря комплексному подходу вместо того, чтобы тестировать небольшие Изменения, которые проходят слишком часто или со слишком короткими интервалами;.
■ улучшение управления ожиданиями пользователей в рамках организации благодаря своевременной публикации графика Релизов;.
■ сокращение ошибок, попадающих в среду эксплуатации при контролируемых Релизах АО и ПО, например, исключение попадания в Релиз неправильной версии;.
■ поддержка полных записей (или журнала аудита) Изменений в среде эксплуатации, содержащих информацию о распространении ПО и Изменениях в АО;.
■ соответствующий контроль и защита аппаратных и программных активов, от которых зависит деятельность организации;.
■ возможность проводить большое количество Изменений в системах, находящихся в эксплуатации, проводя эти Изменения эффективно и без отрицательного воздействия на качество ИТ-услуг - это достигается путем Релизов большого количества Изменений в одном контролируемом и продуманном Релизе;.
■ возможность сборки и контроля ПО, используемого в удаленных офисах, из центрального офиса;.
■ экономия средств, отведенных на поддержку, благодаря возможности сопровождать унифицированное ПО в большом количестве офисов;.
■ уменьшение вероятности появления и использования нелегальных копий ПО во всех офисах;.
■ более простое обнаружение неверных версий и неавторизованных копий ПО;.
■ уменьшение риска незамеченного появления вирусов и другого ПО, которое может причинить вред;.
■ уменьшение времени для Релизов и задержек;.
■ уменьшение количества Релизов, развертываемых для Заказчиков;.
■ более плавный переход Релизов от разработки к установке в бизнессреду Заказчика.
По мере роста продуктивности и эффективности Управления релизами увеличивается вероятность роста эффективности работы персонала, занятого в предоставлении ИТ-услуг. Наиболее важно то, что преимущества этой эффективности будут осознаны конечными пользователями благодаря уменьшению количества и лучшему планированию Релизов, а также использованию соответствующего обучения и более качественной документации.
9.4.2 Возможные проблемы.
Вот потенциальные проблемы, которые могут возникнуть при внедрении Управления релизами:.
■ Возможно некоторое начальное сопротивление со стороны персонала, который хорошо знаком со старыми процедурами и который не приветствует любые изменения. Чтобы справиться с этим, необходимо четко объяснить преимущества новых процедур с помощью ознакомительной кампании. Также следует установить тесные рабочие связи с группой внедрения этих Изменений;.
■ Опыт показывает, что те группы, которые более всего нуждаются в помощи Управления релизами, часто обладают наименьшим количеством времени для принятия этого процесса. Эту проблему можно обойти путем поиска способов того, как найти точки опоры и обеспечить их помощью на первых этапах. Эти способы должны быть связаны с минимальным воздействием;.
■ Возможно, будут происходить попытки обхода процедур Управления релизами. Эти попытки должны жестко пресекаться, особенно если они включают инсталляцию неавторизованного ПО. Подобные действия с очень высокой вероятностью приведут к появлению вирусов или ПО, не прошедшего тестирование, что осложнит поддержку и сделает ее дороже;.
■ Персонал также может испытывать соблазны обойти стандартные процедуры для инсталляции срочных решений. Эти попытки должны пресекаться и не допускаться правилами безопасности при инсталляции ПО, насколько это возможно;.
■ Вместо того, чтобы осуществить контролируемую сборку в тестовой среде, может возникнуть желание просто скопировать ПО из среды разработки;.
■ В распределенной системе могут возникнуть трудности, если новые версии ПО или АО не будут инсталлированы и активированы вовремя в удаленных офисах. Использование средств распространения ПО при поддержке регулярного аудита может помочь избежать этой проблемы;.
■ Некоторые сотрудники (включая ИТ-руководство) могут считать процедуры Управления релизами неудобными и слишком дорогими. Тем не менее, они всегда обязательны к исполнению для того, чтобы продуктивно и эффективно справляться с Изменениями в ПО;.
■ Может оказаться, что нет четкого владения процессом и распределения ответственности между эксплуатационными группами и группами разработки (проектными группами). Например, когда существует непонимание того, кто несет ответственность за управление компонентами Релиза в разных точках жизненного цикла Релиза;.
■ Недостаточная доступность ресурсов для тестирования приведет к уменьшению эффективности этих процедур или высокое количество вариантов конфигураций в среде эксплуатации может наложить ограничения на проведение полного тестирования;.
■ Если есть недостаток в компьютерных и сетевых ресурсах, соответствующая сборка и тестирование новых Релизов и оборудования может оказаться невозможной или произойти с задержкой. Следует выделить время при тестировании нового Релиза, предусмотрев возможность его первоначального отказа и последующей доработки. Аналогично, процедуры отката должны быть проверены в контролируемой тестовой среде;.
■ Недостаточное понимание содержания Релиза, его сборки и инсталлируемых компонентов может привести к ошибкам;.
■ Тестирование в одной части может пройти удовлетворительно, но в другой - дать сбой, например, из-за разных инфраструктур или значений параметров;.
■ Персонал может сомневаться в необходимости отката Релиза и может подвергаться давлению с целью передачи недостаточно протестированного ПО и АО в среду эксплуатации;.
■ Могут существовать некачественные, ограниченные или не отображающие действительность тестовые среды и процедуры.
При любых обстоятельствах план Управления релизами, его принципы и политика, на которых он основывается, могут на начальных этапах, а потом и периодически, быть включены в кампанию по рекламе этого процесса, чтобы установить определенные ожидания и цели.