Начну с истории «СберТех» — первоначально у банка была своя, скажем так, IT-служба, больше специализировавшаяся на управлении проектами, частично на разработке и, конечно, на внедрении и поддержке. При этом, с точки зрения именно создания и развития программных продуктов, существенная часть работы была отдана сторонним организациям.

В какой-то момент банк понял, что необходимо существенно перестроить бизнес-модель, оптимизировать собственные расходы на IT. Условно, за те же деньги: делать больше, быстрее и качественнее. Стало понятно, что необходимо создавать собственную, т.н. «каптивную» IT-компанию (прим. — включённую в общую структуру). Где-то на рубеже 2010-2011 гг. и был создан «СберТех».

Изначально туда было переведено около 400 сотрудников банка, которые поначалу занимались созданием и развитием приложений. При этом на тот момент было уже порядка двухсот приложений на эти 400 человек — понятно, что глубина экспертизы по каждому из них была недостаточна.

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

В этом году мы отпраздновали пятилетний юбилей компании. На текущий момент в СБТ (используемое внутри сокращение «СберТех») около 8 000 сотрудников по всей стране. Вы сами можете оценить, какой рост произошел за столь небольшой по «банковским» меркам срок. Мы сейчас делаем более половины всех проектов по разработке и развитию систем для Сбербанка.

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

Стоит также добавить, что «около IT» и около создания и внедрения, равно как и поддержки, есть разные функции. Здесь стоит сделать длинное отступление и рассказать о том, как вообще устроен бизнес группы компаний «Сбербанк» (а это более 320 000 человек), но это будет надолго.

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

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

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

За пределами «СберТех» находятся банковская корпоративная структура. Служба, занимающаяся внедрением и поддержкой приложений, также входит в структуру банка, но не «СберТех».

Все, как обычно, чуть сложнее. Самый низкий уровень, о котором можно говорить, — это уровень команд и систем. У нас в «СберТехе» сейчас в разработке более 150 приложений , каждое из которых сильно отличается от другого, они все разные по масштабу. Платформа «Управление рисками на финансовых рынках», которую вы упомянули, на самом деле — «конгломерат» из нескольких приложений (около пятнадцати), которые строятся на одной технологии (и из-за этого названы платформой). При этом все приложения этой платформы разрабатываются в Центре компетенций »Развитие риск-систем», в котором помимо этой платформы создаются и другие приложения. Я привел самый «вкусный» и заметный пример, позволяющий сориентироваться в происходящем.

Принятие решений о создании приложений, как правило, происходит за пределами «СберТех», и в данном случае мы выступаем технологическими консультантами, понимающими ландшафт. У бизнеса возникает потребность или бизнес-задача, он приходит к нам и говорит: «Ребята, я понимаю, что здесь нужна автоматизация». Мы можем проконсультировать, с помощью каких имеющихся систем мы могли бы это сделать или с помощью каких технологий мы можем подобную систему создать. Это функция коллег из CTO-офиса — они и должны понять, что происходит в бизнесе, какие задачи там появляются, какие из них приоритетные. Немаловажным является ответ на вопрос: «Могут ли тут вообще помочь IT-системы?» Бывает и такое, что решение проблем и задач лежит вне области автоматизации или электронного продукта, программы.

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

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

Если мы говорим про конкретные платформы, то здесь нужно провести параллель.

Платформа, управляющая рисками на финансовых рынках, не занимается кредитами физическим и юридическим лицам. Она специализируется только на рыночном риске. Несколько месяцев назад мы успешно закрыли первую фазу большой программы по внедрению автоматизации в этой части. Несколько лет назад, до покупки инвестиционной компании «Тройка-Диалог», в 2012 году (https://ru.wikipedia.org/wiki/Тройка_Диалог) у банка не было системы для управления рыночными рисками в реальном времени.

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

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

Или есть история, в которой мы торгуем с нашими контрагентами на валютном рынке. Это ещёе одна отдельная платформа, которую мы запустили в конце прошлого года, обеспечив самым крупным нашим корпоративным клиентам возможность заключать с нами сделки по валюте в режиме реального времени. Котировки меняются несколько раз в секунду, клиент может за 100-200 миллисекунд увидеть интересующую котировку и совершить с банком сделку. В таких условиях нам необходимо контролировать кредитные лимиты данных клиентов. Другой компонент системы, управляющей рисками на финансовых рынках, умеет проверять кредитный лимит за 6 миллисекунд. Если клиент открыл у нас валютную позицию, а лимит у нас в одной валюте, а позиция — в другой, необходимо при малейшем изменении любой из двух котировок пересчитывать цифры. Математики не очень много, но требования к быстродействию просто высочайшие.

Для контроля рыночности мы рассчитываем стоимость 36 000 000 финансовых инструментов в минуту. Порой они могут быть и производными, то есть сложными.

Мы считаем 17 000 «греков» за 300 миллисекунд (https://ru.wikipedia.org/wiki/Модель_Блэка_—_Шоулза — производные рыночные метрики). Монте-Карло симуляции («что будет, если») также проводятся на высоком быстродействии с большими значениями.

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

Специфика нашей истории — необязательно огромное количество именно пользователей (потому как пользователи наших систем — в основном сотрудники Банка). Это может быть количество сделок или операций, которые нам нужно провести. Иногда это сложная математика, иногда надежность — особенно если мы говорим про передачу финансовых котировок или сделок. То «дано», с которым мы работаем — это сложность финансовых продуктов, быстродействие, количество сделок и операций.

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

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

Еще у нас есть направление, где активно используется SQL баз данных . В платформе электронной торговли мы используем Apache Storm. Также используем специальные технологии, например, комплекс Event Processing. У нас есть много людей, которые пишут на web и c sharp. С точки зрения баз данных мы используем все основные СУБД (Oracle, MS SQL, PostgreSQL).

Я бы сказал, что DevOps для банка вообще — тема достаточно свежая. Я думаю, что наше преимущество в этой части в том, что 4 года назад мы начинали фактически с нуля. У нас не было никакого legacy, вокруг которого построены традиционные процессные гейты, и который нужно было поддерживать.Я считаю, нам повезло, во-первых, в том, что наши коллеги из бизнеса были достаточно модерновыми и готовыми экспериментировать. Во-вторых, они понимали, что это достаточно сложная история, которая совершенно точно будет меняться одновременно со стратегией зарабатывающего бизнеса. В данном случае было неправильно садиться и писать требования. Нам удалось собрать очень сильную команду, которой я горжусь. Она еще на этапе пилота показала, что может не только итеративно и достаточно быстро создавать работоспособные приложения, но и что с ней можно работать в ритме Scrum. У нас быстро сформировался хороший уровень доверия между ИТ и бизнесом, и мы смогли построить процесс front-to-back, начиная с того, как бизнес формулирует свои задачи, как он их приоритезирует, и, заканчивая тем, каким образом мы выкатываем все это в пром и как оно дальше поддерживается. Я бы сказал, что, наверное, у нас были стандартные в таких ситуациях сложности, но они не были связаны именно со Сбербанком.

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

Требования у нас достаточно высокие. Недавно был срочный найм по одному из проектов, и мы смотрели воронку аналитиков, которых сейчас чуть проще найти, чем Java разработчиков. Воронка была следующая: из 500 предварительно отобранных рекрутерами резюме мы встретились с 50-ю людьми. Кого-то мы отсеяли на этапе резюме, кого-то — на этапе телефонного интервью. Из них мы сделали предложение только 10-ти.

Теперь о разработчиках. Если команда большая — проще взять джуниоров. Им можно выделить часть проекта, на которой они смогут обучаться и при этом не повредят систему. Учитывая, что команды маленькие и каждый человек на виду, у нас очень короткий цикл (т.к. под риском находятся большие деньги) и выше требования к технологическим компетенциям, связанным с Java, и к способности решать сложные технологические задачи. Я бы выделил еще два качества — умение решать практические задачи и думать, что называется, out of the box, потому что мы достаточно часто занимаемся задачами, которые никто до нас в России не решал.

Мы регулярно проводим хакатоны для того, чтобы найти таких людей. И в случае, если мы видим компетентных людей, которым было бы интересно работать для Сбербанка, то мы, конечно, пытаемся их привлекать. Кроме того, мы уже не первый год сотрудничаем с МФТИ, МИФИ и планируем сотрудничество еще с рядом российских вузов. Мы еще на этапе 4-5-го курсов отбираем самых толковых и многообещающих ребят для того, чтобы помочь им получить практическую составляющую образования и попробовать их бою. И если все будет хорошо — оставить у себя на работе.

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

Вторая мысль, которая касается Банка в целом — нельзя сказать, что мы стоим на пороге изменений, они уже начались! И в Сбербанке это очень хорошо понимают. Эра очень жесткой конкуренции с финтех-стартапами — уже не завтрашний день, а сегодняшний. Это может быть чуть заметнее в более развитых странах. До нас это тоже докатывается. На российском рынке уже есть работающие платформы (то, что называется peer-to-peer lending), которые фактически пытаются отъедать у традиционных банков рынок кредитования и депозитов. То есть, вместо того чтобы нести деньги на депозит в банк, человек может через эту платформу отдать их кому-то напрямую в долг и получить существенно более высокую доходность. Мне кажется, что это драйвер, который расстраивает банки, но, на мой взгляд, радует айтишников. Это стимулирует банки переходить в область конкуренции, связанную с технологичностью.

Третий момент, который относится к — управлению рисками — как правильно просчитать риски и сделать скоринг Даже если мы возьмем peer to peer lending: есть замечательные модели, но — они не берут этот риск на себя, а отдают тому, кто отдает деньги. Ниша, в которой банки могут быть жизнеспособны, — это если они продолжат брать этот риск на себя, как они делают сейчас. Мне кажется система, которая позволит банкам делать это эффективнее, чем финтехи, — это один из гарантов того, чтобы банки вообще останутся на рынке.