Изменения без рисков
Автор
Григорий Рудницкий
«Лаборатория Касперского» начала масштабный проект по созданию CMDB и внедрению процесса управления конфигурациями
Компаниям со сложной и распределенной ИТ-инфраструктурой и большим количеством предоставляемых ИТ-сервисов жизненно необходимы современные инструменты управления и контроля. Известный производитель средств информационной безопасности «Лаборатория Касперского», с 2009 года перешедшая на процессное управление ИТ, недавно начала масштабный проект по созданию и развертыванию CMDB и внедрению процесса управления конфигурациями. Об этом мы беседуем с Максимом Шахабом, директором по информационным технологиям «Лаборатории Касперского».
Для каких целей и задач ваша компания создает CMDB?
ИТ-инфраструктура «Лаборатории Касперского» предусматривает значительное количество оборудования и систем, распределенных по всему миру. Столь обширным хозяйством нужно скрупулезно управлять, чтобы поддерживать его на должном уровне. Что я имею в виду? Быстрое и в полной мере определение влияния на бизнес компании инцидентов и сбоев, которые не могут не происходить в комплексных распределенных системах, упрощение диагностики и минимизация времени устранения сбоев, а также тщательное планирование, подготовка и проведение изменений в ИТ-инфраструктуре. Одним из первых шагов было внедрение процесса управления изменениями, Change Management.
Резюмируя, скажу, что перед нами стоят две ключевые задачи. Первая — диагностика и чрезвычайно быстрая минимизация влияния сбоя на уровень защиты пользователей наших продуктов, а это возможно сделать, лишь когда видны все зависимости между сервисами, системами и компонентами ИТ-инфраструктуры. Вторая — постоянные исследования, доработки, совершенствование ИТ-сервисов. Именно ради этого мы создаем CMDB и внедряем процесс управления конфигурациями.
CMDB является неотъемлемым элементом ITIL/ITSM. Как в компании организовано управление ИТ-сервисами и как впишется в него CMDB?
В 2009 году отдел ИТ был реорганизован в ИТ-департамент, с целью внедрения сервисной модели и перехода на процессное управление. Уже тогда, проанализировав свои перспективы, мы поняли, что быстрое развитие компании, увеличение количества предоставляемых услуг и их совершенствование значительно усложнят ИТ-инфраструктуру и, если не применить процессный подход, можно потерять управляемость и контроль над происходящим. За основу мы взяли методологию ITIL, ключевые сотрудники прошли обучение и в 2009 году самостоятельно спроектировали и реализовали один из базовых процессов — управление инцидентами с одновременным внедрением ITSM-системы.
В составе ИТ-департамента есть собственное подразделение по управлению ИТ-процессами. Его сотрудники являются профессионалами в области проектирования, внедрения и управления ИТ-процессов и используют такие методологии и стандарты, как ITIL, COBIT и CMMI. В крупных проектах, когда необходим взгляд со стороны, мы привлекаем внешних консультантов, например, Cleverics, с которыми работаем по сей день. Но все же основные компетенции по организации, внедрению и управлению ИТ-процессами мы формируем у себя.
В 2009 году мы разработали «дорожную карту» внедрения процессов на несколько лет вперед, исходя из нашего понимания важности и приоритетности решаемых задач и проблем. Начали с управления инцидентами, далее реализовали управление изменениями, затем — управление проблемами и т. д. Успешно внедрили и продолжаем развивать процесс управления уровнем сервиса, Service Level Management, и его автоматизацию. Собираются и анализируются метрики по сервисам, с учетом которых ежемесячно ИТ-сервис-менеджеры планируют и проводят улучшения ИТ-сервисов. Эта деятельность продолжается, и сегодня мы добрались до управления конфигурациями.
Как происходит сбор и подготовка информации для CMDB? Как вы будете ее актуализировать в процессе эксплуатации?
Вопрос многоплановый. Одна его часть касается аспектов проектирования, другая — эксплуатации и развития. Проект по построению процесса управления конфигурациями и внедрению CMDB мы разбили на несколько этапов. Первый этап относится к проектированию CMDB и процессов. Здесь нам помогают коллеги из Cleverics, но основную работу делают наши собственные сотрудники ИТ. Мы начали с определения круга ключевых специалистов, которые должны участвовать в формировании требований, приоритетов и структуры CMDB, будущего владельца и менеджеров процессов, собрали ожидания от проекта, приоритезировали требования к CMDB и процессу управления конфигурациями.
Временные рамки первого этапа ограничены несколькими месяцами, и к концу года мы должны его завершить в соответствии со следующими критериями: спроектированный процесс; спроектированная, согласованная и утвержденная структура будущей CMDB; роли, полномочия и ролевые инструкции; готовность автоматизировать процесс в нашей ITSM-системе.
Мы уже провели несколько семинаров, в ходе которых сформировали ожидания на разных уровнях управления ИТ, начиная с CIO. Важно было определить пересечения этих ожиданий, чтобы понимание было одинаковым, а цели и задачи в целом совпадали. Уже когда была создана проектная команда, мы выявили такие аспекты, как назначение и задачи процесса, политики процесса, управление процессом, организационные границы. Затем перешли непосредственно к проектированию CMDB, которое включает правила учета информации, контроль обновления данных, взаимодействие с процессами управления инцидентами и изменениями. На более низком уровне занимались разработкой структуры CMDB. С одной стороны, это необходимо, чтобы не утонуть в куче деталей, то есть на уровне конфигурационных единиц. Но если сделать ее слишком поверхностной и высокоуровневой, пользы тоже будет мало. Потом занялись планом идентификации конфигурационных единиц и связей между ними, что имеет самое непосредственное отношение к тому, как CMDB будет первоначально наполняться и поддерживаться в актуальном состоянии.
Мы определились с элементами CMDB, используя принцип «лучше потом расширить, чем сразу пытаться охватить слишком низкоуровневые элементы». Далее рабочей группе и рядовым сотрудникам, которым этим и предстоит заниматься, было поручено сформировать критерии эффективности и результативности процессов. А после рассмотрели процедуру выявления расхождений в CMDB и механизмы борьбы с такими расхождениями. Наконец, обсудили будущую оценку и совершенствование процесса, поскольку изначально нужно думать обо всем жизненном цикле процесса.
По каким принципам формировалась рабочая группа для данного проекта? Вошли ли в ее состав представители бизнеса?
Нет, не вошли. Объясню почему. В принципе, должны быть представители бизнеса, обладающие компетенциями и знаниями по автоматизации своей области, то есть бизнес-сотрудники, понимающие основы ИТ-автоматизации их области бизнеса.
Когда в 2009 году мы начали внедрять сервисный подход, то пришли к решению, что в нашем случае эта роль оптимальна для сотрудников ИТ. Это айтишники с бизнес-бэкграундом, знанием конкретных областей бизнеса.
У нас существует несколько сервисных направлений — продуктовое, финансовое, продажи, маркетинговое и другие. Мы создали институт ИТ-сервис-менеджеров — фактически, это представители бизнеса в ИТ, но являющиеся сотрудниками ИТ и имеющие хорошие связи с менеджерами и сотрудниками бизнес-подразделений. Большую часть времени они проводят в общении с ними и выявляют потребности в автоматизации и развитии существующих ИТ-систем, а также контролируют и улучшают качество ИТ-услуг по своим бизнес-областям.
Планируете ли вы с помощью CMDB решить какие-либо задачи, которые прежде просто были недоступны?
Приведу два самых «больных» примера. Первое — процесс управления изменениями. Как известно, одним из его этапов является Change advisory board, CAB. Это совещание, которое организует инициатор вносимого изменения в ИТ-инфраструктуру, обычно сервис- или проектный менеджер. Он приглашает экспертов, которые при совместном обсуждении должны определить зависимости, риски, план проведение изменения, возможные планы отката и т. д. На определенном этапе роста сложности ИТ-инфраструктуры такой способ «коллективного разума» как инструмент планирования изменения в процессе Change management больше не может эффективно работать из-за человеческого фактора.
Вторая проблема заключается в том, что на определенном этапе роста сложности ИТ-инфраструктуры, когда в системе мониторинга возникает некое событие об инциденте или сбое, сотрудник ИТ не сможет точно определить его влияние на бизнес, на другие системы и сервисы. В большой и комплексной ИТ-инфраструктуре эти проблемы невозможно решать старыми способами. Именно здесь нам и поможет CMDB.
Источник: IT Manager №11, 2013
Опубликовано 03.12.2013