Управление конфигурациями - 3

Записаться

1. Два контура работ

В управлении конфигурациями можно выделить два контура.

Автоматизированный контур включает работы, которые выполняются или могут выполняться с помощью автоматизированных средств, например сервера базы данных:

• идентификация;
• хранение текущей информации и истории статусов;
• мониторинг статуса;
• отчётность и предоставление данных другим процессам.

Организационный контур включает работы, которые нельзя свести только к информационным технологиям:

• планирование;
• контроль;
• верификация;
• определение смысла, границ и ответственности.

2. Идентификация и конфигурационная база данных

Идентификация поддерживает конфигурационную базу данных (CMDB, Configuration Management Database) в актуальном состоянии. В неё входит разработка модели данных:

• определение структуры базы;
• определение связей между компонентами;
• определение владельца или ответственного лица для конфигурационной единицы (CI, Configuration Item) или их группы;
• фиксация связи между единицей и владельцем в модели данных.

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

3. Планирование управления конфигурациями

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

Задачи процесса, сфера действия и приоритеты должны соответствовать бизнес-целям организации. Это не просто описание бизнес-процесса. Осмысленность управления конфигурациями — вопрос бизнеса, а не только ИТ.

Область действия процесса, объём конфигурационных единиц, глубина описания и состав атрибутов — это бизнес-понятия. Они описывают реальные объекты, и кто-то должен отвечать за то, что описание соответствует работе организации и её целям. Это творческая и, по сути, неформализуемая задача. Если её убрать, процесс теряет смысл.

4. Контроль

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

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

Так возникает дополнительное организационное поле контроля: чисто организационные меры обеспечивают корректность информации в базе данных.

5. Верификация

Верификация КБД проводится путём аудита ИТ-инфраструктуры:

• проверяется наличие зарегистрированных конфигурационных единиц;
• проверяется правильность регистрационных записей.

Это аналог инвентаризации на складе. Даже если информационная система описывает все поступления и списания, нужно закрыть склад, пересчитать объекты и убедиться, что данные соответствуют реальности.

Соответствия часто не будет: кто-то внёс объект без первичного документа, кто-то списал его без оформления. Это неизбежные ошибки или небрежность людей. Поэтому нельзя полагаться только на информационные технологии, если нужна достоверная КБД.

6. Степень детализации и атрибуты конфигурационной единицы

Здесь нет универсальных решений. Когда описывается структура данных для внешнего объекта, заранее неизвестно, какие атрибуты и свойства важны в первую очередь.

Пример со справочником клиентов:

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

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

7. Глубина КБД и иерархия

ITIL не предписывает конкретную модель данных. Но есть объективная иерархия конфигурационных единиц и связи между ними.

Например, услуга как конфигурационная единица использует:

• приложения;
• аппаратуру;
• услуги третьих сторон и внешних поставщиков;
• программное обеспечение.

Программное обеспечение можно описать как систему целиком или детализировать до функциональных модулей. Аппаратную часть можно описать как программно-технический комплекс или перечислить серверы, дисковые хранилища, маршрутизаторы и более мелкие компоненты.

Выбор зависит от задач. Если при проблеме достаточно отправить запрос вендору, можно ограничиться верхним уровнем. Если вендор просит указать конкретный модуль, плату или типовой элемент замены, нужна более глубокая детализация. Рекомендаций по глубине нет, потому что она определяется организацией работы.

8. Владелец

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

Информационные технологии помогают поддерживать корректность данных, но лучше, когда есть персональная ответственность за определённые качества конфигурационных единиц. Речь идёт о качествах, нарушение которых связано с большими затратами или рисками для организации.

Такой управленческий подход означает, что самые ответственные свойства контролируют люди, а не только программное обеспечение. Ручной контроль и аудит необходимы. Корпоративный процесс управления изменениями тоже может содержать ошибки, поэтому нет смысла контролировать одни процессы только через другие. Надёжная точка контроля — человек.

9. Базисная конфигурация

Базисная конфигурация (baseline) — это мгновенный снимок группы конфигурационных единиц, сделанный в определённый момент времени. Такой снимок нужен, потому что группа имеет содержательный смысл.

Это не просто набор программных или аппаратных компонентов, а модель реально существующего объекта.

Примеры применения:

• каталог продуктов или услуг организации;
• описание услуги вместе с соглашением об уровне обслуживания (SLA, Service Level Agreement) и документами;
• учёт информации о стоимости или себестоимости услуги;
• исходная точка при разработке и тестировании новых конфигураций;
• возврат к исходному состоянию при проблемах с новой конфигурацией.

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

Другой пример — стандартная рабочая станция. Если организация решила заменять её целиком, то базисная конфигурация фиксирует, что именно входит в стандартную рабочую станцию и что заменяется.

10. Мониторинг статуса и отчётность

Статус конфигурационной единицы нужно контролировать во времени. Набор статусов зависит от потребностей организации. Отчётность предоставляет информацию другим процессам, руководству и владельцам процессов.

Краткие итоги

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