Развивая комплекс фронт-офисных приложений, специалисты Альфа-Банка столкнулись с непростой ситуацией: при переходе на новую процессорную платформу и новую версию сервера приложений производительность не только не возросла, но и значительно упала. Путь решения этой проблемы уникален для России — была создана специальная группа из специалистов IBM, HP, BSC и Альфа-Банка. Об этом рассказывают директор по информационным технологиям Альфа-Банка Сергей Меднов, начальник управления сопровождения информационных систем Виктор Алферов и начальник отдела оптимизации производительности Денис Антохов.

Intelligent Enterprise: Какие задачи решал проект по построению фронт-офисных приложений?

Сергей Меднов: В 2003--2005 годах розничное подразделение Альфа-Банка последовательно запустило несколько новых розничных сервисов, в том числе потребительское кредитование, автокредитование и SMS-банкинг (оповещение клиентов об активных транзакциях через SMS). Кроме того, мы планировали предложить услуги в области интернет-банкинга, и сейчас «Альфа-Мобайл» (Java-приложение, с помощью которого можно управлять своими счетами с мобильного телефона -- уникальный продукт на банковском рынке) позволил нам занять одно из ведущих мест на этом рынке. Кроме того, совершенствовались и традиционные продукты – персональные кредиты, банковские карты и прочее. Понятно, что все эти сервисы не могли быть запущены без создания соответствующих ИТ-систем, и инвестиционные проекты по развитию розничного бизнеса включали в себя в том числе и ИТ-разделы. И в 2004 году мы начали большой проект по созданию фронт-офисных приложений и объединению их в одну систему. Владельцем процесса выступал розничный бизнес банка, а мы являлись исполнителем и технологическим организатором. Мы опирались на мощный бэк-энд в виде основной банковской системы Misys Equation и других надежных технологий, базирующихся на серверах IBM System i. В качестве фронт-офисной системы мы выбрали приложение Gemini чешской компании BSC, которое работает под управлением IBM WebSphere Application Server на базе серверов HP. Мы тяжело трудились и за три года сделали большой комплекс фронт-офисных приложений.

Какие обстоятельства повлияли на выбор ИТ-решений? Почему вы остановились на IBM WebSphere Application Server?

Сергей Меднов: Решение задачи осложняли несколько обстоятельств. Во-первых, весьма бурный, и подчас непредсказуемый рост этих сегментов бизнеса. Новые розничные сервисы Альфа-банка запускались быстро, рынок агрессивно рос, особенно в области потребительского кредитования, где он ежегодно удваивался. Кроме того, в 2003--2004 годах банк активно создавал сеть отделений и точек продаж «Альфа-Банк–Экспресс» для всех направлений бизнеса. Причем если классические розничные отделения банка должны поддерживать все сервисы, то, например, потребительские кредиты выдаются и в сетях розничных магазинов, а автокредиты – в дилерских сетях.

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

Централизация решения определялась только требованиями топ-менеджмента?

Сергей Меднов: Нет, не только. На единой системе должны быть построены все новые сервисы, которые розничное отделение Альфа-Банка вводило с 2004 года, в этой же архитектуре должен был находиться и интернет-банкинг. Причем, все новые направления бизнеса должны были работать на единой платформе, чтобы через несколько лет по мере накопления необходимой информации получать дополнительные преимущества от перекрестного анализа данных по этим направлениям. Кроме того, понятно, что централизованное решение проще сопровождать и дешевле обслуживать. Хотя, конечно, у такой архитектуры есть и обратная сторона – повышенные требования к надежности и производительности, и с этими проблемами нам потом пришлось столкнуться. Мы вообще стараемся выбрать промышленное, масштабируемое решение, которое имеет соответствующую поддержку в России, для нас это очень важно. IBM WebSphere Application Server прекрасно подходит под эти требования. Кроме того, и наши чешские партнеры – компания BSC– открыли филиал в Москве.

Почему вы выбрали серверы HP? Разве не логично для ПО IBM выбрать ее же серверы?

