Сбербанк России: от сберкассы к высокотехнологичной компании

Хлызов

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

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

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

На тот момент АБС в компании еще не было?

АБС еще не было, а то, что было, — это скорее фронтальная система. Крупный проект по внедрению АБС начался в 1993 году. Тогда была предпринята попытка внедрить решение Unisys — огромной по тем временам западной корпорации, выпускавшей машины А-серии. Банк закупил довольно много таких машин.

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

То есть у каждого филиала Сбербанка была своя АБС?

Абсолютно верно. Внедрение решения Unisys стало первой попыткой централизовать процесс автоматизации структур Сбербанка и построить единую систему, охватывающую все уровни начиная с Центрального аппарата. Закончилась она неудачно. Только две части решения Unisys были внедрены. Первая — система для расчетов с Банком России и внутри Сбербанка. Это была неплохая система, разработанная своими силами на базе Unisys. Ее аппаратную основу составляли сверхнадежные огромные мэйнфреймы — машины А-серии архитектуры Burroughs. Впоследствии, когда мы разорвали контракт с Unisys, мы вернули им эти машины и получили обратно часть затраченных средств.

Вторая внедренная тогда система — процессинг Unisys. Она проработала на машинах А-серии до начала2000-х годов — вплоть до того, как мы перевели процессинг на системы, используемые и поныне, — SmartVista (обеспечивает управление всеми АТМ и POS-терминалами) и WAY4 (обеспечивает эмиссию банковских карт и ведение контрактов и счетовых схем банковских карт). На тот момент мы уже обслуживали порядка трех-четырех миллионов карт, что по тем временам было совсем не плохо.

Поскольку проект c Unisys по созданию АБС, охватывающей все структуры банка, своей цели не достиг, а все территориальные банки внедрили свои опердни, в 1996–1997 годах Центральный аппарат решил подойти к стандартизации иначе: ограничить перечень разрешенных для внедрения решений четырьмя стандартными продуктами. Это были АБС RS-Bank компании R-Style Softlab, банковская система компании «Диасофт», системы «АС-филиал» и «АС-отделение», разработанные Московским банком, и АБС «София», которую разработала компания «Телеформ».

Почему же отказались от унификации и перехода на одну АБС?

На тот момент это было сложно. Но на самом деле в структурных отделениях банка, то есть в точках, где сводился баланс, наибольшее распространение получила система R-Style Softlab. Я помню, что компания даже подарила нам бесплатно тысячную(!) копию RS-Bank — так много тогда было у нас отделений. Довольно популярна была и разработка Московского банка — ее внедрили в Москве, Московской области и еще в нескольких регионах.

В 1998 году рубль был деноминирован и введен в действие новый план счетов. Тогда у нас серьезно осложнились отношения с R-Style Softlab, потому что за переход на новый план счетов с нас потребовали, как нам показалось, сумасшедшие деньги.

Так продолжалось до 2000 года, когда мы разработали новую стратегию банка, а в ее рамках — и новую стратегию развития ИТ. В соответствии с последней была принята программа централизации управления ИТ. Через год, в 2001-м, структура, прежде состоявшая из огромного количества территориальных банков, была укрупнена до семнадцати или восемнадцати банков. В частности, был создан Поволжский банк, объединивший все банки Поволжья с центром в Самаре. Западно-Уральский банк с головным подразделением в Перми включил в себя также банки Ижевска и Сыктывкара.

Все эти банки обслуживал центральный ЦОД?

На момент принятия решения все отделения работали со своими ЦОДами, и было их огромное количество — больше тысячи. Первоочередная задача программы централизации заключалась в том, чтобы в территориальном банке, объединившем несколько областей, внедрить единую систему с переходом на централизованную инфраструктуру и с созданием резервных центров.

Для этого проекта были выбраны решения компании ЦФТ (IBSO), те же самые АБС RS-Bank и «София», а также разработка Центрального аппарата Сбербанка — так называемая система «Гамма». Сейчас ее уже нет.

Программа длилась пять лет — в 2006 году мы ее закончили. Два территориальных банка использовали «Софию», которая была выкуплена у компании «Телеформ», и развивали ее сами и силами внешних разработчиков. Северо-Восточный банк, Алтайский банк (он сейчас вошел в состав Сибирского) и Северный банк, серверы которого размещались в Ярославле, работали с АБС RS-Bank. Еще шесть территориальных банков внедрили IBSO ЦФТ, точнее, ее корпоративную и кредитную части, а системы для обслуживания розничных продаж в банках могли различаться. Семь банков выбрали нашу систему «Гамма».

Решения по каждому банку принимались отдельно на уровне Центрального аппарата в зависимости от ресурсов банка и его предшествующего опыта. Это была федеративная программа, которой руководил я.

При ее реализации не обошлось, конечно, без проблем, не все цели были достигнуты, но в общем программа централизации нулевого уровня в 2006 году была завершена. Количество ЦОДов сравнялось с количеством территориальных банков — 17 единиц.

