7.3.7. Управление Мощностями
Руководитель Процесса Управления Мощностями в первую очередь занимается вопросом анализа совокупного эффекта по результатам изменений в течение продолжительного периода времени, например, увеличением времени реакции приложений или потребностью в большей емкости для хранения информации. На основе составленного Плана мощностей Управление Мощностями регулярно предлагает усовершенствования и инициирует изменения в форме Запросов на Изменения (RFC).
7.3.8. Управление Непрерывностью ИТ-услуг
Превентивные мероприятия и планы восстановления, гарантирующие непрерывность услуг, должны постоянно контролироваться, так как изменения инфраструктуры могут сделать эти планы неосуществимыми или избыточными. Процесс Управления Изменениями действует в тесной взаимосвязи с Процессом Управления Непрерывностью ИТ-услуг, чтобы в нем учитывались все изменения, которые могут повлиять на планы восстановления, и предусматривались меры, необходимые для проведения восстановления.
7.3.9. Виды деятельности в рамках Процесса Управления Изменениями
Процесс Управления Изменениями включает в себя следующие виды деятельности для обработки изменений:
? Направление Запроса – не включается в виды деятельности по Управлению Изменениями, но поддерживается этим процессом, так как Управление Изменениями отвечает за правильную регистрацию всех изменений.
? Прием в обработку – предварительный просмотр (фильтрация) Запросов на Изменения и прием их к дальнейшему рассмотрению.
? Классификация – сортировка Запросов на Изменения по категориям и приоритету.
? Планирование – объединение изменений, планирование их проведения и планирование необходимых ресурсов.
? Координация – координирование компоновки, испытаний и проведения изменений.
? Оценка – оценка успешности каждого изменения и составление заключения для будущей деятельности (накопление знаний).
Рис. 7.3. Виды деятельности в рамках Процесса Управления Изменениями
7.4. Виды деятельности
7.4.1. Регистрация
Прежде всего, все Запросы на Изменения (RFC) должны быть зарегистрированы. При подаче Запроса на Изменение для решения проблемы также регистрируется номер известной ошибки.
Что представляет собой Запрос на Изменения (RFC)?
Не каждый Запрос на Модификацию обрабатывается как изменение: некоторые повседневные задания, точно определенные и подчиняющиеся установленным процедурам (стандартизованные), но включающие в себя модификации, могут обрабатываться как Запросы на Обслуживание (например, изменения "категории 0", см. 7.1.1). В результате возникает следующая классификация изменений:
? Запросы на Обслуживание (здесь: стандартные изменения) – полностью определенные и утвержденные изменения, регистрируемые, но не оценивающиеся Процессом Управления Изменениями. Эти изменения проводятся в рабочем порядке. (Примечание. Не все Запросы на Обслуживание являются изменениями).
? Запросы на Изменения – все другие Запросы на Модификацию инфраструктуры.
Откуда исходят Запросы на Изменения (RFC)?
Запросы на Изменения могут касаться всех аспектов инфраструктуры в пределах сферы действия процессов ITIL. Любой сотрудник, работающий с инфраструктурой, может подать Запрос на Изменения (RFC). Можно определить несколько источников Запросов на Изменения (RFC), например:
? Управление Проблемами – предлагает решения для исключения долговременных ошибок с целью стабилизации предоставления услуг.
? Заказчики – могут запросить больший, меньший Уровень Сервиса или другие услуги. Эти запросы могут подаваться прямо как Запрос на Изменения или направляться через Управление Уровнем Сервиса (SLM) или через Управление Отношениями с заказчиками ИТ (IT CRM).
? Политика компании – тактические и стратегические процессы из области Предоставления услуг (Service Delivery Set) и Указания руководства (Managers Set) могут привести к направлению Запросов на Изменение Услуг. Например, Управление Уровнем Услуг, Управление Доступностью и Управление Мощностями составляют ежегодные планы улучшения услуг, которые позднее могут быть поданы как Запросы на Изменения (RFC).
? Законодательство – если возникают ограничения, регламентирующие бизнес-деятельность, или вводятся новые требования по ИТ-безопасности, непрерывности бизнес-процессов и Управлению Лицензиями.
? Поставщики – поставщики выпускают новые версии и модификации[109] своих продуктов и сообщают об исправленных ими ошибках. Они могут сообщить, что больше не поддерживают определенные версии или что не могут гарантировать производительность версии (например, из-за "Ошибки тысячелетия" – Millennium bug). Это может дать толчок Процессам Управления Проблемами или Управления Доступностью к подаче Запроса на Изменения (RFC).
? Проекты – проект часто вызывает ряд изменений. Руководство проекта должно эффективно согласовывать свои действия с Управлением Изменениями с помощью соответствующих процессов, таких как Управление Уровнем Услуг, Управление Мощностями и т. п.
? Любой другой сотрудник ИТ - в принципе, любой сотрудник может подать предложения по улучшению услуг. В особенности, ИТ-персонал может способствовать усовершенствованию процедур по поддержке и предоставлению услуг и обновлению руководств.
Регистрация Запросов на Изменения
Вот примеры информации, которая может включаться в Запросы на Изменения (RFC):
? идентификационный номер Запроса;
? номер проблемы/известной ошибки (если имеется), связанной с Запросом;
? описание и определение соответствующих Конфигурационных Единиц (CI);
? причина изменения, включая обоснование и ожидаемый бизнес-результат;
? текущая и новая версия изменяемой Конфигурационной Единицы;
? имя, адрес и номер телефона лица, направляющего Запрос;
? дата подачи;
? предварительная оценка необходимых ресурсов и времени.
7.4.2. Прием в обработку
После регистрации Запроса на Изменения (RFC) Управление Изменениями делает первичную проверку, нет ли среди них неясных, нелогичных, непрактичных или ненужных Запросов. Такие Запросы отклоняются с объяснением причин. Сотруднику, направившему Запрос, всегда должна быть предоставлена возможность для защиты своего Запроса.
Проведение изменения ведет за собой обновление в базе данных CMDB, например:
? изменение статуса существующей Конфигурационной Единицы;
? изменение взаимосвязи между различными Конфигурационными Единицами;
? новая Конфигурационная Единица или изменение существующей Конфигурационной Единицы;
? новый владелец или другое месторасположение Конфигурационной Единицы.
Если Запрос на Изменения (RFC) принимается в работу, в регистрационную запись изменения включается информация, необходимая для дальнейшей обработки изменения. Позднее к записи добавляется следующая информация:
? назначенный приоритет;
? оценка степени воздействия и требующихся затрат;
? категория;
? рекомендации Руководителя Процесса Управления Изменениями;
? дата и время авторизации изменения;
? запланированная дата проведения;
? план возврата к исходному состоянию;
? требования по поддержке;
? план проведения изменения;
? информация о разработчике и сотрудниках, ответственных за проведение изменения;
? фактическая дата и время проведения изменения;
? дата проведения оценки результатов;
? результаты испытания и обнаруженные проблемы;
? причины отклонения Запроса (если необходимо);