О том как вендоры и аналитики победили ITIL

Наверное, я один из немногих читателей книжки Роба Ингланда «Овладевая 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

О том как вендоры и аналитики победили ITIL: 4 комментария

  1. Я как раз размышляю над тем, как в ACM системах иметь модель продукта (product/design model) — а модель продукта существенно связана с его модульностью и изменчивостью, т.е. с управлением конфигурацией/изменениями. Это хоть как-то обсуждается у айтишников, но сильно меньше у железячников — а задачку-то хочется решать в каком-то общем виде (даже в случае IT-решения там ведь есть и обработка данных, и оборудование). Так что часть про отсутствие внятной онтологии рассмотрения системной иерархии как модулей/конфигурационных единиц я бы поддержал всецело: без этого никакой связки с моделью проекта (project/development process model) не получится.

    Про изменение же рассмотрения процессов и архитектур, отражающих эти самые плохо моделируемые emergent особености, я нарыл прелюбопытную табличку. См. http://ailev.livejournal.com/971288.html

    1. Не знаю, совпадение это или тенденция, но меня последние два месяца терзают вопросом: как нам увидеть наших клиентов и нашу сеть из системы управления инцидентами. Т.к. речь идет не только о корпоративных клиентах, но и о домашнем Интернете, то клиентов уже даже не сотни тысяч. Сетевых сущностей — тоже очень много и размазаны они по десятку учетных систем. Идея о том, чтоб загрузить это все в одну большую базу данных как-то уже не срабатывает.

      Одним словом, похоже, в новом году ждет меня веб-ориентированная архитектура со всеми своими нюансами.
      За ссылку спасибо, табличка, действительно, прелюбопытная

  2. Завершенное внедрение CMDB является одним из важных качественных показателей зрелости процессов IT-подразделения. Там, где процессы не обладают необходимым уровнем зрелости, а руководство не имеет желания или возможности их совершенствовать, CMDB действительно не бывает.

    С другой стороны, процессы Help Desk будут работать и без CMDB. Да, они будут менее эффективными, но вполне работоспособными. Это одна из причин, почему внедрение процессов ITIL после Incident Management и Problem Management может надолго забуксовать.

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

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

    1. Павел, так многие ИТ-компании так и работают. Зарегистрировали инцидент, как-то проклассифицировали (заставили пользователя это сделать), назначили на кого-нибудь и ждут. Либо сам решиться, ну или в крайнем случае в проблему перерастет. Или же решили, закрыли забыли. Какое там накопление знаний, даже разработчика не проинформировали.

      А адекватные аналитик, конечно, нужны. Нужны, не для того чтоб книжки писать, а ту же референсную модель нарисовать; предложить средства интеграции разрозненных процессов и данных; рассказать, что CMDB — мастер данные и предложить поизучать тему MDM, а инциденты и данные мониторинга завернуть в activity streams…

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *