- Какие ИТ-компоненты используются в настоящее время по каждой модели (версии) и на протяжении какого времени?
- Какие тенденции существуют в разных группах продуктов?
- Какова текущая и остаточная стоимость ИТ-компонентов?
УПРАВЛЕНИЕ КОНФИГУРАЦИЯМИ
- Какие ИТ-компоненты нужно выводить из операционной среды и какие требуют модернизации?
- Сколько будет стоить замена определенных компонентов?
- Какие имеются лицензии и достаточно ли их?
- Какие контракты на сопровождение следует пересмотреть?
- Какова степень стандартизации инфраструктуры?
Выявление неисправностей и оценка результатов
- Какие ИТ-компоненты необходимы для поддержки процесса восстановления в случае чрезвычайной ситуации?
- Будет ли работать план восстановления на случай чрезвычайных обстоятельств, если была изменена Конфигурация Инфраструктуры?
- Какие ИТ-компоненты будут затронуты при развертывании новых сервисов?
- Как оборудование подключено к сети?
- Какие программные модули входят в каждый из комплектов программного обеспечения?
- Какие ИТ-компоненты затрагиваются изменениями?
- Какие Запросы на Изменения (RFC) конкретных ИТ-компонентов находятся на рассмотрении и какие инциденты и проблемы произошли в прошлом и сейчас продолжают оставаться актуальными?
- Какие ИТ-компоненты вызывают известные ошибки?
- Какие ИТ-компоненты были закуплены у конкретного поставщика в течение определённого периода?
Предоставление услуг и выставление счетов
- Какие Конфигурации ИТ-компонентов являются существенными для определенных услуг?
- Какие ИТ-компоненты используются в том или ином месте и кем?
- Какие стандартные ИТ-компоненты может заказать пользователь и какие из них поддерживаются (каталог продуктов)?
Если Управление Конфигурациями применено к информационным системам, а не только к информационным технологиям, то Конфигурационная База Данных (CMDB) может хранить и управлять детальной информацией о пользователях, персонале ИТ-организации и бизнес-структурах. Эти Конфигурационные Единицы также попадают под действие процесса Управления Изменениями, например, при найме и увольнении работников.
УПРАВЛЕНИЕ КОНФИГУРАЦИЯМИ
Все Конфигурационные Единицы должны быть включены в Конфигурационную Базу Данных (CMDB), которая отслеживает все ИТ-компоненты и взаимоотношения между ними. В самой примитивной форме Конфигурационная База Данных представляет собой набор бумажных форм или электронных таблиц.
Разработчики часто используют нечто подобное Конфигурационной Базе Данных для контроля версий всех программных модулей. Некоторые платформы предоставляют такой вид контроля. Конфигурационная База Данных может состоять из нескольких физически раздельных баз данных, которые вместе составляют единое логическое целое. Рекомендуется оптимально интегрировать различные источники Конфигурационных Данных.
He следует путать Конфигурационную Базу Данных со складскими или инвентаризационными базами данных. Такие программы предоставляют только ограниченную информацию о действующем аппаратном и программном обеспечении, сетевых компонентах и компонентах среды. Кроме того, Конфигурационная База Данных (CMDB) демонстрирует, какой должна быть инфраструктура, если все идет по плану (см. также Управление Изменениями), включая документацию. Данные в базе CMDB фактически представляют авторизованную Конфигурацию Инфраструктуры. Список расхождений (дельта) между бухгалтерскими и Конфигурационными Базами Данных является источником ценной информации. Управление Конфигурациями не следует путать с Управлением Активами.
§ Управление Активами — это бухгалтерский процесс мониторинга амортизации активов, чья закупочная цена превышает определенную величину. Мониторинг ведется путем учета закупочных цен, амортизации, месторасположения активов. Эффективно работающая система Управления Активами может послужить основой для системы Управления Конфигурациями.
УПРАВЛЕНИЕ КОНФИГУРАЦИЯМИ
§ Управление Конфигурациями идет дальше, учитывая также информацию о взаимоотношениях между Конфигурационными Единицами и решая задачу стандартизации и авторизации единиц CI. Управление Конфигурациями также контролирует информацию о статусе ИТ-компонентов, их расположении, произведенных в них изменения и т. д.
АТРИБУТЫ
Помимо структуры Уровней Конфигурационных Единиц, взаимоотношений между ними и соглашений о присвоении имен, детальная проработка модели CMDB также включает в себя описание атрибутов. Атрибуты используются для хранения информации, имеющей отношение к Конфигурационной Единице. При формировании CMDB можно использовать приведенные ниже атрибуты.
| АТРИБУТ | ОПИСАНИЕ |
| Номер/метка Конфигурационной Единицы или штриховой код | Уникальный идентификатор Конфигурационной Единицы. Часто это номер, автоматически присваиваемый базой данных. Хотя не все Конфигурационные Единицы имеют физические метки, у всех есть уникальный номер |
| Номер лицензии или серийный номер | Идентификационный номер поставщика в виде серийного номера или номера лицензии |
| Номер инвентаризационной системы | Инструментальные средства инвентаризации (аудита) часто используют свои собственные идентификаторы, которые в разных областях инфраструктуры могут быть разными. Данный атрибут обеспечивает связь с этой средой |
| Номер модели/ идентификационный номер Каталога | Уникальный идентификатор, используемый в Каталоге Поставщика. У каждой версии модели свой номер, например, PAT-NL-C366-4000-T |
| Наименование модели | Полное наименование модели, в которое часто входит идентификатор версии, например, PIIMMX400MHZ |
| Изготовитель | Изготовитель Конфигурационной Единицы |
| Категория | Классификация Конфигурационной Единицы (например, технические средства, программное обеспечение, документация и т. д.) |
| Тип | Описание типа Конфигурационной Единицы, предоставляет детальную информацию о категории, например, Аппаратная Конфигурация, пакет программ или программный модуль |
| Гарантийный срок | Срок действия гарантии |
| Номер версии | Номер версии Конфигурационной Единицы |
| Расположение | Месторасположение Конфигурационной Единицы например, библиотека или носитель, на котором находится программное обеспечение, или территория/комната, где находится Конфигурационная Единица |
| Владелец | Имя владельца или лица, ответственного за Конфигурационную Единицу |
| Дата начала ответственности | Дата, когда вышеуказанное лицо стало ответственным за Конфигурационную Единицу |
| Источник/поставщик | Источник Конфигурационной Единицы, например, собственная разработка, закуплена у поставщика «X» и т. д. |
| Лицензия | Номер лицензии и ссылка на лицензионное соглашение |
| Дата поставки | Дата поставки Конфигурационной Единицы в организацию |
| Дата приемки | Дата приемки Конфигурационной Единицы в операционную среду |
| Статус (текущий) | Текущее состояние Конфигурационной Единицы, например, «в тестировании», «в работе», «выведено из операционной среды» |
| Статус (запланированный) | Следующий планируемый статус Конфигурационной Единицы с указанием даты и требуемых действий |
| Стоимость | Стоимость приобретения Конфигурационной Единицы |
| Остаточная | Текущая стоимость Конфигурационной Единицы с учетом амортизации; амортизационная стоимость |
| Комментарии | Текстовое поле для комментариев, например, для описания отличий одного варианта от другого |
БАЗИСНАЯ КОНФИГУРАЦИЯ
Базисная Конфигурация — это мгновенный снимок группы Конфигурационных Единиц, сделанный в определенный момент времени. Базисную Конфигурацию можно использовать в качестве:
§ авторизованного/поддерживаемого продукта, который можно включить в ИТ-инфраструктур; (такие Базисные Конфигурации включаются в Каталог Продуктов);
§ стандартных Конфигурационных Единиц для учета информации о стоимости;
§ базы при разработке и тестировании новых Конфигураций;
§ для выполнения возврата к исходному состоянию, если возникают проблемы с новой Конфигурацией после проведения изменений;
§ стандарта для поставки Конфигураций пользователям, например, «стандартное рабочее место»;
§ базы при установке нового программного обеспечения.
Стандартная рабочая станция является типичным примером Базисной Конфигурации. Ограничивая количество разных стандартных рабочих станций, можно облегчить оценку результатов и определение ресурсов, необходимых для реализации новых функций и улучшения их тестирования. Базисные Конфигурации также могут помочь в проведении политики комбинирования и планирования изменений, например, для пакетных релизов. Они способствуют сокращению затрат на Управление и облегчают планирование проектов.
Другим полезным применением Базисной Конфигурации является Каталог Продуктов. В нем даются Сертифицированные Конфигурации, которые можно использовать в ИТ-инфраструктуре и которые доступны для заказа пользователями. В этом случае новая Конфигурационная Единица является копией единицы из Каталога с ее номером и меткой.
МОНИТОРИНГ СТАТУСА
Цикл жизни компонента можно разделить на несколько этапов, каждому из которых присваивается свой статус. Этапы зависят от тех характеристик ИТ-инфраструктуры, которые организация хочет регистрировать. Регистрация даты каждого изменения статуса дает важную информацию о жизненном цикле продукта: о времени заказа, времени инсталляции, о сопровождении и поддержке продукта.
Статус компонента также помогает определить, какие действия можно выполнять с ним. Например, если составлен отчет об элементах со статусом «неэксплуатирующиеся запасные части», то эти технические средства нельзя перераспределять куда-либо еще без предварительного согласования, например, в рамках развертывания плана восстановления после чрезвычайных ситуаций. Изменение статуса Конфигурационной Единицы может быть вызвано авторизованными или неавторизованными изменениями или инцидентами.
Может быть использована следующая классификация статусов.
§ Новые Конфигурационные Единицы:
- В разработке/заказе;
- Протестирована;
- Принята (по результатам тестирования).
§ Существующие Конфигурационные Единицы:
- Получена (принята в операционную среду);
- Открыт Запрос на Изменение (RFC) Конфигурационной Единицы, запрошена новая версия;
- Изменение утверждено и включено в план изменений, новая Конфигурационная Единица и документация (также являющаяся Конфигурационной Единицей) будут предоставлены;
- На обслуживании;
- Не функционирует.
§ Архивированные Конфигурационные Единицы:
- Выведена из операционной среды;
- Исключена (deleted);
МОНИТОРИНГ СТАТУСА
- Удалена (removed);
- Похищена;
- Продана или истек срок аренды/лизинга;
- В архиве в ожидании безвозмездного дарения, продажи или уничтожения;
- Уничтожена.
§ Все Конфигурационные Единицы:
- В наличии;
- Получена по заказу или доступна новая версия;• - Тестируется;
- Одобрена для инсталляции;
- Активная Конфигурационная Единица находится в использовании;
- Запасные части.
Для того, чтобы авторизованная Конфигурационная База Данных отражала реальную ситуацию, необходимо проводить мониторинг следующих действий:
§ добавление Конфигурационной Единицы;
§ изменение статуса Конфигурационной Единицы, например, «работает» или «не работает» (полезно для процесса Управления Доступностью);
§ изменение владельца Конфигурационной Единицы;
§ изменение взаимоотношений Конфигурационной Единицы с другими Конфигурационными Единицами;
§ удаление Конфигурационной Единицы;
§ возникновение новых взаимоотношений Конфигурационной Единицы с каким-либо сервисом, другой Конфигурационной Единицей, документацией и т. д.;
§ возобновление или изменение лицензии;
§ обновление детальной информации о Конфигурационной Единице после аудита.
ВЕРИФИКАЦИЯ И АУДИТ
Аудит проводится для проверки, насколько точно отражена текущая ситуация в CMDB. Например, инструментальные средства аудита могут автоматически выполнять анализ рабочих станций и формировать отчеты о текущей ситуации и статусе ИТ-инфраструктуры. Эта информация будет использоваться для проверки и обновления Конфигурационной Базы Данных. Аудит возможен в следующих ситуациях:
§ после внедрения новой Конфигурационной Базы Данных;
§ к примеру, спустя полгода с момента внедрения;
§ перед серьезными изменениями и после них;
§ после чрезвычайных обстоятельств;
§ в любое другое удобное время.
При проведении аудита рассматриваются следующие вопросы:
§ Регистрируются ли в CMDB данные всех Запросов на Изменения на всех этапах их реализации, и контролирует ли процесс Управления Конфигурациями эту регистрацию?
§ Находится ли Конфигурационная База Данных в актуальном состоянии, если нет, то почему? Какое воздействие это оказывает на процесс Управления Изменениями (анализ текущего воздействия запланированных изменений)?
§ Производится ли присвоение имен новым Конфигурационным Единицам в соответствии с соглашением о присвоении имен?
§ Правильно ли используются варианты? Правильно ли регистрируются Базисные Конфигурации и становятся ли они сразу же доступными к использованию?
§ Соответствует ли содержимое Библиотеки эталонного программного обеспечения (DSL) и Склада эталонного аппаратного обеспечения (DHS) информации в Конфигурационной Базе Данных? Если нет, то почему?
Аудиторские проверки также можно проводить, выбирая объекты случайным образом или проводить там, где Руководитель Процесса Управления Конфигурациями считает, что информация может быть некорректной. Если существует связь с автоматическими инструментальными средствами аудита, тогда можно делать аудит соответствующих областей или формировать по ним дельта-отчеты практически ежедневно.
ВЕРИФИКАЦИЯ И АУДИТ
Если обнаруживаются расхождения, то инструментальные средства аудита не должны автоматически обновлять Конфигурационную Базу Данных. Все расхождения свидетельствуют о том, что изменения были произведены в обход процесса Управления Изменениями, и теперь эти прецеденты должны быть изучены.
УПРАВЛЕНИЕ ИЗМЕНЕНИЯМИ
В ходе эксплуатации ИУС требуется постоянно вносить изменения в состав ее ИТ-компонентов, а также в их конфигурацию. Бесконтрольное внесение данных изменений может негативно повлиять на уровень качества предоставляемых ИТ-сервисов, поэтому внесение таких изменений должно документироваться и контролироваться.
Целью внедрения подсистемы управления изменениями является минимизация негативного влияния вносимых изменений в состав и конфигурацию ИТ-компонентов ИУС на качество предоставляемых ИТ-сервисов.
Процесс Управления Изменениями включает в себя следующие виды деятельности для обработки изменений:
§ Направление Запроса — не включается в виды деятельности по Управлению Изменениями, но поддерживается этим процессом, так как Управление Изменениями отвечает за правильную регистрацию всех изменений.
§ Прием в обработку — предварительный просмотр (фильтрация) Запросов на Изменения и прием их к дальнейшему рассмотрению.
§ Классификация — сортировка Запросов на Изменения по категориям и приоритету.
§ Планирование — объединение изменений, планирование их проведения и планирование необходимых ресурсов.
§ Координация — координирование компоновки, испытаний и проведения изменений.
§ Оценка — оценка успешности каждого изменения и составление заключения для будущей деятельности (накопление знаний).
ВИДЫ ДЕЯТЕЛЬНОСТИ
Регистрация
Прежде всего, все Запросы на Изменения (RFC) должны быть зарегистрированы. При подаче Запроса на Изменение для решения проблемы также регистрируется номер известной ошибки.
Что представляет собой Запрос на Изменения (RFC)?
Не каждый Запрос на Модификацию обрабатывается как изменение: некоторые повседневные задания, точно определенные и подчиняющиеся установленным процедурам (стандартизованные), но включающие в себя модификации, могут обрабатываться как Запросы на Обслуживание (на пример, изменения «категории 0», см. 7.1.1). В результате возникает следующая классификация. изменений:
§ Запросы на Обслуживание (здесь: стандартные изменения) — полностью определенные и утвержденные изменения, регистрируемые, но не оценивающиеся Процессом Управления Изменениями. Эти изменения проводятся в рабочем порядке. (Примечание. Не все Запросы на Обслуживание являются изменениями).
§ Запросы на Изменения — все другие Запросы на Модификацию инфраструктуры.
Рис. 7.3. Виды деятельности в рамках Процесса Управления Изменениями
