Портал №1 по управлению цифровыми
и информационными технологиями

Вопрос из зала. Управление конфигурациями (CMDB)

Опубликовано 11 марта
Рубрики: Вопрос из зала
Комментарии

В редакцию портала поступил вопрос:

Добрый день, вопрос про управление конфигурациями, CMDB.
У нас в ИТ департаменте работает CMDB, внедрена система, ведется учет различных нужных нам CI, есть минимальный доступ для всех сотрудников компании, чтобы они могли смотреть свое оборудование и некоторую другую информацию.

И вот эта система стала предметом интересов со стороны других департментов. Например, кому-то нужно управлять какими-то данными и как раз таки наша система очень хорошо им подходит. Система позволяет гибко разделять доступы для разных департаментов, ролей – это не проблема, но администрировать ее можно только в ИТ. То есть на выходе мы можем получить одну систему, которая настраивается и администрируется в ИТ, но в ней живут классы объектов (CI), которые управляются как ИТ департаментом (сервисы, оборудование, софт, сервера и т.д.), так и другими департаментами (какие то продукты, реестры с информацией не ИТ). Какие риски можно отметить в таком подходе?

Комментариев: 4

  • Арсентьева Лилия

    1. Риски влияния изменений, которые потребуются, например, для ИТ, но будут противопоказаны для остальных подразделений компании.
    2. Риски отказоустойчивость: если рухнет ИТ часть, то рухнет всё. Можно его минимизировать через особенность инсталляции, наверно.
    3. Рост расходов на поддержку системы (добавились пользователи), которая автоматизирует cmdb.

    Обычно спрашиваю бизнес, какую задачу они хотят решить (им точно нужен свой вариант cmdb для ее решения)?

  • Руслан

    Большие трудозатраты на внесение изменений. Постоянный диалог иди даже трения с командами по поводу структуры данных (CI) их их взаимосвязей. Особенно чувствительно это будет с командами, которые плохо понимают в CMDB. В общем каждая из команд захочет построить свою собственную уникальную CMDB, которая будет нуждаться в уникальной поддержке.
    Что бы все прошло хорошо, необходимо что бы каждая из команд “на берегу” представила свою концепцию, защитила ее и строго придерживалась в будущем.

  • Алексей

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

  • Илья

    CMDB не может жить самостоятельно, обособленно от других процессов. В частности, в правильно реализованных процессах/системах информация в CMDB добавляется, изменяется и контролируется преимущественно (а по-правильному – полностью) смежными процессами. Например, был сервер, его проапгрейдили, новые характеристики должны не вноситься руками, а автоматически обновиться по завершении соответствующего изменения.
    Так вот, в ИТ, где CMDB и смежные процессы живут вместе, всё работает малыми трудозатратами и каждый процесс актуализирует все смежные. А если мы эту же CMDB не просто делаем доступной другим подразделениям, но и расширяем CMDB под них, то вот это вот расширение придется вести/актуализировать/контролировать исключительно вручную. Или встраивать какие-то бизнес-процессы смежных подразделений в ITSM систему…
    НЕожданное, но правильно решение состоит в том, что если смежники осознали полезность единого учета, то они скорее всего готовы и на единые процессы управления…нужно их полностью погрузить в ITSM систему и таким образом постепенно или сразу накрывать всю организацию единым учетом, едиными процессами управления, едиными принципами управления 😉


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM