Как Газпромбанк перешел на российскую СУБД
Перевести крупный бизнес на российские информационные технологии (ИТ) — не та задача, которую можно решить быстро. Большим корпоративным структурам свойственно наличие сложной экосистемы, состоящей из сотни автоматизированных систем, тесно связанных между собой. Часто они работают на годами выстроенном унаследованном зарубежном программном обеспечении. Тем интереснее изучить опыт крупного банка, который прошел путь длиной в несколько лет и смог по-настоящему заменить иностранные решения российскими ИТ-продуктами.
Гибридные системы или тотальное импортозамещение?
С 1 января 2025 года по указу президента все организации, обладающие значимыми объектами критической информационной инфраструктуры (ЗОКИИ), должны были перейти на российское программное обеспечение. А на российские СУБД — с 1 января 2026 года. Тогда, в 2022-м, для нас это означало, что нужно за 2,5 года отказаться от привычных зарубежных платформ, найти оптимального российского вендора и совершить миграцию.
Справедливо уточнить, что процент ЗОКИИ во всех автоматизированных системах банка не так велик. Но на практике это самые важные и чувствительные элементы. Наверное, у многих компаний возникает соблазн заменить только ЗОКИИ и не вмешиваться в остальную ИТ-инфраструктуру: на этапе внедрения так действительно проще и быстрее. Но долго ли продержится такая поделка, наспех склеенная из актуальных технологий вперемешку с решениями 15-летней давности, да еще и без нормальной поддержки от поставщиков, ушедших из России?
Мы взвесили риски и преимущества и пришли к выводу: гибридная ИТ-инфраструктура не наш вариант. Такая конструкция потребовала бы от нас тысяч человеко-часов просто на то, чтобы объяснить сотрудникам все нюансы. А еще на то, чтобы осознать, как встраивать новые сервисы в сложившуюся конфигурацию со всеми ее перекосами.
Мы перед собой поставили более амбициозную задачу: недостаточно только импортозаместиться, чтобы соответствовать требованиям законодательства, необходимо перестроить саму логику ИТ-инфраструктуры. Цель — не допустить потери качества и скорости работы, обеспечить масштабируемость и долгий срок жизни внедряемых решений, а также учесть угрозы безопасности. Поэтому было решено создать внутрибанковскую платформу с потенциалом роста, импортозаместив свою ИТ-инфраструктуру, которая позволила мигрировать автоматизированные системы (АС) в ландшафт, свободный от иностранных продуктов.
Естественно, такие далекоидущие планы вызывали у скептиков сомнения. Некоторые говорили, что определенные сегменты не подлежат импортозамещению в принципе. Опираясь на наш опыт и тот путь, который мы прошли, могу сказать, что таких областей нет. Любая задача решаема, если задан верный горизонт времени: многие перемены не случаются за день, но рано или поздно результат будет достигнут.
Конечно, с тремя сотрудниками в команде и парой месяцев на работу задачу не решить. Однако если правильно рассчитать трудозатраты, корректно поставить цель и наметить реалистичные сроки, то переход окажется вполне реальным. Только начинать надо заранее, а не в последний момент. Достаточно вспомнить цифровизацию: когда-то говорили, что и она невозможна, но колесо эволюции крутится, и сейчас можно смело сказать, что цифровыми стали почти все компании.
Унаследованные системы: оставаться
или меняться
Иногда в дискурсе об импортозамещении возникает особая тема: будущее унаследованных систем, которые могли создаваться 20 или 30 лет назад. Это устаревшее, но все еще работающее программное обеспечение, которое не требуется менять по закону. Возникает логичный вопрос: зачем переходить на незнакомое отечественное решение, если есть привычная система, которая нормально функционирует?
Однозначного ответа нет, ведь унаследованные системы обладают своими плюсами и минусами. С одной стороны, они хорошо знакомы: бизнесу не нужны сотни часов, чтобы в них разбираться и обучать персонал работать в непривычном интерфейсе. С другой стороны, их сложно подстроить под актуальные нужды бизнеса и они более уязвимы с точки зрения безопасности: когда их разрабатывали, мир еще не знал киберугроз сегодняшнего дня. Подчас одна только забота о кибербезопасности в унаследованных системах сводит на нет все преимущества от использования знакомых продуктов.
У перехода на современный технологический стек есть ключевое преимущество — возможность быстрого развития продукта. Для унаследованной системы появление новых функций сопряжено с переписыванием ядра: это долгий процесс, который в некоторых случаях может занимать до полугода. Актуальный технологический стек благодаря своей высокой сегментированности позволяет добавлять новые функции чуть ли не каждый день.
Это неоспоримый плюс для бизнеса в наши дни: рынок услуг настолько требователен и динамичен, что всего одни сутки от идеи до ее реализации уже кажутся долгим сроком. Бизнес нам не простит, если ИТ-департамент будет тормозить его и утягивать в двухтысячные, если не девяностые. Конечно, где-то до сих пор программируют на языке «Кобол», но это не значит, что современный банковский бизнес должен оставаться в прошлом веке в плане технологий.
Как мы сравнивали СУБД разных поставщиков
Если пофантазировать и представить, что мы живем в условиях абсолютно свободного рынка, где можно приобрести программное обеспечение из любой страны на планете, а российский рынок ИТ находится на той стадии развития, на которой он сегодня реально находится, — мы бы все равно предпочли отечественное решение. Не только ради поддержки своего производителя, но и из чисто бизнесовых соображений.
Например, около пяти лет назад мы начали постепенную интеграцию российских решений в неключевые процессы. Тогда же мы обратили внимание на СУБД семейства Postgres Pro, так как она заточена под промышленную эксплуатацию и регулярно обновляется. К тому же ее поддерживает российский вендор с большим опытом анализа работы СУБД. Система высокопроизводительна, не так требовательна к своему окружению, более проста в эксплуатации и при этом столь же надежна. После кропотливого анализа платформы мы пришли к выводу, что с точки зрения наших бизнес-задач западные решения проигрывают Postgres Pro Enterprise по всем параметрам.
Приведу пример с резервным копированием и восстановлением данных. Высокая скорость этих процессов была для нас одним из ключевых требований, потому что при наступлении фатальной ошибки критически важно быстро восстановиться из резервной копии. Postgres Pro Enterprise делает это за два часа, иностранные решения, которые мы тестировали, — за 14.
Кроме того, у Postgres Pro Enterprise есть множество расширений, которые позволяют добавить необходимый конкретной компании функционал, чтобы добиться гибкости и удобства управления СУБД. И здесь кроется еще одна причина, почему даже в мире бесконечных возможностей для покупки ПО мы бы выбрали отечественную разработку. Дело в том, что сейчас у российского бизнеса появилась потрясающая возможность влиять на дорожную карту вендора, на появление в продуктах новых функций.
До повсеместного импортозамещения нам было не достучаться до западных производителей: они не собирались прислушиваться к нашим пожеланиям. Нам оставалось довольствоваться тем, что есть. Сейчас российская ИТ-отрасль слышит потребности бизнеса, в частности банков, и отвечает на них в своих продуктах. С вендорами можно связаться быстро, обсудить все на русском языке, а затем в разумные сроки получить решение — это же ровно то, о чем ИТ-департаменты всех банков мечтали последние 20 лет.
Миграция «сердца» банка на новую СУБД
Важнейшим этапом нашей работы по переходу на российскую СУБД стал перевод на нее «сердца» банка — автоматизированной банковской системы (АБС). На ней держится вся жизнь банка: система автоматизирует ключевые процессы, и длительный перерыв в ее работе может парализовать организацию — невозможно будет обслуживать клиентов, проводить платежи и переводы, формировать отчетность.
Проект перехода был очень ответственным и сложным, поэтому состоял из нескольких этапов. Сначала программное обеспечение, на котором работает наша АБС, вместе с Postgres Pro Enterprise больше полугода проходило разные тесты на площадке партнера. Мы проверяли, выдерживает ли этот тандем необходимую банку нагрузку, и решали проблемы совместимости.
Затем мы перенесли тестирование в контур банка. Здесь проводили не только технические испытания, но и воссоздавали реальную рабочую среду, в которой должна была справляться со своими задачами новая СУБД. Подключали к системе сотни операционистов, которые воспроизводили не просто свой рабочий день, а дни повышенной нагрузки, например закрытие месяца или квартала. Так мы проверяли быстродействие системы, совместимость ПО и оборудования. По результатам дорабатывали программное обеспечение банка.
На следующем этапе мы приступили к перемещению данных банка из старой СУБД в новую: сначала перенесли устаревшие данные, затем актуальные, а следующим шагом те, что меняются в режиме реального времени. После этого в назначенное время за три часа полностью переключили АБС на новую СУБД. Отмечу, миграция на Postgres Pro Enterprise позволила нам повысить производительность АБС.
Как подготовиться к бесшовной миграции
Вероятно, некоторые компании, которые только начали обдумывать переход на российские решения, боятся действовать. Но, если судить по нашему опыту, в 99% случаев переход будет под силу любой организации. Один процент я оставляю на человеческий фактор — все же разработчикам придется переписать миллионы строк кода.
Не стоит бояться и сроков перехода. Благодаря долгой кропотливой подготовке на протяжении 2,5 лет нам в итоге удалось переключиться на Postgres Pro Enterprise буквально за три часа. Причем без прерывания обслуживания: миграция была настолько бесшовной, что клиенты банка этого не заметили.
Однако даже самое продвинутое решение требует основательной подготовки и слаженности команды. Например, важно выбрать правильное время перехода: лучше, чтобы это была ночь с четверга на пятницу. Если что-то пойдет не так, в пятницу систему можно будет «пронести на руках», а в субботу и воскресенье все поправить.
Еще одна рекомендация — детально проработать аварийный план и учесть в нем даже самые маловероятные факторы, какими бы нереальными они ни казались. Оцениваем вероятность наступления события в 0,1%? Это больше нуля, а значит, берем в работу, расписываем пошаговый план выхода из критической точки с указанием точной роли каждого сотрудника. Любая трансформация сопряжена с большим количеством сложностей, легко не будет — но результат многократно окупит потраченные усилия.