Наверное, я один из немногих читателей книжки Роба Ингланда «Овладевая ITIL», которым эта книжка не нравится. Не нравится не потому, что я не согласен с приводимыми автором фактами и выводами. Наоборот, с большинством суждений о роли, месте и истинных мотивах популяризаторов ITSM я согласен. Мне не нравится подход IT sceptic-а. На протяжении всей книжки автор пишет о том, что построение ИТ-сервисов в соответствии с ITIL это очень дорого не всегда нужно, и потому предлагает действовать более прагматично. В одном направлении немножко поработать с процессами, в другом – немножко, вот всем и станет немного лучше.
Собственно ИТ-отделы организаций всю жизнь этим и занимались без всякого ITIL. В одном месте придумают каталог ИТ услуг, в другом месте наладят управление изменениями, в третьем простроят процесс управления инцидентами. С некоторыми подразделениями подпишут SLA, с другими о чем-нибудь договорятся на словах и т.д. В результате мы получаем большой набор слабосвязанных друг с другом процессов. Казалось бы CMDB должна все это связать воедино. Но современные CMDB с такой задачей плохо справляются.
Один из разделов книжки так и называется «CMDB не бывает». В нем автор предлагает жить без CMDB, т.к. во-первых, CMBD – это очень дорого, а во-вторых, она не решает возложенных на неё задач. Посмотрел бы я, например, на оператора связи, которому предложили бы жить без систем inventory или на торговое предприятие, которому предложи ли бы отказаться от складского учета: — Все равно же будут проблемы, а потом еще и инвентаризацию понадобиться проводить, зачем вам всё это?
CMDB не бывает по очень простой причине. Её пока никто толком не написал. Самописные CMDB, разработанные айтишниками на коленке, вполне справляются с возложенными на них задачами. Но затем появляются вендоры, приносят «промышленные решения» и тут с идеей централизованного учета и управления ИТ-активами начинаются проблемы. Это не значит, что сама идея не верна. Может лучше пристальней приглядеться к инструменту, которым мы пытаемся эту идею реализовать.
А вот инструмент, действительно имеет явные ограничения. Во-первых, ограничения логические, а во-вторых ограничения технологические. Ограничения логические заложены в той структуре данных (или её отсутствии), о которых я написал в заметке Почему ИТ-сервисы должны базироваться на архитектуре. Проще говоря, в ITIL нет референсной модели данных, четко определяющий отношения между основными понятиями. Т.е. нет однозначности в понимании связей между конфигурационными единицами(CI), change-ами, релизами, сервисами. Нам предлагается связывать эти понятия между собой в меру своего разумения (см. Релизы и версии)
Технологическая проблема CMDB в том, что реализуются они в технологиях прошлого века, т.е. в виде монолитных приложений. О таких словах как Enterprise 2.0 (см. Enterprise 2.0 для чайников) среди сервисменов похоже никто и не слышал. Казалось бы интернет давно должен быть завален статьями с заголовками типа «CMDB 2.0 : Freeform, Social, Emergent Platforms for Collaboration and Knowledge Sharing». Я не хочу повторять слова, написанные в статьях Почему Интранет должен стать 2.0 и Почему архитектура нуждается в социальном ПО, лишь отмечу, что ключевым словом в системах работы с контентом является Emergent. Т.е. ваша система должна уметь наращивать контент. Контент, как создаваемый непосредственно людьми, так и новыми приложениями, надстраиваемыми над CMDB. Вдохновение следует черпать в приложениях, поддерживающих социальные сети.
Одним словом, стоит ли спешить с категоричными фразами: «CMDB не бывает»? Не лучше ли закрутить еще один виток взаимного обогащения процессов и технологий
Продолжение: Правильные CMDB существуют. По крайней мере, в виде идей см. Service Knowledge Management System