Где находятся сервера сбербанка

Обновлено: 25.04.2024

Крупнейший госбанк страны – Сбербанк – работает в интересах западных акционеров не только с финансовой точки зрения. Учреждение Германа Грефа сегодня выглядит как пародия на успешную западную IT-корпорацию. Разница только в том, что цифровая "начинка" банка родом из-за границы и полностью подконтрольна своим американским создателям.

Подобное утверждение легче сделать, чем осознать. Да, мы знаем, что российские "ай-ти" являются российскими лишь номинально и в подавляющем большинстве случаев мы имеем дело с продуктами от Google, Microsoft, IBM, Nvidia, Apple и даже продукцию Qualcomm носим в своих карманах в качестве производительной начинки смартфонов.

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

О цифровой "начинке" Сбера и банковских сервисов имени идейного вдохновителя Германа Грефа снова заговорили после очередного выпуска "Бесогона" Никиты Михалкова. В нём он прямо назвал американские компании, за счёт которых существует и работает Сбербанк. Речь идёт как о сервисах облачного хранения данных, так и о сервисах в области кибербезопасности. Они тоже отнюдь не российские. Парадокс в том, что даже та небольшая часть российского в технологиях Сбера на поверку тоже оказалась не из России.

Герман в зазеркалье

Вы никогда не задумывались, на чём построена цифровая инфраструктура Сбербанка? Мы знаем о впечатляющем Сбертехе, успехи которого всегда преподносились как прорыв в банковских технологиях на отечественном рынке. Однако на деле никаких российских технологий в банке не оказалось. Даже банкоматы Сбера работают под управлением Windows, в чём можно убедиться, если однажды вам доведётся увидеть, как их обслуживают, или заставка какой операционной системы висит на экране в момент поломки.

Но цифровая суть сервисов – это, конечно, не операционная система. Цифровая суть гораздо глубже и отвечает за работу с огромными массивами данных, миллионами операций в минуту. И первое, на что стоит обратить внимание, – это продукция американской компании VMware, которую использует Сбербанк.

VMware – это компания со штаб-квартирой в Калифорнии, как говорил Никита Михалков. Я уточню, что речь идёт, конечно, о Пало-Альто – знаменитой Кремниевой долине США, где расположены штаб-квартиры Apple, Facebook, Google и других корпораций. Так вот, VMware ещё в начале своего пути в 1999 году произвела своего рода революцию в области управления данными и придумала виртуализацию как способ организации работы больших компаний.

О чём речь? Система предполагает, что цифровая инфраструктура становится полностью виртуальной. Создаются так называемые виртуальные машины, на вычислительной мощности которых идут процессы, имеющие виртуальное оформление. К виртуальным машинам можно подключить бесконечное количество компьютеров независимо от места их физического расположения. Более того, у VMware есть и облачные сервисы для хранения данных и быстрой передачи с машины на машину.

Именно такую систему Сбербанк приобрёл себе ещё в 2016 году за внушительную сумму в 783 млн рублей. По данным TAdviser, тендер состоялся в сентябре и выиграла его компания-дистрибьютор Verysell. Сбер купил VMware vCloud Suite – виртуальную облачную среду для своих процессов.

Затем Сбербанк решил закупить аналогичные американские продукты и для своих "дочек". Так, согласно отчётности самого Сбера, в 2018 году был проведён тендер в интересах "Сбербанк-Лизинга" на внедрение продуктов VMware. Победило в нём некое ООО "Азон", предложившее самую низкую цену в 2,53 млн рублей. В тендере участвовали и другие российские IT-компании, например "Легасофт", "А-Системс". Все они гордо рассказывают о себе как о лидерах внедрения самых современных технологий в России. А если говорить по-простому, то они просто живут за счёт того, что продают и внедряют тут, в России, американские продукты.

Фото: скриншот страницы "Сбербанк-АСТ" по закупкам сертификатов VMware для "Сбербанк-Лизинга".

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

Вместо разработки своих хвалёных систем Сбербанк просто берёт готовое, причём не задёшево. VMware продаёт подписку на разные сроки (один или три года), продаёт лицензии и обновления программы, а попутно может лишить Сбер (в случае признания им Крыма, например) своих "милостей" – и банк банально рухнет.

