Создание CMDB: некоторыми секретами делится Крис Кингсбери (Консультант по вопросам предоставления услуг в CGI IT UK Limited)
Крис Кингсбери работал со многими организациями, которые начинали путешествие по созданию идеальной базы данных управления конфигурациями (CMDB): единой структуры, содержащей все, что они когда-либо хотели знать о своем бизнесе, услугах, ИТ-оборудовании, статусах, финансах, проектах. Это может показаться пугающим опытом, и, хотя амбиции могут казаться восхитительными, сам масштаб задачи часто отталкивает многих от инвестиций и усилий, необходимых для решения такой грандиозной задачи.
Работая в этой области уже много лет, Крис хотел бы поделиться некоторыми из своих ключевых принципов и отправных точек для создания функциональной и полезной CMDB, которая может становиться более зрелой благодаря стандартным методам ведения бизнеса и постоянному совершенствованию услуг.
Поймите ваш охват
Многие, начиная контролировать свои конфигурационные единицы (КЕ), в итоге оказываются в растерянности и в состоянии “тумана в голове” от переизбытка данных. Пытаясь одним махом взять под контроль все имеющиеся данные, легко оказаться обескураженным или подавленным масштабами задачи. Именно поэтому важно на раннем этапе определить очень конкретный (а в идеале – ограниченный) охват базы данных. Тщательное управление процессом внедрения может помочь гарантировать, что первичная информация, с которой CMDB начинает работать, будет точная и достоверная, что в конечном счете позволит другим увидеть перспективы и преимущества, которые могут принести надежные данные, и побудит их вкладываться в помощь по достижению общего замысла.
Вначале рекомендую сосредоточиться на вещах, которые можно легко проверить. Инструменты обнаружения, приносят огромную пользу, поскольку они могут идентифицировать устройства, которые регулярно подключаются к вашей сети, и быстро и эффективно предложить большое количество атрибутов и характеристик КЕ. Кроме того, отслеживая то, что регулярно подключается к сети, вы можете выделить устройства в вашей CMDB, которые, возможно, перестали автоматически обнаруживаться, проактивно определяя потенциальные проблемы в сети или даже выявляя неконтролируемые изменения. Инструменты обнаружения также могут выявлять взаимосвязи между конфигурационными единицами, что будет очень полезно, когда CMDB будет развиваться и вы начнете думать о картировании услуг.
Используйте CMS
Не забывайте о принципе ITIL касательно системы управления конфигурациями (CMS). ITIL описывает CMS как набор инструментов и баз данных, которые используются для поддержки сервисных активов и управления конфигурационными данными поставщика ИТ-услуг. Это означает, что нам не обязательно вносить в нашу CMDB данные, которые являются частью CMS, особенно если эти данные будут более точными или отображаться в режиме реального времени в случае хранения в исходном источнике данных. Информация о доступной памяти или IP-адресе в динамической среде может фактически снижать вашу уверенность в точности данных в вашей CMDB, если она не согласуется с другими элементами вашей CMS.
Сохраняйте простоту
Польза от CMDB в вашей организации должна состоять в том, что она помогает описывать вашу техническую среду относительно простым способом. Именно поэтому важно убедиться, что в ней используются простые и понятные термины и ссылки. Делая имеющуюся информацию доступной как для технических, так и для нетехнических пользователей, CMDB помогает вашей организации достичь общего языка, что и является ключевой целью CMDB. Это еще одна причина начать с малого и со временем увеличивать степень покрытия CMDB и ее охват.
Подумайте о входах и выходах
Одним из заключительных соображений при определении того, как построить и что поместить в вашу CMDB, является размышление о том, что вы хотите от нее получить. Если включение в базу конкретного показателя не приносит никакой пользы, и вы делаете это только ради тщеславия, то зачем это делать? Работая с ключевыми заинтересованными сторонами CMDB, вы можете сосредоточиться на активном поиске типов и атрибутов КЕ, имеющих отношение к вашему бизнесу, и это гарантирует, что усилия и пропускная способность не будут потрачены впустую на сбор данных, которые не будут активно использоваться.
Сосредоточение внимания на выходах также может помочь вернуться к вопросу о входах. Если заинтересованные стороны требуют от CMDB определенного результата, то в рамках оценки воздействия мы можем задать вопросы “Как мы зафиксируем данные?” и “Как это будет поддерживаться?”. Может оказаться, что запрос необоснован или нереален, и привлечение заинтересованных сторон к нашему путешествию по созданию CMDB и процессу принятия решений приведет бизнес к общей цели в отношении управления данными и конфигурациями.
Поддержка изменений в динамичной среде, планирование и обеспечение доступности релизов, развёртывание услуг, подтверждение и тестирование, обеспечение накопления и актуализации информации о конфигурации услуг и ИТ-активах и много другое на нашем популярном курсе VAP: Управление изменениями и конфигурациями в ИТ (CMDB)
Следующие шаги к CMDB
Приведенные выше рекомендации являются хорошей отправной точкой для вашего проекта CMDB. После того, как определен начальный объем данных, понятны отношения между CMDB и CMS, выбраны соответствующие входы и выходы, а также продуманы язык и коммуникация в организации, вы сможете начать работу над реализацией.
Следующие этапы могут включать в себя привлечение нужных заинтересованных сторон, позиционирование CMDB в рамках практик и процессов более широкой ИТ- и бизнес-среды, а также определение потенциальных препятствий в процессе перехода.