Место SMF-функции «Изменение и конфигурация» в жизненном цикле ИТ-услуги MOF

Место SMF-функции «Изменение и конфигурация» в жизненном цикле ИТ-услуги MOF

Жизненный цикл ИТ-услуги в модели процессов Microsoft® Operations Framework (MOF) охватывает все действия и процессы управления ИТ-услугой, а именно: планирование, разработку, эксплуатацию, обслуживание и, в конечном счете, вывод из эксплуатации. В модели MOF эти действия и процессы упорядочены в виде функций управления ИТ-услугами (SMF-функций), которые группируются по этапам жизненного цикла. Каждая SMF-функция относится к определенному этапу жизненного цикла и обладает уникальным набором целей и результатов, отвечающих назначению этого этапа. SMF-функции можно использовать как автономный набор процессов, но только их взаимодействие обеспечивает наиболее эффективное предоставление услуги с требуемым качеством и уровнем риска.

SMF-функция «Изменение и конфигурация» относится к уровню «Управление» — основе жизненного цикла ИТ-услуги в модели MOF. Следующий рисунок иллюстрирует место данной SMF-функции в составе уровня «Управление», а также положение этого уровня в жизненном цикле ИТ-услуги.

Рис. 1. Место SMF-функции «Изменение и конфигурация» в жизненном цикле ИТ-услуги

Перед использованием этой SMF-функции рекомендуется ближе ознакомиться с жизненным циклом ИТ-услуги MOF и уровнем «Управление», прочитав следующие руководства по MOF 4.0:

· Обзор MOF

· Обзор уровня «Управление»

Назначение SMF-функции «Изменение и конфигурация»

SMF-функция «Изменение и конфигурация» полезна тем, кому необходимо анализировать и контролировать изменения в ИТ-услугах.

Она охватывает выполнение следующих действий:

· Управление изменениями

· Определение текущего состояния конфигурации в любой момент времени

· Снижение риска негативного влияния изменений на работу организации

Типы ролей для SMF-функции «Изменение и конфигурация»

Основная ответственность SMF-функции «Рабочая группа» в отношении SMF­функции «Изменение и конфигурация» — ответственность «Управление».

В следующей таблице перечислены типы ролей ответственности «Управление», а также соответствующие им обязанности и роли.

Таблица 1. Ответственность «Управление» и ее роли

Тип роли	Обязанности	Роль в данной SMF­функции
Менеджер по изменениям	· Руководит управлением изменениями в ИТ­подразделении	· Обеспечение внесения изме­нений с минимальным риском и влиянием на организацию
Администратор конфигураций	· Отслеживает изменения и их влияние · Отслеживает конфигура­ционные элементы и обновляет систему управ­ления конфигурациями	· Обеспечение наличия полных сведений о состоянии в любой момент времени.

Входные данные

· Соглашения об уровне обслуживания (см. документ SMF­функция «Выравнивание бизнеса и ИТ»)

· Соглашения об уровне операционного обслуживания (см. документ SMF-функция «Выравнивание бизнеса и ИТ»)

· Договоры с внешними поставщиками услуг (см. документ SMF-функция «Выравнивание бизнеса и ИТ»)

· Применимые законы и нормативные акты (см. документ см. документ SMF-функция «Политика»)

· Внутренние политики (см. документ см. документ SMF­функция «Политика»)

· Анализ рисков и влияющих факторов (см. документ SMF­функция «Управление, риск и соответствие нормативным требованиям»)

· Перечень требований и пожеланий к отчетам CMS

Конечный результат

· Требования к CMS и RFC

Рекомендации

· Определите особенности использования данных в коммерческих (взаимозависимости служб) и технических (компоненты системы) целях.

· Чтобы сформировать полный перечень потребностей, привлеките к оценке и планированию все заинтересованные стороны (например, представителей подразделений разра­ботки решений, корпоративной архитектуры и эксплуатации, бизнес-подразделений и службы поддержки).

· Начните с отслеживания минимально возможного набора данных. Добавляйте данные по мере необходимости. Для своевременного обновления данных конфигурации необходимы ресурсы. Убедитесь, что сбор дополнитель­ных данных целесообразен. Определите цель отслеживания для всех данных.

