Читать онлайн «ИТ СЕРВИС–МЕНЕДЖМЕНТ. Вводный курс на основе ITIL». Страница 23

Таблица 6.3. Атрибуты взаимоотношений

Как уже обсуждалось, поддержка информации о взаимоотношениях между Конфигурационными Единицами является важным аспектом процесса Управления Конфигурациями. В зависимости от типа базы данных эти взаимоотношения могут быть представлены в виде атрибутов CI или в отдель­ной таблице.

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

Кроме рассмотренных выше атрибутов, необходимыми являются перечни атрибутов с технической информацией о каждом типе Конфигурационной Единицы. У каждого типа свои характеристики. Например, для PC это емкость жесткого диска, изготовитель BIOS и версия BIOS, размер оператив­ной памяти, IP-адрес и т. д. Многие инструменты системного администрирования фиксируют та­кую информацию, в этом случае достаточно установить связь с типом Конфигурационной Единицы, чтобы избежать дублирования информации. Однако следует помнить, что такие системы предостав­ляют текущую информацию, не указывая, является ли она результатом реализации утвержденных изменений или же это результат неавторизованных действий.

Для облегчения ввода и обновления атрибутов можно использовать открывающиеся меню[94]. Можно устанавливать связи и с другими надежными источниками для получения информации о месторас­положении Конфигурационной Единицы, пользователях, подразделениях, номерах телефонов, вла­дельцах и параметрах бюджета. Вариантов много, но всегда следует учитывать нагрузку, связанную с поддержкой актуальности этих файлов.

Базисная Конфигурация

Базисная Конфигурация – это мгновенный снимок группы Конфигурационных Единиц, сделан­ный в определенный момент времени. Базисную Конфигурацию можно использовать в качестве:

? авторизованного/поддерживаемого продукта, который можно включить в ИТ-инфраструктуру (такие Базисные Конфигурации включаются в Каталог Продуктов);

? стандартных Конфигурационных Единиц для учета информации о стоимости;

? базы[95] при разработке и тестировании новых Конфигураций;

? для выполнения возврата к исходному состоянию, если возникают проблемы с новой Конфигура­цией после проведения изменений;

? стандарта для поставки Конфигураций пользователям, например, "стандартное рабочее место";

? базы при установке нового программного обеспечения.

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

Другим полезным применением Базисной Конфигурации является Каталог Продуктов. В нем дают­ся Сертифицированные Конфигурации, которые можно использовать в ИТ-инфраструктуре и кото­рые доступны для заказа пользователями. В этом случае новая Конфигурационная Единица являет­ся копией единицы из Каталога с ее номером и меткой.

До того как новая модель или продукт будут добавлены в инфраструктуру, они должны появиться в Каталоге. Для этого нужно принять решения по трем вопросам:

? Бизнес: отвечает ли модель/продукт бизнес-интересам пользователя?

? Финансы: приемлемы ли затраты на поддержку?

? Влияние: приемлем ли уровень воздействия модели/продукта на услугу?

Регистрация

Первоначально База данных CMDB наполняется информацией из финансовых систем, записями о существующей ИТ-инфраструктуре, техническими данными от поставщиков. Регистрируется толь­ко информация из известных (проверенных) источников. Организация должна быть готова к поддержанию этой информации в актуальном состоянии.

6.4.3. Мониторинг статуса

Цикл жизни компонента можно разделить на несколько этапов, каждому из которых присваивается свой статус. Этапы зависят от тех характеристик ИТ-инфраструктуры, которые организация хочет ре­гистрировать. Регистрация даты каждого изменения статуса дает важную информацию о жизненном цикле продукта: о времени заказа, времени инсталляции, о сопровождении и поддержке продукта.

Рис 6.6. Пример мониторинга статуса Конфигурационной Единицы

Статус компонента также помогает определить, какие действия можно выполнять с ним. Например, если составлен отчет об элементах со статусом "неэксплуатирующиеся запасные части", то эти тех­нические средства нельзя перераспределять куда-либо еще без предварительного согласования, на­пример, в рамках развертывания плана восстановления после чрезвычайных ситуаций. Изменение статуса Конфигурационной Единицы может быть вызвано авторизованными изменениями или неавторизованными изменениями или инцидентами.

Может быть использована следующая классификация:

? Новые Конфигурационные Единицы:

? В разработке/заказе;

? Протестирована;

? Принята (по результатам тестирования).

? Существующие Конфигурационные Единицы:

? Получена (принята в операционную среду);

? Открыт Запрос на Изменение (RFC) Конфигурационной Единицы, запрошена новая версия;

? Изменение утверждено и включено в план изменений, новая Конфигурационная Единица и до­кументация (также являющаяся Конфигурационной Единицей) будут предоставлены;

? На обслуживании;

? Не функционирует.

? Архивированные Конфигурационные Единицы:

? Выведена из операционной среды;

? Исключена (deleted);

? Удалена (removed);

? Похищена;

? Продана или истек срок аренды/лизинга;

? В архиве в ожидании безвозмездного дарения, продажи или уничтожения;

? Уничтожена.

? Все Конфигурационные Единицы:

? В наличии;

? Получена по заказу или доступна новая версия;

? Тестируется;

? Одобрена для инсталляции;

? Активная Конфигурационная Единица находится в использовании;

? Запасные части.

6.4.4. Контроль

Для поддержания Конфигурационной Базы (CMDB) в актуальном состоянии необходимо эффек­тивное Управление Информацией. При любом изменении зарегистрированных характеристик Кон­фигурационных Единиц или взаимоотношений между ними, вызванном выполнением любого дей­ствия, это изменение должно быть отражено в базе данных.

Примечание. Изменять характеристики Конфигурационных Единиц можно только путем проведе­ния изменений авторизованных процессом Управления Изменениями; Управление Инцидентами может изменять только статус существующих Конфигурационных Единиц.

Управление Конфигурациями контролирует все ИТ-компоненты, существующие в организации, и отвечает за их регистрацию в системе. Аппаратные средства можно регистрировать при их заказе или получении, а программное обеспечение – при его включении в Библиотеку эталонного программного обеспечения (Definitive Software Library – DSL).

Одна из задач контроля – гарантировать регистрацию только авторизованных и включенных в Ка­талог Продуктов Конфигурационных Единиц. Для этого должно быть организовано активное взаи­модействие процесса Управления Конфигурациями с поставщиками и процессами Управления Инцидентами, Проблемами и Изменениями.

Если по согласованию с Управлением Изменениями произведены некоторые изменения в ИТ-инф­раструктуре, процесс Управления Конфигурациями обязан отразить эти изменения в Конфигураци­онной Базе Данных. Хотя публикации ITIL не дают четких указаний по этому вопросу, на практике ответственность за регистрацию Запросов на Изменение (RFC) происходит под контролем процесса Управления Изменениями[96]. Формализованные записи об изменениях являются основным источни­ком информации об изменениях в инфраструктуре, которая используется для обновления Конфигу­рационной Базы Данных. По существу процесс Управления Конфигурациями предъявляет требования к уровню зрелости процессов в организации, особенно к Управлению Изменениями, операцион­ной средой и проведения закупок.

Для того, чтобы авторизованная Конфигурационная База Данных отражала реальную ситуацию, не­обходимо проводить мониторинг следующих действий:

? добавление Конфигурационной Единицы;

? изменение статуса Конфигурационной Единицы, например, "работает" или "не работает" (полез­но для процесса Управления Доступностью);

? изменение владельца Конфигурационной Единицы;

? изменение взаимоотношений Конфигурационной Единицы с другими Конфигурационными Еди­ницами;

? удаление Конфигурационной Единицы;