configuration identification

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

Частая ошибка — воспринимать идентификацию конфигурации как разовую инвентаризацию. На практике это непрерывная дисциплина: КЕ появляются, изменяются, выводятся из эксплуатации, и без устойчивого механизма идентификации CMDB быстро теряет доверие. Ещё одно типичное заблуждение — сводить задачу к «присвоению номера» активу. Маркировка КЕ важна, но не менее важны правила, позволяющие однозначно сопоставлять физический или логический объект с записью о конфигурации, включая обработку дублей, переименований и миграций. Идентификацию конфигурации также путают с управлением ИТ-активами: ИТ-активы ориентированы на финансовый и жизненный цикл владения, тогда как КЕ ориентированы на управление услугами и зависимостями, влияющими на ценность, гарантию и полезность услуги. Ошибка проектирования — пытаться занести в CMDB «всё подряд» без критерия ценности: это приводит к высокой стоимости сопровождения и низкому качеству данных. Практически полезнее начать с КЕ, влияющих на ключевые услуги, крупные инциденты и изменения, и обеспечить качество связей; иначе анализ влияния будет формальным и вводящим в заблуждение.