· При добавлении нового конфигурационного элемента выполните повторную оценку данных конфигурации, которые необходимо отслеживать.

Аудит содержимого CMS

Основные вопросы

· Предписывает ли политика или требования к обеспечению соответствия нормативным актам проведение аудита? Как часто его необходимо проводить?

· Каким образом будет подтверждаться информация, хранящаяся в CMS? Кто будет ее подтверждать?

· Нужно ли ограничивать доступ?

Входные данные

· Система управления конфигурациями

· Требования к ограничению доступа

· Требования политики и нормативных актов

· Рабочая среда

Конечный результат

· Точный отчет о текущем состоянии

· Планы внесения исправлений в случае неточностей

Рекомендации

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

· Если CMS часто устаревает, проанализируйте и измените используемые процессы, чтобы повысить их точность.

Таблица 8. Действия и основные аспекты процесса разработки и тестирования изменения

Действия	Аспекты
Проектирование изменения	Основные вопросы · Учтены ли в проекте бизнес-требования и определены ли функции, которые необходимы пользователям для выполнения работы? · Разработаны ли надлежащие сценарии использования? · Учтены ли в проекте требования к эксплуатации? · Учтены ли в проекте требования к системе? Входные данные · Требования пользователей и бизнес-подразделений · Сценарии использования · Требования к эксплуатации и к системе Конечный результат · Проектные документы Рекомендации · Поддерживайте связь между требованиями и функцииями решения. Это позволяет проверять правильность проек­та и его соответствие целям и требованиям решения.
Выявление зависимостей конфигурации	Основные вопросы · Существуют ли другие конфигурационные элементы, которые зависят от предлагаемого изменения или могут быть затронуты им? · Зависит ли предлагаемое изменение от других изменений? Другими словами, нужно ли для внесения предлагаемого изменения сначала выполнить другие изменения? · Сохранены ли в системе управления конфигурациями сведения обо всех изменениях (как о предварительных требованиях, так и о конечном изменении)? Входные данные · Сведения о других предлагаемых изменениях в системе управления конфигурациями Конечный результат · Запись в системе управления конфигурациями, показывающая зависимости конфигурационных элементов, на которые может влиять предлагаемое изменение или которые могут влиять на него Рекомендации · Данные в CMS должны обновляться при каждом утвер­ждении RFC. Это поможет отслеживать изменения, запланированные для конфигурационного элемента или группы конфигурационных элементов. После успешного завершения изменения данные в CMS также необходимо обновить.
Разработка и тестирование изменения	Основные вопросы · Соответствует ли готовое изменение спецификациям заказчика? · Подготовила ли группа разработчиков среду разработки? · Подготовила ли группа разработчиков процесс отслеживания ошибок? Каким образом информация об этих ошибках будет передана группе эксплуатации для использования в базе знаний? · Проводили ли группы разработки и тестирования совместную работу по подготовке тестовых заданий? · Подготовила ли группа несколько версий-кандидатов и протестировала ли каждую из них, чтобы проверить, можно ли выпускать соответствующую версию для пилотной группы? · Завершила ли группа приемочное тестирование пользователями? · Выполнила ли группа пилотное развертывание решения и получила ли отзывы? Входные данные · Документ с описанием концепции и области действия проекта · Функциональная спецификация · Требования заказчиков · Код. · Техническое задание на проведение тестирования · План тестирования · Лабораторная среда · База данных, политики и процедуры отслеживания ошибок Конечный результат · Версии-кандидаты · Версия-кандидат, готовая к пилотному тестированию Рекомендации · Разрешайте все известные проблемы (разрешение может заключаться в исправлении или отсрочке). · Создайте стандарты для определения приоритета и серьезности ошибок и проинформируйте о них всех участников группы, включая роли разработки, тестирования и взаимодействия с пользователем. · Предоставьте специалистам по обучению и поддержке доступ к базе данных для отслеживания ошибок, чтобы они могли получить представление об истории создания решения и о проблемах, возникавших во время разработки. · Для анализа ошибок и выработки стратегий их разре­шения проводите регулярные собрания с участием разработчиков и тестировщиков.
Анализ готовности изменения к выпуску	Основные вопросы · Существует ли выравнивание бизнеса и ИТ и понятны ли приоритеты? · Определены ли ответственные за все операции и действий? · Подписаны ли все планы надлежащими руководителями? · Проинформированы ли надлежащим образом все группы, которых затрагивает изменение?  · Знают ли пользователи и владельцы зависимых услуг о влиянии, которое окажет на них это изменение, и о том, что оно запланировано?  · Готовы ли пользователи к использованию новых процессов и одобряют ли их? · Завершено ли тестирование? · Готовы ли к выпуску группы эксплуатации и поддержки? Входные данные · Отчеты о состоянии для руководителя процесса управления релизами Конечный результат · Решение о готовности/неготовности релиза Рекомендации                              · Убедитесь, что руководителю процесса управления релизами предоставлены надлежащие отчеты о состоянии.  · Предоставьте отзывы и подтверждения тем, кто должен поддерживать релиз, и напомните организации об ожидаемых выгодах.
Обновление RFC	Основные вопросы · Внесены ли обновления, отражающие намеченную дату выпуска, планы и причины возврата (если таковой необходим), требования к поддержке, план развер­тывания, результаты тестирования, выявленные проблемы и дату анализа после внедрения (PIR)? Дополнительные сведения о PIR см. в разделе «Процесс 7. Проверка и анализ изменения». · Ведется ли в ходе процесса мониторинг и обновление состояния? · Может ли инициатор изменения просматривать RFC и определять его состояние в ходе процесса? · Осуществлялось ли при выпуске информирование инициатора изменения? Входные данные · Обновления для изменения Конечный результат · Обновленный запрос на изменение Рекомендации · Чтобы убедиться, что информация обновлена, руководитель процесса управления релизами должен осуществлять мониторинг выполняемых изменений, которые задерживают выпуск. Чтобы установить ожидае­мые результаты, можно использовать соглашение об уровне операционного обслуживания.

