Управление конфигурациями и КБД
Управление конфигурациями (Configuration Management) в ITIL описывает работу с КБД — конфигурационной базой данных (CMDB, Configuration Management Database). Это централизованный справочник, который должен существовать и использоваться процессами управления уровнем услуг.
Что может идти не так? На уровне здравого смысла возможны две крайности:
- неправильно определён охват КБД: в ней нет нужных данных или есть лишние, которые там совершенно не нужны;
- неверно выбран уровень детализации конфигурационной единицы: либо данных для конкретного процесса не хватает, либо их слишком много, и никто ими не пользуется.
Как описан процесс
Процесс описан на верхнем уровне — только его взаимодействие с другими процессами управления уровнем услуг. На инструментальном уровне сказано, что любой процесс управления уровнем услуг может сформировать запрос и получить информацию, особенно если работает автоматизированная система управления базами данных. Но какой именно запрос, как он будет обрабатываться — неизвестно.
Идея процесса проста: существует централизованный справочник. Формат справочника не определён. Фактически утверждается только факт его существования. Справочник должен быть, и его нельзя реализовывать только автоматическими средствами. Нужно обязательно предусматривать участие людей во всех операциях, которые меняют справочник или читают из него.
Часть задач процесса совпадает с обычными функциями СУБД (система управления базами данных; DBMS). Остальные задачи — планирование, контроль, верификация — типичны для управления любым достаточно сложным справочником. Специфична для ИТ-услуг только связь между услугой и конфигурационными единицами, которые нужны для её предоставления. В остальном есть объекты, они как-то связаны между собой.
Аналогия со спецификацией (BOM)
Авторы, возможно явно или неявно, построили конструкцию, близкую к стандарту управления производством MRP (Material Requirements Planning, планирование материальных ресурсов). В этом стандарте говорится: на любом дискретном производстве, включая производство услуг, должен существовать объект BOM (Bill of Materials, спецификация состава изделия) и специальный процесс управления им.
Спецификация — это иерархическое описание продукта. Для материального продукта, например телевизора, в спецификации указаны основные узлы и разузловка до уровня, достаточного для планирования, мониторинга и закупки компонентов. Если завод что-то производит сам, а что-то покупает, всё это описывается иерархической структурой. Это типичный BOM.
По аналогии КБД задаёт спецификации услуг. Идея апробирована и не вызывает сомнений. Она выглядит естественно.
Качество данных и дублирование ПО
Процесс не затрагивает вопросов качества информации в справочнике. Он не описывает метаданные, бизнес-словари, мастер-данные и другие сложные понятия, нужные для обеспечения качества данных. Причина проста: во времена разработки ITIL v2 про качество данных почти ничего не знали. Сейчас эта деятельность существует, но выдающихся успехов пока нет. Это передний край современной бизнес-информатики.
Поэтому нужно иметь в виду: одна КБД без дополнительных инструментов не решает всех проблем.
Пример. Есть стандарт на приобретение программного продукта. Для одной задачи выбрали и закупили ПО, оно присутствует в конфигурационной базе и используется в бизнес-процессе. Другая группа людей решает другую задачу, у них свой программный продукт, который тоже закупается, используется и присутствует в КБД. Но есть третий продукт, который объединяет функциональность первого и второго. Им можно было бы обойтись одним, оказывая услуги обеим группам заказчиков. Однако требования пришли в разное время разным людям, задачи решались разными коллективами. Получилось два продукта вместо одного.
Это не очень хорошо: возможно, за два продукта платят дороже, чем за один. С другой стороны, объединённый продукт может быть менее удобен отдельным пользователям, чем индивидуальные решения. Кто-то должен разбираться в этих вопросах, время от времени просматривать информацию в конфигурационной базе и принимать решения. Кто это делает, из каких соображений и когда — в ITIL не говорится. Требовать этого от авторов ITIL было бы неправильно.
На этом рассмотрение ITIL заканчивается, хотя говорить о нём можно долго. Остаётся ещё 8 процессов и Service Desk.
Краткие итоги
Управление конфигурациями в ITIL строится вокруг централизованного справочника, но его ценность определяется не самим фактом существования, а качеством границ. Охват и детализация — два ключевых параметра, которые напрямую влияют на применимость КБД. Если справочник включает лишние объекты, процессы тратят ресурсы на поддержание нерелевантных данных. Если в нём отсутствуют нужные сведения, процессы не могут получить основу для решений. Слишком высокий уровень описания лишает исполнителей конкретики, а слишком глубокий создаёт информационный шум, которым никто не пользуется. Поэтому практическая настройка управления конфигурациями начинается с ответа на вопрос, какие процессы и какие решения будут опираться на КБД.
Описание процесса в ITIL намеренно оставляет свободу: формат справочника, конкретные запросы и порядок обработки не заданы. Это означает, что организация должна сама определить регламенты, роли и интерфейсы. Автоматизация полезна, но не заменяет человеческое участие. Люди нужны там, где справочник меняется или используется для выводов. Без этого даже технически совершенная база остаётся набором записей.
Аналогия со спецификацией состава изделия помогает увидеть в КБД не просто реестр, а иерархическую модель услуг. Спецификация описывает продукт до уровня, достаточного для планирования, мониторинга и закупки. Для услуг это означает необходимость декомпозиции до practically значимого уровня. Если декомпозиция не связана с управлением уровнем услуг, она теряет смысл. Если связана, КБД становится инструментом согласования целей, ресурсов и ответственности.
Отдельный практический вывод касается качества данных. Процесс управления конфигурациями сам по себе не обеспечивает достоверность, полноту и однозначность записей. Метаданные, бизнес-словари и мастер-данные находятся за его рамками. Организация, которая внедряет КБД без этих механизмов, рискует получить дубли, противоречия и устаревшие сведения. Пример с дублированием программных продуктов показывает, как разрозненные решения, принятые в разное время разными коллективами, приводят к избыточным затратам. Кто-то должен периодически анализировать конфигурационную информацию и принимать управленческие решения. В ITIL этот вопрос не раскрыт, поэтому его нужно закрывать на уровне организации.
Практическое применение идей требует управленческой воли. Нужно назначить владельца КБД, определить правила включения объектов, установить периодический пересмотр, связать справочник с качеством данных и избегать автоматического подхода без человека. Тогда управление конфигурациями перестаёт быть формальным реестром и становится основой для прозрачных решений по услугам, компонентам и затратам.
Управление конфигурациями (Configuration Management) в ITIL работает с КБД — конфигурационной базой данных (CMDB). Это централизованный справочник. Он должен существовать и использоваться процессами управления уровнем услуг.
Основные проблемы:
- неверный охват КБД: нет нужных данных или есть лишние;
- неверный уровень детализации конфигурационной единицы: данных либо не хватает, либо слишком много и ими никто не пользуется.
Процесс описан на верхнем уровне. Показано только взаимодействие с управлением уровнем услуг. На инструментальном уровне сказано, что любой процесс может сформировать запрос и получить информацию, особенно при автоматизированной системе управления базами данных. Но какой именно запрос и как он обрабатывается — неизвестно.
Идея проста: есть централизованный справочник. Его формат не определён. Утверждается только факт существования. Справочник нельзя реализовывать только автоматическими средствами. Нужно участие людей во всех операциях изменения и чтения.
Часть задач совпадает с обычными функциями СУБД. Остальные — планирование, контроль, верификация — типичны для сложного справочника. Специфична для ИТ-услуг связь услуги и конфигурационных единиц, нужных для её предоставления.
Конструкция близка к стандарту MRP. В нём для дискретного производства, включая услуги, есть объект BOM — спецификация состава изделия. Спецификация — иерархическое описание продукта. Для телевизора это узлы и разузловка до уровня, достаточного для планирования, мониторинга и закупки. По аналогии КБД задаёт спецификации услуг.
Процесс не затрагивает качество информации: метаданные, бизнес-словари, мастер-данные. Во времена ITIL v2 про это почти не знали. Сейчас это передний край, но одна КБД без дополнительных инструментов не решает проблем.
Пример дублирования ПО. Одна группа закупила продукт для своей задачи, другая — для своей. Оба есть в КБД. Но существует третий продукт, объединяющий функциональность. Им можно было бы обойтись одним. Требования пришли в разное время разным людям, задачи решали разные коллективы. Получилось два продукта вместо одного. Возможно, дороже. Но индивидуальные продукты могут быть удобнее. Кто-то должен просматривать КБД и принимать решения. Кто, когда и из каких соображений — в ITIL не сказано.
Остаётся ещё 8 процессов и Service Desk.
1. Центральный элемент управления конфигурациями — КБД как централизованный справочник.
2. Неверный охват КБД приводит к отсутствию нужных данных или наличию лишних.
3. Слишком высокий уровень детализации не даёт процессам нужной информации.
4. Слишком глубокий уровень создаёт массу данных, которыми никто не пользуется.
5. Формат справочника, конкретные запросы и порядок работы в ITIL не определены.
6. Справочник не должен реализовываться только автоматическими средствами.
7. Участие людей необходимо во всех операциях изменения и чтения справочника.
8. Часть задач управления конфигурациями совпадает с функциями СУБД.
9. Специфична для ИТ-услуг связь услуги с конфигурационными единицами.
10. Конструкция близка к BOM в MRP: КБД задаёт спецификации услуг.
11. Качество данных, метаданные и мастер-данные не входят в процесс.
12. Дублирование ПО возникает из-за разрозненных решений разных коллективов.
1. Почему централизованный справочник сам по себе не гарантирует эффективного управления конфигурациями?
2. Какие проблемы возникают при неверном охвате КБД?
3. Чем опасен слишком высокий уровень детализации конфигурационной единицы?
4. Чем опасен слишком глубокий уровень детализации?
5. Что именно не определено в описании процесса управления конфигурациями?
6. Почему справочник не должен быть полностью автоматическим?
7. Какие задачи процесса совпадают с обычными функциями СУБД?
8. Какие задачи типичны для управления сложным справочником?
9. Что специфично для управления конфигурациями в ИТ-услугах?
10. Как аналогия с BOM помогает понять назначение КБД?
11. Почему качество данных осталось за рамками процесса?
12. Как пример с дублированием ПО показывает необходимость управленческих решений?
