Вход |  Регистрация

Все Тэги

CMDB в роли предохранителя

13.07.2015426 просм.

Это четвертый пост в серии статей о подходах и направлениях в мониторинге современных бизнес-приложений. Другие публикации серии доступны по следующим ссылкам:

С помощью  АРМ-решений,  о которых мы пишем в своих статьях, наша команда профессионально реализовала большое количество проектов по мониторингу. Этот опыт дает нам возможность отнести себя к немногочисленной группе специалистов в области мониторинга, способных компетентно говорить не только о возможностях каждого АРМ- инструмента, но и об их реальной отдаче. Если Вы фанат какого-то из продуктов, и у Вас иная точка зрения, мы искренне будем рады отзывам и комментариям, а также конструктивным дискуссиям (оставлять свои комментарии Вы можете внизу статьи или в User Group DevOps Hub. IT Service management организовывать дискуссии, где мы активно участвуем). А если Вы, дорогой читатель, представитель компании-производителя, то мы будем рады, если наше мнение поможет сделать Ваш продукт более совершенным и полезным для нашего сообщества пользователей и внедренцев…

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

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

Производители систем ИТ-мониторинга проявляют разную степень искренности, говоря о своих реализациях CMDB. Например AppDynamics и New Relic абсолютно честно информируют, что функции CMDB в их продукт не заложены, поэтому предлагают интегрироваться с другими продуктами – например HP uCMDB или BMC Atrium CMDB. Другие, – DELL Foglight, Microsoft SCOM, Compuware/Dynatrace, на поверхности дают ответ ДА. Но это ДА становится все менее и менее конкретным по мере решения КОНКРЕТНЫХ задач, стоящих перед CMDB.

Задачи CMDB, обеспечивающие непрерывность бизнеса
Передовые компании, работа которых напрямую зависит от надежности ИТ сервисов, отлично понимают, зачем выделяют миллионы долларов на опытных специалистов, отказоустойчивую инфраструктуру и комплексные системы мониторинга. И когда плановая профилактика из-за банальной ошибки выводит из строя ключевые сервисы и приносит немалые финансовые и репутационные потери, возникают закономерные вопросы, почему же не помогли  все эти инвестиции? Чего не хватает, чтобы подобные вещи не происходили?

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

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

От мониторинга – к интеллектуальному управлению
Во всех примерах, приведенных выше, актуальная база элементов и их взаимосвязей позволила бы избежать таких “досадных”, а главное критических для бизнеса, сбоев.

Как? – с помощью автоматизации “what-if” сценариев. Рассмотрим на примере продукта HP BSM. Во встроенной CMDB реализована возможность проверки различных сценариев – “если перестанет работать какая-либо компонента (сбой или плановое выключение), какие системы, сервисы и пользователи будут затронуты?” Результат – табличное и графическое представление зависимостей, затронутых систем и уровня влияния. Это называется impact analysis (оценка влияния) и позволяет избежать непредусмотренных последствий планируемых действий.

Лучшая практика:На одном из недавних проектов, мы использовали автоматизированную оценку влияния следующим образом:

  • Во-первых, любой сотрудник ИТ на портале системы мониторинга может автоматически получить оценку того, какие системы и бизнес-сервисы будут затронуты при выполнении работ c той или иной ИТ-компонентой (например сервер, база данных, дисковый массив, интеграционный сервис и т.д.). Этим успешно пользуются проектные менеджеры, администраторы ИТ-систем и их руководители.
  • Во-вторых, мы автоматизировали согласование регламентных работ так, что при внесении заявки система (i) автоматически отрабатывает алгоритм оценки влияния  и к заявке прилагается отчет с перечнем затрагиваемых систем, (ii) обязательно уведомляет “владельцев” затрагиваемых ИТ-сервисов, (iii) при необходимости, автоматически корректирует расчет SLA затронутых систем, с учетом запланированных работ.

Оптимальное решение – это CMDB, интегрированная с системой мониторинга
Конечно, ценность CMDB не в базе данных как таковой, а в ее корректном наполнении и грамотном использовании.

Наполнение и актуализация CMDB вручную является, скажем мягко, нетривиальной задачей, с высокой вероятностью различных ошибок, поэтому критична автоматизация данного процесса. В HP BSM универсальная CMDB (HP uCMDB), изначально встроена в единый инструмент вместе с системой мониторинга. Таким образом, обеспечены автоматический сбор детальной информации об ИТ-системах и их компонентах (как программных, так и аппаратных), определение зависимостей и отслеживание изменений.

Автоматическое обнаружение и отображение конфигурационных элементов в топологии и в моделях бизнес сервисов и их инфраструктуры позволяют реализовать интеллектуальный мониторинг, снижающий количество ложных оповещений и сбоев (при интеграции с HP BSM и его средствами мониторинга).

Это был краткий экскурс в описание того, что же такое CMDB, и четвертый пост в серии статей о подходах и направлениях в мониторинге. Остальные публикации серии доступны по следующим ссылкам:

 

Метки: , , , , , , , , , ,

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

Для отправки комментария вам необходимо авторизоваться.

Партнеры DevOpsHub и DevOpsWiki