А как развивалась система процессинга?

Как я уже отметил, с 2003 года процессинг обеспечивали системы SmartVista и WAY4, и эта конфигурация сохранилась до сих пор. Другое дело, что нагрузка на системы выросла многократно, а сами они доведены до высочайшего уровня надежности. Сейчас они сильно отличаются от рыночных версий. Специально для нас их дорабатывали компании БПЦ и Open Way Systems.

Была ли программа централизации ИТ продолжена впоследствии?

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

Почему две платформы, а не одна?

Как вы думаете, сколько транзакций ежедневно проходит через Сбербанк?

Думаю, речь идет о нескольких миллионах.

Сильно ошибаетесь — более ста миллионов в день. Нам не были известны системы на российском рынке, которые могли бы обрабатывать такие объемы транзакций. Мы изучали рынки на Западе, но и там не нашли решений, удовлетворяющих нашим требованиям.

Поэтому было принято решение о разработке двух платформ, которые были бы максимально унифицированы по бизнес-процессам, по данным и реализованы на уровне центров обработки данных в Центральном аппарате. Посчитали экономический эффект и начали реализацию программы. Одна платформа создавалась на базе IBSO ЦФТ (корпоративная часть) и на продуктах компании «Техно Диасофт» (розничная часть), созданной специально под нас.

Вторая платформа строилась на внутренних разработках. Мы отказались от системы «АС-филиал», стоявшей в каждом отделении, и стали создавать систему, ориентированную на централизованную обработку данных: «Филиал-Сбербанк». Она интегрировалась с АБС «Гамма», которая была растиражирована в территориальных банках.

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

Эту программу централизации контролировал лично Герман Греф. Я руководил программой, и два раза в год мы отчитывались о ходе ее выполнения перед Правлением банка.

В мае 2013-го, когда для этого созрели условия, мы вышли с предложением о создании единой платформы Сбербанка России на базе собственных разработок. Правлением банка было принято положительное решение, и в нынешнем году мы эту программу завершили. Она была признана успешной. Мы создали новое качество для банка, теперь в части core-banking у нас всё централизовано и размещено в наших центрах обработки данных.

Вы, очевидно, имеете в виду ЦОДы Сбербанка в Москве? А как используютcя ЦОДы территориальных банков?

В данном случае я говорю о системах класса core-banking. Но, конечно, кроме основного и резервного московских ЦОДов сохранились ЦОДы и в территориальных банках. Там есть множество локальных систем, которые необходимы для других целей — аналитики, взаимодействия с местными регуляторами, подразделениями ЦБ, службами судебных приставов. Распределенной осталась и система электронногодокументооборота. Вместе с тем критически важных систем в региональных ЦОДах уже нет. Соответственно существенно снизились и требования к ним. Поэтому мы не стали их модернизировать до уровня Tier 3, которому соответствует наш мегаЦОД.

На какой аппаратной основе работают серверы баз данных в основном ЦОДе и как организовано резервирование критически важных систем?

Основные серверы баз данных функционируют на IBM Power 795 и SUN SPARC Enterprise M4000 (М9000). На тот момент, когда мы выбирали платформу, решения IBM выглядели более предпочтительными. Сейчас лучше смотрится Oracle, купившая компанию SUN. Например, если большие машины IBM поддерживают до 256 процессоров, то у Oracle — до 384.

Для систем категории mission-critical предусмотрено стопроцентное аппаратное резервирование, развернут геокластер. Составляющие его ЦОДы находятся в Москве, но размещены на очень значительном расстоянии друг от друга. Имеется также несколько арендуемых резервных ЦОДов. У каждой системы есть свой функциональный дублер — мы это называем stand-in. В качестве дублера используется предыдущая версия прикладной системы на случай повреждения данных и ошибок в софте. Постоянно выполняется репликация данных на прикладном уровне. Если падает основная система, принимается решение о переходе на stand-in. В зависимости от системы и поддерживающего ее ЦОДа это занимает 15–30 минут. В процессинге значительно меньше — 20 секунд. Дублирующая система менее производительна, но позволяет обеспечивать непрерывность процессов. Когда работоспособность основной системы восстанавливается, выполняется обратный переход на нее с дублирующей.

Сегодня у нас 40 систем mission-critical. Это АБС, включающая ряд плотно интегрированных между собой систем, работающих на единой базе данных, — таких как единая платежная система, единая корпоративная система, единый кредитный портфель, единый центр обработки депозитов, Филиал-Сбербанк, процессинг. В эту же группу входят сервисы «Сбербанк-Онлайн» и «Бизнес-Онлайн», удаленные каналы, единый распределенный контактный центр…

Кстати, стоит, наверное, отметить, что мы первыми в мире (подчеркиваю — в мире!) построили трехузловой Real Aplication Cluster на серверах класса IBM Power 795 c 256 процессорами для Единой корпоративной системы. И не ради инноваций, а потому, что того требовал объем обрабатываемых данных.

