ЮMoney перевёл АБС с MS SQL и Windows на PostgreSQL и Linux

Разбор новинки простыми словами: что это, кому нужно и брать ли.

Кейс показывает, что миграция СУБД — это не автоконвертация, а ручное переписывание и оптимизация логики: без плана отката и параллельного контура импортозамещение нагруженной системы не уложить в часы простоя.

Связанные услуги: каталог, AI Boost Team, стать клиентом.

32 тысячи строк SQL. Пять терабайт данных. Больше 200 бизнес-процессов. И ни один автоматический конвертер не справился с этой работой целиком. ЮMoney вместе с АО «ПрограмБанк» довели до конца перевод своей автоматизированной банковской системы с Windows и MS SQL Server на Linux и PostgreSQL. Звучит как техническая заметка для архитекторов. Читать её стоит любому собственнику, у которого критичная система живёт на иностранном стеке и однажды должна переехать.

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

Вместе с АО «ПрограмБанк» полностью перевели нашу АБС «ПрограмБанк.АБС» на ОС Linux и СУБД PostgreSQL.

Вердикт за 30 секунд

• Что сделали: банковское ядро перевели на открытый стек, база ужалась с 5 ТБ до примерно 1 ТБ за счёт пятилетней глубины данных.
• Чем заплатили: ручной переписью 32 000+ строк кода, падением части операций в 2–5 раз (а модуля подписи в 10 раз) и месяцами на отладку производительности.
• Кому подходит как образец: тем, у кого есть второй контур, тестовые стенды и готовность держать новую систему параллельно минимум неделю. Без этого не начинайте.

Что именно переехало

АБС — это ядро банковского учёта. Счета, проводки, платежи, отчётность. Слой, где ошибка стоит не перезапуска сервиса, а разбирательства с регулятором. ЮMoney держал это ядро на связке Windows плюс MS SQL Server. Теперь там Linux плюс PostgreSQL.

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

Пятилетнее окно по данным — приём, который стоит взять на заметку. Полная база на 5 ТБ грузилась бы и индексировалась несопоставимо дольше, а финальное переключение должно было уложиться в несколько часов. Часть выигрыша по объёму дала не оптимизация, а трезвое решение не тащить историю глубже нужного. Это управленческий выбор, не инженерный.

Откуда взялась сама задача

Причины две группы. Первая — требования регулятора к импортозамещению в финансовом секторе. Вторая — собственные риски. После ухода зарубежных вендоров из России банки столкнулись с тем, что поддержка и обновления просто прекратились. Тут не про политику, а про бытовую уязвимость: если критическую дыру в проприетарной СУБД некому закрыть, вы живёте с ней до следующего релиза, которого не будет.

Открытый стек даёт предсказуемые затраты на поддержку и возможность править решение под себя. Для SMB тот же довод работает без поправки на масштаб: когда вендор отключает вам доступ к обновлениям, бизнес-процесс останавливается так же, как у банка, только заметнее для клиентов.

Порядок работ здесь важнее самих работ. Сначала развернули параллельную инфраструктуру: новую АБС на Linux, PostgreSQL, тестовые стенды и вспомогательное ПО. Закупка оборудования вылилась в отдельную ветку проекта — команда собирала системные требования и сопровождала подготовку железа. Действующая система при этом продолжала работать. Именно на этом параллельном контуре потом строились все следующие этапы: перенос данных, адаптация логики, тесты.

Почему автоконвертация не вывезла

Самый полезный кусок кейса — про 32 000 строк. Transact-SQL пришлось перенести в PL/pgSQL. Пробовали инструменты автоматической конвертации, включая решения на базе ИИ. Результата не хватило.

Мы пробовали инструменты автоматической конвертации, в том числе на базе ИИ, но их качества не хватило, чтобы сделать всё автоматически.

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

