Задать вопрос юристу

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

  Планирование
Задачи процесса Управления Конфигурациями, сфера сто действия, а также приоритеты должны определяться в рамках Сервис-менеджмента и обязаны соответствовать бизнес-целям организации.
Соответствующие этапы в реализации Управления Конфигурациями выходят за рамки данной книги, Идетификация
Идентификация связана с определением и поддержкой соглашений о присвоении имен и нумерации версий физических компонентов инфраструктуры, взаимоотношений между ними и атрибутов. Базисные Конфигурации Аппаратного Обеспечения, используемого в настоящий момент и в будущем, описываются в форме специальных групп Конфигурационных Единиц (кластеров CI)
Общий вопрос, на который должна дать ответ идентификация ИТ-компонентов состоит в следующем:
Какие услуги и связанные ь ними компоненты ИТ-инфраструктуры должны находиться под
контролем Сервис-менеджмента и какая информация необходима для этого?
При разработке системы идентификации должны быть приняты решения относительно охвата (границ)1 процесса и уровня детализации регистрируемой информации. Для каждого параметра (характеристики) следует определить владельца или заинтересованное лицо2. Чем больше параметров регистрируется, тем больше усилий потребуется на обновление этой информации. Общий вопрос «Что же регистрировать?» может быть сведен к перечню конкретных вопросов для определения требуемой информации, например: Какие ресурсы имеются для сбора и обновления информации? Насколько зрелыми являются наши административные и материально-технические (логистические) процессы? На каких уровнях организация выполняет инсталляцию, замену, разработку и/или распространение компонентов отдельно от основного компонента? Какие виды деятельности, выполняемые сторонними организациями, должны измеряться и контролироваться? Какие компоненты могут повлиять на услуги в случае сбоя и какая нужна информация для диагностики этих сбоев? Для каких компонентов следует регистрировать статус и его предысторию? Какие компоненты используются в организации в различных версиях или вариантах? Изменения в каких компонентах могут повлиять на возможности и доступность услуг? Какие компоненты являются дорогостоящими и их следует защищать от кражи или утери? Какова настоящая и будущая информационная потребность у других процессов? Для каких компонентов требуется такая информация, как серийный номер, дата покупки и поставщик, и какая информация необходима для бухгалтерии?
’ Scope.
8 Stakeholder.
Какие требования вытекают из условий, закрепленных в Соглашениях об Уровне Услуг? Какая информация необходима для выставления счетов заказчикам? Насколько реальны наши стремления, не нужна ли корректировка?
Ответы на эти вопросы дают представление об объеме работ, которые необходимо выполнить. Следует принять решение об охвате (ширине, границах) CMDB и уровне ее детализации (глубине). Понятие детализации включает в себя: количество уровней в базе данных, взаимоотношения, подлежащие мониторингу, соглашения о присвоении имен и атрибуты. Все они будут рассмотрены ниже.
Охват (сфера действия, границы)1
При создании Конфшурационной Базы Данных и обновлении модели данных следует определиться, какая часть ИТ-иифраструктуры будет находиться под контролем процесса Управления Конфигурациями. Например, следует ли включать в сферу действия данного процесса такие компоненты, как «электронные органайзеры» (PDA), сетевые копировальные устройства, факсы, клавиатуры и ИТ-псрсонал, или же они должны находиться за пределами действия процесса? Границы, определенные для процесса Управления Конфигурациями, влияют на границы, в которых, например, процесс Управления Проблемами выполняет диагностирование, на анализ степени воздействия, проводимый процессом Управления Изменениями, планирование, выполняемое процессом Управления Доступностью и г. д.
Кроме т ого, работая над границами процесса можно произвести анализ вклада ИТ-услуг в конечную деятельность заказчика или степень воздействия на нее, а также рассмотреть соглашения с пользователями об уровне поддержке и услугах.
Сферу действия процесса можно разделить на области, каждая со своими требованиями и подходом к проектированию. Примерами таких областей могут стать настольные рабочие места, системы передачи данных, файловые сервисы, сервисы печати и прикладного ПО, центральная процессинговая система, базы данных, телефонные услуги. Для разработки каждой области может быть инициирован отдельный проект в соответствующей управленческой среде.
Границы Конфигурационной Базы Данных могут включать аппаратное и программное обеспечение, а также документацию, например, Соглашения об Уровне Услуг (SLAs), процедуры, руководства, технические спецификации, организационные схемы, персонал и планы проектов. Как и другие Конфигурационные Единицы, эти документы физически могут находиться в разных местах, но ии формация о них находится в базе данных с номерами версий, датами публикаций, именами авторов и т. д. В этом случае процессы Управления Конфигурациями и Управления Изменениями могут контролировать эти характеристики документов.
На рис. 6.3 показаны взаимоотношения между услугами и компонентами Конфигурационной Базы Данных. Отслеживание этих взаимоотношений облегчает определение степени воздействия инцидентов на услуги. Это также позволяет создавать отчет обо всех компонентах, вовлеченных в предоставление сервиса. Такая информация в дальнейшем может быть использована для улучшения услуг. У такой «сервисной» Конфигурационной Единицы могут быть взаимоотношения с другими единицами, такие как договоренности с заказчиком в форме Соглашения об Уровне Услуг. В приведенном примере услуга «В» полностью выходит за границы базы данных. Из рисунка видно, что не все Конфигурационные Единицы, участвующие в услуге «А», входят в сферу действия Конфигурационной Базы Данных (например, находятся в рассматриваемой организации), это означает, что услуга «А» не может полноценно поддерживаться.
(осле определения областей, включенных в сферу дейс твия процесса, возможно определить этапы жизненного цикла Конфигурационных Единиц, которые будут содержаться в CMDB. Будут ли единицы со статусом «в разработке» или «заказана» включены в базу данных или же их включат в CMDB только после того, как они будут введены в работу? Преимущество включения в базу данных продуктов, находящихся на стадии разработки, состоит в том, что в этом случае их спецификации уже нельзя будет менять без получения одобрения, и их передача в рабочую среду будет происходить согласованно. От этого выбора будет зависеть мониторинг статуса CI в рамках процесса Управления Конфигурациями, к тому же это позволит расширить диапазон конт роля жизненного цикла продукта в рамках этого процесса.
Уровень Детализации CMDB
Определение Уровня Детализации для каждого типа Конфигурационных Единиц является важным этапом разработки процесса Управления Конфигурациями. Здесь нет универсальных решений. На этом этапе анализируется информация о Конфигурационных Единицах. Для определения Уровня Детализации составляется схема взаимоотношений между задействованными Конфигурационными Единицами и выбирается требуемая глубина детализации CMDE. Кроме того, определяются имена и атрибуты для Конфигурационных Единиц.
При определении глубины Конфигурационной Базы Данных и взаимоотношений между Конфигурационными Единицами, отражаемыми в CMDB, нужно добиться сбалансированности требований к CMDB — с одной стороны, и загруженности персонала и имеющихся ресурсов — с другой. Количество взаимоотношений растет экспоненциально количеству уровней.
Взаимоотношения между Конфигурационными Единицами
Информация о взаимоотношениях между Конфигурационными Единицами является очень полезной для диагностики ошибок и прогнозирования доступности услуг. Можно определить много разных типов взаимоотношений на логическом и физическом уровнях.
• Взаимоотношения на физическом уровне: Является частью: это взаимоотношения типа «parent/chilcl» («родитель/ребеиок»), например, дисковод является частью PC, а программный модуль — частью программы. Подключена к: например, PC подсоединен к сегменту сети. Требуется для: например, технические средства требуются для работы приложения.

АТГИБУТ

ОПИСАНИЕ

Номер/метка Конфигурационной Единицы или штриховой код

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

Номер лицензии или серийный номер

Идентификационный помер поставщика в виде серийного нолгра или номера лицензии

Номер
инвентаризацией и-юй системы

Инструментальные средства инвентаризации (аудита) часто используют свои собственные иден1ификаторы, которые в разных областях инфраструктуры могут быть разными. Данный атрибут обеспечивает связь с эта) средой