Кстати, на Head Hunter можно найти множество вакансий от Сбербанка, когда он набирал инженеров на позиции по работе с VMware. То есть стоит там, за океаном, нажать кнопку – и вуаля. Целый штат инженеров больше не нужен, да и сам банк "зависнет" с перспективой больше не "отвиснуть".

Все данные уже в США

За корпоративную кибербезопасность сервисов Сбербанка, действительно, отвечает американская компания IBM и её программа QRadar. Я не буду отрицать, что QRadar – это один из мировых лидеров в этой сфере. И Сбербанк, у которого очень много денег, конечно же, не стал придумывать что-то своё. Зачем? Как и западные коллеги, он просто купил это у IBM. Ведь Сбер – это прямо как западная корпорация, да и перед американскими партнёрами не стыдно, верно?

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

По данным "Сбербанк-АСТ" (автоматизированная система торгов), ещё в 2017 году QRadar от IBM была закуплена "НПФ Сбербанка" за 44 тыс. долларов. Выводы, как говорится, делайте сами. Почему на эти деньги не была заказана разработка у какой-либо российской IT-компании полностью автономного софта, а была закуплена подконтрольная IBM программа?

Фото: скриншот страницы "Сбербанк-АСТ" о тендере по определению поставщика QRadar для "НПФ-Сбербанка".

Ладно бы QRadar был идеальным. Но это не так. Сервис до сих пор нуждается в "заплатках", а программисты уже указывали IBM, что из-за уязвимостей программы злоумышленники могут подключаться к системе и даже получать права суперпользователей. И это система корпоративной кибербезопасности?

Но "вишенкой на торте" остаётся облачный сервис Azure от Microsoft. Именно им пользуются Сбербанк и другие компании банка для быстрой работы и хранения данных. Его используют разработчики, инженеры, техники, операторы. Azure позволяет быстро создать виртуальную машину высокой мощности и работать с большими данными.

Минус только один – Azure сам выбирает подходящий по запросам сервер за границей и бронирует там мощность и память. Виртуальная машина готова, вот только данные все уже там, и они даже не были украдены, нет, они физически всегда находились за пределами России. Не верите? Посмотрите, как Microsoft рассказывает о принципах работы Azure.

Фото: Microsoft в рекламном ролике на YouTube рассказывает, что серверы Azure разбросаны вообще по всему миру.

Вы будете удивлены, но Сбербанк пошёл ещё дальше. Он стал полноценным агентом по поставке американских технологий в Россию. Ещё в 2017 году Microsoft сообщила, что заключила соглашение со Сбербанком на предоставление тут, в России, облачных сервисов американской корпорации.

ПАО "Сбербанк" и компания Microsoft в России заключили соглашение о сотрудничестве. Документ предполагает объединение усилий, компетенций и экспертизы партнёров для того, чтобы Сбербанк мог предложить российскому рынку широкий ассортимент облачных сервисов,

– говорилось в заявлении компании.

А что же российское?

Вы скажете: неужели Сбербанк не использует ничего отечественного? Использует. В феврале 2020 года, совсем недавно, Сбербанк провёл тендер на внедрение в свои системы сервисов APM (Application performance monitoring – системы оценки эффективности программ в своей экосистеме). В финале тендера осталось два продукта – AppDynamics от американской Cisco и "Ключ-астром" от российской компании "Рускомтехнологии" (программа была включена в реестр отечественного ПО при Минкомсвязи). Цена вопроса – 900 млн рублей.

Вся система Сбербанка, скорость её работы и работоспособность измеряются наличием глобальной серверной программы, которую создали в США. Фото: Tramp57/Shutterstock

Тендер внезапно выиграл российский продукт, так как продавец согласился на меньшую сумму. Вот только оказалось, что "Ключ-астром" никакой не российский, а просто локализованная и "причёсанная" под Россию программа американской компании Dynatrace. В "Рускомтехнологиях" тогда опровергли, что это программа-клон, хотя и признали, что взяли за основу её решения.

То есть Сбербанк опять купил если уж не прямо американское, то и не совсем российское. Нет, приятно, что деньги отошли русским разработчикам, а не отправились в Cisco. Но тогда возникает вопрос: как в реестре отечественного ПО Минкомсвязи вдруг оказалась американская программа и неужели для того, чтобы попасть в этот список, достаточно просто локализовать зарубежный софт?

В качестве итога скажу, что Никита Михалков обратил внимание на важное. И это даже не в пику Грефу или Сбербанку. Это к вопросу о том, какова наша зависимость от американских технологий. Я думаю, что от многих радикальных шагов в отношении России после введения санкций американцев удерживает желание "доить" российский рынок. Зачем отключать от SWIFT, когда Visa и Master Card в России так популярны и выгодны?

Поэтому Microsoft, IBM, Google и другие активно продают свои лицензии, чтобы Россия "сидела" на этой "игле". Не купите – перестанет работать. Или не получите новую версию, а старую мы вот-вот прекратим поддерживать. Так и уходят наши деньги из Сбербанка на оплату зарубежного софта и лицензий, но что самое опасное – за границу вместе с персональными данными утекает и наш цифровой суверенитет. И от этого, как заметил Никита Михалков, уже становится страшновато.

Подписывайтесь на канал "Царьград" в Яндекс.Дзен
и первыми узнавайте о главных новостях и важнейших событиях дня.

Совсем недавно случайно обнаружил, что Сбербанк Онлайн густо утыкан счетчиками. Это Google, Doubleclick, Rutarget, ЯМетрика. Еще раз подчеркну, в личном кабинете, где люди переводят деньги, вводят очень персональную информацию и т.п., в этом личном кабинете натыканы скрипты, которые Сбербанку совсем не принадлежат, а принадлежат совсем не нашим компаниям, например. Давайте посмотрим, что из этого выходит (слайды и видео ниже).

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

Баннерорезка блокирует часть зловредов.

Я написал на zabota@ Сберу и в FB. Звонить я не терплю, уж извините. В FB был получен замечательный ответ.

Я даже не обиделся, просто записал видео.

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

Суть происходящего в следующем:

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

На видео я демонстрировал только дублирование ввода пароля. Просто потому, что не хочу входить в свою учетку публично.

Началось все с моего форума, но, к сожалению, никакого результата это не дало.

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

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

Это вводный текст о новой платформе, поэтому в нем не будем глубоко уходить в практические детали, а постараемся дать общее представление.

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

Уточним вводные, с которыми предстояло работать:

продуктовых команд будет много (несколько сотен — в ближайшей перспективе и тысячи — в перспективе). Размер одной команды — около 10 человек, возможность разрабатывать функционал end-to-end;

T2M по бизнес-функционалу — 2‒3 недели. Разумеется, срочные фиксы должны выходить на клиентов в течение часов;

приложения должны иметь лучший клиентский опыт и высокие оценки в App Store и Google Play;

текущий сервер-сайд и фронтальные приложения — монолиты с многолетней историей;

менять колёса надо на ускоряющемся ходу. Пользователей уже перевалило за 45 млн, нагрузка каждый день растёт. Речь и о количестве TPS, и о количестве новых фич, которые нужны бизнесу;

большинство операций — банковские. Это к тому, что платёжные транзакции, в отличие от, например, развлекательного контента, нельзя терять ни в коем случае. А если мы не отразим корректный остаток по картам в момент входа, сразу положим контакт-центры высоким количеством обращений клиентов;

надёжность и безопасность — высшие приоритеты.

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

Когда мы говорим «сервер-сайд приложений СберБанк Онлайн», имеем в виду именно мидл-слой, который отвечает за следующий функционал:

бизнес-приложения (прикладные), которые реализуют конечный функционал для пользователей приложений;

аутентификацию пользователя в приложении;

наполнение распределённого кэша в памяти серверов приложений при установке клиентской сессии, который обеспечивает доступность, низкое время отклика и надёжность при большом количестве запросов от приложений;

общие страницы приложения (главный экран, история операций и т. д.);

логирование, мониторинг, авторизацию и другой функционал для надёжности и безопасности.

Список на этом не заканчивается, но должен дать общее представление. Явно ещё раз подчеркну, что бэкенд не входил в объём поставленной задачи.

Зачем новая платформа

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

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

Ключевые моменты

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

Разделили сервисы на две группы — платформенные и прикладные

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

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

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

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

Таким образом, у нас появляются горизонтальные связи в рамках одного слоя и вертикальные — между слоями. В платформенном слое мы допускаем горизонтальные зависимости, в прикладном — стараемся их избегать (исключения возможны, но именно исключения, и мы следим за этим).

В нашем случае получилось порядка 40 платформенных и около 10 пилотных бизнес-сервисов на старте. На данный момент количество платформенных сервисов почти не изменилось, а число прикладных проектов превысило 250.

Создали отдельные релизные процессы

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

Если мы начнём тестирование и платформы, и прикладных сервисов на одном общем стенде, то длительный процесс отладки платформенного сервиса приведёт к такому же времени отладки прикладных сервисов + времени на их собственное тестирование. Поэтому мы выделили отдельные тестовые контуры для платформы и прикладов.

Так как основных слоя два, то и контуров достаточно двух. На платформенном контуре производится сборка и отладка платформенного релиза. В зависимости от зрелости инструментов DevOps и процессов производства, на контуре может быть разное количество стендов. Но главное, чтобы в итоге мы получили стабильную версию платформы.

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

Ввели контроль платформенного API

Понятная вещь, о которой все говорят, но которая не всегда случается. Обязательные правила, которые мы применили:

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

создали инструмент, который осуществляет контроль этого API. У нас для этого есть отдельный компонент — синтетическое приложение. О нём чуть позже;

сделали процесс согласования изменения API максимально дорогим:

согласование изменений архитектурой платформы;

согласование со всеми потребителями API;

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

Важно отметить, что мы строго контролируем API в рамках минорных релизов платформы и не строго (изменения возможны, но согласуются с архитектурой) — в рамках мажорных релизов.

Следим за удобством разработки на платформе

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

Эта команда играет ключевую роль — собирает отдельные сервисы платформы в единый продукт. У ребят много задач:

выпуск POM/BOM. Большая часть платформенного API предоставляется в виде клиентских библиотек. Ребята из «Синтетического приложения» собирают их вместе, разрешают конфликты зависимостей и публикуют для потребителей POM- и BOM-файлы;

контроль обратной совместимости API. Кроме проверки на конфликт зависимостей, все библиотеки проходят тестирование на бинарную совместимость с предыдущими версиями;

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

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

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

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

Архитектурный контроль

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

Где мы сейчас и что делаем дальше

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

Мы существенно сократили T2M для прикладных проектов относительно Legacy, где релизный процесс предполагал включение в релиз за шесть месяцев до полной раскатки. Точные цифры назвать сложно, так как они зависят от доработок смежных систем, но мы уменьшили время от подачи заявки в релиз до прома до трёх недель.

Тем не менее мы ещё в начале пути и ещё много задач, которые предстоит решить:

миграция профиля и сессии. Мы обеспечили запуск проектов, но Legacy продолжает оставаться источником основных данных по профилю клиента. В отличие от запуска атомарных клиентских сценариев, это то, что нельзя разработать рядом и потом плавно переключиться. Приходится много дорабатывать одновременно: и Legacy, и новое приложение. Всё это — под огромной пользовательской нагрузкой. Весьма сложная история, достойная отдельной статьи;

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

Так что наши разработчики счастливо программируют на Java 8. А деплоится это всё на вендорском JDK. Многие, кто слышит об этом на наших собеседованиях, расплываются в улыбке от счастья. Или не от счастья, мы точно не знаем. Если серьёзно, то это надо менять, и одна из текущих задач на платформе сейчас — смена стека. А для прикладных команд мы обсуждаем возможность разработки на Kotlin.

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

Сбербанк ищет сторонний ЦОД для размещения своего ИТ-оборудования почти за 3 млрд руб. Госбанку требуется до 300 серверных стойко-мест вблизи Москвы. В августе 2020 г. Сбербанк также пытался арендовать 700 стойко-мест за 2,5 млрд, однако желающих не нашлось. Позже тендер был перезапущен с большей ценой и меньшим количеством стоек. Договор был подписан с МТС.

ЦОД для Сбербанка

