Коробочные решения хороши тем, что позволяют переложить доработку и внедрение на поставщика ПО. И поначалу всё идёт хорошо: не тратится время на разработку, стоимость решения высокая, но адекватная.
Однако не всё так радужно: помимо лицензии приходится оплачивать поддержку, даже если для конкретного продукта она на данном этапе не нужна. В контрактах многие услуги появляются прицепом, просто потому, что они являются частью коробки. Кроме того, стоимость обновлений с каждым годом растёт, тогда как старые версии перестают поддерживаться. Запросы на доработку продукта под себя долго согласовываются, а иногда выясняется, что нужную фичу просто невозможно прикрутить в разумные сроки по разумной цене. Когда подобные вещи всплывают, у руководства неизбежно возникают вопросы вида «Что делать?», «Можно ли не платить?» и «Зачем платили, если можно было не платить?».
В посте мы рассказали, как разбирались с зависимостью от вендоров в Росбанке: с какими специфическими для финтеха трудностями столкнулись, как с ними справлялись и чего в итоге удалось достичь банку на ниве open source.
Почему финтех медлит с переходом на Open Source
Большая часть интернета находится под управлением серверов, использующих Nginx, а СУБД вроде MySQL или PostgreSQL уже завоевали доверие мирового сообщества. Но потребовались годы, чтобы подобные решения стали проникать в банковскую сферу.
Почему так долго? Банковская отрасль консервативна, так как напрямую оперирует большими денежными потоками — цена ошибки слишком высока. Любое изменение проверяется в самых разных аспектах десятки раз, прежде чем выйти на прод. А ещё для любого изменения в банковской сфере требуется веская причина. Некоторые люди стараются заполучить все новинки сразу после их выхода, но большинство будет пользоваться имеющимися решениями до тех пор, пока они работают. Долгое время только проприетарные продукты могли удовлетворить требования банковского сектора. Даже с появлением альтернатив выгода от их использования часто не перекрывала стоимость перехода.
Но что означает для крупного банка зависимость от поставщика программного обеспечения? Это зависимость от монополии со всеми вытекающими. В отсутствие альтернатив поставщик способен диктовать условия, от которых банк не сможет отказаться.
Стоимость лицензирования ПО — это первая линия расходов. Вторая линия — стоимость установки и поддержки. Специалистов по обучению на рынке мало, так что, обращаясь за экспертизой к различным интеграторам, мы вынуждены покрывать их расходы на персонал. Третья линия расходов заключается в обучении и сертификации собственных спецов.
Долгое время мы занимали весьма слабую позицию в переговорах с поставщиками и несли значительные издержки, которые к тому же постоянно росли.
Росбанк входит в группу Societe Generale, так что основные решения по вендорам ПО принимаются в штаб-квартире в Париже. Внутри группы мы, насколько это возможно, стараемся использовать единый технологический стек и придерживаться единых технологических стандартов. В 2016-м на уровне группы Societe Generale стартовала программа по развитию использования опенсорс-решений. Росбанк присоединился к этой программе в конце 2019-го. Основных целей три: снизить долю проприетарных решений и их вендоров в периметре банка, сократить операционные расходы на IT-системы, а также способствовать укреплению бренда банка в глазах талантливой молодёжи, чтобы привлечь молодых специалистов. В периметр программы вошли три технологических потока: базы данных, ПО промежуточного уровня (middleware) и операционные системы.
Как мы обновляли ПО на наших тонких клиентах
Одним из первых шагов к восстанию против поставщиков стала миграция тонких клиентов, используемых во всех офисах и отделениях банка, с Windows 7 на открытое ПО.
Началось всё с того, что было объявлено окончание поддержки Windows 7, которая стояла на наших тонких клиентах HP TCD. Всего таких устройств у нас насчитывалось около 4500. Железо этих девайсов нас полностью устраивало, но, как выяснилось, Windows 10 оно не поддерживает. А значит, простое обновление не представлялось возможным. Классический вариант решения проблемы заключался в закупке HP TCD следующего поколения с последующей установкой Windows 10, что нас не совсем устраивало: стоимость девайсов, лицензий, работы техников и системных администраторов выливалась в большие бюджеты. Кроме того, нужно было утилизировать предыдущее поколение неплохого железа, а это тоже затраты.
Также к образам на базе Windows были вопросы со стороны отдела безопасности: образ системы не является закрытым (read-only) и его потенциально можно модифицировать, что представляло собой достаточно серьёзную угрозу. Злоумышленник может подменить системную библиотеку, что чревато внедрением зловредного ПО в инфраструктуру банка. Конечно, за счёт остальных мер обеспечения безопасности подобное событие крайне маловероятно, но безопасность складывается из исключения вот таких крайне маловероятных неблагоприятных событий. Тогда мы решили перейти на альтернативную платформу на базе Linux и разработать закрытый от изменений образ ОС. В качестве базовой ОС была выбрана HP ThinPro, основанная на Ubuntu 16.
Выбор был вполне очевиден, так как это ОС от производителя, предназначенная специально для тонких клиентов HP, включая те устройства, что использовались у нас. Таким образом, мы не теряли поддержку железа производителем, что определённо говорило в пользу данного решения. Практически всё, что предоставляется в рамках ThinPro, можно накатить самостоятельно на ту же Ubuntu, но, когда есть готовый образ и поддержка, — это намного удобнее. Начиная с версии 7.1, ThinPro можно использовать не только на тонких клиентах HP, но и на любом железе, отвечающем минимальным требованиям, применяя средство развёртывания HP ThinPro PC Converter (по сути это просто средство записи загрузочного образа на флешку). Проблема вендор-лока исчезла практически полностью, мы стали более независимыми и от поставщиков ОС, и от поставщиков железа.
Из коробки в образе предустановлены клиенты Citrix и VMware Horizon View, однако другие часто используемые пакеты, в частности некоторые медиакодеки, отсутствуют. Мы модифицировали базовый образ, установив плагины поддержки медиакодеков, а также настройки сканеров и печати. Управление TCD осталось за HP Device Manager.
С учётом всех работ оценочная стоимость данного решения оказалась в 8 раз меньше по сравнению с обновлением парка тонких клиентов. С точки зрения пользовательского опыта мало что поменялось (это же тонкий клиент, помните?), хоть операторам и пришлось пройти дополнительную подготовку.
Другие направления, где мы избавлялись от vendor lock
Почувствовав в себе силы, мы решили попробовать уйти от vendor lock в других направлениях.
Долгое время СУБД в компании были представлены MsSQL и Oracle DB. В отсутствие экспертизы поначалу даже те продукты, что могли использовать PostgreSQL из коробки, строились на MsSQL и Oracle DB.
Чтобы изменить ситуацию, мы стали создавать платформенные команды по развитию и поддержке опенсорс-продуктов. В частности, команду по работе с PostgreSQL. На тот момент в банке уже были работающие системы на PG, так что определённый опыт работы с платформой имелся. Но так как команда была ещё молода, для решения сложных случаев мы привлекали в том числе сторонних подрядчиков, постепенно перенимали их опыт и наращивали собственную экспертизу. Первым проектом по миграции был перевод внутреннего сервиса Zabbix с Oracle DB на PostgreSQL. Вообще это стандартная практика — отрабатывать миграции на внутренних инфраструктурных сервисах, перед тем как переходить к бизнесовым системам.
Экспертизу привлекали внешнюю, это был интегратор. Он своими силами разработал целевую архитектуру, обновил версию Zabbix и осуществил миграцию Zabbix на PostgreSQL. При этом было высвобождено 48 лицензий Oracle Ent. Экономию от такого значительного сокращения может оценить любой специалист по БД.
Примерно та же ситуация сейчас с Apache Kafka и рядом других продуктов. Помимо собственных платформенных команд, мы также заключаем договоры с производителями и поставщиками решений на базе открытого исходного кода. Но по сравнению с проприетарными решениями стоимость этих контрактов ниже.
Разница в том, что, во-первых, стоимость поддержки за ядро у опенсорс-решений существенно ниже; во-вторых, для проприетарных решений вы обязаны весь используемый парк лицензий ставить на техподдержку, а в случае опенсорса вы вольны выбрать на поддержку только те системы, у которых такая необходимость действительно есть.
В качестве ОС на серверах мы выбрали CentOS. От серверного дистрибутива нам требуется надёжность, открытость, но чтобы была поддержка крупных игроков и максимальная приближенность к нуждам энтерпрайза. CentOS, как предельно приближенная пересборка выпусков Red Hat Enterprise Linux, нам подошла как нельзя лучше. Но тут не обошлось без сюрпризов: мы работали с CentOS 7 и рассчитывали на долгосрочную поддержку CentOS 8, на которую планировали обновиться, как вдруг Red Hat заявила о прекращении поддержки этой версии дистрибутива в скором будущем и рекомендовала перейти на непрерывно обновляемую редакцию CentOS Stream, а это меньше похоже на RHEL, чем все предыдущие выпуски CentOS. Что с этим делать и как жить дальше, мы пока не решили — прямо сейчас прорабатываем варианты. Пока продолжаем работать с CentOS 7, которая будет поддерживаться RH ещё пару лет.
Претерпела изменения и инфраструктура разработки. Для управления исходным кодом сейчас мы рассматриваем GitLab как опенсорсную альтернативу используемому в банке стеку Atlassian. Есть внедрения: как GitLab Community Edition, так и Enterprise Edition. В целом это соответствует общему подходу нашей программы развития опенсорс-решений: для каждого функционального стека наряду с проприетарным платформами должна быть альтернатива в виде опенсорсного аналога, причём по нему в банке должна быть экспертиза.
Даёт ли open source что-то, кроме экономии
Помимо очевидной финансовой выгоды использование открытого исходного кода в инфраструктуре компании принесло нам неожиданные плюсы. В частности, появилась возможность гибко выстраивать архитектуру. Изначально у нас существовала монолитная платформа дистанционного банковского обслуживания (ДБО) и любое изменение требовало регресса всего бэкенда. Это плохо влияло на скорость доставки приложений конечному пользователю, а проприетарное ядро ограничивало нас в возможностях модификации.
В итоге мобильный сервис был полностью перестроен на микросервисных принципах, которые позволили обеспечить изоляцию, гибкое управление функционалом и в разы улучшить показатели Time-to-Market. Подробнее о принципах построения «чистой архитектуры» в нашем банке мы рассказывали в отдельной статье, а если хочется больше практических примеров — добро пожаловать в серию статей про WSO2 API Manager (раз, два).
Немаловажно также наличие хорошей документации и большого комьюнити вокруг open source. Знания об особенностях работы с PostgreSQL найти на порядок проще, чем в случае с Oracle. Всегда можно спросить совета по проблеме в специализированных сообществах, и вероятность получить квалифицированный ответ как минимум не ниже, а возможно, и выше, чем в случае обращения в официальную поддержку. И всё же поддержка в open-source-продуктах тоже есть: сейчас у нас контракт с интегратором, а в дальнейшем мы планируем перейти на поддержку от российского разработчика PostgreSQL через его сертифицированных партнёров.
Кроме того, у открытого исходного кода есть преимущество, которого по определению нет у кода закрытого, — это возможность увидеть и прочитать его (да, вот так банально). Прямой доступ к коду позволяет детально разобраться в работе системы, наработать собственную экспертизу и исключить некоторые проблемы, связанные с неудачным использованием ПО (иногда даже до возникновения этих проблем).
Как бонус — использование открытого исходного кода делает компанию более привлекательной в качестве работодателя. Стоимость специалистов с экспертизой в open source растёт, но высокий спрос на них рождает предложение — на рынок выходят новые кадры. Мы готовы вкладываться в развитие наших специалистов, в то же время не сильно ограничивая их в свободе выбора используемых решений.
Конечно, банковская сфера всё ещё остаётся достаточно консервативной: любой open source здесь должен быть многократно проверен. Но количество таких решений год от года только растёт, а это значит, что выбор инструментов при разработке становится шире, что не может не радовать.
Что мы поняли, когда начали избавляться от vendor lock
Чтобы запустить столь масштабные изменения, требуется поддержка со стороны топ-менеджмента организации. А чтобы эта поддержка появилась, руководство должно иметь информацию о возможностях, которые даёт ПО с открытым кодом. В нашем случае для правления банка была проведена отдельная презентация программы перехода на open source, где мы подсветили цели и задачи, а также показали масштаб нововведений. Вертикальная коммуникация очень важна, ведь без поддержки правления реализовать такую программу в банке невозможно.
Если вы решили пойти по пути трансформации текущих систем, вам не обойтись без инвентаризации. Сначала необходимо определить, какие системы в текущей инфраструктуре могут стать кандидатами на миграцию, а потом выделить среди них ключевые. В нашем случаем такими элементами были платформы Oracle Database и Microsoft SQL Server.
Мы исключили из списка системы, которые так или иначе будут выведены из эксплуатации в ближайшие два года. Убрали коробки, в которых конфигурация с PostgreSQL не поддерживалась вендором. Оставили только энтерпрайз-версии Oracle DB и MSSQL. Сформированный в результате список систем мы проработали на предмет технической возможности миграции с помощью средств Ora2PG для Oracle DB и iSpirer для MSSQL. Данные средства широко используется в практике миграции на PostgreSQL.
По результатам аудита, проведённого с нашим партнёром (российским интегратором), список был скорректирован. По оставшимся в нём системам мы оценили трудозатраты на миграцию, что позволило сразу прикинуть экономическую эффективность. Это позволило выработать чёткий план, что в итоге упрощает обсуждение со всеми заинтересованными — банк понимает, что, в какой момент и зачем мы что-то делаем. Например, в первую очередь мы решили переводить на open source системы, поддерживающие PostgreSQL из коробки — это дало первые большие результаты ещё на ранних этапах реализации программы.
Основные каналы проникновения опенсорса в любой организации — это внедрение новых систем в рамках проектов (Change) и перенос действующих IT-систем на новые платформы (Run). Для Change очень важно организовать коллаборацию с корпоративными и solution-архитекторами, а также определить магистральные опенсорсные платформы, под которые будут формироваться платформенные команды. Например, у нас это PostgreSQL, Kafka, JBoss, WSO2, RHEL/CentOS.
Потребуется уделить время популяризации программы и провести воркшопы с гильдиями и сообществами разработчиков. Успех внедрения open source во многом зависит от того, используются ли эти решения в командах. Внутри организации должны сформироваться «центры компетенций» — сотрудники и команды, которые поддерживают внедрение новых платформ. Принципиально важно накапливать компетенции по этим платформам внутри, следить за их развитием и минимизировать bus factor.
Чем больше разработчиков знают, что в банке можно пилить сервисы на PostgreSQL, что уже есть выделенная команда поддержки, что эта платформа стала стандартом, — тем шире воронка потенциальных участников, тем больше решений разрабатываются на опенсорсе. Мы это оцениваем исходя из количества обращений на создание новых экземпляров PostgreSQL, Middleware и RHEL/CentOS.
И наконец, главное: программа по развитию опенсорса — это игра вдолгую. Наивно ожидать быстрых результатов. Эффект от подобных мероприятий в крупных компаниях начинает ощущаться спустя 6–9 месяцев.
Не стоит также планировать полную замену всех проприетарных платформ на опенсорсные. Есть вероятность, что многие IT-системы просто не смогут на них работать. Но вдумчивый подход и долгосрочное планирование позволят вам двигаться к цели небольшими шагами — даже если работаете вы в финтехе, где цена ошибки высока.
Наша программа перехода на опенсорс рассчитана вдолгую, впереди ещё много вызовов. Но мы уверены, что так или иначе преодолеем их — и расскажем об этом Хабру.
