Что такое и зачем нужна CMDB

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Этот пост адресован, скорее, моим коллегам из SMB‑сегмента, потому что в больших компаниях эти вопросы худо‑бедно решены. Как вы знаете, социализм — это учёт и контроль. А коммунизм — это социализм и электрофикация всей страны. Вот так, с наскока, всё в комплексе очень сложно. Давайте попробуем начать с учёта.

Хотя я и порекомендую к использованию программный продукт, в статье не будут рассмотрены этапы его установки и настройки, так как это не сложно. Основная задача — объяснить зачем это надо и как идеологически верно организовать работу с процессом контроля и управления ресурсами компании.

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

Итак, основной целью деятельности коммерческих организаций является извлечение прибыли. Прибыль они извлекают в ходе выполнения тех или иных бизнес‑процессов. Бизнес‑процесс реализуется с помощью неких обеспечивающих сервисов, которые, в свою очередь, предоставляются одной или несколькими автоматизированными системами(АС). Автоматизированные системы состоят из приложений и баз данных, располагающихся на неких виртуальных(или физических) серверах, которые живут на гипервизорах. Гипервизор — это программное обеспечение, он тоже не в вакууме, а установлен на физический сервер. Сервер замонтирован в стойку и подключен к PDU. Стойка стоит в ЦОД. Прослеживаете логическую цепочку? От процесса продажи товара или услуги к железному шкафу в кондиционированном помещении?

Так вот, CMDB, база данных конфигурационных единиц, являясь частью более сложных процессов ITIL, обеспечивает хранение компонентов ИТ‑инфраструктуры, позволяет построить и отобразить взаимосвязи между ними, помогает выстроить процессы управления изменениями и управления сервисными активами и конфигурациями (ну и всеми стальными процессами ITIL тоже). Процессы управления инцидентами, проблемами и другие забавные вещи(SLA, OLA, etc.) мы сейчас трогать не будем, так как это слон такого размера, что его осилить можно только по частям.

Повторюсь, статья предназначена для тех храбрых специалистов, у которых в компании, в силу размера или исторических причин, не ведется учёт оборудования, а проблемы пользователей решаются по звонку. Остальным будет не интересно.

Как говорил профессор Преображенский, — «разруха не в клозетах, а в головах». Админы приходят и уходят, унося с собой крупицы опыта, по тем или иным причинам не оставляя накопленные знания последующим поколениям. Энтропия нарастает без приложения энергии извне и рано или поздно выливается в факап и простой. Для того, чтобы этого избежать и нужна CMDB. Это хранилище знаний о вашей инфраструктуре, о том, в каких бизнес‑процессах инфраструктура задействована и, в конечном итоге, что произойдет, если выдернуть вот тот желтый патчкорд.

Основным элементом CMDB является «конфигурационная единица»(КЕ, CI). Это любая самостоятельная сущность, необходимая для предоставления ИТ‑сервиса. Бизнес‑процесс — это КЕ, сервер, VLAN, рабочая станция, принтер — это всё разные типы КЕ. КЕ могут иметь вложенную структуру, например КЕ полки расширения системы хранения данных может включать в себя КЕ жестких дисков, а в КЕ принтера может быть отдельное КЕ картриджа, но избегайте излишней детализации, так как сопровождение базы будет линейно усложняться с увеличением числа типов КЕ. Каждый тип КЕ имеет свой уникальный набор свойств. Например, КЕ сервера, СХД, принтера, источника бесперебойного питания будут иметь серийный и/или инвентарный номер. У КЕ виртуальной машины серийного номера нет, но есть количество RAM и vCPU.

Так же, CMDB обеспечивает структуру взаимосвязей между КЕ, привязку к КЕ сопровождающих документов и хранит историю изменений КЕ. Например, в КЕ канал связи можно подцепить сканы договоров с провайдером и регулярно подкладывать сканы счетов. Это позволит не бегать, выпучив глаза, в случае какого‑нибудь аудита. По истории изменений можно будет отследить рост потребления ресурсов виртуалки или перемещения рабочей станции между офисами. Структура взаимосвязей позволит видеть к какой СХД принадлежит полка расширения, какое оборудование отключится, если пропадет питание в стойке и какие бизнес‑процессы при этом пострадают.

Даже если вы будете вести базу данных конфигурационных единиц вручную и заставите себя и коллег поддерживать её в актуальном состоянии(а это очень сложно!) вы увидите, насколько упростится ввод в строй новых сотрудников ИТ, инвентаризации станут проходить на позитиве и станет понятно кто пожрал весь хмель все мощности(это уже управление мощностями, нам пока туда рано). Не надо сразу настраивать автоматический сбор всего, до чего руки дотянутся, вы рискуете получить неудобоваримую кашу. Берите по одной АС и описывайте снизу доверху. Так вы получите достоверное описание каждой АС и увязку их с бизнес‑процессами. Заодно ответственных найдёте.

