После окончания этапа выбора существует достаточно информации для подачи Запроса на Измене­ние. Далее исправление известной ошибки будет произведено в рамках Процесса Управления Изме­нениями.

Анализ результатов внедрения (PIR)

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

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

Отслеживание и мониторинг

Данная задача предполагает выполнение мониторинга хода работ по разрешению проблем и извест­ных ошибок на всех этапах Контроля проблем и Контроля ошибок. Цели состоят в следующем:

? Определить, изменилась ли степень влияния или срочность проблемы, и на основании этого про­изводить корректировку приоритета проблемы.

? Вести мониторинг процесса выработки и реализации решения и контролировать правильность ис­полнения Запроса на Изменение. По этой причине Управление Изменениями регулярно передает информацию о состоянии Запросов на Изменение в Контроль ошибок.

Предоставление информации

В течение всего процесса информация об обходных решениях и быстрых исправлениях передается в Управление Инцидентами. Пользователи также могут информироваться об этом. Хотя данные пре­доставляет Процесс Управления Проблемами, их распространением занимается Служба Service Desk. Управление Проблемами использует Конфигурационную Базу Данных, а также Соглашения об Уровне Услуг, для уточнения, какую информацию и кому следует предоставлять.

5.4.3. Проактивное Управление Проблемами

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

5.5 Управление Процессом

5.5.1. Отчеты об Управлении и Ключевые показатели эффективности

Успешное Управление Проблемами проявляется в:

? сокращении количества инцидентов в результате разрешения проблем;

? сокращении времени, требуемом для разрешения проблем;

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

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

Отчеты об Управлении Проблемами могут быть достаточно объемными и охватывать следующие ас­пекты:

? Отчеты о времени исполнения: разделенные на Контроль проблем, Контроль ошибок и проактив­ное Управление Проблемами, а также разделенные между группой поддержки и поставщиком.

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

? Эффективность Процесса Управления Проблемами: точное количество инцидентов до и после решения проблемы, зарегистрированные проблемы, количество поданных Запросов на Измене­ния и решенных известных ошибок.

? Баланс между реактивным и проактивным Управлением Проблемами: увеличение объема проактивного Управления Проблемами по сравнению с простым реагированием на инциденты свидетельствует о большей зрелости процесса.

? Качество разработанных продуктов: продукты, переданные от разработчиков, должны иметь вы­сокое качество, иначе они могут создать новые проблемы. Для мониторинга качества важны отче­ты о новых продуктах и имеющихся в них известных ошибках.

? Статус и план работ по открытым проблемам: итоговый отчет о том, что было сделано и что будет сделано для разрешения наиболее серьезных проблем, включая запланированные Запросы на Из­менения, необходимое время и ресурсы.

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

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

5.5.2. Критические факторы успеха

Успешное Управление Проблемами зависит от следующих факторов:

? Эффективная автоматизированная регистрация инцидентов и эффективный контроль за состоя­нием инфраструктуры.

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

? Эффективность взаимодействия Управления Проблемами и Управления Инцидентами. При рас­пределении заданий и работ нужно учитывать конфликт интересов этих двух процессов: "тушение пожара" в рамках Управления Инцидентами и необходимость выяснения корневых причин в рамках Управления Проблемами.

5.5.3. Функции и роли

Работа процессов происходит в горизонтальной плоскости, проходя через различные иерархические (вертикальные) подразделения организации и функциональные обязанности в рамках отделов. Эф­фективная работа возможна только при четком определении ответственности и полномочий, связан­ных с реализацией процессов. Для повышения гибкости может быть использован ролевой подход. Если организация небольшая или имеются соответствующие экономические ограничения, то воз­можно комбинирование ролей, например, Руководителя Процесса Управления Проблемами и Про­цесса Управления Уровнем Сервиса. Последний пункт в разделе 5.5.2 объясняет, почему многие организации избегают объединения ролей руководителя службы Service Desk/Управления Инциден­тами и Руководителя Процесса Управления Проблемами.

Руководитель Процесса Управления Проблемами

Руководитель Процесса несет ответственность за такие виды деятельности по Управлению Пробле­мами, как:

? разработка и поддержка подпроцессов Контроля проблем и Контроля ошибок;

? оценка эффективности и рациональности работ по Контролю проблем и Контролю ошибок;

? предоставление Управленческой Информации;

? управление Персоналом, участвующим в Процессе Управления Проблемами;

? обеспечение необходимых ресурсов;

? разработка и совершенствование систем Контроля Проблем и Контроля Ошибок;

? анализ работы и оценка эффективности проактивного Управления Проблемами.

Роли поддержки деятельности по Управлению Проблемами

Ответственность персонала, выполняющего роли по решению проблем:

? Реактивное Управление:

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

? изучение проблем на основе их приоритетности;

? подача Запросов на Изменение;

? мониторинг устранения ошибок;

