Задачи мониторинга ИТ-инфраструктуры

Сегодня бизнес настолько зависит от обслуживающей его потребности ИТ-инфраструктуры, что более или менее значительный сбой в ее работе может привести к значительным убыткам или даже к банкротству компании. Но, как ни парадоксально, вопросу мониторинга работоспособности ИТ-инфраструктуры не уделяется внимания, адекватного возможным рискам. Вполне вероятно, что это пренебрежение вызвано тем, что сама по себе ИТ-инфраструктура никакой бизнес-ценности не создает, а является лишь средством для реализации приложений, выполняющих бизнес-задачи.

Пошаговое закрытие задач

Под ИТ-инфраструктурой будем понимать серверы, системы хранения, СУБД и прочее неприкладное обеспечение. Сюда же отнесем различные процессы и ресурсы, связанные с их обслуживанием: планирование, закупка, установка, администрирование, защита, обновление, резервное копирование, disaster recovery, электропитание, охлаждение/отопление, provisioning/deprovisioning (подключение/отключение доступа) и т.п. Согласно исследованиям Gartner Group, расходы на инфраструктуру и общесистемное ПО составляют 68% всех ИТ-затрат, «хотя никак не сказываются на качестве бизнес-процессов». Стратегия оптимизации таких ИТ-ресурсов сводится к экономии, стандартизации, возможному аутсорсингу и т.д.

Основным критерием применения комплексных систем мониторинга ИТ-инфраструктуры является переход ИТ-подразделения компании к сервисной модели работы. Именно ИТ-сервисы заставляют оценивать работу ИТ-инфраструктуры и приложений не как отдельных независимых элементов, а как многоуровневой, распределенной среды, обеспечивающей выполнение бизнес-процессов. И если для мониторинга рабочих характеристик сервера или отдельно взятого маршрутизатора вполне допустимы частные решения, включая open-source, то переход к обеспечению работоспособности бизнес-приложений, поддерживающих соответствующие бизнес-процессы, требует комплексной многогранной оценки. В первую очередь, для любого произошедшего события или сбоя должна быть осуществлена приоритизация с точки зрения влияния этого сбоя на выполнение бизнес-целей. Это означает, что в режиме реального времени необходимо скоррелировать статусы и события со всех технологических доменов, спрогнозировать возможные сценарии развития ситуации и сформировать для службы технической поддержки набор рекомендаций для оперативного устранения критической ситуации.

Несомненно, мониторинг сложных программно-аппаратных комплексов с несколькими тысячами единиц учета является нетривиальной задачей и требует детального проектирования. Однако это вступает в противоречие с требованиями бизнеса — прозрачность структуры вложения средств и ясность результатов, приносимых системами мониторинга. Хорошо понимая все эти проблемы, компания «ТехноСерв А/С»  предлагает концепцию внедрения систем ИТ-мониторинга и вариант ее практической реализации, в частности, на базе продуктовой линейки компании CA.

Исходные данные, постановка задач, методика решения

Поскольку ИТ-инфраструктура большинства компаний построена на базе стандартных продуктов (сетевое оборудование, серверы, операционные системы, используемые протоколы, приложения), то для решения 80% задач можно и нужно скомпоновать стандартное решение, позволяющее их охватить в режиме out-of-the-box. Для оставшихся 20% задач, которые и отражают уникальность того или иного бизнеса, можно применять индивидуальный подход.

Исходные данные

Как правило, сетевая инфраструктура компаний построена по топологии «звезда». Центром в этой архитектуре является ЦОД (центр обработки данных), также включающий в себя серверную составляющую всех корпоративных распределенных приложений, таких как SAP, Oracle Applications, Exchange и т.д. В качестве оконечных элементов выступают центры дистрибуции, созданные по типовому проекту (в идеале). В силу «разбросанности» центров дистрибуции по часовым поясам и учитывая планы развития компаний, как правило, можно предъявить к инфраструктурной составляющей весьма жесткое требование: работа в режиме 24x7x365 с надежностью не менее 99,5% (т.е. простой не более 11 часов в квартал).

Возможные направления оптимизации

Решение вопросов, указанных выше, требует проведения работ в различных направлениях:

• обеспечение оперативного контроля над сбоями в работе ИТ-инфра­структуры и производительностью работы сетевого и серверного оборудования;
• обеспечение оперативного монито­ринга распределенных корпо­ративных приложений;
• переход к сервисной модели предостав­ления ИТ-услуг;
• оптимизация использования арен­ду­е­мой/лич­ной канальной инфраструктуры, организация контроля за соблюдением SLA-услуг, предоставляемых провайдерами.

