Содержание
Читайте в Telegram
|
После ухода зарубежных решений стало понятно, что привычная инфраструктура больше не работает как раньше. Банкам пришлось в сжатые сроки искать новые решения, пересобирать архитектуру и брать на себя те риски, которые раньше закрывали вендоры.
Мы в ОТП Банке прошли этот путь одними из первых и сегодня делимся тем, как принимались решения, какие варианты рассматривались и что в итоге сработало.
Почему мы не стали разрабатывать своё
Собственную разработку мы рассматривали как один из сценариев, но довольно быстро стало понятно, что этот путь не укладывается в реальные сроки. Полноценный процессинг с нуля занял бы не менее пяти лет, которых у нас не было.
В условиях активного импортозамещения это означало слишком высокий риск по срокам и ресурсам. Поэтому мы сосредоточились на выборе готового решения, которое можно адаптировать под нашу инфраструктуру.
Как мы выбирали решение
Мы проанализировали ключевых российских вендоров, представленных на рынке на тот момент, включая БПЦ, «Кард стандарт» и «Компас+». Все решения оказались монолитными и построенными на СУБД Oracle. Это означало, что после внедрения нам пришлось бы проходить дополнительную миграцию уже на PostgreSQL. Такой сценарий увеличивал нагрузку и добавлял риски.
В итоге мы выбрали решение компании Solanteq, изначально построенное на отечественном стеке. Важную роль сыграли не только технические характеристики, но и формат взаимодействия. Для нас было принципиально, чтобы команда вендора была готова работать с нами в плотной связке на всех этапах внедрения.
Где оказалось сложнее, чем мы планировали
Сам переход занял около 18 месяцев, еще несколько месяцев ушло на доработки и тестирование. При этом довольно быстро стало понятно, что сама процессинговая платформа является только частью задачи.
Основная сложность возникла на этапе интеграции с существующим ландшафтом банка. Новый процессинг нужно было связать с автоматизированной банковской системой, дистанционным обслуживанием, цифровыми каналами и отчетностью перед регулятором. Именно здесь объем работ оказался выше ожиданий, и на интеграцию ушло больше времени, чем мы закладывали изначально.
Отдельным блоком стало тестирование. Мы провели нагрузочные испытания на своих средах и получили примерно трехкратный запас прочности при текущей нагрузке. Параллельно мы запустили пилот на ограниченной группе сотрудников и клиентов. Это позволило выявить нюансы, которые не проявлялись в тестовой среде.
Переход, который нельзя было повторить дважды
Отдельным решением стала стратегия миграции. Мы выбрали сценарий big bang и одномоментно перенесли около 2,5 млн карт. Переход прошел в одну ночь и завершился успешно, хотя в процессе были критические моменты. У нас был подготовлен план отката, но возвращение к старой системе означало бы дополнительную нагрузку на инфраструктуру и клиентов.
Оглядываясь на этот опыт, мы понимаем, что более безопасным вариантом могла бы быть поэтапная миграция, например по BIN-диапазонам. Такой подход требует больше времени, но снижает операционные риски.
Что изменилось после перехода
Новый процессинг работает уже почти год и показывает стабильные показатели по скорости и отказоустойчивости. Ключевое изменение связано с архитектурой. Переход на стек PostgreSQL, Java и Kafka позволил нам обновлять систему без остановки сервисов. В предыдущей архитектуре любое развертывание означало простой, сейчас развитие происходит непрерывно.
На момент старта проекта мы использовали зарубежные серверы и операционные системы, поскольку отечественные решения тогда не демонстрировали достаточной зрелости. Сейчас ситуация изменилась, и мы рассматриваем переход на российские платформы как следующий этап.
Что важно учитывать
По итогам проекта мы выделили несколько практических рекомендаций, которые могут быть полезны коллегам:
- Во-первых, при выборе решения стоит смотреть не столько на заявленные характеристики платформы, сколько на готовность команды вендора глубоко включаться в задачи банка и работать в плотной кооперации.
- Во-вторых, основной объем ресурсов нужно закладывать не на внедрение самой системы, а на интеграцию с существующим ландшафтом. Именно на этом этапе возникает большинство сложностей.
В-третьих, критически важно уделить внимание тестированию. Нагрузочные испытания на своей конфигурации и пилотные запуски на ограниченной группе пользователей помогают выявить проблемы до того, как они затронут клиентов.
