Надо сказать, что писать про управление конфигурациями — дело неблагодарное. Это исключительно обеспечивающий процесс, основополагающий для всех других процессов ITIL. Но в явном виде от него особого толку нет, а хлопот с его организацией — пропасть.
Захотел, например, какой‑нибудь ИТ‑менеджер новый разрез данных увидеть — вперед, переделываем учет и проводим верификацию. А заказчик взглянул на результаты и произнес: «Опять не то!»
К тому же многие просто не видят (или не понимают) разницы между управлением конфигурациями и управлением активами, а то еще и путают это с бухгалтерским учетом.
В реальной жизни управление конфигурациями обычно заключается в стандартизации ПК, программного обеспечения (ПО), установленного на них, и подключенной к ним же периферии (принтеров, сканеров и т.п.). Что, собственно, и правильно: любая компания тратит на это добрую треть ИТ-бюджета. К тому же если не наведен банальный порядок в стандартизации ПО на рабочих местах, можно даже и внедрение ЕRP‑системы если не провалить, то существенно замедлить.
Но управление конфигурациями на этом отнюдь не заканчивается. Сегодня предлагаю поговорить о том, как непосредственно от этого процесса получить явные и выигрышные результаты для более сложных конструкций. Не забудем и о теме текущего номера журнала.
Сразу следует заметить — все вопросы, которые мы будем рассматривать далее, актуальны только для больших предприятий с разветвленной территориальной структурой, использующих широкий набор ИТ‑систем и построенных на их базе услуг.
Что нам говорит учебник? Что процесс управления конфигурациями начинается с планирования. А планирование начинается с определения целей процесса. Давайте поищем цели.
Ненадолго отвлечемся на мониторинг. Как обычно организован мониторинг ИТ‑систем? Есть специализированные конструкции, накрывающие один или несколько технологических сегментов: энергоснабжение, переменные среды, физическая и информационная безопасность, телекоммуникации, сетевое оборудование, серверы Wintel, СУБД, почтовые системы, конкретные приложения и т.п. Функциональность таких систем варьируется в широком диапазоне: от простой индикации «Up/Down» до измерения производительности и отслеживания сложных корреляций. Общее у всех систем мониторинга одно: в конечном итоге тем или иным способом каждому из объектов мониторинга присваивается некоторый статус. То есть в большой ИТ-инфраструктуре мы имеем обычно некое количество некоторых интерфейсов, из которых можем получить информацию о статусе различных конфигурационных единиц (КЕ).
И что дальше с этой информацией делать? Ее кто‑то должен воспринять, проанализировать и по результатам анализа предпринять некие правильные действия. В самом простом варианте эти «кто‑то» — сотрудники служб ИТ, отвечающие за эксплуатацию ИТ-инфраструктуры и приложений. На некоторых предприятиях создана специальная службы технологической диспетчеризации, дежурная инженерная служба или что‑то подобное. При этом ИТ-менеджеры, отвечающие за предоставление конечных услуг, и сотрудники служб технической поддержки получают информацию уже от тех или иных технических специалистов.
У такого подхода есть один недостаток: сотрудники, отвечающие за работу с заказчиками и потребителями ИТ-услуг, получают информацию о статусе конфигурационных единиц, а для работы с заказчиками и потребителями им нужна информация о статусе ИТ-услуг. Именно на основании информации о статусе ИТ-услуг работают центры поддержки пользователей, происходит информирование пользователей и заказчиков, рассчитывается доступность услуг, ведется тарификация и биллинг, а также делается многое другое.
В случае простой инфраструктуры нетрудно понять, к каким проблемам привело то или иное событие (изменение статуса КЕ). Но если у вас в инфраструктуре несколько сотен серверов, использующих различные системы хранения данных, есть несколько различных систем резервного копирования, сложная система сетей и телекоммуникаций, и на этом всем работает несколько десятков приложений, интегрирующих различные бизнес-процессы (то есть на базе одного приложения организовано несколько услуг), то задача становится весьма нетривиальной.
Возможный вариант решения — объединить каталог ИТ-услуг с базой данных конфигурационных единиц (CMDB), правильно организованной и дополненной требуемой системой учета взаимосвязей. Иначе говоря, вы должны построить многоуровневую CMDB, где на нижнем уровне будут элементарные КЕ (системы хранения, резервного копирования и обработки данных, инсталляции ПО и т.п.), на нескольких средних уровнях — комплексные КЕ (платформа, информационные системы, приложения), а на верхнем уровне — конечные ИТ-услуги из актуального каталога ИТ-услуг. Для получения модели, пригодной к использованию в мониторинге состояния ИТ-услуг, надо будет еще разработать логику влияния КЕ нижнего уровня на КЕ следующего уровня. В простейшем варианте можно использовать двоичную логику «да/нет»: то есть если один из компонентов системы имеет аварийный статус, то этот статус транслируется выше по иерархии вплоть до ИТ-услуги. Но возможны и более сложные логические построения.
Что мы получим в итоге? Построив такую модель и реализовав ее на какой‑либо автоматизированной платформе (такие уже существуют, рекламу вендорам здесь делать не будем), мы получим инструмент, который в режиме, близком к реальному времени, позволяет контролировать состояние предоставления ИТ-услуг.
Как можно использовать такой инструмент? Это уже зависит от конкретной ситуации, вариантов много. Например, вы можете централизовать управление предоставлением ИТ-услуг в большом холдинге, обеспечить контроль качества обслуживания заказчиков при территориальном расширении вашего бизнеса, контролировать качество предоставления услуги, организованной на разных платформах, при слияниях и поглощениях предприятий.
Какие еще эффекты можно получить от управления конфигурациями, используя такой подход?
Вполне реально привязать все прямые и косвенные затраты на ИТ к КЕ нижнего уровня и разработать методику распределения этих затрат вверх по иерархии. В результате вы получите инструмент для определения себестоимости и управления ИТ-затратами.
Точно так же можно привязать к КЕ нижнего уровня поставщиков и контракты и получить инструментарий для управления поставщиками.
При ограничении и дефиците бюджета стандартной проблемой становится определение приоритетов — на что тратить средства, например, планируя обучение сотрудников. Наличие правильно отстроенной CMDB, связанной с каталогом услуг, поможет решить и такую задачу.
В заключение не могу не коснуться одной сравнительно новой проблемы в отечественной ИТ-практике. В последнее время размещение оборудования корпоративных систем в арендуемом центре обработки данных (ЦОД) стало вполне доступным и реальным. Тем не менее очень многие менеджеры вообще не могут объяснить — зачем? Или же возникают проблемы с формулированием критериев выбора — что переносить? Так сводятся на нет все потенциальные положительные эффекты от такого перемещения.
Одна из основных задач, которую можно решать при помощи ЦОД, — это повышение надежности (или, по ситуации, — доступности, катастрофоустойчивости) предоставления критичных ИТ-услуг. Наличие правильно отстроенного процесса управления конфигурациями даст вам возможность, идя от услуги, идентифицировать критичные для нее КЕ и посмотреть — что изменится при переносе этих КЕ в ЦОД. В итоге можно оценить саму целесообразность переноса услуги в ЦОД, обнаружить «слабое звено», требующее модификации (например, переработка архитектуры приложения или его платформы), а также избежать ситуации, когда одна из критичных КЕ не была перенесена в ЦОД, и в результате требуемый эффект не был достигнут.
Вопросы? Критика? Дополнения? Пишите автору по адресу ASennator@gmail.com
Необходимы системы, основанные на стандартах
Петр Петров,
ведущий эксперт отдела развития бизнеса Microsoft компании «АйТи»В своей голове мы легко сопоставляем данные инвентаризации, мониторинга, планы переезда в новый ЦОД и так далее, понимая, что в каждом конкретном случае имеем дело с одной и той же сущностью, например сервером или приложением. Этого мы хотим и от автоматизированных систем.
Соответствовать таким ожиданиям может только комплексная система управления ИТ. В настоящее время подобные системы можно строить, интегрируя между собой решения одного вендора и его близких партнеров. Такое решение практически всегда дорого.
Пожалуй, качественный скачок в построении таких систем может произойти, когда интеграция и интероперабельность различных компонентов, обеспечиваясь за счет единых стандартов обмена данными об управляемых объектах, не будут зависеть от конкретного вендора.
Однако тема конкуренции производителей ПО в создании полных линеек продуктов управления еще не исчерпала себя. Выйдет еще много новых версий продуктов, специализированных и универсальных «коннекторов», прежде чем ISO заменят API.