Постановка задач

Базовая бизнес-задача: обеспечение заданной производительности работы распределенных корпоративных приложений с заданной надежностью. Эта задача декомпозируется на следующие технические подзадачи:

1. Создание надежных каналов связи:

• Дублирование каналов связи: как минимум два провайдера и интер­нет-связь.

• Модернизация оборудования.

• Введение QoS.

• Мониторинг утилизации каналов связи в режиме реального времени.

• Создание балансировщика между задействованными провайдерами с целью минимизации отношения цена/качество при обеспечении требуемой надежности связи.

• Мониторинг качества работы каналов связи:
   - Выставление штрафных санкций провайдерам, согласно подписанным SLA.
   - Анализ тенденций с целью своевременного принятия решения о расширении/ расторжении контракта/модернизации оборудования/оптимизации QoS и т.д.

2. Оптимизация трафика во внутрикор­поративных сетях/повышение надежности работы тонких транзак­ционных механизмов корпоративных приложений:

• Сжатие/кеширование.

• Использование терминальных решений.

3. Пассивный и активный мониторинг работы корпоративных приложений с целью своевременного определения деградации производительности:

• Мониторинг производительности работы серверного оборудования.

• Мониторинг производительности составных элементов многозвенных приложений: сервера приложений и базы данных.

• End-to-еnd мониторинг прило­жений на уровне транзакций и биз­нес-транзакций.

4 Сокращение времени решения возникающих проблем:

• Введение централизованной точки входа приема и обслуживания заявок.

• Своевременное и четкое отслеживание выполнения этих заявок.

• Снижение влияния человеческого фактора путем централизованного накопления получаемого опыта эксплуатации и решения проблем.

Предлагаемая методика решения

Настоящая методика опирается на предположение, что в компании не существует ни одного модуля, входящего в комплексную систему мониторинга ИТ-инфраструктуры. Поскольку в действительности дело часто обстоит иначе, тот или иной шаг методики может быть пропущен или рассмотрен в разрезе оптимизации уже существующего модуля.

Шаг 1. Внедрение подсистемы регистрации и управления неисправностями (fault management)

Основное назначение этой подсистемы следующее:

• Работа в режиме реального времени.

• Сбор и накопление сообщений от сетевых устройств, приложений и систем управления.

• Обработка сообщений: фильтрация и корреляция событий (в том числе междоменная) с учетом топологии сети.

• Автоматический анализ корневой причины неисправности (Root Cause Analysis).

• Обогащение событийной информации данными из внешних источников.

• Возможность получения дополнительной информации из внешних систем для проведения кросс-доменного анализа.

• Отображение аварийных сигналов в различной форме, многослойность представления.

• Оповещение службы поддержки компании об аварийной ситуации в различной форме (SMS, e-mail и т.д.).

• Хранение истории аварийных событий.

• Разнообразные формы отчетности, включая графическое представление.

Предполагаемая модель описания ИТ

В рамках готового решения на базе линейки продуктов компании CA для решения этой задачи предназначен продукт CA Spectrum. Внедрение системы fault management (в варианте out-of-the-box этот процесс занимает, с момента принятия решения до проведения приемо-сдаточных испытаний, как правило, 1,5—2 месяца) позволит поставить полностью под контроль всю сетевую инфраструктуру, а также мониторинг базовых характеристик работы серверов (загрузка процессоров, памяти, свободное место, запущенные процессы и т.д.). Тем самым будет подготовлена площадка для наиболее сложного модуля мониторинга, отвечающего за мониторинг качества работы распределенных приложений.

Шаг 2. Внедрение подсистемы приема и обработки заявок (service desk/trouble ticketing)

Основное назначение этой подсистемы следующее:

• Открытие карточки проблемы (TT).

• Планирование работ по устранению неисправностей.

• Оптимизация распределения работ по решению проблемы.

• Автоматическое перенаправление ТТ на исполнение в соответствующие подразделения.

• Контроль исполнения заданий (статус проблемы, позиция в ходе выполнения работ, исполнитель).

• Ведение базы знаний по проблемам и методам их решений.

• Составление подробных отчетов для управленческих и технических служб.

Служба Service Desk является фундаментом для перехода к сервисному подходу в оказании ИТ-услуг (ITSM). В рамках законченного комплекса на базе линейки продуктов компании CA для решения этой задачи предназначен продукт CA Unicenter Service Desk. Внедрение системы Service Desk позволит систематизировать работу службы технической поддержки, разработать основные процессы приема и обработки заявок, сформировать наиболее интересные отчеты. В варианте out-of-the-box этот процесс может занять 1,5—2 месяца. Опираясь на полученные в течение последующих 2—3 месяцев работы службы Service Desk аналитические данные,  можно будет детально определить дальнейший план развития в рамках методологии ITSM.

Шаг 3. Внедрение мониторинга производительности сетевой и канальной инфраструктуры (network & server performance management)

Основное назначение этой подсистемы:

• Оперативный мониторинг загруженности и использования контролируемых физических и логических элементов сети.

• Мониторинг различных SLA-параметров.

• Формирование и отображение сигналов тревоги при превышении контролируемыми параметрами пороговых значений.

• Накопление и анализ статистических данных о производительности контролируемых систем.

• Генерация разнообразных форм отчетности, включая графическое представление.

Задача проактивного мониторинга, как правило, возникает на этапе перехода к сервисному подходу в оказании ИТ-услуг (ITSM). Формулирование метрик оказываемых услуг позволяет определить количественное выражение качества этих услуг. Проактивный мониторинг позволяет обнаруживать возможные проблемы еще до того, как произойдут деградация качества сервисов и нарушение SLA. Длительное наблюдение за параметрами работы всех интересующих элементов ИТ-инфраструктуры и сервисов позволяет генерировать различную статистическую отчетность, планировать долгосрочные инвестиции в инфраструктуру на основе объективных показателей, оптимизировать использование существующего оборудования. В рамках законченного комплекса на базе линейки продуктов компании CA для решения этой задачи предназначен продукт CA eHealth. Внедрение системы performance management позволит перейти от реактивного способа управления ИТ-инфраструктурой к проактивному и тем самым оптимизировать расходы. Внедрение системы в варианте out-of-the-box занимает не менее двух месяцев. Связано это с принципиальными особенностями систем класса performance management, в частности, с параметрами агрегации данных. Как минимум, чтобы получить результат работы системы должна произойти агрегация за месяц (т.е. по данным, собираемым в течение месяца).

Шаг 4. Внедрение мониторинга производительности работы корпоративных приложений (application performance management)

Основное назначение этой подсистемы аналогично назначению подсистемы network & server performance management, но только эти задачи решаются в домене приложений. Большинство корпоративных приложений построено по трехзвенной архитектуре с использованием платформ на базе J2EE или .NET. Дополнительно существуют системы документооборота, ERP и различные порталы.

Задержки в обработке заказа по причине длительного отклика приложения (не говоря уже о сбоях) могут найти весьма точное отражение в финансовых потерях. С другой стороны, в силу большой сложности и многофакторности архитектуры корпоративных приложений практически невозможно без применения специализированного инструментария определить причину деградации производительности. Даже если все составные элементы: клиентская часть, сеть, сервер представлений, балансировщик, серверы баз данных и т.д. — работают в штатном режиме, качество работы приложения может быть неудовлетворительным.

Для решения задач такого класса должны использоваться специализированные системы мониторинга, которые позволяют как отслеживать с точки зрения конечного пользователя параметры выполнения отдельных транзакций и бизнес-транзакций, являющихся объединением отдельных транзакций в рамках одной бизнес-операции, так и контролировать параметры работы приложений изнутри. В рамках законченного комплекса на базе линейки продуктов компании CA для решения этой задачи предназначен продукт CA Wily. Внедрение системы в варианте out-of-the-box возможно только для коммерчески распространенных продуктов, например, OEBS, SAP, Siebel, BEA WebLogic, IBM WebSphere, JBoss, SQL Server (DB2, Microsoft, Oracle, Sybase), и занимает около 1,5—2,5 месяца. Для различных самостоятельно разработанных решений внедрение может занять больше времени, поскольку потребует детального предварительного обследования существующих бизнес-процессов и их связки с программным комплексом компании.

Особенности выбора

Опыт интегратора показывает, что очень часто пренебрежение долгосрочным анализом развития приводит к ошибкам при первоначальном выборе программного решения, будь то система документооборота или система мониторинга. И чем раньше совершена ошибка — выбран слишком сложный и дорогой в обслуживании программный продукт, продукт не обладает всей требуемой функциональностью, продукт плохо масштабируется, продукт не интегрируется с последующими приобретениями, продукт снимается с поддержки и т.п., — тем сложнее дальнейшее развитие и дороже стоимость совершенной ошибки.