Конечно, шишек вместе с вендорами набили много. Надо сказать, что поддержка Oracle у нас в стране хромает. По-настоящему хороших специалистов мало. Чтобы поднять двухузловой кластер для процессинговой системы, пришлось вызывать специалиста из США. Это были очень тяжелые проекты — привлекали вендоров, но в основном все же решали проблемы своими силами. И всё это сейчас работает.

Прямым результатом программы централизации стали также существенная реорганизация служб сопровождения ИТ банка и перестройка ИТ-процессов. Была создана территориально распределенная служба, обеспечивающая функционирование централизованных систем и поддержку пользователей в режиме24×7.

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

Свои силы — это специалисты компании «Сбербанк-Технологии»?

Все внутренние разработки ведет «Сбертех» — компания очень большая, в ней уже порядка 5 тыс. сотрудников и много центров компетенции. Причем «Сбертех» обслуживает только Сбербанк России и наши дочерние банки. Мы считаем ИТ своим конкурентным преимуществом и делиться ими ни с кем не собираемся. Никто в стране не создавал систем такого масштаба — более 100 миллионов клиентских транзакций в день, 630 миллионов счетов в системе обработки депозитов (вторая по этому показателю система в мире, на первом месте — китайский ICBC). Это многое говорит об уровне квалификации людей, создавших систему.

У вас немало дочерних организаций за рубежом. Они работают на своем ПО?

У нас есть филиал в Индии, дочерний банк в Турции, несколько дочерних банков в Европе, в Казахстане, Белоруссии и на Украине. Внутри банка создана мощная архитектурная служба. В целевой архитектуре все мы должны работать на одних и тех же системах. И сейчас открыта программа 18+, которая позволит перевести на наше решение все иностранные дочерние банки и филиалы. Она завершается в 2018 году. Это касается не только АБС, но и канальных решений, процессинга. В Европе мы сейчас будем внедрять наш мобильный банк, адаптированный под местного потребителя.

А ЦОДы у них будут свои?

Сегодня у них есть свой сегмент в нашем ЦОДе. Но не все системы мы можем обслуживать здесь — есть законодательные ограничения, поэтому получается некий микст. Например, Украина жестко требует, чтобы серверы, обслуживающие их клиентов, там и стояли. Но если мы добиваемся разрешений от местных регуляторов, то эксплуатируем решения в Москве. Например, в Европе внедрены работающие в нашем ЦОДе системы «Кредитная фабрика» и «Единый кредитный процесс» по корпоративным клиентам. Всё, что связано с рисками и каналами, мы уже сейчас можем унифицировать и постепенно этим занимаемся. Что касается core-banking, то это будет реализовано до 2018 года.

Как работает архитектурная служба?

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

Этот совет утверждает архитектурные стандарты по всем направлениям — по информационной, технической, интеграционной, прикладной архитектуре. Кроме того, в банке утвержден процесс управления архитектурой.

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

Кроме корпоративных архитекторов у нас есть архитекторы автоматизированных систем — люди, которые находятся в подразделениях разработки, но функционально подчиняются и частично мотивируются архитектурной службой. Они определяют данные, модули, взаимосвязь между ними.

Прикладную и интеграционную архитектуру мы ведем в System Architect — это продукт IBM. Аналогичный продукт применяется для описания процессов в банке (архитектуры без процессов не существует) и архитектуры данных.

Есть еще архитекторы сопровождения — их задача просматривать архитектуры, которые мы рисуем, с эксплуатационной точки зрения. И подумать о надежности решений.

То есть в этом плане банк очень сильно продвинулся вперед.

Использует ли Сбербанк облачные технологии?

Мы давно и активно используем виртуализацию. И добились неплохих экономических результатов. В том числе в рамках программы централизации. Это одна история.

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

Некоторые сервисы мы используем от внешних провайдеров. Хотя их число незначительно. Когда у нас нет ресурсов, чтобы заниматься какой-нибудь мелочью, мы идем в облако. Но это никоим образом не касается систем mission-critical и никогда их не коснется. Даже наши облака для тестовых сред не расположены в основных ЦОДах, сертифицированных по Tier 3.

Существует три уровня сертификации по Tier 3. Прошли ли ваши ЦОДы для систем mission-critical третий уровень — сертификацию на эксплуатацию?

Сейчас проходит их сертификация по операционной устойчивости. Очевидно, что мы ее пройдем, так как мы сильно в этом заинтересованы. Если не отстроить процессы по операционной устойчивости в соответствии с Tier 3, то по международной статистике на пятый-шестой год ЦОД становится настолько запутанным и сложным, что люди начинают много и часто ошибаться. Так что, не отстроив процессы, уровень надежности Tier 3 не получишь. Мы планируем закончить эту сертификацию в нынешнем году.

Сбербанк считается одним из лидеров в освоении технологий Big Data. Как вы их используете?

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

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

Николай Носов

опубликованно в PCWEEK/RE

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *


4 + два =