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

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

К примеру, менеджера по продажам в компании, занимающейся торговлей по каталогу, могут приводить в недоумение возникающие время от времени странные всплески интереса клиентов. Даже с применением развернутого BI-анализа (Business Intelligence) не удается определить причину этих перепадов. По непонятной для расстроенных менеджеров причине регулярно отказывают серверы выполнения заявок — ситуация, прекрасно знакомая сотрудникам ИТ-отделов. Пока ИТ-специалисты выясняют причину отказа и перезапускают сервер, заказы откладываются, выполняются неправильно или просто теряются. А неделей позже разъяренные клиенты выстраиваются в очередь, чтобы вернуть покупки. Тем временем менеджерам остается лишь наблюдать, как падает прибыльность, при этом они и не догадываются, что имеющиеся в компании серверы обходятся слишком дорого из-за потерянных продаж и клиентов.

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

Больше, чем сумма частей

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

Ключ к реализации инфраструктурной аналитики — разработка исчерпывающего набора ключевых показателей деятельности (key performance indicators, KPI) для бизнес-систем. В перечень KPI обычно включают такие метрики, как частота перемещения между серверами из-за сбоев, загруженность полосы пропускания и число одновременно подключенных пользователей.

Для определения KPI в конкретной инфраструктуре нужно в первую очередь создать представления ИТ-систем по направлениям бизнеса (line-of-business, LOB). Каждое LOB-представление должно отражать подсистему, поддерживающую определенную область деятельности предприятия, такие, как продажи, разработка, обеспечение присутствия в Web и т. д. Эти представления часто перекрываются: например, одна сеть может обслуживать многие бизнес-подразделения. Проблема подобного перекрытия может быть решена при подключении новых источников данных к имеющимся BI-механизмам, обычно в виде хранилища данных. На первом этапе достаточно просто сгруппировать системы и их компоненты по направлениям.

После создания видов инфраструктуры в разрезе направлений необходимо изучить обязательные связи между выделенными модулями. В качестве подобных связей могут выступать соглашения об обязательном уровне сервиса (service-level agreement, SLA) и лицензировании. SLA — это обязательные к выполнению соглашения между подразделениями и их клиентами и партнерами — как внутренними, так и внешними. Хотя SLA жизненно необходимы для нормальной работы бизнес-подразделений, они пользуются дурной славой из-за трудности их реализации. Определив в каждом соглашении метрики производительности, можно отслеживать результаты в контрольных точках и таким образом контролировать выполнение соглашения. Сопоставляя эти данные с другой BI-информацией, можно судить о целесообразности того или иного соглашения об уровне сервиса или даже моделировать результаты предлагаемых изменений.

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

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

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

Доступные ресурсы

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

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

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

Вам следует разработать матрицу, которая показывает связи между целевой информацией (вашими KPI), существующими элементами системы и развернутыми средствами мониторинга. В качестве последних могут применяться либо первоклассные пакеты, такие, как Unicenter компании Computer Associates, HP OpenView или Service Level Advisor из пакета IBM Tivoli, либо условно-бесплатные средства (shareware), например, Big Brother (недавно приобретенный компанией Quest Software) и MRTG. Итоговые карты должны создаваться в разрезе направлений бизнеса — одна матрица на каждую область деятельности предприятия. После однократного уточнения эти карты становятся первым, грубым приближением конечных витрин данных. Наиболее важно то, что пустые ячейки в карте указывают на пробелы в сборе информации, и их необходимо заполнить.

После создания этих матриц мониторинга разрабатывают полный список источников данных, в котором следует указать все журналы и отчеты, имеющиеся во всех источниках. В дополнение к существующим журналам необходимо указать все журналы, которые в принципе можно создавать, но которые не применяются. Также требуется детально исследовать отчеты: даже если стандартный результат работы инструмента — это HTML-отчеты, которые лишь отчасти можно считать источником данных, может оказаться полезно обратиться к базовым журналам, доступным даже если их публикация не предусмотрена. Кроме текстовых журналов многие инструментальные средства мониторинга аккумулируют информацию в SQL-совместимых базах данных. В общем случае работать с этими источниками намного проще, чем с «сырыми» журналами, поэтому рекомендуется применять именно их, если это возможно.

Устранение пробелов

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

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

Например, известно, что журналы Web-сервера и информацию о статистику посещений и переходов очень сложно «загнать» в хранилище в детализированном виде. Однако, подсчитав сводные данные о поведении посетителей, удается создать ценные метрики. Например, можно определять продолжительность посещения отдельных страниц на Web-узле каждым из посетителей. Эта информация часто оказывается ценной, но представляет собой огромный и сложный для управления объем данных; поэтому свертка таких данных к средней продолжительности посещения отдельной страницы может оказаться более разумной. Точно так же фильтрация информации в ETL-процессе (extract-transform-load — «извлечение-преобразование-загрузка») иногда позволяет обойти конфигурационные ограничения. Инструменты мониторинга иногда информируют о состоянии отдельных компонентов (например, зеленым, желтым или красным цветом). Если нас интересует только критичное состояние (красное), но при этом другие нельзя исключить из результатов вывода, их можно просто отфильтровать в процессе загрузки информации в хранилище данных или сохранить как простой счетчик.

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

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

Дэрин Стюарт (Darin Stewart) — директор по управлению информацией в компании CenterSpan Communications. С ней можно связаться по e-mail: darin@centerspan.com.