Серьезная программная и методическая поддержка управления ИТ-инфраструктурой позволяет решать ряд важных задач, чтобы достичь эффективной организации работы внутри ИТ-отдела, а также адекватного взаимодействия с бизнесом. Об этом мы беседуем с Михаилом Толчельниковым, менеджером по предоставлению ИТ‑сервисов компании «САБМиллер РУС»
Intelligent Enterprise: У вас важная функция — планирование развития информационной инфраструктуры. Каким образом это осуществляется? Насколько важна здесь информационная поддержка?
Михаил Толчельников: Занимаясь организацией планирования, важно моделировать различные сценарии развития событий, позволяющих просчитать ситуацию с учетом запросов. Для этого необходим достаточно высокий уровень развития ИТ-отдела и определенная методическая подготовка.
Функционирование любого ИТ‑сервиса связано с определенным программно-аппаратным комплексом и зависит от производительности компонентов, входящих в этот комплекс, и степени доступности аппаратных средств. Раскладывая ИТ‑сервис на компоненты, мы определяем список ИТ-инфраструктуры, вовлеченной в работу этого сервиса. Например, почтовая система работает на выделенном кластере, хранит свои данные в корпоративной системе хранения данных, этот комплекс обслуживается системой информационной безопасности, в которую входят файервол и подсистема обнаружения вторжений (Intrusion Detection System). Именно эти компоненты и составляют ИТ‑сервис. Большинство аппаратных компонентов могут обслуживать и соответственно быть связанными с более чем одним ИТ‑сервисом, некоторые будут критичными для всей ИТ-инфраструктуры. Все эти связи в контексте сложившейся ИТ-инфраструктуры конкретного бизнеса должны быть проанализированы, выстроены логически. Текущие рабочие параметры и пиковая нагрузка также должны быть учтены. Если говорить о нашем случае, то данный анализ мы выполняли средствами Excel, и уже затем полученная модель была реализована в Microsoft System Center Operation Manager (MS SCOM).
После того как завершен перенос инфраструктуры в MS SCOM, можно проводить полноценное «виртуальное» моделирование ситуаций по принципу «что, если». Проще говоря, мы можем в виртуальном режиме отключить любой аппаратный компонент или перевести его в какой‑либо статус недоступности и посмотреть, как это влияет на работу корпоративных приложений.
Надо сказать, что на практике мы без надобности не усложняем ситуацию и строим модель ИТ‑сервисов на том уровне упрощения, который нас устраивает. Упрощение состоит в том, что подробно описывается инфраструктура только для ключевых сервисов и только в рамках главного центра обработки данных. Инфраструктуру филиалов мы моделируем более упрощенно. Например, мы не контролируем отдельные коммутаторы в сетях наших филиалов и, следовательно, не можем сказать, есть ли проблемы у отдельных работников, но можем точно диагностировать масштабные проблемы, потому что мы мониторим состояние канала между центральным офисом и филиалом, а также ИТ‑серверы и коммутационное ядро филиала.
Опираясь на нашу модель, мы можем также планировать развитие ИТ-инфраструктуры. Наблюдая продолжительное время нагрузочные параметры критичных частей ИТ-инфраструктуры, мы можем достаточно точно предсказать ее поведение в случае дальнейшего возрастания нагрузки. Допустим, для почтового сервера Exchange мы мониторим очередь на отправку, очередь чтения/записи на дисковой подсистеме, очередь памяти и загрузку процессора. Эти данные позволяют нам достаточно точно предсказать, что произойдет с качеством предоставления сервиса, если, скажем, в домене появится дополнительно 300 пользователей. Точное понимание текущих узких мест в ИТ-подсистемах позволяет не только предсказать проблемы, но и парировать их, улучшая только те компоненты, которые не справятся с потенциальной нагрузкой.
Раз уж мы заговорили о взаимоотношениях с бизнесом, хотелось бы понять, изменилось ли что‑либо в отношении не только технического, но и финансового планирования модернизации инфраструктуры после внедрения новых продуктов.
Конечно, бизнес не разговаривает на языке процессорной загрузки сервера или очередей чтения/записи подсистем хранения. Однако качество взаимоотношений с бизнесом для ИТ-отдела в значительной степени определяется качеством информации о текущем состоянии корпоративных ИТ‑сервисов. Имея адекватную модель работы приложений в среде Microsoft Operation Manager, мы четко показываем доступность каждого внесенного в модель элемента наших аппаратных ресурсов и производительность приложений. Мы всегда можем наглядно показать бизнесу, как вложение средств в ИТ-инфраструктуру влияет на ее доступность и производительность.
Можно говорить с полной уверенностью, что сейчас аналитические данные и проектные обоснования для бизнеса готовятся гораздо проще, чем это было ранее.
Вообще развитая культура подобных отношений с бизнесом предполагает наличие количественных соглашений об уровне сервиса, которые надо предварительно обсуждать и готовить. К тому же само понятие сервиса, которое вы только что упомянули, тоже не возникает само собой, а является скорее плодом кропотливой методической работы. Что можно сказать об этом, имея в виду бизнес компании «САБМиллер»?
Многие ИТ‑сервисы критичны для бизнеса, и понимание уровня их доступности и производительности — ключевой вопрос во взаимоотношениях бизнеса и ИТ. К сожалению, на данный момент наш проект не охватывает критичные финансовые сервисы (проект был ориентирован на управление и мониторинг платформы Windows, финансовые же сервисы работают под управлением SUN Solaris на серверах SUN), но тем не менее включает критичные для бизнеса сервисы (Remote Access, Print, Mail, Active Directory). Модель ИТ-инфраструктуры, которую мы упоминали, для этого совершенно необходима, если мы говорим об общении в терминах SLA. Только анализ на уровне сервисов, а не серверов может вывести ИТ-отдел на такой уровень, и MS SCOM в этом помогает. Для каждого включенного в нашу модель сервиса прописано значение SLA. Поскольку на данный момент договор по SLA формально не заключен с бизнесом, уровень большинства ИТ‑сервисов мы стараемся поддерживать на уровне 99,9%, взяв его за базовый минимум. С бизнесом мы уже сейчас пытаемся активно выстраивать отношения, применяя параметры SLA, но с формальной точки зрения подпись на документах, регламентирующих данные отношения, еще не поставлена.
Оценивая доступность наших сервисов, мы учитываем несколько параметров, вычисляемых на основе общей доступности сервиса. Это общий процент доступности сервиса, среднее время по восстановлению сервиса после сбоя и среднее время, проходящее между сбоями. Дополнительные параметры требуются для более гибкого подхода к требованиям бизнеса относительно модели предоставления сервиса. Иногда бизнесу выгоднее, чтобы тот или иной сервис в случае возникновения инцидентов (в том числе, кстати, и плановых) простаивал чуть дольше, но при этом интервал между инцидентами тоже был максимально увеличен. Иногда требования носят обратный характер. В зависимости от этих требований мы меняем модель обслуживания данного сервиса, не выходя при этом за рамки требуемого уровня его доступности. То есть мы либо реже останавливаем компоненты сервиса для проведения плановых работ, либо проводим обслуживание чаще, но при этом минимизируем простои. Для управления этими параметрами используется бесплатная надстройка к MS SCOM, SLA Dashboard. Если бы не этот инструмент, расчет был бы чрезвычайно затруднен.
В разговоре о сервисах речь до сих пор шла о неких функциях, предоставляемых скорее каждому пользователю индивидуально. А насколько они могут быть привязаны к бизнес-процессам компании и как сочетаются с ними на сегодняшний день?
Все ИТ‑сервисы так или иначе связаны с бизнес-процессами. При этом, как я уже говорил, добавление в MS SCOM приложений, непосредственно относящихся к поддержке ERP‑системы предприятия, — следующий шаг нашего проекта. К тому же я прекрасно себе представляю, насколько сложно будет связывать вопросы нагрузки на определенные компоненты нашей инфраструктуры с бизнес-процессами, а затем на все это накладывать параметры SLA. Этой задачей нам придется заниматься, если она будет поставлена. Понятно, что потребуется намного более сложная работа, чем проделанная нами сейчас.
Пока же мы можем смотреть только на доступность серверов SUN с помощью кросс-платформенного компонента MS SCOM, но ничего не знаем о производительности приложений SAP.
Мы довольно подробно поговорили о серверной инфраструктуре, но пока ничего не сказали об управлении клиентской частью, то есть непосредственно рабочими местами. Что делается в этом направлении?
Управление клиентскими устройствами можно разделить на две части: управление аппаратной платформой и вычислительной средой конечного пользователя, а также управление лицензиями на установленное ПО. Сейчас мы используем достаточно простую схему в отношении лицензирования. Основа нашего пакета лицензирования покрывается договорами с компаниями SAP Microsoft и McAfee. Это наши основные продукты, и они составляют около 90% от всего пакета ПО, установленного в нашей компании. Можно сказать, что все управление направлено на работу с компонентами MS Office, не входящими в пакет Standard, и тем ПО, который пользователи иногда ставят на свои компьютеры самостоятельно. В отношении параметров производительности аппаратных компонентов клиентских рабочих станций мы опытным путем оцениваем так называемый комфортный уровень (Comfort Baseline), необходимый для работы на клиентских компьютерах наших прикладных программных компонентов. Базовый уровень определяется требованиями производителей ПО и накладывается на те аппаратные платформы, которые имеются в сети на данный момент. Comfort Baseline позволяет планировать необходимую частичную замену парка персональных компьютеров при массовом переходе на новое ПО, причем делая это планирование более логичным и привязанным к реальным показателям производительности, а не к возрасту конкретной модели, скажем, ноутбука. Все, о чем я говорил выше, реализуется с использованием Microsoft System Center Configuration Manager (MS SCCM). Именно с его помощью можно отслеживать выполнение «программы обновления» клиентского парка, определять рабочие станции пользователей с установленным нелицензионным ПО и отслеживать частоту запуска программ с целью оптимизации использования лицензий. MS SCCM управляет также развертыванием и удалением ПО на рабочие станции. Подобно случаю с MS SCOM, здесь мы имеем возможность решать проблемы как технического управления, так и организационно-финансового планирования.
Применение обсуждаемых нами продуктов, по сути, предназначено для управления ИТ-инфраструктурой предприятия, а стало быть, хотя бы в кокой‑то степени должно ассоциироваться с применением ITIL/ITSM. Есть, как известно, программные системы, неразрывно связанные с построением соответствующих процессов, к которым ни SCOM, ни SCCM явным образом не относятся. В связи с этим хочется спросить: используете ли вы данные методологии? В какой степени они связаны с применением данных продуктов Microsoft?
Несомненно, мы используем процессы ITIL и ITSM-практики. Так или иначе, без этого невозможно построить сколько‑нибудь эффективную работу в сфере корпоративного ИТ, особенно при высоких требованиях, предъявляемых к ИТ-подразделению. Вместе с тем мы не видим возможности ориентироваться на данные подходы в полном соответствии с их требованиями. Прежде всего вследствие компактности нашего ИТ-подразделения. Иными словами, идеальная ролевая модель трудно достижима, а попытки ее создания, скорее всего, не будут оправданы с финансовой точки зрения.
Вместе с тем такие ITIL-процессы, как incident management, service level management, capacity planning и availability management, максимально приближены к стандартам ITIL. Продукты, о которых мы разговариваем, — несомненно важные элементы для обеспечения ITIL-ориентированных процессов, наравне с такими компонентами ИТ, как ПО, обеспечивающее работу Service Desk и CMDB.
К примеру, все заявки на инсталляцию программного обеспечения приходят в Service Desk, обрабатываются и назначаются на специалиста по Microsoft System Center Configuration Management. Далее идет штатный процесс удаленной установки при помощи MS SCCM. При этом в результате использования инструментария для удаленной установки от инсталляции ПО разгружаются сотрудники первой линии поддержки, а специалисты серверной группы — от анализа работы с лицензиями. Ранее все эти задачи как бы равномерно распределялись по всему ИТ-подразделению, что снижало общую производительность отдела. MS System Center Operation Manager тесно интегрирован в процесс работы с инцидентами как продукт, позволяющий быстро поднять проблему на нужный уровень и столь же быстро определить ее причину. При этом продукт дает возможность проактивно обнаружить негативные тенденции в нагрузке сервиса или в работе компонентов ИТ-инфраструктуры до момента реального сбоя.
Реализованная в MS SCOM и визуализированная в MS SCOM add-on for Visio (бесплатный компонент по визуализации моделей ИТ‑сервисов) модель функционирования ИТ-инфраструктуры позволяет любому сотруднику первой линии идентифицировать проблему и правильно эскалировать ее, что заметно снижает время реакции на инциденты. В целом благодаря тем продуктам, которые мы внедрили (MS SCOM, MS SCCM, SAL Dashboard, MS SCOM add-on for Visio), ИТ-отдел сможет работать более эффективно, не увеличивая при этом штат сотрудников и не привлекая к обслуживанию сторонние организации.
