ITIL/ITSM - концептуальная основа процессов ИС-службы

Выбор классов и типов объектов конфигурации, их атрибутов, формируемых в CMDB, определяется разработчиком, в соответствии с требованиями предметной области. Атрибуты CI, как правило, отражают их специфические свойства и могут включать:

• идентификаторы;
• марки и названия моделей;
• серийные номера;
• сетевые адреса;
• технические характеристики;
• операционные характеристики.

Взаимосвязи CI представляют отношения, которые существуют или могут возникнуть между двумя и более CI. Как правило, язык спецификации модели CMDB – XML. На рис. 2.3 приведен пример модели классификации конфигурации [ 2.4 ] .

Рис. 2.3. Классификация элементов конфигурации

При реализации процесса управления конфигурациями должны выполняться следующие функции:

• планирование – определение стратегии, правил и целей для реализации процесса, определение инструментария и ресурсов, определение интерфейсов с другими процессами, проектами, поставщиками;
• идентификация – разработка модели данных для записи в базу конфигураций всех компонент инфраструктуры ИТ, отношений между ними, а также информации о владельцах этих компонент, их статусе и соответствующей документации.

При спецификации процесса важными понятиями являются:

• сфера охвата;
• глубина детализации;
• контроль;
• мониторинг статуса;
• верификация.

Сфера охвата (Scope) определяет, какая часть инфраструктуры будет находиться под контролем процесса. Например, можно охватывать только сервера и маршрутизаторы. Правильный выбор Сферы охвата очень важен на начальном этапе внедрения процесса Управление конфигурациями.

Глубина детализации (Level of Detail) – важный аспект, определяющий в дальнейшем отношения между CI. Отношения, как правило рассматриваются физические и логические.

Физические отношения:

• родители - дети;
• соединенная.

Логические отношения:

• копия;
• "использует", когда одна единица использует другую. Например, программа использует сервер.

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

Мониторинг статуса предполагает отслеживание реального статуса CI, содержащихся в базе: В процессе жизненного цикла информационной системы статус CI может меняться от "заказано" до "исключено из конфигурации"

Верификация предполагает проверку того, насколько информация в базе конфигураций соответствует реальности.

При реализации процесса необходимо формировать отчеты руководству и другим процессам для осуществления их эффективного выполнения.

Процесс управления изменениями предназначен для обеспечения уверенности ИТ-менеджера в том, что все изменения необходимы, запланированы и согласованы. Данный процесс предполагает регистрацию всех существенных изменений в среде ИС предприятия, разрешает изменения, разрабатывает график работ по изменениям и организует взаимодействие ресурсов, всесторонне оценивает воздействие изменения на среду ИС и связанные с ним риски. Диаграмма активности процесса управления изменениями приведена на рис. 2.4.

Основная задача данного процесса - проведение только обоснованных изменений в ИТ-инфраструктуре и отсев непродуманных или потенциально рискованных изменений. Для этого каждое изменение конфигурации ИС организации в обязательном порядке оформляется запросом на изменение. Запрос на изменение проходит стандартную процедуру одобрения. В зависимости от масштаба изменения решение принимается на уровне менеджера процесса, комитета по оценке изменений в рамках службы ИС, правления организации.

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

увеличить изображение
Рис. 2.4. Диаграмма активности процесса управления изменениями

Процесс управления изменениями выполняет следующие функции:

• обрабатывает запросы на изменения;
• оценивает последствия изменений;
• утверждает изменения;
• разрабатывает график проведения изменений, включая восстановление при сбое;
• устанавливает процедуру обработки запроса на изменение;
• устанавливает категории и приоритеты изменений;
• управляет проектами изменений;
• организует работу комитета по оценке изменений;
• осуществляет постоянное улучшение процесса.

Важную роль в процессе управления изменениями играет коллегиальный орган по согласованию изменений. Этот орган включает в себя ИТ-директора (председателя), представителей бизнес-подразделений (представителей от финансовой службы и основных направлений бизнеса) и сотрудников ИС-службы, отвечающих по мере необходимости за следующие роли: планирование сервисов, управление изменениями, управление уровнем сервиса, управление проблемами и др. Задача коллегиального органа - планирование возможных результатов и рисков при внесении изменений в ИТ-инфраструктуру. Изменение отвергается как в случае незначительных результатов, так и в случае значительных рисков. В остальных случаях изменение может быть принято.

На основании положительного решения по изменениям разрабатывается график будущих изменений - детальный календарный график одобренных изменений, согласованный с заказчиками изменений, а также рядом других процессов ITSM.

