Изменения без рисков
Григорий Рудницкий | 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
Поделиться:
Мысли вслух
В статье из Harward Business Review авторы задались целью выявить поведенческие индикаторы того, что сотрудник собирается уйти.
А можно ли обойтись без этого гадания на ромашке "уйдет-не уйдет". Может, все проще?
А можно ли обойтись без этого гадания на ромашке "уйдет-не уйдет". Может, все проще?
Облачные технологии стали применять даже там, где раньше они не пользовались популярностью. Сравнительно недавними пользователями можно считать ретейлеров и сферу питания.
Даже если электронная запись не работает, всегда найдется возможность пройти вакцинацию.
Компании сообщают
Мероприятия
Защита от сложных и направленных угроз в высоконагруженных средах
Москва, ул. Василисы Кожиной, д.1/1, ресторан «Атмосфера»
Бесплатно
03.03.2021
9:30
Форум промышленных инноваторов «Инновации и организационная трансформация в промышленных компаниях»
Площадка санатория «Юбилейный» ПАО «Магнитогорский металлургический комбинат»
Бесплатно
11.03.2021 — 12.03.2021