1 задание. Вадим Алджанов итархитектура от а до Я Теоретические основы. Первое
 Скачать 8 Mb.
|
|
Управление ИТ активами и Конфигурациями (Assets & Configuration Management SAC) Управление активами и конфигурациями (Service Asset and Configuration Management или SACM) – процесс, ответственный за Управление конфигурациями и Управление активами. Целью SACM является определение и контроль компонентов услуг и конфигурационных единиц, а также предоставление достоверной информации о состоянии услуг и инфраструктур. Процесс фактически осуществляет инвентаризацию активов и назначение ответственных за их контроль. Данный процесс отвечает на такие вопросы как: •Формирование процесса •Управление ИТ активами •Управление конфигурациями Деятельность по процессу: •Процесс управления и планирования •Идентификация компонентов •Контроль конфигураций •Отчет о состоянии •Проверка и аудит состояния Управление и планирование Не существует единого шаблона для осуществления SACM. Менеджеры каждой организации устанавливают уровень Управления конфигурациями, приемлемый для конкретного случая и то, как его можно достичь. Это отображается в Плане управления конфигурациями. Пример содержания Плана управления активами и конфигурациями. Контекст и цель. Охват: •применяемые услуги; •среда и инфраструктура: •географическое месторасположение. Требования: •требования стратегии и политик; •требования бизнеса, Управления услугами и контрактов; •совокупность требований к подотчетности и трассируемой; •требования Системы управления конфигурациями. Применяемые политики и стандарты: •политики; •индустриальные стандарты; •внутренние стандарты, относящиеся к Управлению конфигурациями, например, стандарты к оборудованию. Организация Управлением конфигурациями: •роли и ответственности; •комитеты для контроля изменений и конфигураций; •авторизация. Процессы и процедуры в рамках Управления активами и конфигурациями: •идентификация конфигураций; •управление версиями; •управление интерфейсами; •управление поставщиками; •управление изменениями конфигураций; •релиз и развертывание; •управление сборкой; •управление снабжением; •управление CMS. Ссылка на План реализации Управление и контроль необходимых связей и интерфейсов, в частности, с финансовым управлением активами и поставщиками. Идентификация конфигураций Для идентификации конфигураций важно: •определить, как будут категорироваться активы и конфигурационные единицы; •определить подход к идентификации и наименованию всех активов и конфигурационных единиц; •определить роли и ответственности для владельцев конфигурационных единиц отдельных типов в рамках этапов жизненного цикла, например, владелец услуги в процессе релиза. Деятельность в рамках идентификации конфигураций включает в себя: •определение и документирование критериев выбора конфигурационных единиц и составляющих их компонентов; •выбор конфигурационных единиц и их компонентов на основе установленных критериев; •назначение уникальных идентификаторов для выбранных конфигурационных единиц; •определение атрибутов для каждой конфигурационной единицы; •определение для каждой конфигурационной единицы момента, когда она поступает в Управление конфигурациями; •определение владельца, ответственного за каждую конфигурационную единицу. Входы процесса: Запросы на изменения (Change Requests) Заказы на закупку (Purchase Orders) Запрос на приобретение (Acquisition Requests) Запрос на сервис (Service Requests) Выходы процесса: CMDB Категории и классификация компонентов (CI) Атрибуты компонентов Связи компонентов Предоставляет данные для всех процессов управления сервисами Участники процесса: ИТ архитектор Руководители ИТ подразделений Экспертная группа Сотрудники ИТ департамента Service Asset Manager Configuration Manager Configuration Analysis Change Manager Управление конфигурациями отвечает за то, чтобы отдельные компоненты услуги, системы или продукта, были должным образом определены, снабжены всем необходимым и контролировались. Процесс также контролирует все изменения компонентов. Он предоставляет модель конфигураций со всеми связями между активами и конфигурациями. Объектом рассмотрения является Конфигурационная единица. Конфигурационная единица (Configuration Item или CI) – любой компонент, который нуждается в управлении для того, чтобы предоставлять услугу. Информация о каждой КЕ регистрируется в форме Записи о КЕ в Системе управления конфигурациями и поддерживается актуальной в течение всего жизненного цикла процессом Управления конфигурациями. КЕ находятся под контролем Управления изменениями. Типичными примерами являются услуги, оборудование, программное обеспечение, здания, люди и документы, такие как Процессная документация и Соглашения об уровне услуг (SLA). Для того чтобы управлять конфигурационными единицами, их нужно определить и классифицировать. ITIL рекомендует следующие категории: •Конфигурационная Единица жизненного цикла •Конфигурационная Единица услуги •Конфигурационная Единица организации •Внутренние Конфигурационная Единицы •Внешние Конфигурационная Единицы •Конфигурационная Единица интерфейса Конфигурационная Единица жизненного цикла – бизнес-кейс, планы сервис-менеджмента, проектная документация, планы релизов, изменений и тестирования. Эти конфигурационные единицы предоставляют полную картину об услугах поставщика и их предоставлении, ожидаемых выгод от использования, затратах и сроках релиза. Конфигурационная Единица услуг: •возможности услуг – управление, организация, процессы, знания, люди; •ресурсы услуг – капитал, системы, приложения, информация, данные, инфраструктуры и т. п.; •модель услуг; •пакет услуг; •пакет релизов; •критерии приемки услуг. Конфигурационная Единица организации. Некоторая документация определяет характеристики CI, некоторая сама является CI и требует контроля, например, стратегия бизнеса или политика организации; Внутренняя Конфигурационная Единица – материальные и нематериальные активы, которые необходимы для предоставления и управления услугами; Внешняя Конфигурационная Единица – требования заказчиков, соглашения, релизы поставщиков и внешние услуги; Конфигурационная Единица интерфейсов – активы, необходимые для предоставления услуг «от начала до конца» в рамках Интерфейса поставщика услуг. Интерфейс поставщика услуг (Service Provider Interface или SPI) – интерфейс между поставщиком услуг и пользователем, заказчиком, бизнес-процессом, или поставщиком. Анализ интерфейсов поставщика услуг помогает координировать сквозное управление услугами. Для управления совокупностью активов Управление активами и конфигурациями ведет Систему управления конфигурациями. Система управления конфигурациями (Configuration Management System или CMS) – набор инструментов и баз данных, которые используются для управления данными о конфигурациях поставщиком услуг. CMS включает в себя инструменты для сбора, хранения, управления, обновления и представления информации обо всех конфигурационных единицах и их взаимоотношениях. Модель конфигураций должна включать в себя связи и позицию каждой конфигурационной единицы. Важной частью Управления конфигурацией является определение уровня контроля для каждой конфигурационной единицы. Для этого применяется иерархический подход, так как каждая CI может являться частью другой CI или группы CI. Например, база данных может использоваться многими приложениями. Конфигурационные единицы нижних уровней не подвержены детальному контролю и аудиту. Например, клавиатуры, используемые в организации, могут послужить примером CI нижнего уровня. Важно отметить, что в зависимости от конкретной организации, критерии выбора CI нижнего уровня отличаются. Всем конфигурационным единицам необходимо назначить имена, состоящие из идентификатора и версии. Имена должны быть уникальными. Помимо этого, все физическое оборудование должно иметь бирки, по которым их можно будет легко идентифицировать. Атрибуты конфигурационных единиц описывают характеристики, значимые в рамках SACM. В базе данных должны содержаться атрибуты каждой конфигурационной единицы. ITIL выделяет следующие стандартные атрибуты: уникальный идентификатор; тип CI; имя/описание; версия; расположение; дата поставки; детали лицензии (в частности, дата ее истечения); владелец/куратор; статус; поставщик/источник; документация; данные истории, например, аудиторские отчеты; тип связей; соответствующий SLA. Чаще всего характеристики CI содержатся в документации к ней. Связи конфигурационных единиц отражают то, как они взаимодействуют друг с другом в процессе предоставления услуг. Информация о связях хранится в CMS. Основные связи между CI: •CI является частью другой CI. Например, сервер является частью инфраструктуры сайта. Это отношение «родитель-ребенок»; •CI соединен с другим CI. Например, персональный компьютер соединен с локальной сетью; •CI использует другой CI. Например, программа использует модуль другой программы; •CI установлена на другую CI, например, Microsoft Excel на персональный компьютер. •CI может иметь множество связей. Например, быть частью другой CI и одновременно использоваться другими CI. Контроль конфигураций предоставляет механизмы контроля для конфигураций. CI не может быть перемещена, изменена, удалена без соответствующего контроля. Процедуры и политики контроля включают в себя: •лицензионный контроль – проверяет количество людей, которые используют лицензионный продукт, следит за тем, чтобы в организации не использовались нелицензионные продукты, следит за сроками истечения лицензий и т. п.; •управление изменениями; •контроль версий активов, программного и аппаратного обеспечения, релизов, сборок и т. п.; •контроль активов – возможности, место хранения, CMS; •контроль сборки с использованием документации от CMS; •поддержка и миграция электронных данных и информации; •формирование базы активов и конфигурационных единиц перед релизом; •контроль развертывания; •инсталляция; •управление целостностью Библиотеки эталонного ПО. Библиотека эталонного ПО (Definitive Media Library (DML) – одно или несколько защищенных хранилищ, в которых находятся определенные и авторизованные версии всех конфигурационных единиц, относящиеся к программному обеспечению. Также может содержать CI, ассоциированные с ПО, такие как лицензии и документация. Механизмы контроля должны быть спроектированы и встроены в новую или измененную услугу на ранних этапах ее развертывания. Каждая CI имеет ряд дискретных статусов в рамках своего жизненного цикла. Значимость каждого статуса определяется использованием CI в его рамках. Выделяют следующие статусы: •разработка или проектирование – CI находится на этапе проектирования и пока ее нельзя использовать; •утверждена – CI утверждена, и могут проводиться дальнейшие работы; •отозвана – CI больше не используется. Запись о конфигурации содержит следующее данные: •информация о конфигурации – идентификационный номер, версия, статус, история изменений и т. п.); •конфигурация услуги или продукта – статус проектирования или сборки; •статус релиза обновления для конфигурации; •изменения, которые осуществлены или осуществляются; •сбор результатов тестирования качества. Проверки Включает в себя набор следующих проверок: •соответствие документации и актуального состояния CI; •физическое наличие CI в организации, функциональные характеристики; •документации для релиза до его осуществления. Только авторизованные и корректные CI должны использоваться для поддержки услуг. Если в рамках проверок выявлены нарушения, они должны быть немедленно устранены, а результаты проверок отображены в соответствующих отчетах. Как и любой другой процесс, SACM имеет свои ключевые показатели производительности. Применяются следующие метрики: •процентное улучшение в управлении расписаниями в рамках жизненного цикла активов; •ускоренная идентификация активов, вызвавших сбои в работе услуг; •уменьшение влияния инцидентов и ошибок на CI; •процент лицензий, которые используются, к общему количеству купленных (в идеале 100%); •увеличение качества информации о CI в CSM; •уменьшение использования нелицензионного ПО; Информацию, формируемую в рамках SACM, используют все процессы в рамках жизненного цикла услуг. Управление Релизами и Установкой (Release & Deployment Management RDM) Процесс Управления Релизами и Установкой является частью этапа «Внедрения» и отвечает за тестирование возможностей для предоставления услуг. Данный процесс отвечает на такие вопросы как: •Формирование процесса управления ИТ активами и конфигурациями. •формирование и согласование планов релизов и развертывания с заказчиками и инвесторами; •гарантия того, что каждый пакет для релиза состоит из набора связанных и совместимых компонентов; •осуществление управления релизом и его компонентами в рамках процессов Внедрения; •гарантия того, что все пакеты для релизов могут быть протестированы, отслежены, проверены, установлены или устранены (при необходимости); •гарантия того, что все изменения управляются в рамках деятельностей по управлению релизами и развертыванием; Деятельность по процессу: •Планирование •Подготовка, тестирование и внедрение релиза или сборки •Сборка и тестирование Входами процесса Управления релизами и развертыванием являются: •авторизованные Запросы на изменения; •Проектная документация (SDP); •пакет уровней услуг (SLP); •План обеспечения непрерывности бизнеса и IT; •приобретенные активы и компоненты с их документацией; •модели и планы сборки; •требования и спецификации сред для сборки, тестирования, пилотирования, развертывания, обучения и восстановления; •политика и проект релизов от этапа Проектирования; •модели релизов и развертывания; •критерии входа и выхода для каждой стадии развертывания и релиза. Выходами процесса Управления релизами и развертыванием являются: •План релиза и развертывания; •завершенные Запросы на изменения для деятельностей в рамках релиза и развертывания; •оповещение об услуге; •обновленный Каталог услуг с информацией о новой или измененной услуге; •новые протестированные возможности услуги и среды; •новая или измененная документация сервис-менеджмента; •пакет услуг, учитывающий требования бизнеса •Пакет уровней услуг (SLP); •SLA, OLA и другие контракты; •протестированные планы непрерывности; •полный и актуальный перечень конфигурационных единиц; •план мощностей, соответствующий планам бизнеса; •подготовленный пакет релизов •отчет о внедрении. Участники процесса: •Комитет по Управлению Изменениями •Менеджер по Релизам и сборкам •Менеджер по внедрению Ключевые показатели производительности Управления релизами и развертыванием можно разделить на два класса: Заказчики и бизнес: •уменьшение отклонения значений производительности услуг от требуемых заказчиками и бизнесом; •уменьшение количества инцидентов, связанных с услугами; •увеличение удовлетворенности пользователей и заказчиков предоставленными услугами; •уменьшение неудовлетворенности пользователей и заказчиков. Поставщики услуг: •уменьшение необходимых ресурсов и затрат для диагностирования и исправления инцидентов и проблем в рамках развертывания и производства; •увеличение использования стандартизированного подхода к Внедрению, в том числе процессов, документации и стандартов; •уменьшение несовпадений между информацией, предоставляемой проверками конфигураций, и реальной ситуацией. Ключевые моменты процесса: •Комитет по Управлению Изменениями является владельцем процесса •ИТ департамент управляет процессом в рамках ИТ сервисов Единица релиза (Release Unit) – компоненты услуги, которые обычно компонуются вместе и выпускаются в рамках одного релиза. Единица релиза обычно включает в себя компоненты, необходимые для выполнения какой-либо полезной функции. Например, Единицей релиза может быть настольный компьютер, включающий в себя программное, аппаратное обеспечение, лицензии, документацию и т. п. Важно определить подходящий уровень Единицы релиза для каждого актива и компонента. Необходимо учитывать следующие факторы: •простота и количество изменений, необходимых для релиза и развертывания; •количество ресурсов и времени, необходимое для сборки, тестирования и развертывания; •сложность взаимосвязей между единицей и остальными услугами и компонентами; •хранение, доступное в рамках сборки, тестирования, распространения и эксплуатации. Для развертывания релиза необходимо разработать различные планы, в частности, Планы релизов и развертывания. Они должны определять: •охват и контекст релиза; •оценку рисков для релиза; •организации и отдельные лица, которых затронет релиз; •инвесторов, которые утвердили запрос на изменение; •команду, ответственную за релиз; •стратегию предоставления и развертывания; •ресурсы для релиза и развертывания; •количество изменений, которые могут быть осуществлены. В рамках Внедрения должны быть определены критерии, которые позволят установить успешность выполнения каждой стадии релиза и развертывания. Результат выполнения либо принимается (pass), либо отклоняется (fail). Перед передачей услуги в промышленную эксплуатацию, необходимо совершить ряд действий по сборке и тестированию различных сред. Среды, необходимые для релиза: •среда сборки – используется для сбора и комплектования пакета релиза; •единичная среда тестирования – используется для проверки функциональности, производительности, восстанавливаемости и полезности отдельных компонентов услуги; •комплект сред тестирования – используется для проверки функциональности, производительности, восстанавливаемости и полезности комплекта компонентов услуги; •среда интеграции – используется для сборки и интеграции компонентов услуги; •среда тестирования услуги – используется для тестирования всех аспектов объединенной архитектуры услуги; •среда тестирования релиза – используется для установки, сборки и тестирования пакета релиза в контролируемой среде; обычно совмещена со средой тестирования услуги. •среда тестирования готовности к эксплуатации – для тестирования возможностей услуги и ее компонентов перед передачей в промышленную эксплуатацию; •среда, симулирующая бизнес-среду; •среда, симулирующая Управление услугами; •среда для обучения; •среда для пилотирования; •среда для резервного копирования и восстановления. Для тестирования услуги на маленькой части пользователей используются пилоты. Пилот (Pilot) – ограниченное развертывание услуги, релиза или процесса в среде промышленной эксплуатации. Пилот используется для сокращения рисков и получения обратной связи, а также приемки от пользователей. Для пилотирования также должны формироваться планы. Планирование сборки пакета релизов содержит следующие процедуры: проверка критериев входа/выхода; взаимодействие с инвесторами: •управление контрактами и их деталями; •доведение до инвесторов информации о предлагаемых изменениях, выгоде, которую они могут принести и сопутствующих затратах, и рисках обучение персонала и передача знаний; установление услуг и активов в виде имеющихся контрактов; согласование графиков; разработка механизмов и инструментов для: •сборки, тиражирования, продвижения, распространения, контроля, инсталляции и активации релизов; •управления лицензиями и авторскими правами. настройка систем и обучение пользователей для работы с новой или измененной услугой; разработка возможностей и ресурсов для сервис-менеджмента; оценка готовности целевой группы к использованию релиза; определение и согласование критериев для выхода. В рамках составления планов развертывания необходимо ответить на следующие вопросы: •для кого предназначено развертывание? •кто будет пользователями? •есть ли какие-то особенности месторасположения? •где пользователи? •кто еще должен быть подготовлен к релизу? •когда необходимо завершить развертывание? •почему необходимо развертывание? •какие факторы успеха и критерии выхода? •каковы текущие возможности поставщика услуг? Далее разрабатываются Планы снабжения и предоставления. Они определяют следующее: •как и когда релиз и его компоненты будут предоставляться? •какие имеются команды сопровождения, и что будет в случае задержки? •как отследить прогресс в предоставлении и необходимость его завершения? •есть ли возможность защищенного хранения, если потребуется? Прежде чем добавлять какие-то действия в планы развертывания, необходимо осуществить финансовое планирование. Оно рассматривает вопросы выделения средств для обеспечения деятельностей, покупки необходимого оборудования и лицензий, имеющиеся контракты и обязательства. После того, как детальные планы для каждой деятельности в рамках Управления релизами и развертыванием составлены, наступает этап подготовки к сборке, тестированию и развертыванию. На этом этапе происходит оценка рисков, возможных проблем и несоответствий в проектной документации. Оценка проверяет, принесет ли изменение желаемые результаты. Формируется отчет, в котором содержатся рекомендации об утверждении изменения или его отклонении. Если изменение утверждено, наступает этап сборки и тестирования. Ключевые аспекты, которыми необходимо управлять в рамках этого этапа: •использование сред сборки и тестирования; •стандартизация и интеграция; •управление конфигурациями: •контроль версий, управление базовым состоянием, контроль входов и выходов этапа сборки и тестирования; •ведение отчетности, которая позволит осуществить сборку снова при возникновении необходимости; •управление наглядностью тестирования •контроль доступа к физическим компонентам и технологиям; •проверка выполнения требований безопасности; •проверка деятельностей – все необходимые условия выполнены; •управление вопросами среды – кондиционирование, электропитание, физическое место, пожарная сигнализация и т. п. •проверка готовности релиза к передаче на следующую стадию; •передача релиза на следующую стадию. В ITIL вводится понятие «базовое состояние». Базовое состояние (Baseline) – зафиксированное состояние, используемое как ориентир (контрольная точка). Трактовка зависит от контекста. В контексте Внедрения базовое состояние может быть использовано для возврата инфраструктуры к исходной конфигурации в случае, если внедрение релиза оказалось неудачным. Информация о базовых состояниях конфигураций хранится в CMS. Для сборки релиза необходимо объединить множество компонентов, активов и продуктов от внешних и внутренних поставщиков. Деятельность по приобретению компонентов включает в себя: •взаимодействие с процессами снабжения для приобретения компонентов; •сбор: •проверка, мониторинг и ведение отчетности о качестве поступающих конфигурационных единиц и компонентов услуг; •обеспечение того, что наличие лицензии можно будет доказать при возникновении необходимости; •ответные действия в случае, если качество, полученное на практике, отличается от ожидаемого, и оценка влияния снижения качества на внедрение в целом; •обновление статусов конфигурационных единиц в SACM. После того, как все необходимое куплено, документация готова, можно приступить к сборке пакета релизов. При сборке релизов важно понимать, что продукт поступит скоро в промышленное производство, следовательно, использованные в рамках сборки процедуры должны быть повторимы в случае необходимости. Ключевые этапы деятельности сборки пакета релизов: •комплектование и интеграция компонентов релиза; •создание документации для сборки и релиза •инсталляция и проверка пакета релиза; •отправка уведомлений всем заинтересованным участникам о том, что пакет релиза готов для инсталляции и использования. Если тестирование пакета релизов прошло успешно, релиз и его составляющие попадают под контроль Управления конфигурациями. С этого момента все изменения в пакете релизов осуществляются через Управление изменениями. В рамках тестирования операционной готовности проводятся следующие тесты: •тестирование готовности к развертыванию – проверяет то, что процессы, процедуры и системы развертывания могут развертывать, устанавливать, назначать и списывать пакет релизов и соответствующую ему услугу в среде производства/развертывания; •тестирование Управление услугами – проверка того, что производительность услуги может быть измерена и проконтролирована в процессе промышленной эксплуатации; •тестирование группы эксплуатации – проверяет, что сервисные подразделения смогут управлять услугой в процессе промышленной эксплуатации; •тестирование уровня услуг – проверка соответствия новой или измененной услуги требованиям уровня услуг; •тестирование пользователей – проверка того, что пользователи имеют доступ к новой или измененной услуге и могут ее использовать; •тестирование интерфейса поставщика услуг – проверка того, что интерфейсы, поддерживающие услугу, функционируют; •тестирование развертывания – проверка того, что услуга корректно развернута для каждой целевой группы или среды. После проведения указанных выше тестов наступает заключительный этап тестирования – «репетиция услуги». Это метод тестирования, в котором создаются условия, максимально приближенные к условиям реальной эксплуатации. Он должен выявить ошибки и неработающие процессы, прежде чем они повлияют на бизнес в процессе промышленной эксплуатации. Проводится перед непосредственным развертыванием услуги. Как вариант может осуществляться в виде пилота – то есть на маленькой группе реальных пользователей услуги. После успешного тестирования или пилотирования можно приступить к развертыванию услуги. На начальном этапе составляются детальные планы развертывания, и производится оценка рисков. Планы должны быть утверждены, а Запросы на изменения авторизованы процессом Управления изменениями. Только после этого услуга готова к развертыванию. В рамках развертывания могут выполняться следующие действия: •перенос финансовых активов: •Перенос/переход бизнеса и организации •окончательное оформление организационной структуры, ролей и ответственностей; •установление связей между изменениями организации, ролей и ответственностей; •убедиться в том, что люди могут приспособиться к новым практикам; •убедиться в том, что люди понимают планы и процедуры обеспечения непрерывности. Развертывание услуги – развертывание релиза, в том числе действия по распространению и установке услуги, поддерживающих услуг, приложений, инфраструктуры и функциональных возможностей. В этот этап входят следующие деятельности: •распространение и развертывание услуги и ее компонентов в заданных границах времени; •сборка, установка и настройка услуги и ее компонентов на работу с новой или преобразованной информацией; •тестирование системы и услуг в рамках инсталляции, формирование отчетов об инсталляции и тестировании; •фиксация всех проблем, сбоев, ошибок, инцидентов и расхождений с планами; •корректирование всех расхождений, которые не выходят за рамки проектных ограничений. Отзыв услуги – действия, предпринятые для того, чтобы релиз можно было отозвать в случае возникновения необходимости. Поддержка в начале эксплуатации (Early Life Support или ELP) – поддержка, предоставляемая в отношении новой или измененной услуги в течение некоторого времени непосредственно после того, как услуга была введена в эксплуатацию. Во время поддержки в начале эксплуатации поставщик услуг может пересматривать ключевые показатели производительности, уровни услуги и наблюдаемые пороговые значения, а также задействовать дополнительные ресурсы для Управления инцидентами и Управления проблемами. Обзор и завершение развертывания. Обзор развертывания включает в себя следующие действия: •организация опросов и исследований удовлетворенности пользователей, инвесторов и заказчиков новой или измененной услугой; •выявить недостигнутые критерии качества; •проверить завершенность всех необходимых действий, исправлений и изменений; •пересмотреть незавершенные изменения и убедиться в том, что для них выделены финансовые средства и назначены ответственные исполнители; •пересмотреть целевые показатели производительности и успешности; •убедиться, что все проблемы, связанные с ресурсами, возможностями, мощностями и производительностью, решены до завершения развертывания; •проверить то, что все проблемы, известные ошибки и обходные решения согласованы с инвесторами, заказчиками и пользователями. Обходное решение (Workaround) – уменьшение или устранение влияния инцидента или проблемы, для которых в текущий момент недоступно полное разрешение. •пересмотреть все риски и выявить те, которые влияют на эксплуатацию и поддержку услуги; •проверить то, что избыточные активы извлечены из обращения; •проверить готовность услуги к передаче от ELP в промышленную эксплуатацию. Процесс управления релизами и установкой также используется в процессе сопровождения сервиса. Он в основном используется в пределах ИТ департамента. При внедрении процесса управления релизами и установкой необходимо определить следующие важные атрибуты: Определить тип релиза или установки: •Плановый (Planned) •Внеплановый (Unplanned) Определить категория релиза или установки: •Проект (Project) •Обновление (Patch) •Важное обновление (Major patch) •Небольшие обновления (Minor patch) •Сборка (Build) Определить, по возможности категоризацию воздействия с указанием метрик: •Высокое (High) воздействие •Среднее (Medium) воздействие •Низкое (Low) воздействие Определить, по возможности уровень риска, при применении релиза или установки: •Высокий (High) риск воздействие •Среднее (Medium) риск воздействие •Низкое (Low) риск воздействие •Воздействие не определённо (Not assessed) Определение источников, приводящих к появлению релиза: •Запросы на изменения со стороны бизнеса •Запросы на изменения со стороны Безопасности •Анализ инцидентов (Процесс управления инцидентами) •Анализ запросов (Процесс управления запросами) •Анализ проблем (Процесс управления проблемами) •Мониторинг событий и логов •Анализ релизов (Процесс управления Релизами) •Запросы на Улучшение Сервиса Статусы изменений: •Инициирован (Initiate) •Одобренный (Approved) •Активный (In progress) •В ожидании (On pending) •Приостановленный (On hold) •Проверенный (Validated and Reviewed) •Выполненный (Completed) •Закрытый (Closed) •Активность проигнорирована (skipped) Определение групп выполнения и подтверждения изменений при запуске релиза. Зависит от организационной структуры ИТ департамента, классификации изменений и т п. Результаты запуска релиза соответствуют статусу изменений: •Удачно выполненный (Successfully implemented) •Выполненный с незначительными проблемами (Implemented with Issues) •Частично выполненный (Partially implemented) •Не выполненный (Failed) •Отказанный (Rejected) •Отозванный (Cancelled) •Не одобренный (Unauthorized) |