? подготовка рекомендаций по обходным решениям и быстрым исправлениям для Управления Инцидентами.

? Проактивное Управление:

? определение тенденций;

? подача Запросов на Изменения;

? предотвращение распространения проблем на другие системы.

5.6. Затраты и проблемы

5.6.1. Затраты

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

5.6.2. Проблемы

На следующие вопросы следует обратить внимание при реализации Процесса Управления Пробле­мами и, по возможности, их избежать:

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

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

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

Глава 6. Управление Конфигурациями

6.1. Введение

В каждой ИТ-организации имеется информация об ИТ-инфраструктуре. Она чаще всего появляется по­сле реализации крупных проектов, которые обычно завершаются проведением аудита и анализом ре­зультатов. Главным в работе с такой информацией является поддержание ее в актуальном состоянии. Процесс Управления Конфигурациями помогает получать достоверную и актуальную информацию об ИТ-инфраструктуре. Важным в этой информации является то, что в нее входят данные не только о кон­кретных единицах конфигурации (Конфигурационных Единицах или CI), но и о том, как они связаны друг с другом. Взаимоотношения и взаимосвязи между Конфигурационными Единицами составляют основу для анализа степени воздействия инцидентов, проблем, изменений и т. д. на ИТ-инфраструктуру. Процесс Управления Конфигурациями проверяет, правильно ли регистрируются изменения в ИТ-инфраструктуре, включая взаимоотношения между Конфигурационными Единицами (CI), и ведет мониторинг статуса ИТ-компонентов чтобы гарантировать наличие точной информации о версиях существующих Конфигурационных Единиц (CIs).

В случае если Управление Конфигурациями реализовано эффективно, то этот процесс может дать информацию о следующем:

? Финансовая информация и политика компании в отношении продуктов

? Какие ИТ-компоненты используются в настоящее время по каждой модели (версии) и на про­тяжении какого времени?

? Какие тенденции существуют в разных группах продуктов?

? Какова текущая и остаточная стоимость ИТ-компонентов?

? Какие ИТ-компоненты нужно выводить из операционной среды и какие требуют модернизации?

? Сколько будет стоить замена определенных компонентов?

? Какие имеются лицензии и достаточно ли их?

? Какие контракты на сопровождение следует пересмотреть?

? Какова степень стандартизации инфраструктуры?

? Выявление неисправностей и оценка результатов

? Какие ИТ-компоненты необходимы для поддержки процесса восстановления в случае чрезвы­чайной ситуации?

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

? Какие ИТ-компоненты будут затронуты при развертывании новых сервисов?

? Как оборудование подключено к сети?

? Какие программные модули входят в каждый из комплектов программного обеспечения?

? Какие ИТ-компоненты затрагиваются изменениями?

? Какие Запросы на Изменения (RFC) конкретных ИТ-компонентов находятся на рассмотрении и какие инциденты и проблемы произошли в прошлом и сейчас продолжают оставаться актуальными?

? Какие ИТ-компоненты вызывают известные ошибки?

? Какие ИТ-компоненты были закуплены у конкретного поставщика в течение определённого пе­риода?

? Предоставление услуг и выставление счетов

? Какие Конфигурации ИТ-компонентов являются существенными для определенных услуг?

? Какие ИТ-компоненты используются в том или ином месте и кем?

? Какие стандартные ИТ-компоненты может заказать пользователь и какие из них поддержива­ются (каталог продуктов)?

6.1.1. Основные понятия

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

Рис. 6.1. Конфигурационные Единицы

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

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

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

Управление Конфигурациями не следует путать с Управлением Активами.

? Управление Активами – это бухгалтерский процесс мониторинга амортизации активов, чья заку­почная цена превышает определенную величину. Мониторинг ведется путем учета закупочных цен, амортизации, месторасположения активов. Эффективно работающая система Управления Активами может послужить основой для системы Управления Конфигурациями.

? Управление Конфигурациями идет дальше, учитывая также информацию о взаимоотношениях между Конфигурационными Единицами и решая задачу стандартизации и авторизации единиц CI. Управление Конфигурациями также контролирует информацию о статусе ИТ-компонентов, их расположении, произведенных в них изменения и т. д.

6.2. Цель процесса

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

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

? предоставление точной информации и документации для поддержки других процессов сервис-ме­неджмента.

6.2.1. Преимущества использования процесса

Управление Конфигурациями содействует рентабельному предоставлению высококачественных ИТ-услуг с помощью:

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

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

? Эффективного разрешения проблем – Управление Конфигурациями помогает в определении Конфигурационных Единиц, затронутых проблемой, и контролирует модификацию и замену этих элементов. Данный процесс также предоставляет информацию о тенденциях, которая является также входной информацией для Управления Проблемами.

? Более быстрой обработки изменений – Управление Конфигурациями помогает в проведении более быстрого и точного анализа степени влияния, поэтому изменения могут быть реализованы быстрее и эффективнее.

