Привет, Хабр! Меня зовут Константин Гоголев, я работаю в Сбере более 10 лет и сейчас руковожу управлением развития высоконагруженной инфраструктуры. Я расскажу о том, как мы создавали собственный шлюз прикладного уровня, как он развивался и смог полностью вытеснить вендорское решение из ИТ-инфраструктуры банка.

Зачем нужны шлюзы. Концепция сетевого зонирования и межсегментного взаимодействия

Шлюз прикладного уровня (Application Gateway) — это устройство или программное обеспечение, которое выполняет функции безопасности и управления доступом на уровне приложений. Шлюз работает на прикладном уровне модели OSI, обрабатывая и контролируя трафик на уровне протоколов приложений, таких как HTTP, FTP, SMTP и другие.

Шлюзы прикладного уровня в ИТ-инфраструктуре используют для выполнения нескольких важных функций.

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

• Во-вторых, шлюзы прикладного уровня могут использовать для контроля доступа к внутренним ресурсам компании. Они позволяют администраторам ограничивать доступ к определённым сервисам или приложениям в зависимости от IP-адреса, порта или других параметров.

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

• Наконец, шлюзы прикладного уровня часто используют для преобразования протоколов. Например, они могут конвертировать HTTP-запросы в SOAP-сообщения или наоборот. Это позволяет интегрировать различные системы и приложения, работающие на разных платформах и использующие разные протоколы.

В нашем банке принята концепция сетевого зонирования, поэтому шлюзы активно используют не только на периметре, но и внутри Банка, на границах сетевых зон.

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

DataPower был прекрасным решением, но у него были две особенности, которые немного портили впечатление. Во-первых, это программно-аппаратный комплекс: при его сбоях приходилось просить инженеров ЦОД перезагружать его, при поломках ехать самому, держать резерв на случай выхода устройства из строя, а необходимость масштабирования закладывать на год вперёд, потому что покупка, доставка (включая растаможку) и размещение были действительно долгими процессами. Второй неприятной особенностью была цена: устройство и лицензии на него были очень дорогими, а включение дополнительной функциональности стоило отдельных денег.

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

Исходя из перечисленных выше базовых функций, для ядра нового продукта выбрали веб-сервер nginx с открытым исходным кодом и намертво прикрученными к серверу модулями libmodsecurity, которые могли закрыть основные требования Банка. 

Новое решение получило название SOWA — аббревиатуру от Sber Own Web Application. Как вы можете догадаться, название всем понравилось, и Сова начала свой сложный, но успешный полёт.

Первый полёт

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

При этом выделились два серьёзных конкурентных преимущества и для команды эксплуатации, и для клиентов:

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

• Скорость развёртывания. Помимо вышеперечисленных операций по установке, у любого ПАК есть один большой недостаток: это физический объект. Если устройства заканчивались на складах, нужно было закупать новые. Или если устройства находятся в стойке в одном ЦОД, а нужно было срочно усилить «второе плечо», то приходилось заказывать перевозку. Если сгорал блок питания, то необходимо было ехать в ЦОД и менять его. Решения на виртуальных машинах были лишены всех этих проблем.

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

Сразу мигрировать с работающего решения никто не захотел, поэтому первыми клиентами стали новые интеграции, ещё не подсевшие на иглу закрытых вендорских решений. Самая первая инсталляция SOWA появилась в АС СберAPI — коммунальном сервисе, предоставляющем интеграционные шлюзы как сервис. Новые технологии заинтересовали и крупнейшего потребителя ПАК DataPower — Единый розничный интернет‑банк, который известен большинству наших читателей как Сбербанк‑Онлайн. Хотя там использовали десятки устройств, их применяли как шлюзы безопасности, не затрагивая расширенную интеграционную функциональность.

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

SOWA расправляет крылья

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

Мы решили сосредоточиться на двух направлениях: расширении функциональности со стороны СберТеха и повышении удобства получения и обслуживания продукта со стороны СберИнфры. Если с первым пунктом вектор был понятен — поддержка мультипротокольности и интеграции с сервисами потоковой антивирусной проверки и DLP‑системами (защита от утечек данных), — то в работе над второй задачей помогли два новых решения в СберИнфре: порталы Динамической инфраструктуры и Автоматизации инфраструктурных изменений.

