Банки как потребители IT-решений широкого спектра всегда предъявляют повышенные требования к внедряемым аппаратным комплексам.

Геннадий Карпов, директор департамента продуктов и технологий корпорации Квазар-Микро: Техническое Задание для банков формируется в процессе сотрудничества заказчикаи и нтегратора

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

Корпорация “Квазар-Микро” имеет успешный практический опыт внедрения комплексных банковских решений. Мы попросили Геннадия Карпова, директора департамента продуктов и технологий, поделиться опытом корпорации в банковской сфере.

PC Week/UE: Большая часть серверов, продающихся у нас — это сервера локальной сборки. Кто покупает сервера А-бренд класса enterprise? В чем принципиальная разница между приобретением сервера локальной сборки и брендового продукта?

Г. К.: При рассмотрении вопроса о выборе сервера, я бы делил их не по типу сборки — локальной и брендовой, а по типу архитектур. Локально производится только подмножество всех серверов, а именно — серверы на базе процессоров Intel архитектуры IA32. В то же время существует ряд бизнес-приложений, автоматизирующих работу банков, которые можно отнести к разряду критических для самого бизнеса банка. Все эти приложения характеризуются повышенными требованиями к параметрам вычислительных комплексов. Прежде всего, к отказоустойчивости, производительности, масштабируемости и управляемости. Далеко не во всех случаях в качестве основы для вычислительного комплекса, который отвечает всем этим требованиям, могут использоваться серверы на базе процессоров IA32. Это достаточно редкая ситуация. Поэтому в банковской сфере чаще используются серверные системы, которые относятся к классу 64-разрядных RISC-систем. В мире всего несколько производителей, предоставляющих свои решения на базе этой архитектуры: Sun Microsystems, IBM, Fujitsu-Siemens и Hewlett-Packard. Серверы на базе RISC-архитектуры локально не производятся. Поэтому если принимать решения о поставке оборудования исходя из потребности обеспечить нормальную работу критических банковских бизнес-приложений, то тут выбора нет — это будет сервер нелокальной сборки.

Однако есть сегмент рынка, где может быть вполне эффективным применение серверов архитектуры IA32. например, это рынок блейд-серверов, которые производятся в Украине, пока только на фабрике “Квазар-Микро”. Поэтому теоретически здесь выбор между локальным производителем и мировым брендом возможен, но на практике он практически не может быть реализован. В большинстве случаев для критических приложений приобретают серверы “А-бренд”.

Блейд-сервер NetFire 7000 производится в Украине

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

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

PC Week/UE: Соответственно возникает вопрос — кто формулирует техническое задание (ТЗ) для банков? Как банк приходит к пониманию необходимости покупки именно сервера от производителя с мировым именем?

Г. К.: Это совместная работа банка и интегратора. IT-департамент банка, во главе с IT-директором, становится связующим звеном между бизнесом банка и IT-технологиями, которые служат средой для существования внутренних бизнес-процессов. Банк формулирует свои требования к вычислительному комплексу на уровне требований к бизнес-приложениям. IT-отдел банка должен, в свою очередь, преобразовать их в требования к аппаратной платформе, способной обеспечить работу этих бизнес-приложений. Интегратор оценивает реальность выдвинутых требований и формирует на их основе предложение. Формулировка ТЗ требует создания совместной рабочей группы, состоящей из представителей банка и интегратора.

PC Week/UE: По какому принципу формируется состав команды проектировщиков задания? Специалисты какого рода в группе присутствуют со стороны заказчика, какие — со стороны интегратора?

Дисковый массив FireStore 3160ES: высокая скорость доступа к информации и доступная цена

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

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

PC Week/UE: Если рассмотреть банк с разветвленной филиальной сетью, то какие технологии, протоколы, программные и аппаратные решения используются для обеспечения стабильной работы банка и филиалов? Как это осуществлялось раньше, и какой прогресс в этой сфере произошел за последнее время?

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

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

Централизация наблюдается также и в области информационного обеспечения предоставляемых банком услуг. Раньше, в конце 90-х годов, использовался подход, который можно назвать “островковым”. Для него было характерно построение отдельного “островка” для существования каждого бизнес-приложения, включавшего сервер, систему хранения данных, систему резервирования, источник бесперебойного питания и каналы взаимодействия другими “островками”. Недостаток такого подхода к автоматизации банка заключается в том, что ресурсы невозможно распределить между бизнес-приложениями, даже если на одном из “островков” они присутствуют в избытке, а на другом наблюдается их дефицит. Расчлененность такой системы также понижала её суммарную надежность. Кроме этого, катастрофически повышалась сложность управления всем этим “островковым” комплексом. От такой схемы мы давно отказались, и сейчас для автоматизации банков применяем модель, которую можно условно назвать “ресурсной”. В рамках платформы информационной системы производится выделение отдельных подсистем по функциональному признаку и консолидация ресурсов в рамках функциональной группы — для каждой функциональной группы формируется общий ресурсный пул. Это означает, что одной и той же системой хранения данных, одними и теми же серверами могут пользоваться разные бизнес-приложения. Таким образом, система автоматизации работы банка заметно упрощается в управлении и администрировании, концентрируется в одном месте, повышается ее надежность, а также появляется возможность гибкого и эффективного распределения ресурсов между всеми бизнес-процессами банка.

PC Week/UE: Как в таком случае обеспечивается катастрофоустойчивость информационной системы банка? Ведь принцип консолидации всех ресурсов в одном месте идет в разрез с основным принципом обеспечения катастрофоустойчивости — разнесения ресурсов по разным местам.

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

PC Week/UE: Если рассмотреть гипотетическую ситуацию полного разрушения основного вычислительного центра, для восстановления функциональности бизнес-процессов потребуется какое-то время или переключение на резервный центр произойдет мгновенно?

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

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

PC Week/UE: В чем, по вашему мнению, заключается залог успеха компании-интегратора? Каким должен быть успешный интегратор, какова должна быть его структура и схема взаимодействия с заказчиком для достижения успешного результата? Какие специалисты должны быть в штате компании-интегратора?

Г. К.: Для успешного взаимодействия с заказчиком у интегратора в штате должны быть различные группы специалистов. На этапе реализации проекта нужны глубокие инженерные знания, инженерная компетенция, знание мелочей и большой практический опыт. Ценность инженера заключается в том, что его знания очень глубоки. Но за счет этого они не могут быть очень широкими.

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

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