Лекции грант. Лекции_грант. Курс лекций РостовнаДону 2007
 Скачать 1.36 Mb.
|
|
1.3 Вопросы для самопроверки 1. Поясните понятие ИТ-менеджмента. 2. Перечислите основные объекты ИТ-менеджмента. 3. Что определяет инфраструктура ИТ-предприятия? 4. Чем обусловлены постоянные изменения в ИС предприятий? 5. Поясните понятие «ИТ-сервис». 6. Приведите примеры корпоративных ИТ-сервисов. 7. Перечислите основные характеристики ИТ-сервисов. 8. Как задается характеристика «время обслуживания» для ИТ- сервиса? 9. Как задается характеристика «производительность» для ИТ- сервиса? 10. Почему в организационной структуре службы ИС целесообразно выделять подразделения разработки и сопровождения ИС? 11. Поясните основные функциональные направления службы ИС. 12. Какие факторы влияют на организационную структуру службы ИС? 23 13. Какая существует связь между функциями службы ИС и парамет- рами ИТ-сервиса? 14. Какие возможны варианты перехода от функциональной к про- цессной модели службы ИС предприятия? 15. Какие имеются преимущества использования типовых моделей бизнес-процессов службы ИС? 1.4 Список использованных источников 1. Wikipedia / http://en.wikipedia.org/wiki/Wikipedia 2. Черняк Л. Библиотеки передового опыта и парадоксы управления ИТ / Открытые системы №01, 2005 - http://www.osp.ru/os/2005/01/185188/ 3. Экономическая информатика: Введение в экономический анализ информационных систем: Учебник. – М.:ИНФРА-М, 2005. – 958 с. 24 2 ITIL/ITSM − КОНЦЕПТУАЛЬНАЯ ОСНОВА ПРОЦЕССОВ ИС-СЛУЖБЫ 2.1 Общие сведения о библиотеке ITIL В настоящее время ИТ-служба предприятия становится полноправным участником бизнеса, выступая в роли поставщика определенных услуг для биз- нес-подразделений, а отношения между ними формализуются как отношения «поставщик услуг – потребитель услуг». Бизнес-подразделение формулирует свои требования к необходимому спектру услуг и их качеству, руководство предприятия определяет объем финансирования для выполнения этих требова- ний, а подразделения ИТ-службы поддерживают и развивают информационную инфраструктуру предприятия таким образом, чтобы она была в состоянии обес- печить запрошенную услугу с заданным качеством. Отражением трансформации роли и места ИТ-службы в структуре пред- приятий является концепция и модель управления качеством информационных услуг (Information Technology Service Management – ITSM, управление ИТ- услугами) [1]. Бизнес-процессы сегодня неразделимы с программными прило- жениями, техническими ресурсами и деятельностью персонала ИТ-служб, по- этому качество работы последних становится важнейшим фактором, опреде- ляющим эффективность деятельности предприятия в целом. Модель ITSM является открытой для изменения со стороны пользовате- лей и описывает совокупность процессов службы ИС. Это позволяет настраи- вать процессы ITSM для конкретного применения. Существует большое коли- чество инструментальных средств, реализующих модели процессов ITSM, раз- работанных компаниями-консультантами и производителями программного обеспечения управления инфраструктурой ИТ. Модель ITSM не дает ИТ- менеджеру службы ИС однозначных рекомендаций как конкретно строить сис- тему управления информационной инфраструктурой предприятия. В то же вре- мя концепция ITSM содержит модель типовых процессов службы ИС, поня- 25 тийный аппарат, на основе которых целесообразно строить модели процессов для ИТ-службы. Модель ITSM, разработанная в рамках проекта ITIL (IT Infrastructure Li- brary - библиотека инфраструктуры информационных технологий, произносит- ся как «айти́л»), описывающая процессный подход к предоставлению и под- держке ИТ-услуг [2, 3]. Данная модель получила наибольшую известность в си- лу того, что предоставление и поддержка ИТ-услуг является первичной задачей ИТ-службы предприятия. В отличие от более традиционного функционального подхода к органи- зации ИТ-службы, ITSM рекомендует сосредоточиться на клиенте и его по- требностях, на ИТ-услугах, предоставляемых пользователю информационными технологиями, а не на них самих. При этом процессная организация предостав- ления услуг и наличие заранее оговоренных уровней параметров эффективно- сти позволяет ИТ-службе предоставлять качественные ИТ-услуги, измерять и улучшать их качество. По проекту ITIL была разработана библиотека, описывающая лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий [2]. Множество частных и государственных компаний в разных странах мира, включая и Россию, добились значительных успехов в повышении качества ИТ-сервисов, следуя изложенным в ITIL рекомендациям и принципам. В настоящее время ITIL становится стандартом де-факто для ИТ. Библиотека ITIL создавалась по заказу британского правительства. В на- стоящее время она издается британским правительственным агентством Office of Government Commerce и не является собственностью ни одной коммерческой организации. В семи томах библиотеки описан весь набор процессов, необхо- димых для того, чтобы обеспечить постоянное высокое качество ИТ-сервисов и повысить степень удовлетворенности пользователей. Следует отметить, что все эти процессы нацелены не просто на обеспечение бесперебойной работы ком- 26 понент ИТ-инфраструктуры. В гораздо большей степени они нацелены на вы- полнение требований пользователя и заказчика. Особенностью проекта является свобода использования его результатов: − ограничений на использование нет; − материалы модели могут быть использованы полностью или час- тично; − модель может быть использована в точном соответствии с текстом книг ITIL либо адаптирована пользователем. При этом модель сегодня является наиболее широко распространенным в мире подходом к управлению ИТ-сервисами. Она применима к организациям любого размера и любой отраслевой принадлежности. Текущая версия библиотеки ITIL включает 7 книг по основным разделам управления ИТ-сервисами [3]: − Service Delivery (предоставление услуг) – содержит описание типов ИТ-услуг, предоставляемых предприятием; − Service Support (поддержка услуг) – представляет собой описание процессов, позволяющих обеспечить пользователям доступ к ИТ- услугам, необходимым для выполнения бизнес-задач; − Information & Computing Technology Infrastructure Management (управление ИТ-инфраструктурой). В книге представлено общее описание методики организации работы ИТ-службы по управлению ИТ-инфраструктурой компании; − Application Management (управление приложениями) указывает, как обеспечить соответствие программных приложений изменениям в потребностях бизнеса, а также рассматривает общий жизненный цикл приложений, включающий разработку, внедрение и сопрово- ждение; − The Business Perspective (бизнес-перспектива) – рассматривается, как работа ИТ-инфраструктуры может влиять на бизнес компании в целом; 27 − Planning to Implement Service Management (планирование внедрения управления услугами) – посвящена проблемам и задачам планиро- вания, реализации и развития ITSM, необходимым для реализации поставленных целей; − Security Management (управление безопасностью) – посвящена про- блемам безопасности. В ней рассматриваются проблемы разграни- чения доступа к информации и ИТ-сервисам, особенности оценки, управления и противодействия рискам, инциденты, связанные с на- рушением безопасности и способы реагирования на них. В третьей, разрабатываемой версии библиотеки ITIL (проект ITIL Re- fresh), представлено пять книг, названия которых отражают жизненный цикл ИТ-услуг: − «Стратегии обслуживания» (Service Strategies); − «Проектирование услуг» (Service Design); − «Внедрение услуг» (Service Introduction); − «Оказание услуг» (Service Operation); − «Непрерывное совершенствование услуг» (Continuous Service Im- provement). В Европе существуют два центра сертификации специалистов по модели ITIL/ITSM − EXIN (Нидерланды – Голландский Экзаменационный Институт) и ISEB (The Information Systems Examination Board – подразделение Британского Компьютерного Общества – British Computer Society). Внедрением процессов ITIL/ITSM и обучением занимается целый ряд компаний-консультантов. В Рос- сии это Hewlett-Packard Consulting, «Ай-Теко», IT-Expert. Модель ITIL/ITSM поддерживается более чем десятком программных продуктов и пакетов. Лидерами разработки программных инструментов управ- ления ИТ-инфраструктурой являются: Hewlett-Packard, Computer Associated, IBM, BMC Software и Microsoft. Среди российских компаний, поставщиков программных систем автоматизации управления ИТ-услугами следует отме- тить компании СофтИнтегро и Итилиум. 28 Важным элементом инфраструктуры ITIL/ITSM являются так называе- мые ITSM-форумы. Эти форумы представляют собой сообщества пользовате- лей модели, консультантов, внедряющих модель, и производителей инструмен- тального программного обеспечения. Сообщество, как правило, имеет сайт в сети Интернет (например, ITSM ПОРТАЛ.RU), а также проводит конференции и другие мероприятия, обеспечивающие реальное общение участников. Так российское партнерство «Форум по ИТ Сервис-менеджменту» получило меж- дународную аккредитацию ITSMF и стало полноправным членом всемирного сообщества. ITSMF International представляет собой независимое сообщество профессионалов в области управления ИТ-услугами. Оно было создано в Вели- кобритании в 1991 году и занимается пропагандой идей ITSM, разработкой стандартов в этой области и поддержкой обмена опытом в десятках стран мира. На сегодняшний день национальные отделения itSMF действуют уже в 41 стра- не мира. ITSMF Russia было образовано в 2005 году и на сегодняшний день объединяет около 200 представителей из более чем 45 российских компаний. С более подробной информацией по библиотеке ITIL можно познако- миться на сайтах, приведенных в табл. 2.1, 2.2. Таблица 2.1 – Англоязычные сайты Web-адрес Описание www.itil-officialsite.com/ Оффициальный сайт ITIL www.itil.org/en/index.php Сайт на английском и немецком, общие сведения www.itil.org.uk Информация по ITL www.pinkelephant.com Компания — эксперт в области ITIL, соз- дает ITIL v3 www.itilmonkey.com/ Статьи по ITIL www.itilcommunity.com/ Форум по ITIL www.itilpedia.com/ Ссылки и информация www.itsm-portal.com/ Статьи по ITIL www.ogc.gov.uk Статьи по ITIL www.itservicetoday.com/ Статьи по ITIL manageengine.adventnet.com/ Статьи о Service Desk www.asktheserviceexpert.com/ Статьи от Robin Yearsley www.isoiec20000certification.com/ Статьи ISO 20000 29 Продолжение табл.2.1 Web-адрес Описание www.itsmwatch.com Статьи, форум www.toolselector.com/ Статьи, форум, ссылки и многое др. www.bita-center.com/ Cсылка на bita-сайт (business-to-it- allignment). en.wikipedia.org/wiki/Itil Новости, анонсы www.itilsurvival.com Много ссылок на платные ресурсы www.becta.org.uk/fits FITS — Framework for ICT Technical Sup- port, построен на принципах ITIL www.becta.org.uk/tsas/ «Облегченная» ITIL, предназначенная для британских школ www.itserviceblog.com/ Блоги по тематике ITIL en.itsmportal.net/ Портал по ITSM (статьи, книги, советы, форум) dritil.blogspot.com/ Статьи и блоги по тематике ITIL www.itilworx.com/ Статьи по тематике ITIL www.informit.com IT Management Reference Guide service.mirror42.com Библиотека KPI www.itservicetoday.com Сайт об ITSM — IT Service Today; Таблица 2.1 – Англоязычные сайты Web-адрес Описание www.itsmportal.ru/ Информационный портал по управлению ИТ www.akmeev.ru/ Сайт Руслана Акмеева, информация про MOF и ITIL, таблица взаимодействия процессов и ролей easmf.ru/ Евразийский форум по управлению сер- висами www.networkdoc.ru/forum Форум по ITIL krylov.lib.ru/index.html Страница Евгения Крылова, статьи по ITIL Внедрение методики управления ITSM – поэтапный процесс. Как пока- зывает практика, решение первоочередных задач связано с рекомендациями, приведенными в первых книгах «Поддержка сервисов» и «Предоставление сер- висов». Процессы группы предоставления сервисов считаются оперативными 30 процессами, поскольку включают в себя повседневные функции ИТ-службы. Процессы группы поддержки сервисов относятся к тактическим, которые пред- назначены для обеспечения предоставления сервисов заданного качества. 2.2 Процессы поддержки ИТ-сервисов Блок процессов поддержки ИТ-сервисов включает следующие процессы: − управление инцидентами; − управление проблемами; − управление конфигурациями; − управление изменениями; − управление релизами. Процесс управления инцидентами предназначен для обеспечения быстро- го восстановление ИТ-сервиса. При этом инцидентом считается любое событие не являющееся частью нормального функционирования ИТ-сервиса. К инци- дентам относятся, например, невозможность загрузить операционную систему, сбой электропитания, сбой жесткого диска на рабочей станции пользователя, появление компьютерного вируса в локальной сети офиса, отсутствие тонера или бумаги для печатающего устройства и т.д. Показателями качества реализа- ции процесса являются: − временная продолжительность инцидентов; − число зарегистрированных инцидентов. При реализации процесса должны выполняться следующие функции: − прием запросов пользователей; − регистрация инцидентов; − категоризация инцидентов; − приоритизация инцидентов; − изоляция инцидентов; − эскалация инцидентов; − отслеживание развития инцидента; 31 − разрешение инцидентов; − уведомление клиентов; − закрытие инцидентов. Необходимым элементом обеспечения эффективного функционирования процесса является создание службы поддержки пользователей (Help Desk), еди- ной точки обращения по поводу различных ситуаций в ИТ-инфраструктуре, обработки и разрешении пользовательских запросов. Следует отметить, что роль службы поддержки пользователей в последнее время возрастает, что от- ражается в её модифицированном названии – Service Desk. Это говорит о том, что современные службы поддержки переориентируются с реактивного прин- ципа работы, на проактивный, позволяющий анализировать ситуацию и пре- дотвращать инциденты еще до их возникновения. Для управления качеством процесса необходимо определить систему управления инцидентами, разработать управленческие отчеты и обеспечивать непрерывное улучшение процесса. На рис. 2.1 приведена диаграмма активности для процесса Управление инцидентами. Пользователь ИТ-сервиса обнаруживает нарушение режима пре- доставления сервиса и обращается в Service Desk ИТ-службы. Сотрудник под- разделения Service Desk фиксирует в регистрационном журнале инцидент, классифицирует его, определяет приоритет и при возможности осуществляет начальную поддержку. Например, при невозможности для пользователя кор- ректно завершить транзакцию предлагается перезагрузить операционную сис- тему и повторно провести транзакцию. Если начальной поддержки пользовате- лю достаточно и не требуется специализированная поддержка, то осуществля- ется закрытие инцидента. Если необходимо специализированное обслуживание, то информация по инциденту передается в подразделение сопровождения ИТ- сервисов. В этом подразделении на основе базы знаний выясняется возмож- ность устранения инцидента оперативным персоналом, т.е. нет необходимости эскалации инцидента на более высокий уровень обслуживания. В этом случае 32 оперативный персонал реализует ранее документированную процедуру восста- новления ИТ-сервиса. Классификация и начальная поддержка Обнаружение и фиксация инцидента Начало Пользователь Служба Service Desk Закрытие инцидента Требуется специализированное обслуживание? нет Процедура обслуживания инцидента Эскалация Инцидента? да нет Управление сопровождения оперативные специалисты Изучение и диагностика Разрешение и восстановление да Восстановление предоставления сервиса Управление сопровождения специалисты по разрешению инцидентов Конец Рисунок 2.1 – Диаграмма активности процесса управления инцидентами Если для устранения инцидента отсутствует решение в базе знаний, то осуществляется эскалация на следующий уровень обслуживания, где специали- сты высокого класса проводят изучение и диагностику инцидента, разрабаты- вают методы его устранения, восстановления заданной работоспособности ИТ- сервиса и пополняют базу знаний по инцидентам. После закрытия инцидента для пользователя предоставляется возможность доступа к ИТ-сервису с требуе- мыми показателями качества. Момент закрытия инцидента фиксируется в жур- нале службы Service Desk. 33 Процесс управления проблемами предназначен для минимизации нега- тивного влияния инцидентов на бизнес и уменьшения количества инцидентов, за счет предотвращения возможных причин инцидентов. В данном контексте под проблемой понимают инцидент или группу инцидентов, имеющих общую неизвестную причину. При реализации процесса должны выполняться следующие функции: − анализ тенденций инцидентов; − регистрация проблем; − идентификация корневых причин инцидентов; − отслеживание изменений проблем; − выявление известных ошибок; − управление известными ошибками; − решение проблем; − закрытие проблем. Для управления качеством процесса необходима организация системы управления проблемами/известными ошибками, организация превентивных процедур поддержки, организация способов верификации известных ошибок, организация интерфейса поддержки поставщиком, разработка отчетов для управления, постоянное усовершенствование процесса. На рис. 2.2 приведена диаграмма активности для процесса Управление проблемами. Процесс управления конфигурациями предназначен для оказание помощи в управлении экономическим характеристиками ИТ-сервисов (комбинация тре- бований клиентов, качества и затрат) за счет поддержания логической модели инфраструктуры ИТ и ИТ-сервисов, а также предоставление информации о них другим бизнес-процессам. Это реализуется путем идентификации, мониторин- га, контроллинга и обеспечения информации о конфигурационных единицах (CI – Configuration Item) и их версиях. Конфигурационные единицы описывают системные компоненты с их конфигурационными атрибутами. 34 Формирование БД по инцидентам Начало Служба Service Desk Закрытие проблемы Анализ статистики инцидентов Управление сопровождения специалисты по проблема Формирование запроса на изменения Согласование изменений Коллегиальный орган по изменениям Конец Выявление корневых причин Рисунок 2.2 – Диаграмма активности процесса управления проблемами Процесс Управление конфигурациями отвечает за поддержание инфор- мации о взаимоотношениях между CI и за стандартизацию CI, мониторинг ин- формации о статусе CI, их местоположении и всех изменениях CI. Информация о CI хранится в базе данных конфигурационных единиц (Configuration Man- agement Data Base – CMDB). База данных управления конфигурациями пред- ставляет собой репозиторий метаданных, описывающий элементы конфигура- ции, их взаимосвязи и атрибуты. Элементы конфигурации представляют ин- формационные компоненты, являющиеся объектами или субъектами процесса управления конфигурациями: − материальными сущностями (серверная стойка, компьютер, мар- шрутизатор, модем, сегмент линии связи); 35 − системными или прикладными программными продуктами и ком- понентами; − реализациями баз данных; − файлами; − потоками данных; − нормативными или техническими документами; − логическими или виртуальными сущностями (виртуальный сервер, серверный кластер, пул дисковой памяти, группа устройств). Выбор классов и типов объектов конфигурации, их атрибутов, форми- руемых в CMDB, определяется разработчиком, в соответствии с требованиями предметной области. Атрибуты CI, как правило, отражают их специфические свойства и могут включать: − идентификаторы; − марки и названия моделей; − серийные номера; − сетевые адреса; − технические характеристики; − операционные характеристики. Взаимосвязи CI представляют отношения, которые существуют или мо- гут возникнуть между двумя и более CI. Как правило, язык спецификации мо- дели CMDB – XML. На рис.2.3 приведен пример модели классификации кон- фигурации [4]. 36 Конфигурация Элемент конфигурации (CI) Ресурс ИТ Стока серверная Узел технологический Компьютер Сервер Настольный ПК Ноутбук КПК Устройство хранения данных Концентратор Коммутатор Устройство комплектующее Жесткий диск Процессор Плата сетевая Потр ПО системное Операционная система ПО серверное СУБД ПО управляющее ПО прикладное Пакет прикладных программ Конфигурация программы Файл конфигурации IP-адрес Имя хост-машины DNS Сетевой интерфейс База данных Сервис Бизнес-сервис Технологический сервис Web-сервис Сотрудник Администратор Системный инженер Пользователь Документ Бизнес-документ Регламент Техническое описание Контракт Рисунок 2.3 – Классификация элементов конфигурации При реализации процесса управления конфигурациями должны выпол- няться следующие функции: 37 − планирование – определение стратегии, правил и целей для реали- зации процесса, определение инструментария и ресурсов, опреде- ление интерфейсов с другими процессами, проектами, поставщика- ми; − идентификация – разработка модели данных для записи в базу кон- фигураций всех компонент инфраструктуры ИТ, отношений между ними, а также информации о владельцах этих компонент, их статусе и соответствующей документации. При спецификации процесса важными понятиями являются: − сфера охвата; − глубина детализации; − контроль; − мониторинг статуса; − верификация. Сфера охвата (Scope) определяет, какая часть инфраструктуры будет на- ходиться под контролем процесса. Например, можно охватывать только сервера и маршрутизаторы. Правильный выбор Сферы охвата очень важен на началь- ном этапе внедрения процесса Управление конфигурациями. Глубина детализации (Level of Detail) – важный аспект, определяющий в дальнейшем отношения между CI. Отношения, как правило рассматриваются физические и логические. Физические отношения: − родители - дети; − соединенная. Логические отношения: − копия; − «использует», когда одна единица использует другую. Например, программа использует сервер. Контрольпроцессаозначает, что процесс контролирует все изменения КЕ, кем бы они не производились. 38 Мониторинг статуса предполагает отслеживание реального статуса CI, содержащихся в базе: В процессе жизненного цикла информационной системы статус CI может меняться от «заказано» до «исключено из конфигурации» Верификация предполагает проверку того, насколько информация в базе конфигураций соответствует реальности. При реализации процесса необходимо формировать отчеты руководству и другим процессам для осуществления их эффективного выполнения. Процесс управления изменениями предназначен для обеспечения уверен- ности ИТ-менеджера в том, что все изменения необходимы, запланированы и согласованы. Данных процесс предполагает регистрацию всех существенные изменений в среде ИС предприятия, разрешает изменения, разрабатывает гра- фик работ по изменениям и организует взаимодействие ресурсов, всесторонне оценивает воздействие изменения на среду ИС и связанные с ним риски. Диа- грамма активности процесса управления изменениями приведена на рис. 2.4. Основная задача данного процесса − проведение только обоснованных изменений в ИТ-инфраструктуре и отсев непродуманных или потенциально рискованных изменений. Для этого каждое изменение конфигурации ИС орга- низации в обязательном порядке оформляется запросом на изменение. Запрос на изменение проходит стандартную процедуру одобрения. В зависимости от масштаба изменения решение принимается на уровне менеджера процесса, ко- митета по оценке изменений в рамках службы ИС, правления организации. Конечный результат процесса — набор изменений, согласованных между собой и с существующей конфигурацией информационной системы и не нару- шающих функционирования уже существующих сервисов. Все изменения в обязательном порядке регистрируются процессом управления конфигурацией. 39 Начало Формирование требования на изменения Формирование запроса на изменения Согласование изменения Разработка графика проведения изменения Изменение согласованно? да Конец нет Управление сопровождения специалисты по проблема Коллегиальный орган по изменениям Менеджер процесса Рисунок 2.4 – Диаграмма активности процесса управления изменениями Процесс управления изменениями выполняет следующие функции: − обрабатывает запросы на изменения; − оценивает последствия изменений; − утверждает изменения; − разрабатывает график проведения изменений, включая восстанов- ление при сбое; − устанавливает процедуру обработки запроса на изменение; 40 − устанавливает категории и приоритеты изменений; − управляет проектами изменений; − организует работу комитета по оценке изменений; − осуществляет постоянное улучшение процесса. Важную роль в процессе управления изменениями играет коллегиальный орган по согласованию изменений. Этот орган включает в себя ИТ-директора (председателя), представителей бизнес-подразделений (представителей от фи- нансовой службы и основных направлений бизнеса) и сотрудников ИС-службы, отвечающих по мере необходимости за следующие роли: планирование серви- сов, управление изменениями, управление уровнем сервиса, управление про- блемами и др. Задача коллегиального органа − возможных результатов и рисков при внесении изменений в ИТ-инфраструктуру.. Изменение отвергается как в случае незначительных результатов, так и в случае значительных рисков. В ос- тальных случаях изменение может быть принято. На основании положительного решения по изменениям разрабатывается график будущих изменений — детальный календарный график одобренных из- менений, согласованный с заказчиками изменений, а также рядом других про- цессов ITSM. Таким образом, процессы управления изменениями и конфигурациями обеспечивают целостность и согласованность информационной системы пред- приятия. В процессе управления изменениями эта задача решается посредством процесса одобрения изменений, предусматривающего всесторонний контроль за изменениями со стороны сотрудников ИС-службы, а при значительных из- менениях — и руководства предприятия в целом. Процесс управления конфи- гурациями регистрирует все изменения в ИТ-инфраструктуре организации и обеспечивает все остальные процессы данными об установленных позициях оборудования и программного обеспечения, включая данные о произведенных настройках. Процесс управления релизами предназначен для обеспечения согласован- ности изменений, вносимых в ИТ-инфраструктуру предприятия. Под релизом 41 понимается набор новых и/или измененных позиций конфигурации, которые тестируются и внедряются совместно. Процесс управления релизами предполагает консолидацию, структуриро- вание и оптимизация всех изменений или обновлений, а также снижение риска при переводе сервиса на новый качественный уровень. Процесс управления релизами состоит из трёх этапов: − разработка; − тестирование; − распространение и внедрение. Этап разработки не является обязательным для всех предприятий. Но для некоторых компаний, данный этап может являться одним из основополагаю- щих, к ним могут относиться, например, компании по разработке программных средств. Второй этап, этап тестирования, является важным для всех предприятий без исключения. На данном этапе необходимо определить критерии, по кото- рым будет проводиться тестирование для каждого релиза, что позволяет опре- делить степень определения готовности релиза к распространению и внедре- нию. Если процесс Управления релизами подготавливает реализацию приня- тых изменений, то необходимо определить, какой процесс ответственен за их непосредственное внедрение. Руководствуясь материалами ITIL, можно сделать заключение, что в некоторых случаях, например, внедрение срочных или не значительных изменений, процесс Управления релизами осуществляет сам, на этапе внедрения. А в некоторых случаях, возможен вариант формирования це- лых проектов под управлением процесса управления проектами для внедрения комплексных и глобальных изменений, затрагивающих значительные ресурсы. В любом случае, это решается непосредственно в процессе внедрения самого процесса Управления релизами в каждой конкретной ситуации. Процесс управления релизами выполняет следующие функции: − планирование релиза; 42 − проектирование, разработка , тестирование и конфигурирование ре- лиза; − подписание релиза в развертывание; − подготовка релиза и обучение пользователей; − аудит оборудования и ПО до начала внедрения изменений и по за- вершении такового; − размещение эталонных копий ПО в DSL ; − установка нового или усовершенствованного оборудования и ПО; − постоянное улучшение процесса. Для оценки качества деятельности процесса важно тщательно выбирать метрики. По масштабу релизы подразделяются на три вида: − большой релиз ПО и/или обновление оборудования − обычно со- держит значительный объем новой функциональности, которая де- лает ранее сделанные исправления проблем частично или полно- стью избыточными. Также большой релиз обычно отменяет пред- шествующие малые релизы; − малый релиз ПО и/или обновление оборудования − обычно содер- жит незначительные улучшения, часть из которых могли быть вы- полнены ранее как чрезвычайные релизы. Соответственно, эти из- менения отменяются малым релизом; − чрезвычайный релиз ПО и/или обновление оборудования — обычно содержит исправления некоторого числа известных ошибок. По способу реализации релизы подразделяются также на три вида: − при полном релизе все компоненты релиза разрабатываются, тести- руются, распространяются и внедряются вместе. В результате уве- личивается трудоемкость релиза, зато повышается вероятность то- го, что возможные проблемы будут обнаружены и устранены на этапе разработки и тестирования и не попадут в среду промышлен- ной эксплуатации; 43 − дельта-релиз, или частичный релиз, включает в себя только новые или измененные позиции конфигурации. Например, если речь идет о программном релизе, дельта-релиз включает в себя только те мо- дули, которые были созданы или изменены с момента прошлого ре- лиза; − пакетный релиз включает в себя несколько различных полных или частичных релизов, которые распространяются и внедряются со- вместно для снижения общего числа релизов, что облегчает работу пользователей. Сами релизы могут разрабатываться и тестироваться отдельно и быть объединенными в пакет лишь на заключительных этапах. Особой сферой ответственности процесса управления релизами является библиотека эталонного ПО (Definitive Software Library − DSL). Все позиции DSL отражаются как записи CMDB. Эта библиотека — физическое хранилище протестированных и подготовленных к распространению копий разработанного и покупного ПО, лицензий на последнее, а также пользовательской и эксплуа- тационной документации. Информация о копиях ПО, хранящихся в DSL, ведет- ся в базе данных позиций конфигурации. Наличие такой библиотеки играет важную роль в процессе управления релизами, особенно на этапе распростра- нения и установки ПО. Функции процесса управления релизами таковы: − планирование релиза; − проектирование, разработка , тестирование и конфигурирование ре- лиза; − подписание релиза в развертывание; − подготовка релиза и обучение пользователей; − аудит оборудования и ПО до начала внедрения изменений и по за- вершении такового; − размещение эталонных копий ПО в DSL ; |