Полная медиатека

Стандартная медиатека — это безопасное хранилище информационных технологий , в котором хранятся и защищаются окончательные авторизованные версии программного обеспечения организации. Прежде чем организация выпустит какое-либо новое или измененное прикладное программное обеспечение в свою рабочую среду, любое такое программное обеспечение должно быть полностью протестировано и проверено на качество. Окончательная медиа-библиотека обеспечивает область хранения программных объектов, готовых к развертыванию, и должна содержать только мастер-копии контролируемых элементов конфигурации носителей программного обеспечения (CI), прошедших соответствующие проверки качества , обычно включая как приобретенные, так и заказные приложений и золотых сборок исходные коды , а также исполняемые файлы . В контексте ITIL ^[1] В рамках передовой практики термин «стандартная медиатека» заменяет термин «стандартная библиотека программного обеспечения», который использовался до версии ITIL v3.

В сочетании с базой данных управления конфигурацией (CMDB) он эффективно обеспечивает ДНК центра обработки данных , т.е. все носители приложений и программного обеспечения , подключенные к записи CMDB об установке и настройке.

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

Предыстория [ править ]

В контролируемой ИТ- среде крайне важно, чтобы в производство допускались только авторизованные версии программного обеспечения. Последствия попадания неавторизованных версий программного обеспечения в рабочую среду могут быть серьезными. Как правило, в зрелой организации существуют строгие процессы управления изменениями и выпусками, чтобы предотвратить это, но такие процессы требуют места, где авторизованные версии программного обеспечения могут быть безопасно сохранены и доступны. Решение, предложенное ITIL в третьей версии, называется стандартной медиабиблиотекой или DML (заменяющей ранее названную Definitive Software Library или DSL во второй версии). ITIL предполагает, что DML может быть физическим или виртуальным хранилищем, и у любого метода есть свои преимущества и недостатки. Однако очевидно, что существуют ключевые факторы успеха любого решения DML, т.е. программное обеспечение, необходимое для внедрения в производство, должно быть тщательно протестировано, проверено и лицензировано для работы, а также упаковано таким образом, чтобы его можно было безопасно и последовательно развертывать. Кроме того, доступ к DML должен быть доступен только тем, у кого есть на это полномочия. Таким образом, виртуальное (электронное) хранилище почти всегда будет лучшим решением, а это означает, что DML можно централизовать и получить к нему доступ удаленно или в нерабочее время, если возникнет такая необходимость (см. раздел «Распределение»).

Область применения [ править ]

DML играет решающую роль в поддержке перехода от этапа разработки к этапу производства, и решения DML следует отличать от других хранилищ программного обеспечения и исходного кода, например, от управления конфигурацией программного обеспечения или SCM (иногда называемого управлением изменениями и конфигурацией программного обеспечения), которое поддерживает разработку или этап эволюции программного обеспечения. Это важное различие, которое часто вызывает некоторую путаницу. По сути, тогда как инструменты или репозитории SCM хранят и управляют всеми разработанными версиями и версиями кода (или рабочих продуктов ) вплоть до окончательного авторизованного продукта, но не включая его, DML хранит только окончательные авторизованные версии кода или продукта. Это аналогично жизненному циклу массового продукта , когда продукт перемещается из дизайнерского дома на фабрику , затем на склад , а затем в магазин , т.е.

записи ( метаданные хранятся ) о том, как продукт спроектирован, разработан и создан. Это позволяет определить, какой процесс виноват в обнаружении неисправной продукции либо во время контроля качества, либо даже при последующем обслуживании.
записи (метаданные) хранятся в базе данных управления конфигурацией о том, где программное обеспечение установлено и развернуто из DML в производственную среду. Каждая установка или развертывание должно быть авторизовано соответствующим запросом на производственное изменение, а результирующее изменение должно быть записано в базе данных управления конфигурацией как связь между артефактом DML и платформой, на которой он был развернут.

В более зрелом или развитом состоянии нет различия между двумя формами управления конфигурацией, и процесс непрерывно поддерживает весь жизненный цикл предоставления услуг и их эксплуатации. Это называется управлением конфигурацией предприятия . Даже в этом случае артефакты, основанные на разработке, все равно следует отличать и хранить отдельно от управления гарантированным качеством, окончательными мастер-версиями, доступными для развертывания.В условиях аутсорсинга или сотрудничества с участием нескольких поставщиков наличие или отсутствие последовательной и безопасной формы доступа поставщика будет определять, будет ли управление конфигурацией программного обеспечения выполняться пассивно (извне поставщики внедряют свои собственные инструменты SCM, а затем поставляют готовый продукт) или активно (контролируется внутри компании поставщиками, использующими централизованно размещенный инструмент SCM). Однако все готовые продукты (прикладное программное обеспечение) в их разрешенной к развертыванию форме должны храниться в центральном DML.

Типичные ЭК, которые будет хранить DML, включают:

Упакованное собственное прикладное программное обеспечение
Коммерческие готовые исходные материалы (COTS)
Индивидуальное программное обеспечение COTS (содержащее улучшения, индивидуальную конфигурацию и т. д.)
Пакеты релизов
Патчи (см. патч (вычисления) )
Золотые сборки (клиенты, серверы, сети, устройства хранения и т. д.)
Системные изображения
Через различные технологические стеки и технологии распространения (например, Wintel, UNIX, ORACLE, мэйнфреймы, сети, системы хранения данных и т. д.)