Номер модели/ идентификационный номер Каталога

Уника/\ьный идентификатор, используемый в Каталоге Поставщика.
У каждой версии модели свой номер, например, РАГ NL-C366-4000-T

Наименование моде/\И

Полное наименование модели, в которое часто входит идентификатор версии, например, PIIMMX400MIIZ

Изготовитель

Изготовитель Конфигурационной Единицы

Категория

Классификация Конфигурационной Единицы (например, технические средства, программное обеспечение, документация и т. д.)

Тип

Описание типа Конфигурационной Единицы, предоставляет детальную информацию о категории, например. Аппаратная Конфигурация, пакет программ или программный модуль

Гарантийный срок

Срок действия гарантии

Номер версии

Номер версии Конфигурационной Единицы

Гас положение

Месторасположение Конфигурационной Единицы например, библиотека или носитель, на котором находится программное обеспечение, или территория/комната, где находится Конфигурационная Единица

Владелец

Имя владельца или лица, ответствен! юго за Конфигурационную Единицу

Дата начала ответственности

Дата, когда вышеуказанное лицо стало ответственным, за Конфигурационную Единицу

Источник/поставщик

Источник Конфигурационной Единицы, например, собственная разработка, закуплена у поставщика -X» и т. д.

лицензия

Номер лицензии и ссылка на лицензионное соглашение