В дальнейшем, логичным шагом развития CMDB будет внедрение(или увязка имеющейся) службы ServiceDesk. Это позволит увязывать запросы на обслуживание или запросы на изменение с конкретными КЕ. Запрос на обслуживание — это заявка, поданная пользователем, например, на установку нового ПО. В качестве КЕ тут будет выступать рабочая станция. Запрос на изменение — это заявка, например, на увеличение памяти в виртуальной машине.

Технических реализаций CMDB довольно много, я могу лишь порекомендовать Combodo iTop. Этот продукт содержит в себе помимо CMDB еще и функционал ServiceDesk, довольно легко устанавливается и кастомизируется. Есть русскоязычное сообщество. Ссылки будут в самом низу статьи.

Но, погодите брать в руки консоль, сперва требуется подготовительная работа. Как известно, тщательное планирование упрощает реализацию. Надо составить карты взаимосвязей.

Пойдём от большого к малому, расписывая состав и взаимосвязи каждого уровня. Напомню, избегайте излишней детализации, так как это кратно усложняет ведение базы. Вы, при необходимости, сможете добавить КЕ и суб‑КЕ позже. Представленная структура не догма, а руководство к действию, мы можете и должны подстраивать схему под себя.

Вот они, основные уровни, самые большие квадраты, которыми можно описать всё взаимодействие бизнеса и ИТ.

Сверху у нас бизнес‑процесс. То, что делает существование организации осмысленным и позволяет производить прибавочную стоимость. Внизу у нас болты и гайки. Посередине — прикладное программное обеспечение и базы данных.

Вот тоже самое, но детальнее, во всей своей внутренней красоте. На схеме отображены КЕ и возможные связи между ними(не все возможные варианты, иначе будут макароны).

Вряд‑ли что‑то тут нуждается в дополнительном разжёвывании. У каждой автоматизированной системы есть(должна быть) продуктивная и тестовая среда, среда разработки, нагрузочного и интеграционного тестирования. А может не есть, это уже по ситуации. У нас есть логические и физические компоненты, соответственно логические и физические связи. Связи могут типов «использует», «содержит», «установлен на». Например, бизнес процесс использует автоматизированную систему, которая содержит сервер приложений, установленный на сервер. За каждый уровень назначен свой ответственный(в зависимости от размера организации). Обратите внимание на то, что экземпляр базы данных — это больше прикладное понятие, а система управления базами данных — инфраструктурное. Тут бесконечное поле для доработок и допиливания под свои нужды.

Плюсы CMDB очевидны. Но, есть проблемы. И проблемы вовсе не технического плана, а психологического и коммуникационного. Человек сам с собой, зачастую, не может договориться, а тут такая сложная техника. Люди ленивы и не хотят тратить время на заполнение, как им кажется, бесполезных бумажек. Люди боятся изменений и поэтому будут всячески отбрыкиваться и говорить, что это не их зона ответственности, что они раньше прекрасно без этого всего жили, да что там писать и так все понятно. Людям требуется время на то, чтобы привыкнуть к новому и поэтому регулярно будут забывать вносить изменения или вносить их неправильно. Как и любое другое дело, в которое вовлечено несколько человек, внедрение CMDB чрезвычайно трудно, вам придется запастись большим количеством внутренней мотивации, но он того стоит.

Ссылки на iTop — скачать, ссылка на документацию, сайт русскоязычного сообщества.

Так же, ссылка на мой ТГ‑канал, там много интересного.

Источник: https://habr.com/ru/articles/787740/


Интересные статьи

Интересные статьи

Сложно найти веб-тестировщика, который не знал бы о DevTools, но еще сложнее найти человека, который знал бы DevTools полностью. Помимо знакомой всем базовой функциональности, есть и множество менее и...
Каждый из нас так или иначе сталкивается с техническими собеседованиями: кто-то их проходит, а кто-то - проводит. И каждый вспомнит удачные и неудачные примеры из своего опыта. Чтобы интервью прошло с...
Несколько ответов на один большой вопрос — есть ли смысл с расшифровке своего генома в 2021 году или это просто пустая трата денег.
Привет! Меня зовут Дмитрий, я тренер по продуктам компании Arenadata и один из преподавателей в онлайн-школе для разработчиков в Open Source COMMoN, в которую сейчас идёт набор. Пока мы готовились к э...
Изображение: Unsplash Мы довольно много пишем о том, какие активы сегодня доступны биржевым инвесторам, в том числе в России. Рассказывали мы и о производных инструментах – фьючерсах и опц...