7 февраля мы провели очередную конференцию CleverDAY. Два из пяти докладов затрагивали тему управления конфигурациями. Один – доклад про сервисную экономику, где решение задачи распределения ИТ-затрат и расчета себестоимости ИТ-услуг опирается на данные CMDB. Второй – про встроенный инструментарий по управлению ресурсами в новой версии CleverENGINE, очень тесно переплетающийся с функциональностью CMDB. А поскольку собралось больше 200 человек, и вопросов было много, конечно, заговорили о том, насколько это экономически целесообразно – поддерживать актуальность данных CMDB, если это требует ручных операций? И конечно сразу появилась потребность в уточнении: а собственно сколько требуется ручных операций для актуализации данных CMDB? Вот с этим давайте и разберемся.
На курсе по управлению конфигурациями мы проводим такое упражнение: проектируем правила учета для фрагмента CMDB, который нужен для обеспечения потребностей какого-то конкретного менеджера. Например, менеджера одной из базовых ИТ-услуг – услуги печати, базового рабочего места или ВКС. Потребности эти самые разные – менеджерам услуг нужны данные для эффективной поддержки пользователей, финансовой отчетности, оперативного управления ресурсами, планирования закупок и так далее. Спроектированную таким образом CMDB мы оцениваем на предмет возможности автоматического обновления из существующих источников данных, причем с учетом возможных доработок. И результат обычно не превышает 50%. То есть даже если доработать имеющиеся discovery-решения и скрипты, около половины данных CMDB можно собрать только вручную.
Тут я вижу, как на задних рядах заволновались представители вендоров ПО. Мол, товарищи. Мол, 21-й век. Мол, современное auto discovery – это совершенно могучая вещь. И все само. И тут много правды – вещь могучая, но все же само не все. Да и не будет все. Например:
- очевидно, некоторая часть атрибутов конфигурационных единиц типа расположения или ответственного пользователя может вестись только вручную или, по крайней мере, частично вручную;
- некоторые виды категорий конфигурационных единиц, таких как неуправляемые серверные шкафы или несетевое офисное оборудование – вручную;
- учет комплектующих и расходных материалов – по большей части вручную;
- учет серверов, дисковых массивов, активного сетевого оборудования до включения в сеть и попадания в лапы inventory и мониторинга – вручную;
- кластерные конфигурации, особенно NLB и проприетарные средства обеспечения отказоустойчивости приложений – по большей части вручную;
- некоторые виды лицензий и фактов их использования, таких как лицензии на подключение клиентов (CAL) – вручную;
- отражение в CMDB прикладных архитектур, особенно в части «некоробочных» приложений – по большей части вручную.
И это не исчерпывающий список, а всего лишь наиболее очевидные примеры. Более того, в реальной жизни даже те данные, которые в принципе подлежат автоматической актуализации, могут требовать ручного учета в силу того, что у компаний таки есть бюджетные ограничения, а средства auto discovery бесплатны пока не все.
И оказывается, если проектировать CMDB под конкретные задачи в конкретной организации, а не под возможности имеющихся на рынке средств auto discovery, да – существенная часть данных потребует ручного учета.
Это лучше осознавать на берегу, до начала проекта внедрения. Поскольку чем раньше вы узнали правду, тем больше ошибок вы можете избежать. И основной акцент в проектировании CMDB все же должен быть на решение задачи, а не на возможности инструментария. Но постойте… Это же и так всем известно, верно?
Интересно, а почему вопрос себестоимости сервиса сводится только к стоимости ресурсов(CI и Assets, я не буду тут углубляться в то, что CI и Assets – это один и тот же объект.)? А как же работы по инцидентам и заявкам в контексте тех же сервисов? Из своего опыта могу сказать, что это достаточно существенная часть затрат на сервис и её не стоит недооценивать.
Ну и с точки возможностей автоматизации перечисленных процессов лично у меня взгляд более оптимистичный. Другое дело, на сколько достаточно дорогие инструменты снижают риски, связанные с тем, что некие атрибуты не будут учитываться. Тут я согласен – стоимость борьбы с рисками не должна превышать стоимость возможных потерь.