Дата поставки

Дата поставки Конфигурационной Единицы ь организацию

Дата приемки

Дата приемки Конфигурационной Единицы в операционную среду

Статус (текущий)

Текущее состояние Конфигурационной Единицы, например, «в тестировании», «в работе», «выведено из операционной среды»

Статус (запланированный)

Следующий планируемый статус Конфигурационной Единицы с указанием даты и требуемых действий

Стоимость

Стоимость приобре|ения Конфигурационной Единицы

Остаточная

Текущая стоимость Конфигурационной Единицы с учетом амортизации амортизационная стоимость

Комментарии

Текстовое поле для комментариев, например, для описания отличий одного варианта от другого

Таблица 6.1. Примеры атрибутов

В зависимости от возможностей используемых инструментальных средств (программного обеспечения) автоматизации Сервис-менеджмента в CMDB включается информация о взаимоотношениях с инцидентами и другие аналогичные им взаимоотношения в виде атрибутов или в какой-либо другой форме.

АТРИБУТ

ОПИСАНИЕ

Номера запросов на изменения (RFC)

Номер (номера) Запросов на изменение (RFC), открытых в настоящий момент или ранее для данной Конфигурационной Единицы

Номера изменений

Номер (номера) изменений, открытых в настоящий момент или ранее для данной Конфигурационной Единицы

Номера проблем

Номер (номера) проблем, открытых в настоящий момент или ранее для данной Конфигурационной Единицы

Номера инцидентов

Номер (номера) инцидентов, связанных с данной Конфигурационной Единицей


Обычно номера соответствующих Конфигурационных Единиц входят в состав регистрационных записей инцидентов, проблем и изменений. Независимо от выбранного подхода должны поддерживаться взаимоотношения между Конфигурационными Единицами и следующими записями (табл. 2).

АТРИБУТ

ОПИСАНИЕ

Взаимоотношения с родительскими

Ключ или номер родительской

Конфигурационными Единицами

Конфигурационной Единицы

Взаимоотношения методу дочерними

Ключ или номер дочерней

Конфигурационными Единицами

Конфигурацион! юй Единицы

Другие взаимоотношения

Взаимоотношения между Конфигурационной Единицей и другими единицами, отличными от родительских и дочерних, например, эта Конфигурационная Единица имеет статус «используется» или «подключена к...»

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

Как уже обсуждалось, поддержка информации о взаимоотношениях между Конфигурационными Единицами является важным аспектом процесса Управления Конфигурациями. В зависимости от типа базы данных эти взаимоотношения могут быть представлены в виде атрибутов С1 или в отдельной таблице.
В некоторых базах данных есть дополнительная возможность для записи изменений содержимого поля, что обеспечивает ведение журнала истории. Это помогает, например, получать информацию о простоях, ремонте, техническом обслуживании по истории состояния поля «Текущий статус», кроме того, это полезно для отслеживания истории владения.
Кроме рассмотренных выше атрибутов, необходимыми являются перечни атрибутов с технической информацией о каждом типе Конфигурационной. Единицы. У каждого типа свои характеристики. Например, для PC это емкость жесткого диска, изготовитель BIOS и версия BIOS, размер оперативной памяти, IP-адрес и т. д. Многие инструменты системного администрирования фиксируют такую информацию, в этом случае достаточно установить связь с типом Конфигурационной Единицы, чтобы избежать дублирования информации. Однако следует помнить, что такие системы предоставляют текущую информацию, не указывая, является ли она результатом реализации утвержденных изменений или же это результат неавторизованных действий.
Для облегчения ввода и обновления атрибутов можно использовать открывающиеся меню1. Можно устанавливать связи и с другими надежными источниками для получения информации о месторасположении Конфигурационной Единицы, пользователях, подразделениях, номерах телефонов, владельцах и параметрах бюджета. Вариантов много, но всегда следует учитывать нагрузку, связанную с поддержкой актуальности этих файлов.
Базисная Конфигурация
Базисная Конфигурация — это мгновенный снимок группы Конфигурационных Единиц, сделанный в определенный момент времени. Базисную Конфигурацию можно использовать в качестве: авторнзованного/поддерживаемого продукта, который можно включить в ИТ-ипфраструктуру (такие Базисные Конфигурации включаются в Каталог Продуктов); стандартных Конфигурационных Единиц для учета информации о стоимости; базы2 при разработке и тестировании новых Конфигураций; для выполнения возврата к исходному состоянию, если возникают проблемы с новой Конфигурацией после проведения изменений; стандарта для поставки Конфигураций пользователям, например, «стандартное рабочее место»; базы при установке нового программного обеспечения.
1 Т. е. меню со списком выбора вариантов — Прим. ред. 8 Starting poinl