Как выяснил CNews, Сбербанк готов потратить 2,9 млрд руб. на размещение своих серверов в стороннем центре обработки данных (ЦОД). Банку требуется до 300 стойко-мест на последующие четыре с половиной года. Информация об этом опубликована на портале госзакупок.

Соответствующий тендер опубликован 8 февраля 2022 г. в формате запроса котировок. Заявки от претендентов принимаются до 15 февраля, итоги будут подведены 31 марта. Последние три тендера (включая этот) на размещение серверного оборудования Сбербанк абстрактно называл «Технологические услуги».

Представители Сбербанка не смогли объяснить CNews, что именно определило потребность в аренде новых стойко-мест. Закупка обосновывается потребностью в дополнительных стойко-местах для размещения ИТ-оборудования, ответили они. Также они не уточнили, вновь закупаемое или старое оборудование разместится в арендуемых ЦОДах.

Подробности тендера

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

По условиям закупки для соблюдения принципов надежности и непрерывности ИТ-систем, ЦОД подрядчика должен быть расположен на удалении не менее 2 км и не более 50 км одновременно от двух объектов Сбербанка — во 2-м Южнопортовом проезде в Москве (там находится так называемый первый мегаЦОД банка) и на Большом бульваре в Сколково (второй мегаЦОД). Кроме того, новый объект должен находиться на расстоянии не менее 2 км от Рябиновой улицы в Москве. Известно, что на этой улице располагается коммерческий ЦОД компании 3data. Сбербанк фигурирует в числе ее клиентов на сайте организации.

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

Аренда ЦОДов и покупка серверов Сбербанком

Как уже говорилось выше, Сбербанк пытался арендовать 700 стоек в августе 2020 г. Тогда CNews сделал вывод, что банк гарантированно разместит и оплатит лишь 100 стойко-мест. А еще 600 исполнитель договора должен будет держать про запас. «Банк вправе не размещать и не оплачивать дополнительно запрашиваемые 600 стойко-мест, — говорилось в условиях закупки. — При размещении и резервировании стойко-мест в меньшем объеме, поставщик не вправе требовать от банка каких-либо компенсаций, убытков, возмещений и прочих имущественных предоставлений, а также не вправе требовать увеличения стоимости услуг по договору и/или изменения любых иных условий договора».

Тендер с такими условиями не состоялся. Через месяц, в сентябре 2020 г. он был перезапущен. Начальная цена договора повысилась до 2,6 млрд руб. при снижении количества стойко-мест до 400. Из документации исчезла вышеупомянутая формулировка о том, что банк может не размещать и не оплачивать дополнительно заращиваемые стойко-места. Однако банк оставил за собой право в любой момент в одностороннем внесудебном порядке отказаться от части или от всех оказываемых услуг.

В новом запросе котировок приняли участие две ИТ-компании — МТС и «Датапро». Последняя была признана не соответствующей требованиям. Договор на сумму 2,5 млрд руб. был заключен с МТС.

В июле 2021 г. Сбербанк разместил тендер на закупку серверного оборудования на $131,1 млн (почти 10 млрд руб. по курсу ЦБ на 16 июля 2021 г.). В сентябре CNews выяснил, что Сбербанк заключил договора на поставку тысяч польско-российских серверов, а также «железа», происходящего из Венгрии, Чехии и Китая. Тогда представители Сбербанка не сообщили CNews данных о производителях и поставщиках закупаемого оборудования, так как они являются «конфиденциальной информацией».

Сбербанк в сентябре 2021 г. сообщил о начале строительства крупнейшего в России ЦОДа, площадь которого составит более 55 тыс. квадратных метров. Он расположится в особой экономической зоне в Балаково и вместит 3,5 тыс. стоек. Представители Сбербанка сообщили CNews, что его строительство идет по графику.

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

Провальные тесты «Эльбрусов»

Специалисты Сбербанка провели оценку применимости в экосистеме своей организации серверов на базе российских процессоров «Эльбрус» и по ее итогам на сегодняшний день исключили такую возможность. Об этом рассказал представитель лаборатории новых технологических решений Сбербанка Антон Жбанков.

«Технические выводы достаточно простые: очень слабо для сравнения с Intel Xeon — мало памяти, медленная память, мало ядер, мало частоты. Функциональные требования катастрофически не выполнены», — сообщил он. По его словам, даже близко не может идти речи об эксплуатации в банке предоставленных на тестирование серверов.

