Что не так с CMDB
Чарльз Бетц (Charles Betz) недавно опубликовал статью с броским заголовком — «CMDB мертва — да здравствует граф управления ИТ» (The CMDB Is Dead — Long Live the IT Management Graph).
Среди прочего в ней есть полезные наблюдения о причинах, по которым проекты по внедрению CMDB часто заканчиваются неудачей. Одна из них — неверное понимание самой концепции.
Термин CMDB появился ещё в ITIL v1 (1990) и был заимствован из военной и аэрокосмической практики управления конфигурациями. В то время подход казался логичным, но оказался плохо приспособленным к динамичной, распределённой, программно управляемой природе современного ИТ.
Само название — Configuration Management Database — породило иллюзию, будто CMDB может хранить и управлять всеми конфигурационными данными. Это заблуждение породило нереалистичные ожидания: аудиторы считали, что владелец CMDB отвечает за безопасность серверов, руководители — что через неё можно управлять настройками сетевых карт. На деле CMDB не предназначена для управления быстро меняющимися параметрами и не может служить источником оперативной технической информации.
Инженеры справедливо игнорируют подобные системы, предпочитая получать данные напрямую (подключаясь непосредственно к объектам управления), в реальном времени, а не данные когда-то сохранённые в системе.
Тем не менее многие организации до сих пор воспринимают CMDB как универсальное хранилище всей ИТ-информации и строят вокруг этого заведомо неработающие практики.
Бетц утверждает, что одна из причин путаницы — неудачное название, которое читается слишком буквально как «база данных по управлению конфигурациями». В реальности же речь должна идти не о хранении конфигураций, а об управлении данными и связями между объектами.
В статье автор предлагает отказаться от термина CMDB в пользу «графа управления ИТ» (IT Management Graph). Что по его мнению лучше подходит для описания сложных взаимосвязей между системами, услугами и бизнес-функциями.
В качестве примера другой неудачной терминологической находки Бетц вспоминает роль Product Owner в Scrum — название, которое породило недопонимание и иерархические парадоксым (почему владелец продукта подчиняется менеджеру продукта, ведь «владелец» — более весомо, чем «менеджер»?). Этот пример подчёркивает один из его тезисов: точность терминов напрямую влияет на эффективность практик.