Стандартная рабочая станция является типичным примером Базисной Конфигурации. Ограничивая количество разных стандартных рабочих станций, можно облегчить оценку результатов и определение ресурсов, необходимых для реализации новых функций и улучшения их тестирования. Базисные Конфигурации также могут помочь в проведении политики комбинирования и планирования изменений, например, для пакетных релизов. Они способствуют сокращению затрат на Управление и облегчают планирование проектов.
Другим полезным применением Базисной Конфигурации является Каталог Продуктов. В нем даются Сертифицированные Конфигурации, которые можно использовать в И Г-инфраструктуре и которые доступны для заказа пользователями. В этом случае новая Конфигурационная Единица является копией единицы из Каталога с ее номером и меткой.
До того как новая модель или продукт будут добавлены в инфраструктуру, они должны появиться в Каталоге. Для этого нужно принять решения но трем вопросам: Бизнес: отвечает ли модель/нродукт бизнес-интересам пользователя? Финансы: приемлемы ли затраты на поддержку? Влияние: приемлем ли уровень воздействия модели/нродукта на услугу?
Регистрация
Первоначально База данных CMDB наполняется информацией из финансовых систем, записями о существующей ИТ-инфраструктуре, техническими данными от поставщиков. Регистрируется только информация из известных (проверенных) источников. Организация должна быть готова к под держанию этой информации в актуальном состоянии. 
<< | >>
Источник: Ян Ван Бон и др.. ИТ СЕРВИС- МЕНЕДЖМЕНТ. 2003

Еще по теме Веды деятельности:

  1. Глава 30-Д ЗАЯВЛЕНИЯ О ДОСРОЧНОМ ПРЕКРАЩЕНИИ ПОЛНОМОЧИЙ НАРОДНОГО ДЕПУТАТА УКРАИНЫ В СЛУЧАЕ НЕВЫПОЛНЕНИЯ ИМ ТРЕБОВАНИЙ О НЕСОВМЕСТИМОСТИ ДЕПУТАТСКОЙ ДЕЯТЕЛЬНОСТИ С ИНЫМИ ВИДАМИ ДЕЯТЕЛЬНОСТИ
  2. Инструментальная деятельность; I деятельность и практика
  3. Индивидуальные стили педагогической деятельности Психологическое сопровождение индивидуального стиля деятельности педагога
  4. Место психологии в деятельности педагога Проектирование педагогической деятельности. Рефлексивная психология и ее место в деятельности педагога.
  5. Раздел 4. СОЦИАЛЬНАЯ ДЕЯТЕЛЬНОСТЬ, НАПРАВЛЕННАЯ НА ПОДДЕРЖАНИЕ ИЛИ ИЗМЕНЕНИЕ СУЩЕСТВУЮЩЕГО СОЦИАЛЬНОГО ПОРЯДКА (ДЕЯТЕЛЬНОСТЬ ВТОРОГО ТИПА)
  6. 3.2. Муниципальная деятельность и муниципальная политика Общая характеристика муниципальной деятельности
  7. Я. А. ПОНОМАРЕВ. В книге рассматриваются предмет и методы психологии творчества, центральное звено психологического механизма творческой деятельности, способности и качества творческой личности. В ней содержится обширный экспериментальный материал, на основании которого сформулирован ряд психологических закономерностей творческой деятельности и закономерностей формирования благоприятствующих ей условий., 1976
  8. 3. ВИДЫ ДЕЯТЕЛЬНОСТИ
  9. § 3. Лицензирование предпринимательской деятельности
  10. 1.3.1. Управленческая деятельность
  11. СУЩНОСТЬ ДЕЯТЕЛЬНОСТИ
  12. Понятие ведущей деятельности
  13. §8. Мотивация трудовой деятельности
  14. Регламентация управленческой деятельности
  15. §1. ПОНЯТИЕ ПРОФЕССИОНАЛЬНОЙ ДЕЯТЕЛЬНОСТИ
  16. §4. ПСИХОЛОГИЧЕСКАЯ СТРУКТУРА СОВМЕСТНОЙ ДЕЯТЕЛЬНОСТИ