Консалтинг и автоматизация в области управления
эффективностью банковского бизнеса

Публикации

CIO

Моделирование работы хранилища данных банка

Не секрет, что большинство российских банков, как и их зарубежные коллеги, в условиях экономического кризиса начинают снижать затраты на ИТ. Решение это вполне разумное и, более того, безальтернативное. Однако вопрос сейчас заключается даже не в том, сокращать или нет инвестиции в ИТ, - проблема в том, каким образом осуществлять урезание бюджета с минимальными последствиями для бизнеса. И вот здесь оказывается, что есть разумные пределы сокращения затрат на ИТ, при переходе которых даже крупный банк может поставить крест на своем существовании. Как справедливо замечает заместитель генерального директора по развитию бизнеса компании Intersoft Lab Юлия Амириди, даже работая в "режиме выживания" или находясь на грани банкротства, кредитные организации обязаны поддерживать информационные системы, обеспечивающие обязательные задачи, например, проведение платежей. Аналогичная ситуация складывается и с направлением автоматизации выпуска отчетности для Банка России.

Дело в том, что на фоне кризиса БР начал принуждать наши банки совершенствовать системы выпуска отчетности. Это, опять же, следует рассматривать как вполне логичный и естественный процесс: государство, спасая финансовые учреждения от краха, хочет быть уверенным в том, что они занимаются полезной деятельностью, а не валютными махинациями. На наш вопрос о зависимости финансовых учреждений от ИТ заместитель генерального директора по информационным технологиям и операциям компании КИТ Финанс Страхование Александр Сахаров ответил буквально следующее: "У банков ежедневное закрытие дня - это несколько миллионов операций, и провести его без ИТ невозможно. Если же мы говорим об учреждениях из топового списка (первые 30 банков России), то у них насколько жесткая зависимость от ИТ-системы, что без нее они не просуществуют и 24 часа. Например, мы не закроем сегодня день - на следующие сутки получим предписание, а еще через день лишимся лицензии. Таковы сегодняшние требования регуляторов".

В результате банки откладывают свои задачи по автоматизации кредитных фронт- и бэк-офисов, сосредоточиваясь на автоматизации отчетности для БР. Как эта ситуация отражается на рынке наших ИТ-компаний? Они массово перепрофилируются на выпуск средств подготовки регулятивной отчетности на базе хранилищ данных. Intersoft Lab прогнозирует к середине 2009 года увеличение количества вендоров, специализирующихся на выпуске данного вида продукта, до 8-10 компаний. И здесь перед банками возникает нелегкая проблема выбора: какое из существующих решений хранилищ данных отвечает их потребностям?

Принять решение очень непросто, особенно в той части, которая касается аппаратной составляющей. Производители серверов могут часами описывать достоинства своих систем, заваливая вас всевозможной технической документацией. Создатели, скажем, процессоров Itanium будут с увлечением рассказывать о том, сколько миллиардов транзисторов им удалось разместить на кристалле Montecito, какой мощный кеш получили новые камни. Разработчики серверов HP Integrity будут поражать воображение миллионами операций в секунду, которые может осуществлять их детище. Однако заказчику нужны не эти абстрактные цифры - его интересует практическая составляющая: сколько минут понадобится серверу для загрузки лицевых счетов, клиентских данных, операций, документов? Сколько часов уйдет на архивную загрузку данных? И он потребует ответы на эти вопросы, исходя из конкретных объемов операций, которые зависят от размеров банка и емкости его фактической клиентской базы. Ему будет важно знать, сколько времени займет, например, агрегация оборотов лицевых счетов за день, месяц и квартал? Или, скажем, сколько минут уйдет на агрегацию остатков лицевых счетов за месяц, исходя из расчета данных по балансовым счетам по 3 млн. ЛС?

Компания Intersoft Lab решила создать компьютерную модель работы хранилища данных банка и протестировать ее на оборудовании HP. Сперва была проведена классификация банков по объемам бизнеса. Опираясь на такие ключевые характеристики, как позиционирование финансового учреждения, размер его дистрибьюторской сети и клиентской базы, количество лицевых счетов и проводимых транзакций в сутки, все банки были разбиты на 4 основные категории: небольшие банки, специализирующиеся на корпоративном обслуживании; банки, с развитым сектором обслуживания корпоративных клиентов, мелкого и среднего бизнеса; крупные региональные банки, в том числе универсальные; крупные розничные банки.

Затем разработчики модели определили приблизительные объемы данных (клиенты, лицевые счета, остатки, обороты, операции, документы), загружаемых банками соответствующих групп в хранилище по окончании каждого операционного дня. Естественно, что показатели здесь отражают масштабы кредитной организации: если небольшой банк, специализирующийся на корпоративном обслуживании, может загружать в хранилище 20 000 операций, то у крупного розничного банка эта цифра доходит до 3 млн. Отдельно были определены объемы данных, загружаемых в хранилище при внедрении системы (так называемая архивная загрузка). Здесь уже иные цифры, скажем, для розничного банка количество загружаемых операций может превышать 100 млн., а количество лицевых счетов доходить до 10 млн. На основании общего количества объектов (клиенты, лицевые счета, документы и пр.) в тесте просчитывался общий объем загружаемых данных в Гбайт и задавался загрузочный профиль: 1-й - 1,3 Гбайт; 2-й - 6,5 Гбайт; 3-й - 5,08 Гбайт; 4-й - 12,7 Гбайт; 5-й - 25,52 Гбайт.

Непосредственно для теста компания Intersoft Lab использовала свое хранилище данных "Контур Корпорация" версии 3.х, созданное на базе СУБД Oracle 10g Enterprise Edition. В качестве аппаратной платформы было решено использовать сервер HP Integrity rx8640 (Intel Itanium [Montecito] 1,6 ГГц/24 Мбайт кеш, 16 чипов/32 ядра, 64 Гбайт RAM), работающий на операционной системе HP-UX 11.31, и дисковый массив HP StorageWorks EVA 8000 (15K, RAID10). Сервер HP Integrity был соединен с дисковым массивом по волоконно-оптическому каналу, а по гигабитной сетке к rx8640 подключались: сервер обмена данными HP ProLiant ML350 G4; рабочая станция с терминальным доступом к HP ProLiant и удаленная рабочая станция с терминальным доступом через интернет.

Использование такой мощной аппаратной платформы в сочетании с передовыми программными решениями обеспечило отличные результаты тестирования. Например, процесс загрузки в хранилище данных о 800 тыс. клиентов занял 5 мин, а 7 млн. счетов - 1 час. Критичная по времени операция перезагрузки данных заняла 30 с: на перезагрузку данных о 100 клиентах системе потребовалось 0,1 с; 5 тыс. лицевых счетов - 2,7 с; 5 тыс. остатков по счетам - 1,7 с; 10 тыс. оборотов по лицевым счетам - 3,3 с; 15 тыс. документов - 10,9 с; 15 тыс. операций - 11,3 с. Время выполнения наиболее ресурсоемких операций находится в линейной зависимости от нагрузки, что свидетельствует о высокой масштабируемости решения. Понятно, что и компьютерная модель не даст ответов на все интересующие заказчика вопросы, но составить предварительные выкладки она, безусловно, поможет. Затем уже можно будет выбрать конкретное решение, тем более, что и Intersoft Lab, и HP предлагают своим клиентам гибкий подход, способный подстраиваться под их нужды. Если кого-то не устраивает СУБД Oracle 10g, то хранилище данных "Контур Корпорация" 3.0 может функционировать и на базе Microsoft SQL Server. Возможно, вашей организации не требуется вся мощность HP Integrity rx8640 - тогда HP предложит более экономичные решения начального уровня HP Integrity rx2660/rx3600/6600. Если же речь идет о крупном банке, то могут понадобиться другие решения High End класса - серверы HP Integrity Superdome.

 

Производители уверены, что банки, глядящие "за горизонт кризиса", обязательно будут обновлять свои системы хранения данных. Конечно, финансовые директора сегодня настроены скептически, и мы можем здесь напомнить, что сказал по поводу тех же ЦОД Президент Санкт-Петербургского клуба ИТ-директоров Максим Белоусов: "В условиях кризиса проекты построения резервного ЦОД заморозились у множества компаний до того времени, когда снова появиться возможность инвестировать такие решения". Однако у этого утверждения есть и оборотная сторона медали: раз уж вы не можете позволить себе резервную систему хранения и обработки данных, раз нет денег на второй сервер, резервный канал, то это автоматически означает, что ваша основная система должна работать просто безукоризненно. А это, опять же, возможно лишь при том условии, что ИТ-инфраструктура банка постоянно обновляется и поддерживается в отличном состоянии.

 

Да, в эпоху кризиса многие предпочитают экономить на технике и ПО. В этой методике нет ничего нового: помнится, немецкий генерал-фельдмаршал Эрвин Роммель, командовавший корпусом в Северной Африке, в условиях катастрофической нехватки ресурсов использовал так называемую "тактику безрезервных боев". Роммель был гениальным полководцем, но, как известно, даже ему не удалось спасти от капитуляции Африканский корпус. Так стоит ли повторять чужие ошибки и ставить под удар будущее своего финансового учреждения?