Сергей Меднов: У Альфа-Банка есть два крупных поставщика серверных решений – HP и IBM. Решающую роль в выборе HP сыграл опыт сотрудничества с этой компанией. В банке давно используется оборудование HP, функционирует несколько поколений серверного оборудования и ОС, работают очень грамотные специалисты, и с этой точки зрения наш выбор -- это защита инвестиций. Конечно, нет сомнений, что данное решение будет работать и на оборудовании IBM. Но у нас не было экспертизы по обеспечению работы WebSphere на оборудовании IBM. Зато был успешный опыт развертывания продуктов линейки WebSphere на серверном оборудовании HP, была экспертиза и опыт настройки IBM WebSphere именно на серверах HP. Кроме того, подобное сочетание различных вендоров очень нам помогло в дальнейшем при решении проблем производительности системы.

Каким образом при таком росте вы прогнозировали требуемую производительность системы? Как проводили сайзинг серверов?

Сергей Меднов: Масштабирование серверов по производительности мы проводили постепенно. Нельзя сказать, что нам видна конечная цель – окончательные параметры системы. Рыночные прогнозы весьма приблизительны. Так, в прошлом году прогнозировался рост корпоративного рынка на уровне 30%, а оказалось 40%. В этом году прогнозируется рост в 40%, но реально рынок сейчас растет на 50%, хотя последние события на валютных рынках могут внести коррективы в этот показатель. Такая же ситуация и с рынком потребительского кредитования. В России надо быть готовым к подобным темпам роста. Выход один: как будет развиваться бизнес, так будут развиваться и ИТ.

Опыт работы в таких условиях у нас был. Мы перенесли на этот проект наш опыт по масштабированию Misys Equation и других бэк-энд-систем и научились управлять производительностью. Ведь если посмотреть показатели, то с 2004 года количество счетов клиентов в бэк-энд-системе выросло более чем в семь раз, и мы поддержали такой рост. Кроме того, по прошлому опыту мы научились выбирать решения, приводящие к масштабированию. В этом отношении IBM WebSphere является продуктом, который обладает большим запасом. Аналогично мы рассматривали и линейку серверов HP.

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

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

Аналогично планируется и развитие оборудования. Понятно, что оборудование покупается с расчетом на планы бизнеса и первоначально вся мощность востребована не будет. Управление производительности банка проводит тесты новых версий системы и даёт рекомендации, какое оборудование можно использовать для данного ПО с определенной нагрузкой. Но планировать резерв мощности далеко вперед мы просто не можем – рост рынка непредсказуем, могут измениться и планы, и стратегия. С другой стороны, менять оборудование раз в несколько месяцев – это тоже дополнительные расходы, требующие приостановки развития. Мы ищем компромисс исходя из разумных сроков перехода на новое оборудование.

Поэтому первые версии системы были еще «сырыми», на них не были реализованы многие функции, и они работали на относительно слабом оборудовании. Но рост был очень быстрый, не хватало ресурсов, и уже через полгода нам пришлось менять оборудование. Мы перешли на машины среднего класса – четырехпроцессорные серверы HP на базе PA-RISC. Однако в целом мы идем в сторону централизованных серверов, которые можно перераспределить под разные потребности и задачи.

Сергей Меднов: Понятно, что вместе с расширением функционала шла оптимизация системы. На определенный момент мы получили оптимизированное решение, дальнейшие попытки что-то сделать с кодом были весьма трудоемки, а их конечный результат неизвестен. Мы видели, что система достаточно хорошо масштабируется, и решили взять более мощные серверы и масштабировать её через оборудование. Мы приобрели HP Superdome на основе восьми процессоров Itanium2, обладающий максимальной производительностью среди серверов HP. Для реализации преимуществ нового оборудования решили перейти с IBM WebSphere Application Server 5.1 на версию 6.1. И вот тут пришлось столкнуться с проблемой: мы не получили того роста производительности, который ожидали.

Расскажите подробнее, в чем заключались эти проблемы.

Денис Антохов: Версия 6.1 WebSphere Application Server позволила использовать платформу Itanium2 и увеличивать производительность за счет мощных аппаратных ресурсов HP Superdome. В результате перехода на 64-разрядную адресацию мы смогли задействовать оперативную память объемом свыше 2 Гайт. Кроме того, новая версия WebSphere Application Server имела расширенные возможности кластеризации.

Однако мы столкнулись с серьезной проблемой. Производительность системы WebSphere Application Server 6.1 на четырёхпроцессорном сервере HP на базе Itanium2 оказалась втрое ниже прогнозируемой и при этом вдвое ниже той, что обеспечивала предыдущая конфигурация WebSphere версии 5.1 с четырёхпроцессорным сервером на базе PA-RISC. И лишь на восьмипроцессорном сервере на Itanium2 система на WebSphere 6.1 показала примерно такую же производительность, как и WebSphere 5.1 и 4-процессорный сервер на базе PA-RISC.

Естественно, мы начали решать эту проблему. Сначала все работали над ней по отдельности -- разработчики приложения (BSC), специалисты IBM и эксперты из HP. Однако ни одна компания самостоятельно решить ее не смогла.

Сергей Меднов: Для меня как ИТ-директора ситуация выглядела довольно опасно. В отчетах руководству я вынужден был говорить, что при таком сумасшедшем росте предел производительности системы достигается очень быстро. И при этом решение проблемы производительности находилось вне зоны моей компетенции: оно не в нас и даже не в наших поставщиках – оно между ними. Договор на поставку Gemini включал ответственность за производительность приложения, c IBM – за производительность WebSphere, но ни один из производителей не брал на себя всю ответственность. Но появилась проблема, которую я как менеджер решить не могу. Прямого механизма решения этой проблемы не было видно.

И в этот момент мы вспомнили о соглашении между HP и IBM. Изначально при планировании инфраструктуры мы получили от IBM и HP информацию, что между ними существует альянс и компании объединяют свои усилия для совместного продвижения продуктов и решений друг друга, которые взаимодополняемы, что по системе IBM WebSphere Application Server поверх оборудования HP две корпорации сотрудничают и мы можем получить необходимую поддержку с обеих сторон. Альянс между HP и IBM и стал тем механизмом, который обеспечил решение возникшей проблемы.

Виктор Алферов: В итоге в октябре 2006 года начался совместный проект. На территории компании BSC в Праге был создан специальный испытательный стенд, для которого компания HP предоставила соответствующие технологические мощности, а Альфа-Банк -- реальные данные из своей «боевой» системы. Были собраны очень солидные «объединенные» силы: команда, участвовавшая в решении данной проблемы состояла более чем из сорока специалистов из девяти стран -- 20 экспертов HP (технические консультанты из США, Германии, Великобритании и Испании), 12 специалистов IBM (специалисты по WebSphere из США, Великобритании и Индии) и девяти экспертов из BSC. Кроме того, в решении проблемы участвовало пять специалистов Альфа-Банка, в том числе ИТ-директор, начальник управления производительности и начальник отдела оптимизации производительности.

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

Сергей Меднов: Тем не менее решали они проблему, честно сказать, довольно долго. Проект длился девять месяцев. С октября по декабрь 2006 года было проведено в общей сложности более ста тестов на производительность. В результате в декабре прошлого года нашли даже не технологическую проблему в IBM WebSphere Application Server, а определенную ситуацию, в которой работающее на ней приложение существенно теряет в быстродействии. Специалисты из IBM зафиксировали проблему c первым уровнем эскалации – самым высоким из всех существующих -- и приступили к ее решению. Интересно, что в этот момент специалисты HP нашли обходное решение, чтобы достичь требуемой производительности, не дожидаясь оптимизации WebSphere. Причем к концу проекта (июнь 2007 года) на этом решении и остановились.

Денис Антохов: В результате оптимизации и за счет настроек IBM WebSphere время обработки одной заявки при нагрузке 1000 заявок в час было кардинально уменьшено -- более чем в 50 раз. Но найденное специалистами HP совместно с разработчиками из BSC решение оказалось даже лучше, чем настройки WebSphere 6.1, предложенные инженерами IBM, – оно и было принято за основу. Впоследствии и специалисты IBM подтвердили, что это решение наиболее правильное и позволяет на Itanium-серверах хорошо масштабировать систему. В результате этого проекта, который закончился в июне 2007 года, образовалась конфигурация, на которой мы сейчас и работаем. И производительность новой системы на 15% быстрее, чем старая конфигурация версии 5.1 на аналогичном оборудовании. Причем отдельно были разработаны рекомендации для тех случаев, когда эту конфигурацию использовать невозможно.