медиа - релиза Жизненный цикл

(см. диаграмму «стандартная медиа-библиотека и база данных управления конфигурацией в контексте процесса управления выпусками» выше)

Этапы жизненного цикла медиа-релиза:

Возникает спрос на новую услугу или товар.
Решение о производстве или покупке продукта (услуги, сборки или приложения) принимается на основе функциональных требований, извлеченных из инструмента отслеживания требований. Продукт создается или выбирается из каталога услуг/продуктов в соответствии с политикой архитектурного проектирования (Service Design). Продукт COTS закупается и хранится в DML со статусом актива «закуплено». Если продукт новый, он добавляется в Каталог одобренной продукции. Исходный код приложения, созданный собственными силами, управляется непосредственно в репозитории управления конфигурацией программного обеспечения.
Если упаковывается продукт COTS или золотая сборка, носитель извлекается из DML.
Продукт упаковывается или разрабатывается и упаковывается (в этом случае дополнительные функции рассматриваются так же, как собственные приложения и сборки).
Корневые записи или исходные базовые показатели создаются в инструменте управления конфигурацией программного обеспечения.
Версии кода разработки и версии пакетов записываются в инструменте управления конфигурацией программного обеспечения на протяжении всего процесса разработки.
Проводится модульное тестирование.
Упаковка завершена для создания пакета выпуска.
Упаковка продукта имеет гарантию качества (включая тестирование, подготовку и любые доработки).
Завершенный носитель (сборка, служба или приложение) возвращается в DML как авторизованный носитель, готовый к развертыванию.
После одобрения Управления изменениями продукт передается в собственность через соответствующую систему распространения, а логические установки регистрируются в рамках надлежащей процедуры в CMS (CMDB).
Объекты DML архивируются, как только:
1. CMS или CMDB указывает, что пакетная версия больше не используется ни в каком месте (после последнего вывода из эксплуатации или обновления требуется период отсрочки, чтобы обеспечить возможность любых необходимых регрессий) и
2. Объект DML был удален из технического или пользовательского (сервисного) каталога как выбираемый элемент.

Распространение [ править ]

Несмотря на то, что DML как авторизованное хранилище средств массовой информации предполагает определенную степень централизации, для достижения глобальной модели потребуются локальные медиа-библиотеки (LML). Таким образом, выпуск и развертывание физических экземпляров носителей может быть достигнуто в стране своевременно, избегая постоянной загрузки через глобальную сеть. Репликация авторизованных носителей в неосновных окнах сделает необходимые пакеты доступными локально по мере необходимости, но DML останется «главным» по причинам управления процессом.

Иерархия DML/LML является синонимом уровней распределения главный/вторичный, наблюдаемых во многих технологиях распространения и системах управления пакетами. Однако, хотя инструменты распространения имеют тенденцию быть ориентированы на конкретный технологический стек (например, Wintel, Unix, мейнфрейм и т. д.), одним из основных преимуществ DML является его технологически-независимый характер и настоящее центральное хранилище для всего авторизованного программного обеспечения. Таким образом, инструменты распространения будут подключаться к DML для получения пакета программного обеспечения. Упаковка приложений включает подготовку стандартных структурированных установок программного обеспечения, предназначенных для автоматического развертывания. Упаковка также необходима для купленного программного обеспечения (COTS), поскольку упаковка позволяет настроить программное обеспечение для эффективной работы на определенной платформе или в среде. Даже небольшое изменение в этой платформе (например, замена диска) может помешать успешному развертыванию пакета, поэтому сохранение версии программного обеспечения в формате Raw Media (ISO) имеет решающее значение, поскольку это может потребоваться (часто в чрезвычайной ситуации). упакованная версия больше не развертывается, например, после обновления или замены операционной платформы.

Преимущества [ править ]

DML поддерживает;

Управление выпуском и развертыванием как основа и центральное хранилище для всех выпускаемых пакетов развертывания.
Доступность и непрерывность обслуживания за счет предоставления источника всех упакованных приложений и необработанных носителей для использования в процедурах восстановления услуг и аварийного восстановления.
Автоматизированное предоставление и рационализация серверов за счет хранения золотых сборок.
Управление активами путем предоставления записей метаданных и лицензионных ключей, касающихся предоставления лицензий на программное обеспечение COTS. Экземпляры носителей и авторизованный набор носителей, хранящиеся вместе с лицензиями и условиями лицензий, позволят оптимизировать управление распределением программного обеспечения и обеспечить внешнее соответствие требованиям Сарбейн-Оксли и рекомендациям BSA.
Выполнение каталогизированных запросов либо в виде однопользовательских запросов на клиентские продукты, либо в виде повторяющихся запросов на развертывание существующей многопользовательской службы/приложения в других местах размещения.

См. также [ править ]

Ссылки [ править ]

^ Ширли Лейси и Айвор Макфарлейн (2007). Переход на сервис ITIL. Канцелярский офис. ISBN 978-0-11-331048-7 .

Внешние ссылки [ править ]

[1] Ширли Лейси и Айвор Макфарлейн (2007). Переход на сервис ITIL. Канцелярский офис. ISBN 978-0-11-331048-7 .

[1]