Михаил Данцкер: Важно планировать переход на российскую ОС

— Михаил, как вы оцениваете сегодняшний уровень импортозамещения операционных систем в российских банках с госучастием и коммерческих банках?

Михаил Данцкер: На протяжении последних двух-трех лет мы наблюдаем активные шаги в направлении импортозамещения. Многие банки осознали важность перехода на отечественные IT-решения (в том числе и на операционные системы) для повышения своей технологической независимости и безопасности данных.

По нашим оценкам, импортозамещение достигло значительных успехов. Многие государственные банки уже внедрили отечественный софт в свои IT-экосистемы. Некоторые коммерческие банки также начали процесс перехода, однако делают это более осторожно ввиду их потребности в минимизации рисков.

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

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

— Почему банкам важно переводить свою IT-инфраструктуру на российские ОС?

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

— С какими проблемами сталкиваются банки при выборе операционной системы из Реестра российского ПО Минцифры РФ?

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

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

Кадровый дефицит специалистов с необходимыми навыками для работы с российскими операционными системами также является вызовом, и это может осложнить переход. Вдобавок производительность некоторых российских ОС может не дотягивать до уровня зарубежных аналогов, что негативно скажется на эффективности банковских операций.

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

Таким образом, банки должны тщательно оценивать и планировать этот процесс, чтобы минимизировать трудности и потенциальные риски.

Тимурбулат Султангалиев: Мы берем на себя мозговую работу

— Тимурбулат, чем полезен банкам консалтинг при переходе на российский системный софт?

Тимурбулат Султангалиев: «Астра Консалтинг» — это подразделение вендора, команда сильных консультантов, которая обладает экспертизой и опытом внедрения продуктов «Группы Астра», необходимых, для того чтобы оптимально и в нужные сроки интегрировать эти решения в IT-инфраструктуру банка и архитектуру его бизнеса с учетом требований самого банка и регуляторов. Мы выступаем своего рода гарантом успешности проекта. Наши задачи — проработать детальный план миграции и организовать четкое взаимодействие всех IT-систем. Можно сказать, что роль консалтинга заключается в том, чтобы реализовать бизнес-сценарии заказчика на базе отечественных технологий с обеспечением бесперебойной работы всех бизнес- и IT-систем в ходе проекта.

— С какими трудностями сталкиваются консультанты в проектах миграции банков на российское ПО?

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

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

— Каковы ключевые компетенции экспертов «Астра Консалтинг»? 

Тимурбулат Султангалиев: У нас создана структура центров компетенций, которые мы называем практиками. На сегодняшний день их шесть: премиальный сервис, IT-консалтинг, разработка ПО, бизнес-консалтинг, информационная безопасность и практика «1С». У каждой практики — свой руководитель, задача которого заключается в аккумулировании технологической экспертизы по продуктам и предоставлении ее клиентам. Кроме того, наши специалисты обладают экспертизой в ряде смежных систем, разработанных другими компаниями. Она необходима, поскольку в большинстве проектов нам нужно решать задачи интеграции с решениями других вендоров, в том числе западных, особенно на этапе промежуточной миграции, когда функционирует старая инфраструктура и одновременно идет переход на новую.

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

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

При необходимости эксперты всех практик объединяются в проектные команды и системно решают задачи заказчика.

— Вы ведете проекты сами?

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

— В чем для вас заключается специфика перехода крупного банка на российский системный софт?

Тимурбулат Султангалиев: Общаясь с крупными клиентами из банковского сектора, мы анализируем, что именно приходится импортозамещать. Дело в том, чаще всего у банков есть программы по переходу на отечественный софт, и они весьма объемные, в них участвует большое количество направлений (стримов). А в такой масштабный и сложный стрим, как, например, импортозамещение операционной системы, вовлекается огромное количество сотрудников — в крупных банках работают тысячи АРМ, на которых исполняется множество бизнес-процессов, и т.д. Только после детального анализа того, что именно подлежит импортозамещению, мы приступаем к согласованию сроков, а также оцениваем собственные ресурсы банка, которые можно привлечь к решению поставленной задачи, и определяем, какой результат проекта будет считаться успешным. После этого мы помогаем коллегам из банка составить дорожную карту, или план миграции, а также ресурсную модель. При этом на себя мы берем и аналитическую работу по подготовке плана, и само формирование плана, расставляем нужные акценты. Как правило, прорабатываем производственный процесс: определяем варианты автоматизации, необходимые интеграции и сценарии бизнес-процессов.

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

— Каковы основные этапы миграции банка на отечественное ПО? 

Тимурбулат Султангалиев: Первый этап — обследование банка. Его результаты ложатся в основу дорожной карты — документа, в котором описываются все шаги по реализации проекта: ответственные, сроки и критерии достижения результата. Когда дорожная карта готова, в банке составляется и подписывается приказ руководства, а его содержание доводится до всех служб. Затем формируется рабочая группа, в которой участвуют все заинтересованные лица, назначается руководитель проекта со стороны банка, определяется, кто еще заинтересован в проекте. 

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

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

Далее — «железо»: рабочие станции и их окружение (принтеры, сканеры, дактилоскопические или биометрические системы и т.д.) проверяются на совместимость с отечественным ПО. Затем на способность поддерживать «боевую» инфраструктуру тестируется серверная группировка. После этого все компоненты запускаются в работу на опытном участке, проводятся нагрузочные и функциональные тесты. В результате появляется обратная связь от конечных пользователей и выявленные недочеты устраняются. Наконец, заключительный этап — тиражирование программных решений. Вот так, шаг за шагом, миграция охватывает всю инфраструктуру банка.

Кирилл Вихровский: Мы готовы поддержать любое инфраструктурное ПО

— Кирилл, на что банкам нужно обращать внимание при выборе системы резервного копирования?

Кирилл Вихровский: Система резервного копирования (СРК) в банках часто является «последней спичкой в коробке»: только она обеспечивает гарантированную сохранность данных. Другие системы защищают данные от определенных видов атак, но не от технических сбоев, не от человеческих ошибок и т.д.

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

Еще один важный критерий — скорость внесения изменений и способность поставщика и партнера работать в одном ритме с банком. Также необходимо удостовериться, соответствует ли СРК регуляторным требованиям по ежедневному резервному копированию и восстановлению данных за каждый операционный день; работает ли с отчуждаемыми машинными носителями информации. 

А банкам с территориально распределенной структурой я советую обращать внимание на готовность СРК к работе в условиях, когда резервные копии распределены и хранятся на отдельных носителях.

— Какие особенности системы резервного копирования RuBackup делают ее интересной для банковского сектора?

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

Что касается информационной безопасности, то в СРК RuBackup мы реализовали функцию полного логирования действий. Также наша СРК интегрируется с системами SIEM. Для контроля действий в системе резервного копирования мы ввели специальную роль ИБ-аудитора, а неизменность резервных копий подтверждаем с помощью их цифровой подписи и 14 алгоритмов защитного преобразования. Они гарантируют службе ИБ, что резервная копия не претерпела изменений в процессе восстановления. А после сертификации решения ФСТЭК России и внедрения процесса безопасной разработки ПО мы сможем дать дополнительные гарантии защищенности RuBackup.

— Работает ли ваша СРК с программными продуктами других поставщиков?

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

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

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

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

— Как в системе резервного копирования RuBackup решается вопрос мониторинга и управления?

Кирилл Вихровский: Любой банк — это довольно сложная организационно и технически выстроенная структура с централизованным мониторингом. Для взаимодействия с нашей СРК мы предоставляем удобный веб-, локальный интерфейс или REST API. В последнем случае любые функции RuBackup будут доступны из интерфейса систем заказчика дистанционно, и крупные банки смогут централизовать затраты на эксплуатацию системы или на мониторинг в рамках одного подразделения, не формируя отдельную штатную единицу, которая будет работать в другом интерфейсе.

— Если оглянуться на проекты, реализованные вами в банках, то какие уроки вы из них вынесли?

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

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

Также мы учли довольно высокие требования к ИБ крупнейших банков РФ и реализовали более сотни функций для обеспечения безопасности. Сейчас мы идем дальше и создаем подразделение, которое будет целенаправленно заниматься аналитикой данных, аналитикой процессов и аналитикой обеспечения безопасности данных, для того чтобы эти возможности заложить в продукт.

— Как вы планируете развивать свою СРК в ближайшие годы? 

Кирилл Вихровский: Мы поставили себе цель — создать продукт, используя который банки любого уровня смогут привести свои процессы обеспечения сохранности и безо­пасности данных в состояние, отвечающее самым передовым российским и мировым требованиям.