По-видимому, большинство инициатив в области хранилищ данных сегодня ориентировано на предоставление отделам продаж, маркетинга и финансов той информации, которая необходима им для поддержки клиентов и понимания финансовых основ компании. Если вы работаете в ИТ-подразделении (скорее всего, так оно и есть, раз вы читаете этот журнал), то практически всегда разрабатываете системы поддержки принятия решений для других. Вряд ли вы сами пользуетесь преимуществами подобных решений.
По мере распространения информационных технологий на все области деятельности компании и сокращения числа людей, занятых управлением ИТ-инфраструктурой, становится жизненно необходимо создать базу знаний о критически важных системах, разрабатываемых и поддерживаемых ИТ-отделом. Я участвовал в создании оперативной системы управления активами (Operational Asset Management System, OAMS) для компании, предоставляющей финансовые услуги. На основе этой системы были организованы сложные хранилища данных с витриной данных, поддерживающие работу ИТ-подразделения.
Подумайте, знаете ли вы конфигурации всех корпоративных приложений своей компании. В отрасли финансовых услуг (как, впрочем, и во многих других сферах) разрабатываются чрезвычайно сложные приложения, охватывающие множество серверов, операционных систем и сетей. Эти приложения обычно отображают продукты и услуги, предлагаемые финансовой компанией, чьи клиенты ежедневно выполняют критически важные финансовые операции.
Часто компании сталкиваются с проблемой отсутствия централизованного хранилища информации обо всех прикладных компонентах и схемах их связей между собой. В условиях распространения технологий распределенных вычислений сбор и хранение информации о компонентах приложений сильно усложнятся, если не уделить вовремя должного внимания этой проблеме.
Так зачем же необходимо единое «видение» ИТ-инфраструктуры? Было бы замечательно, если бы каждое отдельное приложение постоянно находилось на собственном, четко определенном наборе инфраструктурных компонентов. В таких условиях отказ какого-либо сервера приводил бы к сбою только одного приложения и касался бы только одного продукта и ограниченного подмножества клиентов. Тогда достаточно было бы уведомить менеджеров соответствующего подразделения о нарушении работы системы, чтобы те поставили в известность своих клиентов.
Но, как вы прекрасно знаете, в действительности все намного сложнее. В реальном мире нередки ситуации, когда на серверах располагаются несколько приложений или группы серверов обслуживают одно приложение. Отображенная на бумаге структура таких приложений часто напоминает небрежно сплетенную паутину. Поэтому при отказе одного сервера вам вряд ли будет легко определить, какие приложения или программы затронет этот сбой и какие клиенты будут в ярости из-за недоступности сервиса. Один-единственный отказ критически важного приложения в крупном банке может обойтись в миллионы. У большинства организаций нет надежного метода определения и представления взаимозависимостей между приложениями и их компонентами.
Хуже непонимания того, как сконфигурированы компоненты приложений, может быть только полное отсутствие информации. В крупных компаниях многие приложения разрабатывались и совершенствовались на протяжении долгих лет. Информация, необходимая для восстановления целостной картины, часто содержится в головах разработчиков и сотрудников, хорошо знающих систему. Проблема в том, что у большинства компаний нет центрального места хранения и получения данных о прикладных компонентах.
А теперь задайтесь вопросом, легко ли вам отслеживать, управлять и развертывать ИТ-системы. Большинство организаций не в состоянии быстро собрать непротиворечивую ключевую информацию о своих ИТ-активах, в том числе о компонентах приложений, серверах и программах. Управление ИТ-активами жизненно необходимо для планирования финансов; кроме того, повторное использование активов, особенно логических компонентов, — по-настоящему ценная возможность в современных условиях строгой экономии.
Горы данных об ИТ-инфраструктуре собираются ежедневно с применением несвязного набора программных инструментов. Приложения управления системами превосходны для мониторинга производительности сервера, в частности, параметров использования памяти и дискового пространства. Некоторые приложения для администрирования систем прекрасно подходят для управления базовыми параметрами прикладных программ (финансы, расположение и конфигурация). Сетевые диаграммы могут использоваться для определения того, как кластер сервера приложений подключен к локальной или глобальной сети. В результате, независимо от способа организации хранилища данных, создается следующая ситуация: каждый из разобщенных репозиториев представляет свою версию «правды», причем все они с трудом поддаются управлению, изменению инфраструктуры, развитию приложений и практически недоступны для партнеров по бизнесу. Хуже всего то, что эти системы построены на разных платформах и в разных архитектурах, а потому не обеспечивают единого видения архитектуры, компонентов, производительности или бизнес-функций приложения.
Ключ — в обмене информацией. Если компьютерные приложения служат в компании основой предоставления продуктов и услуг (например, в банке), менеджерам абсолютно необходимо знать, какие программы и каких клиентов затронет отказ того или иного сервера. Прежде всего необходимо позаботиться о том, чтобы центр управления сетью (network operations center, NOC) контролировал целостность сети и немедленно уведомлял об отказах серверов. Кроме того, NOC должен «уметь» проанализировать, какие приложения затрагивает отказ, и заранее ставить в известность менеджеров отделов маркетинга и продаж.
Решение
Как следует из названия, система OAMS — это хранилище знаний о приложениях и прикладных компонентах компании, обеспечивающее сквозное представление взаимозависимостей компонентов ИТ-инфраструктуры. OAMS — это своего рода витрина данных, в которой собирается и поддерживается критически важная информация о приложениях и их компонентах, в том числе о конфигурации системы, логической и физической архитектуре, важных бизнес-функциях, принадлежности приложений, контактах, журналах изменений и взаимозависимостях приложений предприятия.
Цель создания OAMS заключается также в формировании библиотеки для отслеживания и управления компонентами, которая поможет менеджерам шире применять повторное использование активов и эффективнее создавать приложения.
В OAMS определяются элементы системы и их связи друг с другом. В случае планового или внепланового отключения подсистемы аналитики смогут определить, как оно повлияет на другие компоненты системы, а эта информация позволит им уведомить соответствующие подразделения, чтобы устранить последствия внепланового отключения, или предупредить все заинтересованные стороны о запланированной остановке.
OAMS — основной механизм обмена информацией о приложениях. Интерфейс этой системы обеспечивает доступ к информации, в том числе к контактам (техническим или связанным с бизнесом), сведениям о регламентных работах, хронологии изменений и статистике производительности.
Мы создали OAMS для объединяющей несколько банков холдинговой компании с суммарным объемом собственных средств в 38 млрд долл., имеющей к тому же свыше 300 млрд долл. в инвестиционном управлении. Офисы участников холдинга расположены в 12 штатах США и пяти странах, банки выступают как ведущие поставщики услуг доверительного управления средствами физических и юридических лиц, а также кредитных, депозитарных и казначейских услуг.
Проект
До начала работы над проектом создания OAMS мы определили два параметра системы, жизненно важных для успеха мероприятия: максимальная возможность наращивания базы данных OAMS и широкие средства анализа и отчетности. Мы провели исследование с целью выяснить, есть ли на рынке готовая программа, отвечающая требованиям к OAMS, и пришли в выводу, что подобного коробочного продукта не существует. Поскольку OAMS — принципиально новое приложение, мы знали, что не сможем спрогнозировать все возможные области ее применения и, следовательно, все необходимые атрибуты. Учитывая это, OAMS должна была легко приспосабливаться к добавлению новых атрибутов приложений или прикладных компонентов без существенной перестройки системы.
При завершении разработки документа о сценариях использования системы (use cases) мы пришли к выводу, что OAMS потребуется механизм отчетности, который позволит легко представлять самую разнообразную информацию в текстовой и графической форме для всех заинтересованных сторон. OAMS должна представлять информацию об ИТ-инфраструктуре с различных точек зрения. Например, менеджеру по разработке приложений может потребоваться увидеть все серверы и взаимозависимости, относящиеся к определенному приложению. Администратор Unix-систем, скорее всего, будет запрашивать информацию о том, какие приложения и прикладные компоненты располагаются на конкретном рабочем сервере. Наконец, бизнес-менеджер воспользуется сведениями о том, какие продукты поддерживаются приложениями, работающими на указанном сервере.
Мы решили, что для удовлетворения технических и функциональных требований подойдет структура традиционной витрины данных, которая может обеспечить необходимую для OAMS гибкость при добавлении дополнительных атрибутов и поддержке разнообразной отчетности. База данных была разработана на основе многомерной модели с таблицами фактов и вспомогательными таблицами измерений в соответствии с архитектурой топологии «звезда».
Абстрактная модель
Для эффективного сбора информации, необходимой для определения влияния отключений систем, OAMS должна различать компоненты, из которых состоят приложения, и их взаимосвязи. Мы быстро обнаружили, что нет никакой унифицированной структуры приложений. Конфигурация отдельного приложения напоминала традиционную иерархическую организационную схему, однако при моделировании множественных приложений создавалась сложная структура, похожая на смешение иерархических и матричных схем. Мы разработали абстрактную логическую модель, чтобы описать отношения между приложениями и их компонентами.
В рамках OAMS определяются компоненты систем, а затем — их связи. В таблице перечислены ключевые термины, применяемые для определения компонентов в OAMS.
Термины, применяемые при определении компонентов в OAMS
| Термин | Определение |
| Приложение | Группа прикладных компонентов, рассматриваемая как единый модуль, решающий конкретную бизнес-задачу |
| Компонент приложения | Любая программа, задача которой заключается в выполнении конкретной функции непосредственно для пользователя или другого компонента приложения |
| Кластер | Совокупность сгруппированных экземпляров приложения, работающих как единая система и обеспечивающих высокую доступность, балансировку нагрузки и параллельную обработку |
| Экземпляр кластерного приложения | Один ресурс четко определенного кластера |
| Тип компонента | Общий термин, описывающий приложение, компонент приложения, кластер, экземпляр кластерного приложения, платформу или сервер |
| Связь компонентов | Объект, объединяющий компоненты |
| Зависимость | См. Связь компонентов |
| Платформа | Информационная система, предоставляющая сервисы прикладного уровня |
| Экземпляр платформы | Определенная установленная копия платформы |
| Сервер | Физическое устройство |
| Зависимость, определяемая системой | Система, устроенная так, что новый компонент нельзя создать без предварительного создания отношения между этим компонентом и компонентом, от которого он зависит |
| Зависимость, определяемая пользователем | Определенная в системе связь, в которой пользователь (человек) устанавливает связь между двумя компонентами приложения или между компонентом и приложением |
Факты и измерения
Абстрактная модель OAMS становится реальной после создания таблиц фактов и измерений. Прежде всего создавались таблицы фактов, отражающие зависимости внутри отдельных приложений. Например, каждая запись в таблице фактов может описывать отношения между приложением, прикладным компонентом, платформой и сервером. Подобная таблица фактов, в сущности, не содержит самих «фактов», так как в записях не содержится каких-либо определенных числовых метрик.
Таблицы измерений поддерживают все эти компоненты абстрактной модели, расположенные в таблицах фактов. Они описывают характеристики и атрибуты всех компонентов приложения, таких, как платформы, кластеры и серверы.
Таблицы измерений также содержат информацию, полезную для самых разных пользователей. Сотрудники группы поддержки найдут в них сведения о производительности и хронологию изменений, бизнес-партнеры — контактную информацию и сведения о состоянии, а также расписание регламентных работ, а отдел финансов — информацию об управлении активами, в том числе данные о закупках, ценах и нормах износа.
Будущее OAMS
Внедрение OAMS позволило создать систему общекорпоративного конфигурационного управления, и работа над ней продолжается. Первый этап фокусировался в основном на задачах сбора и отображения информации о зависимостях между сложными специализированными приложениями. На следующих этапах создания OAMS предполагается включить в нее дополнительные уровни информации об ИТ-среде. Система будет расширена за счет интеграции инструментов системного мониторинга и приложений управления бизнес-операциями. В конечном счете OAMS сможет собирать данные о других логических (нефизических) компонентах, например, о прикладном коде.
В современных условиях консолидации и финансового аскетизма компания обязана собирать сведения об интеллектуальном капитале предприятия. Теперь организации осознали потребность фиксировать рабочие параметры критически важных для бизнеса приложений, так как они создаются многими сотрудниками, часть из которых впоследствии могут покинуть компанию. Большинство хранилищ данных ориентировано на поддержку маркетинга, продаж, финансов и учета. У сотрудников ИТ-подразделения редко есть возможность обзавестись витриной данных для собственных нужд. Такие приложения, как OAMS, обеспечивают ключевую для повседневного обслуживания информацию, которая жизненно важна для работы ИТ-служб и их бизнес-партнеров сегодня и в будущем.
| Джеймс Д. Ньюман (James D. Newman) — руководитель и один из основателей Acquity Group, в которой возглавляет BI-практику. С ним можно связаться по e-mail: jim.newman@acquitygroup.com. |