Процесс 6. Выпуск изменения

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

 

Рис. 8. Выпуск изменения

Заключение

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

 В этой SMF-функции описаны следующие основные процессы;

· Определение базовых показателей конфигурации

· Начальные действия по внесению изменений

· Классификация изменений

· Утверждение и планирование изменений

· Разработка, тестирование, выпуск, проверка и анализ изменений

Обратная связь

Вопросы и комментарии к данному руководству присылайте по адресу [email protected] или [email protected]

 

 

Место SMF-функции «Изменение и конфигурация» в жизненном цикле ИТ-услуги MOF

Жизненный цикл ИТ-услуги в модели процессов Microsoft® Operations Framework (MOF) охватывает все действия и процессы управления ИТ-услугой, а именно: планирование, разработку, эксплуатацию, обслуживание и, в конечном счете, вывод из эксплуатации. В модели MOF эти действия и процессы упорядочены в виде функций управления ИТ-услугами (SMF-функций), которые группируются по этапам жизненного цикла. Каждая SMF-функция относится к определенному этапу жизненного цикла и обладает уникальным набором целей и результатов, отвечающих назначению этого этапа. SMF-функции можно использовать как автономный набор процессов, но только их взаимодействие обеспечивает наиболее эффективное предоставление услуги с требуемым качеством и уровнем риска.

SMF-функция «Изменение и конфигурация» относится к уровню «Управление» — основе жизненного цикла ИТ-услуги в модели MOF. Следующий рисунок иллюстрирует место данной SMF-функции в составе уровня «Управление», а также положение этого уровня в жизненном цикле ИТ-услуги.

Рис. 1. Место SMF-функции «Изменение и конфигурация» в жизненном цикле ИТ-услуги

Перед использованием этой SMF-функции рекомендуется ближе ознакомиться с жизненным циклом ИТ-услуги MOF и уровнем «Управление», прочитав следующие руководства по MOF 4.0:

· Обзор MOF

· Обзор уровня «Управление»