Это и есть главное расхождение с ожиданиями рынка. На импортозамещение до сих пор часто смотрят как на «нажми кнопку migrate». Продавцы конвертеров такую картинку поддерживают охотно. Кейс ЮMoney показывает цену реальности: 32 000 строк, проверенных не абстрактно, а на собственных бизнес-процессах. Плюс минимум треть всего времени миграции ушла на построение индексов — скучная работа, которую в планы обычно не закладывают. И отдельная проверка полноты переноса: сверить всё целиком невозможно, поэтому ключевые показатели сравнивали через специальные механизмы.

Где просело и как вытаскивали

После перехода на PostgreSQL часть операций замедлилась заметно.

Например, массовая обработка платежей стала занимать в 2–5 раз больше времени. Модуль подписи и вовсе начал работать в 10 раз медленнее.

Второй случай показателен: модуль подписи просел не из-за СУБД, а из-за перехода с Windows на Linux. Проблема лежала в зоне вендора, и решал её вендор. Практический вывод для любого проекта: часть замедлений вы поймаете там, где не ждали, и не в своей кодовой базе. Заранее договоритесь, кто отвечает за такие участки и в какие сроки.

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

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

Финал — пошаговый план отката с точкой невозврата. Без него обещание «уложимся в несколько часов» ничего не стоит. Уложиться можно только тогда, когда решение вернуться назад принято заранее и описано по шагам.

Кому это нужно, а кому рано

Кейс релевантен, если у вас есть система, простой которой измеряется деньгами: биллинг, платёжный шлюз, складское ядро, учётная платформа. Масштаб не обязан быть банковским. Логика та же, отличается число нулей.

Что стоит вытащить из этого опыта и приложить к своему проекту:

1. Считайте не только лицензии. Обвязка (бэкап, логирование, балансировка, криптография) съест время, о котором вы не думали.
2. Заложите ручную перепись. Автоконвертеры дадут черновик, не рабочую систему. В смете должна быть строка на ревью и оптимизацию.
3. Отдельно планируйте индексы и сверку данных. Это не деталь, это треть работы.
4. Договоритесь о глубине истории. Пять лет против «всё, что есть» меняют окно простоя радикально.
5. Стройте второй контур до, а не во время. Неделя параллельной работы на реальном потоке — минимальный разумный порог.
6. Пишите план отката. С точкой невозврата и владельцем решения.

Рано — если система маленькая, а данные можно перелить за ночь с полной проверкой. Тогда весь этот аппарат избыточен и вы просто потратите квартал.

Подвох

Первое. Кейс не даёт ответа на вопросы, которые первыми задаст финдиректор: сколько стоило, сколько заняло по календарю, какова стоимость поддержки сейчас. Даты завершения тоже нет — «недавно». Считать по этим вводным бюджет нельзя, можно только строить структуру проекта.

Второе. Сокращение базы с 5 ТБ до 1 ТБ часто читают как «PostgreSQL компактнее». Нет. Основной эффект дала пятилетняя глубина данных. Не перепутайте причину со следствием в собственной смете.

Третье. «Местами производительность выросла» — не универсальное свойство нового стека. Это результат ручной оптимизации по горячим процедурам. Если у вас нет людей, которые умеют это делать, переезд даст ровно противоположный эффект: формально работает, по факту медленнее в разы.

Брать или подождать

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

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

Частые вопросы

PostgreSQL медленнее MS SQL?

Вопрос поставлен неверно. Платежи просели в 2–5 раз после перехода, но причиной была неадаптированная логика и настройки, а не приговор СУБД. После ручной оптимизации по ключевым процедурам вышли на целевые показатели.

Можно ли повторить это компании на 30 человек?

Общая последовательность — да. Объём работ будет другой: у вас меньше кода и меньше процессов. Но принципы те же: второй контур, ручная проверка конвертированного кода, репетиция переключения.

Почему не перенесли всю базу?

Не понадобилось. Взяли данные за последние пять лет, это сократило объём и время простоя при финальном переключении. Решение управленческое, не техническое по своей природе.

Сколько это заняло по времени?

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

Что дальше

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

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