Сбербанк проводил изучение серверов по различным методикам. Приведенные критические оценки в первую очередь относятся к итогам функционального тестирования по методике Sberinfra на соответствие корпоративным эксплуатационным требованиям банка.

В результате тестирования, как отметил Жбанков, «чуда не произошло» — серверы показали соответствие семи из 44 параметров («наличие лапки кабель-менеджмента, наличие рельсов, наличие индикации каждого элемента, наличие удаленного управления» и пр.) — 16%.

«Тесты в принципе вполне выполнимые. Мы так понимаем, что МЦСТ просто раньше с ними никогда не встречались, не работая с коммерческими компаниями, — сказал специалист. — Все понимаем, все принимаем; результаты переданы в МЦСТ».

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

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

Как еще испытывались серверы на «Эльбрусах»

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

На других этапах было проведено синтетическое тестирование на основе известных бенчмарков PGbench из пакета PostgreSQL и SPEC CPU 2017, а также прикладное тестирование на основе Java-приложения, реализующего бизнес-логику.

В качестве критериев по оценке продуктов использовались ценовая эффективность (количество транзакций на $100 млн), средняя производительность на сервер с типовой нагрузкой, а также время старта и отклика Java-приложения.

Сравнение проводилось по отношению к серверу на базе 20-ядерного чипа с частотой в 2,1 ГГц — Intel Xeon Gold 6230. В Сбербанке такую технику называют классической (не топовой); она тысячами закупается этой организацией.

Изделия на российских чипах уступили зарубежному конкуренту по всем параметрам, однако полученные результаты сотрудников Сбербанка все же «неожиданно и очень приятно» удивили.

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

«На данный момент “Сбер” говорит нет, но мы приятно удивлены, что это вообще работает, — резюмирует Жбанков.

Комментарии МЦСТ

К выступлению Жбанкова с описанными заявлениями на партнерском мероприятии МЦСТ (разработчик «Эльбрусов») специалисты компании подготовили свои комментарии, слайд с которыми был включен в его презентацию.

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

«За время тестирования улучшили время старта Java-приложений на 30%, — указывают специалисты МЦСТ. — Над ускорением troughput не работали. Запланирована работа по дальнейшему улучшению характеристик Java-машины. Часть функциональных требований невозможно выполнить на не-х86 платформах в принципе».

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

«В будущих версиях платформы “Эльбрус” планируется увеличение объема ОЗУ: сервер “Эльбрус-8СВ” до 1 ТБ, сервер “Эльбрус-16С” до 4 ТБ на сервер, — заверяют в компании. — В будущих версиях платформы “Эльбрус” планируется поддержка стандартов ОЗУ: сервер “Эльбрус-8СВ” до DDR4-2400, “Эльбрус-16С” до DDR4-3200. Для поддержки Enterprise-сред для контейнеризации и виртуализации для использования в облачных платформах заложены технические возможности в процессор “Эльбрус-16С”».

Уже вне презентации Жбанкова МЦСТ представила некоторые дополнительные комментарии.

«Java-приложение: это сложный ПАК, включает Java-application и СУБД, МЦСТ не имело доступа к приложению, что не позволило провести полноценный анализ, — говорится в них. — Удалось вслепую улучшить время старта Java-приложения и задержку отклика в три раза только подбором опций запуска Java-машины».

Для цели тестирования Сбербанком было разработано и передано макетное приложение, — продолжают сотрудники МЦСТ. — Для этого макетного приложения за счет доработки Java-машины и подбора опций улучшили среднее время отклика на процессоре “Эльбрус-8С” с исходных 24 мс до 4 мс (в шесть раз), при этом на X86 (Соге i7-9700 CPU 3 GHz) оно получилось 3 мс».

«При запуске Java-приложения на сервере загружались не более четырех ядер, что позволило платформе х86 поднимать частоту до 3,9 ГГц, что, скорее всего, не соответствует частоте ядер полностью загруженного сервера (2,1 ГГц)», — добавляют в МЦСТ.

Автор статьи

Куприянов Денис Юрьевич

Юрист частного права

Страница автора

Читайте также: