Важно, чтобы те, кто работают с ITIL, понимали разницу между процессом управления конфигурациями и инструментом CMDB. Вам нужен процесс. Так или иначе вы уже управляете конфигурациями: люди держат нужные данные в головах, в таблицах, в разрозненных базах, в разных системах.
Важно определить, какой уровень зрелости управления конфигурациями нужен вашей организации, и насколько важно иметь доступ к данным о конфигурациях, и как быстро нужно его получать.
Только тогда станет понятно, нужна ли вам CMDB.
Вероятно, любая компания, сумевшая построить работающую CMDB (это удается не всем), получит от этой CMDB пользу. Вопрос лишь в том, оправдывает ли эта польза затраты (часто не оправдывает) и является ли это лучшим доступным способом потратить ресурсы (обычно не является). Лишь для тех немногих компаний, в которых инфраструктура чрезвычайно сложна, а требования к срочности предоставления информации чрезвычайно высоки, CMDB оправдывает себя.
CMDB - ответ на желание любого технаря найти техническое лекарство от культурных и организационных болезней. К сожалению, процессы невозможно исправить технологиями. Скептик совершенно серьёзно предлагает иной подход
к централизации и актуализации конфигурационных данных: собирайте их по мере появления потребности.
Не надо держать все данные в одном месте постоянно, собирайте их по запросу.
В этой идее нет ничего нового, мы и так делаем это. Если данных нет, а они нужны для, скажем, подготовки отчёта начальству, мы собираем их, вычищаем и готовим отчёт.
А если бы у нас был эксперт (или несколько) по сбору необходимой информации в ответ на поступающие запросы? С формализованными процедурами получения, проверки, обработки данных. С инструментарием и навыками его использования. Большинство таких экспертов имело бы в головах CMDB: они знали бы, где и у кого получить нужную информацию. Вместо любительского судорожного поиска информации мы могли бы иметь профессиональный и осуществляемый в рамках формализованного процесса.
Эти люди должны обладать базовыми навыками статистического анализа. В ответ на запрос руководства о, например, распределении инцидентов по категориям они должны суметь получить выборку инцидентов, классифицировать их в соответствии с запросом (говоря начистоту, часто ли имеющаяся классификация достаточна для ответа на очередную фантазию руководителей?), сформировать и предоставить отчёт.
И должна быть дежурная команда на случай крупных инцидентов: «В серверной произошла авария и такие-то серверы остановлены. Какие услуги пострадали вследствие этого события, и кого из пользователей нам придется вызвать на работу в субботу?» Возможно, ответ не найдётся сразу, но эти люди лучше прочих знают, где и как его искать и сколько времени займут поиски.
Разумеется, нам понадобится простейшая постоянно действующая CMDB. Там будет та информация, которую мы уже умеем собирать автоматически: данные о закупках, об активном сетевом оборудовании, о рабочих станциях... плюс та информация, которую мы собираем (или стараемся собирать) на бумаге - записи об изменениях, каталог услуг, списки телефонов, контракты...
Экономия на не-построении идеальной CMDB может быть колоссальной. Плата за эту экономию.
- то, что нужная информация не будет получена нами мгновенно. Возможно, для её получения понадобятся часы, возможно - дни. Следовательно, нужно провести анализ того, насколько актуальные данные нам нужны. Найдутся организации,.
которым придется пройти непростой путь создания и поддержания CMDB. Но большинству это не необходимо.
Рекомендации.
79.
Ограничьте охват управления конфигурациями.
80.
Если вы - часть большинства (не NASA, Boeing, EDS или Tata), вам не нужна CMDB.
81.
Заведите «CMDB по имени Сью
»: одного или двух живых человек, знающих, как всё устроено, и способных анализировать это.
82.
Лучше использовать готовые коробочные решения для CMDB, пусть неидеальные, чем разрабатывать идеальную CMDB самостоятельно.
83.
Если вы уверены, что CMDB нужна - пусть она будет частью системы Service Desk.
Не занимайтесь интеграцией, пусть её сделают другие.
84.
Пресекайте попытки построить идеальную книжную CMDB, если только вы не огромная организация с завышенными стандартами, жёсткими требованиями и бездонными карманами.
85.
Если потребность в CMDB в самом деле есть, не возлагайте заботы о поддержании её актуальности на одну выделенную группу. Сделайте это частью ежедневной работы тех, кто управляет предоставлением и поддержкой услуг, и не забудьте учесть эту работу в системе мотивации. Тем не менее, владение всей CMDB должен осуществлять кто-то один.
86.
Если CMDB не нужна, сосредоточьтесь на конфигурации сети («что с чем соединено»), данных об активах («что есть что») и инвентаризации устройств («что на чём работает»).
87.
Рассмотрите возможность организовать команду для формирования конфигурационной информации по запросу.