При любом взрывном росте спроса на ИТ-инфраструктуру появляется бутылочное горлышко в виде скорости развёртывания новых экземпляров. Сейчас облачные сервисы заказа ИТ-продуктов уже прочно заняли свою нишу, но в 2017-18 годах Сбер стал одним из первопроходцев в России по развёртыванию своего внутреннего IaaS-решения для удовлетворения растущего спроса на ИТ-инфраструктуру, а SOWA стала одним из первых продуктов, появившихся на полке этого маркетплейса, под названием «Портал Динамической инфраструктуры». Моя команда разрабатывала скрипты и сценарии развёртывания, учитывая особенности продукта, например, размещение как на виртуальных серверах с одним сетевым интерфейсом, так и с двумя интерфейсами. Это было связано с использованием шлюза для интеграционного взаимодействия или для проверки трафика между внутренними и внешними сетевыми сегментами.

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

Анализ запросов стал хорошим примером «Закона Парето» — бОльшую часть запросов составляли:

• запуск, остановка и перезапуск ПО;

• обновление конфигураций;

• обновление ПО;

• выгрузка журналов и прочей информации о состоянии и настройках ПО.

Эти сценарии мы автоматизировали текущими силами команды, сделав очередной шаг от обычной группы эксплуатации в единый центр компетенций, отвечающий за продукт от начала до конца. Автоматизировав относительно небольшое количество операций, мы смогли:

• снизить на 90 % количество ручных операций, снизив не только time2market, но и вероятность ошибки из-за человеческого фактора;

• повысить удовлетворённость продуктом, в том числе потому, что появилось время на разбор сложных случаев и постановку задач на развитие функциональности.

• увеличить компетенции команды как в самом продукте, так и в разработке автоматизации;

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

Теперь, когда продукт стал удобным в получении и обслуживании, а его функциональность расширилась, SOWA заинтересовала не только новые команды, но и те, что уже использовали IBM DataPower, а миграция перестала быть добровольно-принудительной и проводилась по инициативе самих команд. Но всё же для взрывного роста объёмов потребления чего-то не хватало…

SOWA взмывает вверх

Большинство людей боится перемен: переезда в другой город, смены привычной Nokia с Symbian на непонятный iPhone/Android, новой стрижки вместо привычного полубокса или установки посудомоечной машины. Поэтому перемены поначалу вызывали опасения и волнения. А когда команде автоматизированной системы предлагают мигрировать с решения от крупного вендора, которое они используют годами, на продукт от небольшой команды, да ещё и основанный на open source, то доводы в подкрепление своих опасений и волнений появляются сами собой.

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

Необходимость быстрого масштабирования и создания новых блоков для новых клиентов и функциональности особо остро возникала у команд, напрямую работающих с самым большим сегментов клиентов Сбербанка — физическими лицами. Нам получилось найти точку соприкосновения с командой, развивающей и сопровождающей самый известный для обычных россиян продукт Сбера — «Сбербанк Онлайн». Коллегам было необходимо удобное, готовое к быстрому масштабированию и поддерживающее простое тиражирование решение для организации шлюзов, а нам был нужен крупный статусный потребитель с высоким классом критичности. Мы быстро нашли общий язык и сосредоточились на доработках, которые нужны были СБОЛу, а коллеги помогали нам, проводя всесторонние тесты, уделяя повышенное внимание производительности и надёжности решений на SOWA. В итоге команда «Сбербанк Онлайн» стала первой крупной критичной системой Банка, полностью перешедшей на SOWA и отказавшейся от ПАК IBM DataPower.

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

SOWA парит над Сбером

В 2021-23 года, благодаря миграции на SOWA, было выведено из эксплуатации более 300 устройств IBM DataPower, а в 2024 году Сбер полностью отказался от этой технологии и перешёл на SOWA. Сроки растягивались из-за необходимости поддерживать некоторые legacy-решения, ведь все новые интеграции создавались под нашу разработку с 2022 года.

Сейчас SOWA не просто заменила решение от IBM, но и превосходит его по функциональным возможностям. В современных условиях важной особенностью стала поддержка актуальных отечественных решений, от систем антивирусной потоковой проверки до ГОСТ‑шифрования и протоколов взаимодействия со внешними контрагентами. При этом мы не замыкаемся на интеграциях с другими решениями от Сбера и СберТеха, но и активно реализуем интеграции с решениями от КриптоПРО, AV Soft и других отечественных вендоров. Полученный за годы эксплуатации опыт разработки и сопровождения позволяет реализовать практически любую интеграцию или конфигурацию решения.

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

За 8 лет SOWA пролетела путь от пилотного решения до зрелого комплексного продукта, взрастила не одно поколение администраторов и разработчиков и стала основой крупнейшей ИТ‑инфраструктуры страны.