Была ли возникшая проблема связана с особенностями технологий различных вендоров? Может быть, правильнее было бы работать с одним вендором?

Сергей Меднов: Нет. Эта глубокая технологическая история показала очень важный момент: не надо бояться сочетания различных вендоров. Да, с одной стороны, существует предубеждение против такого подхода и стремление всё получить «из одних рук». С другой стороны, системы очень сложные и возникают непредвиденные технические проблемы, как, например, в нашем случае. На наш взгляд она инвариантна относительно любого серверного оборудования -- на серверах IBM мы столкнулись бы с тем же самым. Но присутствие в проектной команде двух серьезных поставщиков и разные взгляды на проблему позволили нам получить поддержку существенно более мощную, чем в ситуации одного вендора. Два поставщика – это не один, даже если речь идет о таких мощнейших компаниях, как IBM и HP.

Мы для себя сделали важный вывод: сочетание больших производителей в рамках одного решения – это большое преимущество. Кстати, абсолютно такая же история, как ни странно, случилась и с другой системой и с другими производителями -- в решении Misys для автоматизации розничного бизнеса, работающей на ОС Microsoft Windows. Ситуация была совершенно аналогичной – при сумасшедшем росте объемов ни британский поставщик банковской системы, ни Microsoft по отдельности не могли решить наши проблемы с масштабированием.

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

Сергей Меднов: Отдельно хочется сказать про альянс НР и IBM по взаимной поддержке технологии IBM WebSphere на оборудовании НР. Хотя внешне подобные альянсы кажутся сугубо политическими, на самом деле это не так. Да, начиная этот проект, мы ожидали столкновения с очень высокими барьерами между компаниями. Но обе компании нас очень порадовали. Оказалось, что если альянс существует, то он прекрасно работает и снимает эти барьеры.

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

Вы удовлетворены результатами -- проблемы производительности, хотя бы на время, решены?

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

Денис Антохов: Кроме того, мы имеем запас по производительности. Дело в том, что технологии виртуализации позволили разделить мощности HP Superdome между несколькими системами. Если тех мощностей, которые рассчитаны на основе тестов, не хватает, то есть возможность гибкого перераспределения ресурсов, и мощности могут быть быстро передислоцированы для решения необходимой задачи.

Как сейчас ведётся поддержка системы? Какие подходы вы исповедуете в этой области? Насколько используете сервисные программы поставщиков?

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

Для критически значимых бизнес-приложений мы стараемся получить максимальный уровень поддержки от всех поставщиков, вовлеченных в работу. Есть контракты по продуктам IBM, HP, Orаcle, Misys, BSC и т. д., в которых предусмотрено восстановление системы в режиме 24×7 с фиксированным временем закрытия инцидентов. Это особенно важно для бизнес-критических систем, невзирая на стоимость такой поддержки. Эти затраты -- определенная страховка, которую надо заплатить, чтобы получить высококачественный сервис в нужном месте в нужное время. В противном случае все риски лягут на бизнес. Если ИТ в банке не будет функционировать несколько дней, то тяжело вывести банк из кризиса.

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

Сергей Меднов: Интересно, что подобные ИТ-проекты позволили ИТ-подразделению выступить в роли консолидатора вопросов, связанных с координацией подготовки к высокому сезону. Ведь мы отвечаем за то, чтобы все процессы в банке могли выдержать такой рост. Процессы начинаются в разных фронт-офисных приложениях, а заканчиваются в Misys Equation. Мы консолидируем все планы по росту бизнеса и в соответствии с ними разрабатываем планы по обеспечению производительности системы и производительности ручных процессов (ручной обработки данных). Таким образом мы выступаем в качестве координаторов планов бизнеса.