Сергей Кирюшин, Аэрофлот: Двести приложений и один информационный ресурс.

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

Intelligent Enterprise: В вашей компании существует широкий спектр разнообразных бизнес-приложений, и с каждым из них связаны какие-то данные. Можно ли говорить об этих данных как о едином ресурсе, имеющем самостоятельное значение вне контекста тех бизнес-приложений, к которым они относятся?

Сергей Кирюшин: У нас в настоящее время функционирует около двухсот приложений, с каждым из которых, естественно, связана генерация тех или иных значимых для бизнеса данных. В такой ситуации действительно можно говорить о том, что корпоративные данные вряд ли целесообразно рассматривать исключительно в контексте соответствующих бизнес-приложений. Их количество растет лавинообразно, и для того чтобы справиться с такой ситуацией, необходима надежная инфраструктура. В нашей компании эта проблема во многом решается за счет развития центра обработки данных. Надо сказать, что вопросы создания надежной ИТ-инфрастуктуры сейчас обсуждаются довольно часто, да и с вашим журналом мы на эту тему говорили (см. IE, №9/2005. — Прим. ред.). Несколько иную проблему представляет вопрос, каким образом накапливаемые данные можно наиболее эффективно использовать. Её решение, надо сказать, далеко не всегда напрямую связано с расширением применения или повышением эффективности работы непосредственно ассоциируемых с этими данными бизнес-приложений. Надо знать, какие данные, к примеру, целесообразно консолидировать, а какие можно было бы удалить с дисковых массивов, предварительно где-нибудь сохранив «на всякий случай». Это только самые простые примеры большого пласта проблем эффективности использования информационного ресурса на предприятии в целом. Они качественно иные, чем проблемы формирования надежных аппаратных или программных платформ хранения данных и доступа к ним. Здесь у нас пока не всё решено, и мы в общем только приступаем к этой работе.

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

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

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

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

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

Сейчас много говорится о новых подходах к хранению информации, которые в гораздо большей степени, чем раньше, привязаны к реальным бизнес-процессам использования данных на предприятии. Как вы к ним относитесь?

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

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

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

По пути количественного наращивания недорогих дисковых систем хранения, насколько мне известно, идет и хорошо всем известная Google. При этом для обеспечения надежного хранения данных, размещаемых на недорогих аппаратных ресурсах, приходится платить необходимостью иметь собственную операционную систему и систему управления базами данных и выполнять множество самостоятельных доработок, в том числе на аппаратном уровне.

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

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

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

Мне кажется, для интеграции внутри предприятия форматы данных, хранимых в различных информационных системах, не играют решающей роли. У нас исходная информация, имеющая общекорпоративное значение, при помощи классических средств извлечения, преобразования и загрузки данных ETL-средств или инструментов, имеющихся в составе WebSphere, поступает в хранилище. Для этой задачи целенаправленно использовать XML нет смысла. XML играет большую роль при информационном обмене между различными предприятиями. Данный формат имеет гибкую и понятную структуру, принят корпоративным сообществом и при этом избавляет общающиеся между собой организации от необходимости строить сложную и далеко не безупречную с точки зрения информационной безопасности логику «взаимопроникновения» разных корпоративных систем друг в друга. Здесь преимущества XML неоспоримы.