IT ManagerИТ в бизнесеИнфраструктура

Изменения без рисков

Григорий Рудницкий | 03.12.2013

Изменения без рисков

Компаниям со сложной и распределенной ИТ-инфраструктурой и большим количеством предоставляемых ИТ-сервисов жизненно необходимы современные инструменты управления и контроля. Известный производитель средств информационной безопасности «Лаборатория Касперского», с 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

Журнал: Журнал IT-Manager [№ 11/2013], Подписка на журналы


Поделиться:

ВКонтакт Facebook Google Plus Одноклассники Twitter Livejournal Liveinternet Mail.Ru

Другие материалы рубрики

Мысли вслух

А что IT? А мы работаем, совершенствуемся в популярных технологиях и осваиваемся в новых. И пока до Луны ближе, чем до создания искусственного интеллекта, без работы мы не останемся.
«Пока больше некого назначить, поэтому заткнем дыру тобой. Потом переназначим». Упражнение называется «как убить сломать сотрудника за одно действие: повысить и понизить обратно». Для надежности повторять неоднократно.
Слушания в Конгрессе США, вызов на ковер руководителей Google, FB, Apple, Amazon. Мысли по итогам прочтения стенограммы.

Компании сообщают

Мероприятия

10.09.2020
IT Management Forum 2020

Москва, Новоданиловская наб., д. 6, отель Palmira Business Club

23.09.2020 — 24.09.2020
Форум Индустриальной Роботизации

Санкт-Петербург, Чернорецкий пер. 4-6

28.09.2020 — 29.09.2020
Профессиональная мобильная радиосвязь, спутниковая связь и навигация

Москва, Холидей Инн Москва Лесная

29.09.2020 — 02.10.2020
SMART INDUSTRY EXPO

Минск, Футбольный манеж

30.09.2020
IT в ретейле: Я - легенда.

Москва, Холидей Инн Москва Лесная

27.10.2020 — 29.10.2020
HI-TECH BUILDING 2020

Москва, Крокус Экспо