Таким образом, процессы управления изменениями и конфигурациями обеспечивают целостность и согласованность информационной системы предприятия. В процессе управления изменениями эта задача решается посредством процесса одобрения изменений, предусматривающего всесторонний контроль за изменениями со стороны сотрудников ИС-службы, а при значительных изменениях - и руководства предприятия в целом. Процесс управления конфигурациями регистрирует все изменения в ИТ-инфраструктуре организации и обеспечивает все остальные процессы данными об установленных позициях оборудования и программного обеспечения, включая данные о произведенных настройках.

Процесс управления релизами предназначен для обеспечения согласованности изменений, вносимых в ИТ-инфраструктуру предприятия. Под релизом понимается набор новых и/или измененных позиций конфигурации, которые тестируются и внедряются совместно.

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

Процесс управления релизами состоит из трёх этапов:

• разработка;
• тестирование;
• распространение и внедрение.

Этап разработки не является обязательным для всех предприятий. Но для некоторых компаний, данный этап может являться одним из основополагающих, к ним могут относиться, например, компании по разработке программных средств.

Второй этап, этап тестирования, является важным для всех предприятий без исключения. На данном этапе необходимо определить критерии, по которым будет проводиться тестирование для каждого релиза, что позволяет определить степень готовности релиза к распространению и внедрению.

Если процесс Управления релизами подготавливает реализацию принятых изменений, то необходимо определить, какой процесс ответственен за их непосредственное внедрение. Руководствуясь материалами ITIL, можно сделать заключение, что в некоторых случаях, например, внедрение срочных или незначительных изменений, процесс Управления релизами осуществляет сам, на этапе внедрения. А в некоторых случаях, возможен вариант формирования целых проектов под управлением процесса управления проектами для внедрения комплексных и глобальных изменений, затрагивающих значительные ресурсы. В любом случае, это решается непосредственно в процессе внедрения самого процесса Управления релизами в каждой конкретной ситуации.

Процесс управления релизами выполняет следующие функции:

• планирование релиза;
• проектирование, разработка, тестирование и конфигурирование релиза;
• подписание релиза в развертывание;
• подготовка релиза и обучение пользователей;
• аудит оборудования и ПО до начала внедрения изменений и по завершении такового;
• размещение эталонных копий ПО в DSL;
• установка нового или усовершенствованного оборудования и ПО;
• постоянное улучшение процесса.

Для оценки качества деятельности процесса важно тщательно выбирать метрики.

По масштабу релизы подразделяются на три вида:

• большой релиз ПО и/или обновление оборудования - обычно содержит значительный объем новой функциональности, которая делает ранее сделанные исправления проблем частично или полностью избыточными. Также большой релиз обычно отменяет предшествующие малые релизы;
• малый релиз ПО и/или обновление оборудования - обычно содержит незначительные улучшения, часть из которых могли быть выполнены ранее как чрезвычайные релизы. Соответственно, эти изменения отменяются малым релизом;
• чрезвычайный релиз ПО и/или обновление оборудования - обычно содержит исправления некоторого числа известных ошибок.

По способу реализации релизы подразделяются также на три вида:

• при полном релизе все компоненты релиза разрабатываются, тестируются, распространяются и внедряются вместе. В результате увеличивается трудоемкость релиза, зато повышается вероятность того, что возможные проблемы будут обнаружены и устранены на этапе разработки и тестирования и не попадут в среду промышленной эксплуатации;
• дельта-релиз, или частичный релиз, включает в себя только новые или измененные позиции конфигурации. Например, если речь идет о программном релизе, дельта-релиз включает в себя только те модули, которые были созданы или изменены с момента прошлого релиза;
• пакетный релиз включает в себя несколько различных полных или частичных релизов, которые распространяются и внедряются совместно для снижения общего числа релизов, что облегчает работу пользователей. Сами релизы могут разрабатываться и тестироваться отдельно и быть объединенными в пакет лишь на заключительных этапах.

Особой сферой ответственности процесса управления релизами является библиотека эталонного ПО (Definitive Software Library - DSL). Все позиции DSL отражаются как записи CMDB. Эта библиотека - физическое хранилище протестированных и подготовленных к распространению копий разработанного и покупного ПО, лицензий на последнее, а также пользовательской и эксплуатационной документации. Информация о копиях ПО, хранящихся в DSL, ведется в базе данных позиций конфигурации. Наличие такой библиотеки играет важную роль в процессе управления релизами, особенно на этапе распространения и установки ПО.