? Лучшего контроля аппаратного и программного обеспечения – распространение пакетов про­грамм по возможности нужно объединять с установкой (распространением) аппаратного обеспе­чения и проведением предварительного тестирования. Конфигурационную Базу Данных и Базисные Конфигурации (т. е. мгновенные "фотографии" состояния инфраструктуры) можно исполь­зовать для разработки плана тестирования и распространения конкретным группам пользовате­лей. В базе также содержится информация о проверенных версиях программного обеспечения, ко­торые можно использовать при проведении изменений в случае необходимости возврата в исход­ное состояние.

? Улучшенной безопасности – Управление Версиями дает информацию об авторизованных изме­нениях в Конфигурационных Единицах и использовании различных модификаций программного обеспечения. Такая информация из Конфигурационной Базы Данных также помогает в мониторинге лицензий.

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

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

? Лучшей поддержки процессов Управления Доступностью и Управления Мощностями – эти процессы в части планирования и анализа услуг зависят от правильной детальной информации о Конфигурациях.

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

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

Рис. 6.2. Взаимоотношения между Конфигурационной Базой Данных и другими процессами (источник: OGC)

6.3. Процесс

Входом для процесса Управления Конфигурациями является информация об изменениях и инфор­мация из процесса Управления Закупками, а выходом – отчеты для других процессов и ИТ-руко­водства. Есть еще другой выход, когда Управление Конфигурациями предоставляет данные из Кон­фигурационной Базы Данных другим процессам, необходимые им для выполнения своих задач.

Процесс Управления Конфигурациями связан с многими другими процессами.

6.3.1. Управление Инцидентами

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

6.3.2. Управление Проблемами

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

6.3.3. Управление Изменениями

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

6.3.4. Управление Релизами

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

6.3.5. Управление Уровнем Услуг

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

6.3.6. Управление Финансами

Процессу Управления Финансами необходима информация об использовании услуг, например, у кого имеется в распоряжении PC. Процесс объединяет эту информацию с данными из Соглашений об Уровне Услуг (SLA) для определения цены. Данный процесс также ведет мониторинг инвестиций и стоимости ИТ-компонентов (Управление Активами).

6.3.7. Управление Доступностью

Процесс Управления Доступностью использует Конфигурационную Базу Данных для определения Конфигурационных Единиц, задействованных в услуге, для составления плана изменений и для вы­явления слабых мест, например, с помощью методики CFIA (Component Failure Impact Analysis – анализ влияния сбоев компонентов на предоставление сервиса). Доступность услуги (цепь компонентов инфраструктуры) определяется тем, насколько надежным является самый слабый компо­нент (звено цепочки). Процесс Управления Конфигурациями предоставляет информацию о составе цепочки, а также о каждом ее звене.

6.3.8. Управление Непрерывностью ИТ-услуг

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

6.3.9. Управление Мощностями

Процесс Управления Мощностями использует данные из Конфигурационной Базы Данных для оп­тимизации ИТ-инфраструктуры, распределения рабочей нагрузки и разработки плана мощностей.

6.3.10. Виды деятельности

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

? Планирование: определяются стратегия, политика и задачи процесса, анализируется имеющаяся информация, определяются инструментальные средства и ресурсы, создаются интерфейсы с дру­гими процессами, проектами, поставщиками и т. д.

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

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

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

? Верификация: верификация Конфигурационной Базы Данных путем аудита ИТ-инфраструкту­ры на наличие в ней зарегистрированных Конфигурационных Единиц и правильности регистра­ционных записей.

? Отчетность: предоставление информации в другие процессы и подготовка отчетов об использова­нии Конфигурационных Единиц, тенденциях и т. д.

Ниже дается подробное описание этих действий.

6.4. Виды деятельности

6.4.1. Планирование

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

6.4.2. Идентификация

Идентификация связана с определением и поддержкой соглашений о присвоении имен и нумерации версий физических компонентов инфраструктуры, взаимоотношений между ними и атрибутов. Ба­зисные Конфигурации Аппаратного Обеспечения, используемого в настоящий момент и в будущем, описываются в форме специальных групп Конфигурационных Единиц (кластеров CI). Общий вопрос, на который должна дать ответ идентификация ИТ-компонентов состоит в сле­дующем:

Какие услуги и связанные с ними компоненты ИТ-инфраструктуры должны находиться под контролем Сервис-менеджмента и какая информация необходима для этого?

При разработке системы идентификации должны быть приняты решения относительно охвата (гра­ниц) процесса и уровня детализации регистрируемой информации. Для каждого параметра (харак­теристики) следует определить владельца или заинтересованное лицо . Чем больше параметров ре­гистрируется, тем больше усилий потребуется на обновление этой информации. Общий вопрос "Что же регистрировать?" может быть сведен к перечню конкретных вопросов для определения тре­буемой информации, например: