Российские банки переходят на отечественные СУБД: опыт Газпромбанка и контекст рынка
С 2025 года организации, владеющие значимыми объектами критической информационной инфраструктуры, обязаны использовать российское ПО, а с 2026 года — и отечественные СУБД. Газпромбанк прошёл этот путь за 2,5 года подготовки и 3 часа финального переключения. Разбираем, как устроен этот переход и что происходит на рынке.
Законодательный контур: от указа к отраслевым срокам
Основой импортозамещения в ИТ стал указ президента № 166 от 30 марта 2022 года. Он установил два ключевых рубежа: с 31 марта 2022 года субъектам критической информационной инфраструктуры запрещено приобретать иностранное ПО, а с 1 января 2025 года — использовать его. Для банковской сферы это означало необходимость замещения не только прикладных систем, но и систем управления базами данных, на которых эти системы работают.
Позже сроки для части объектов были скорректированы: ряду организаций разрешили завершить переход до 1 января 2028 года, а наиболее сложным проектам — до 1 декабря 2030 года. При этом стратегическая цель осталась неизменной: к 2030 году около 80% предприятий ключевых отраслей должны работать на отечественном программном обеспечении.
Показательна реакция рынка: в сентябре 2023 года крупные банки на встрече с регулятором просили отсрочить обязательный переход на российские СУБД. Аргумент — длительная адаптация автоматизированных банковских систем, исторически завязанных на Oracle и подобные платформы. Отсрочка частично была предоставлена, но вектор не изменился.
Почему гибридная схема не работает
У Газпромбанка, чьи активы превышают 17 трлн рублей, доля значимых объектов критической информационной инфраструктуры во всём парке автоматизированных систем невелика. Однако это самые чувствительные компоненты. Логичный соблазн — заменить только их, не трогая остальное.
Банк от такого подхода отказался. Причина прагматична: иностранные вендоры ушли с российского рынка, а значит, любая система, оставшаяся на их решениях, лишается поддержки, обновлений безопасности и возможности развития. Гибридная инфраструктура, собранная из современных технологий и решений пятнадцатилетней давности, требовала бы тысяч человеко-часов только на объяснение сотрудникам всех нюансов.
Поэтому была поставлена более широкая задача: не просто выполнить требования закона, а перестроить логику ИТ-инфраструктуры — с расчётом на масштабируемость, длительный жизненный цикл и встроенную безопасность.
Выбор СУБД: скорость восстановления как решающий аргумент
Сравнение платформ велось по практическим критериям. Один из них — скорость резервного копирования и восстановления. При фатальной ошибке время простоя критично. Postgres Pro Enterprise восстанавливается из резервной копии примерно за 2 часа; протестированные иностранные решения — за 14 часов. Для банка с ежедневными транзакциями на триллионы рублей разница в 12 часов — это принципиально иной уровень риска.
Второй фактор — расширяемость. СУБД располагает набором расширений, позволяющих донастроить функциональность под конкретную организацию. Третий — доступность вендора. Если раньше западные производители не включали пожелания российских клиентов в свои дорожные карты, то теперь банк может напрямую обсуждать доработки с разработчиком на русском языке и получать решения в разумные сроки.
Конкурентная среда: рынок перестал быть монопольным
Выбор Газпромбанка — не единственный вариант на рынке. К 2026 году сформировалось несколько значимых игроков:
- Postgres Pro — семейство СУБД, ориентированное на промышленную эксплуатацию, с регулярными обновлениями и поддержкой российского вендора.
- О.К.Е.А.Н. от SberTech — платформа для сверхбольших объёмов данных с заявленным восстановлением после сбоя за 8 секунд.
- РЕД База Данных от РЕД СОФТ — решение на архитектуре Firebird, имеющее сертификацию ФСТЭК и применимое для объектов высшей категории значимости.
- FTData — продукт на базе открытой версии PostgreSQL, включённый в реестр отечественного ПО.
Такая конкуренция выгодна заказчикам: появляются альтернативы, усиливается ценовая и технологическая конкуренция, а вендоры вынуждены быстрее реагировать на запросы отрасли.
Миграция АБС: три этапа и три часа
Автоматизированная банковская система — «сердце» банка. Она обслуживает клиентов, проводит платежи и переводы, формирует отчётность. Длительный перерыв в её работе парализует организацию.
Проект разбили на этапы. Сначала программное обеспечение АБС вместе с новой СУБД более полугода тестировалось на площадке партнёра: проверялась нагрузочная способность и совместимость. Затем испытания перенесли в контур банка — с воссозданием реальной рабочей среды и подключением сотен операционистов, отрабатывавших не только обычный день, но и пиковые нагрузки вроде закрытия месяца или квартала.
Данные переносили последовательно: сначала исторические, затем актуальные, потом меняющиеся в режиме реального времени. Финальное переключение заняло три часа и прошло без прерывания обслуживания — клиенты ничего не заметили. Более того, миграция позволила повысить производительность АБС.
Практические рекомендации
Опыт банка сводится к нескольким тезисам:
Начинать заранее. Подготовка заняла 2,5 года, тогда как само переключение — 3 часа. Успех определяется качеством подготовки, а не скоростью в момент перехода.
Выбирать правильное окно. Оптимально — ночь с четверга на пятницу. Если что-то пойдёт не так, в пятницу систему можно «пронести на руках», а выходные дают запас времени на исправление.
Прорабатывать аварийный план до мелочей. Даже события с вероятностью 0,1% включаются в план: расписывается пошаговый выход из критической точки с указанием роли каждого сотрудника.
Не бояться масштаба. По оценке банка, 99% организаций способны провести подобный переход. Оставшийся 1% — человеческий фактор: объём переписываемого кода измеряется миллионами строк.
