Отказоустойчивость и соответствие регуляторным требованиям: как ПАК меняют подход к модернизации АБС

Главный вопрос для ИТ-руководителей банков сегодня — как провести миграцию на новые решения без сбоев, срывов сроков и потери производительности. Эксперты сходятся во мнении: путь "лоскутной" замены компонентов не подходит для построения автоматизированных банковских систем (АБС). Выходом становится переход на готовые программно-аппаратные комплексы (ПАК). О том, как именно ПАКи отвечают на вызовы импортозамещения, рассказал Валентин Шульга, руководитель направления по продвижению технологий Скала^р (Группа Rubytech).

Импортозамещение критически важных систем, особенно АБС, стало для финансового сектора необходимостью, продиктованной как регулятором, так и логикой становления технологического суверенитета. Несмотря на то, что использование зарубежных ИТ-продуктов запрещено на значимых объектах КИИ уже с 1 января 2025 года, не все банки спешат с миграцией. Причина проста — замена проверенных прикладных и аппаратных составляющих инфраструктуры без длительных и трудоемких испытаний несет значительные риски для работы ключевых сервисов банковской отрасли.

Риски "лоскутного" построения инфраструктуры

На рынке представлено множество решений разного качества и уровня зрелости. Собрать из этого набора стабильный, перспективный и обеспеченный поддержкой технологический стек самостоятельно — ресурсоемкая и рискованная задача. Можно выделить несколько серьезных недостатков такого подхода для построения АБС.

Архитектурная хрупкость. В большинстве случаев банковские ИТ-системы представляют собой классическую трехзвенную архитектуру: клиент (сервис или приложение, которое взаимодействует с пользователем), сервер приложений (именно здесь обрабатываются операции) и сервер баз данных (в котором хранятся результаты операций и исторические данные). Наиболее критичными для работы банка являются последние два. Использование разнородной инфраструктуры для приложений и базы данных может быть не лучшим выбором как с точки зрения совместимости, так и гарантий долгосрочной совместной работы.

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

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

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

Этих рисков можно избежать, если изменить сам подход к миграции — перейти от сборки "конструктора" на старой архитектуре к построению целостной платформы.

ПАК как глобальный тренд: преимущества целостного подхода

Преимущество ПАК заключается в принципиально ином подходе. Это не набор отдельных продуктов, а комплексное, предварительно интегрированное и протестированное решение от одного вендора. Во всем мире наблюдается тренд на выбор ПАКов для построения высоконагруженных инфраструктур, так как они обеспечивают наилучшие показатели надежности и производительности.

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

Единое окно поддержки. Исчезает необходимость искать ответственного среди вендоров при возникновении инцидента. Разработчик ПАК отвечает за работу и производительность всего комплекса в целом, что радикально сокращает время на диагностику и устранение неполадок.

Снижение ТСО (общей стоимости владения) и предсказуемость жизненного цикла. Банк получает единые, скоординированные пакеты обновлений для всего стека, которые уже проверены на совместимость производителем ПАК. Это делает процессы обновления и технического обслуживания безопасными, управляемыми и предсказуемыми. Кроме того, вендор предоставляет управляемую дорожную карту развития продукта, позволяя организации планировать ИТ-бюджет и модернизацию на годы вперед.

Сокращение сроков внедрения. За счет предварительной интеграции сроки развертывания и ввода в промышленную эксплуатацию сокращаются в разы по сравнению с "лоскутным" подходом. Обновления, проверенные на совместимость, поступают от одного источника, что делает процесс поддержки и развития системы управляемым.

На какие критерии стоит обратить внимание ИТ-директору при выборе ПАКа

Переход на единую платформу решает проблемы, связанные с импортозамещением: снижает риски совместимости, упрощает поддержку и сокращает TCO. Однако, чтобы в полной мере реализовать эти преимущества, важно выбрать надежного поставщика.

При оценке производителя ПАК рекомендуем обращать внимание на несколько факторов:

• Наличие референсов и зрелость. Решение должно иметь подтвержденный опыт внедрения в аналогичных высоконагруженных контурах других банков. Время существования продукта и компании на рынке — ключевой индикатор надежности. Например, программно-аппаратные комплексы Скала^р серийно производятся с 2015 года и используются в десятках проектов.
• Соответствие регуляторным требованиям. Обязательно наличие всех необходимых сертификатов ФСТЭК России, включение в реестры Минцифры и Минпромторга.
• Гибкость и возможность кастомизации. Идеально, если ПАК предлагает определенную степень адаптации под уникальные процессы банка, например выбор аппаратной платформы или глубины интеграции.
• Наличие тестировочных полигонов вендора. Возможность провести нагрузочное тестирование, отработать сценарии миграции и оценить реальную производительность на стенде вендора позволяет минимизировать главные риски проекта: технологические и регуляторные. Это превращает выбор из теоретического в практический.
• Предсказуемый жизненный цикл. У вендора должна быть четкая дорожная карта развития продукта и прозрачные гарантии длительной технической поддержки.

Заключение: время для архитектурных решений, а не экспериментов

Перед финансовой системой России стоит комплексная задача обеспечения технологического суверенитета, которая тесно связана с переходом на новые отказоустойчивые и надежные системы. ПАК, как показывает практика, является тем самым инструментом, который позволяет совершить этот переход максимально быстро, безопасно и с предсказуемым результатом, обеспечивая банку не только соответствие требованиям регулятора, но и основу для устойчивого развития в новых условиях.

Главная ошибка, которую совершают сейчас многие организации — тянуть время. Процесс выбора, тестирования и внедрения даже с учетом преимуществ ПАК занимает значительное время — от года и более. Банкам, которые еще не начали импортозамещение критических систем, следует уже сейчас начинать исследовательскую и проектную работу с ведущими производителями комплексных решений. Только так можно уложиться в сроки, избежать рисков и сохранить высокое качество сервиса для клиентов.