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

В подкасте приняли участие:

Ведущий:

Геннадий ГРЕБЕНИК, директор по цифровой трансформации Фора-Банка

Денис Солоничкин, директор центра компетенций РЕД СОФТ

Игорь Коптелов, президент и главный конструктор «Иридиум»

Максим Березин, директор по развитию бизнеса Orion soft

Георгий Дауман, директор продуктового направления «Виртуализация» «Флант»

От дефицита выбора к реальным внедрениям

Два года назад одной из главных проблем для банков был сам выбор платформы. Как отметил Геннадий Гребеник, на тот момент в Реестре российского программного обеспечения насчитывалось около 60 систем виртуализации. Однако само количество решений не означало наличия полноценного рынка. Ситуацию осложнял и кадровый дефицит. Специалистов, хорошо знающих российские решения виртуализации, было мало, а опыт работы с конкретной платформой становился одним из факторов, ограничивающих возможность её внедрения. В итоге банки одновременно решали две задачи: выбирали продукт и искали людей, которые смогут с ним работать.

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

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

Максим Березин говорит о принципиальном изменении подхода: за два года окружение кардинально изменилось: на смену пилотным проектам пришла промышленная эксплуатация в центральных ЦОД и тотальное замещение VMware. По его словам, в Промсвязьбанке инсталляция затрагивает почти 1500 хостов, доля VMware составляет менее 1%, а шесть из двенадцати крупных системообразующих банков используют платформу Orion soft в стандарте.

В таких условиях меняется и способ выбора. Крупному банку уже недостаточно провести небольшой тест и получить хорошие результаты на ограниченной нагрузке. Заказчики хотят понимать, как продукт ведёт себя в реальном ЦОДе и на сотнях хостов. Поэтому всё большее значение получает практический опыт коллег по отрасли, становится популярным «сарафанное радио».

Что банк проверяет перед запуском платформы

Если раньше на первом месте стоял сам вопрос возможности замены зарубежного решения, то теперь требования стали значительно конкретнее.

Денис Солоничкин привёл результаты исследования, проведённого среди заказчиков РЕД СОФТ. Участникам предложили оценить более десяти критериев выбора платформы. Первое место заняла стабильность. Логика здесь проста: виртуализация сама по себе не является конечным бизнес-сервисом. Она должна обеспечивать работу систем, которые находятся внутри неё. Поэтому пользователю не столько важно, насколько эффектно выглядит интерфейс платформы или сколько функций в ней заявлено, сколько то, сможет ли она месяцами и годами стабильно обслуживать критические приложения.

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

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

Четвёртый критерий – стоимость владения. И здесь речь идёт не только о стоимости лицензии. В расчёт необходимо включать обучение сотрудников, техническую поддержку, развитие продукта и выполнение заявленной дорожной карты. Для банка важно понимать, что за платформой стоит команда, обладающая достаточными компетенциями и ресурсами для её сопровождения.

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

Масштаб имеет значение

Ещё одно изменение рынка связано с тем, что банки перестают считать успешным результатом небольшой пилот.

Максим Березин отмечает, что при выборе платформы заказчики смотрят на работу системы на крупных инсталляциях – с сотнями хостов. Затем проводится нагрузочное тестирование: инфраструктуру специально нагружают, чтобы понять, при каких объёмах система начинает терять производительность или отказывает. Отдельно проверяется информационная безопасность, в том числе с помощью сканеров и тестов на проникновение.

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

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

Open source: преимущество или технологический компромисс?

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

Игорь Коптелов предлагает разделять два принципиальных подхода. Первый – создание проприетарной платформы как единого продукта, где основные компоненты изначально проектируются с учётом совместной работы. Второй – использование набора open source-компонентов, которые разрабатывались разными командами и для разных задач.

Проблема второго подхода, по мнению эксперта, заключается не в самом open source, а в необходимости объединять разнородные компоненты. Между ними неизбежно появляются технологические компромиссы.

«Чтобы это не были части лоскутного одеяла, которые связаны между собой технологическими компромиссами, а чтобы это была целостная система», – так Коптелов описывает подход к собственной разработке.

При этом полностью отказаться от открытых технологий невозможно и экономически не всегда оправданно. Разработка с нуля каждого компонента современной ИТ-инфраструктуры потребовала бы огромных ресурсов. Поэтому на практике появляется третий путь – гибридный.

Как объяснил Коптелов, разработчик может использовать open source там, где создание собственного компонента не имеет смысла или потребует слишком много времени, но при этом самостоятельно создавать наиболее важные элементы платформы.

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

Можно ли за несколько лет создать замену продукту, который развивался десятилетиями

Ещё один вопрос, который возник в ходе дискуссии, – сроки создания сложной платформы.

По словам Коптелова, компания «Иридиум» начала заниматься виртуализацией ещё в 2009 году, первоначально используя open source. Примерно через десять лет разработки команда пришла к выводу о существовании технологических ограничений такого подхода и приняла решение создавать целостный продукт.

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

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

«За 1–5 лет невозможно разработать платформу виртуализации, которая отвечает современным требованиям к виртуализации», – считает эксперт.

Это не означает, что молодой продукт автоматически является слабым. Но для заказчика возникает дополнительный вопрос: за счёт чего разработчик компенсирует недостаток исторического опыта? Это могут быть сильная инженерная команда, использование зрелых open source-компонентов, глубокая собственная разработка ключевых элементов, масштабные пилоты и, главное, реальная промышленная эксплуатация.

Как отличить разработчика от интегратора

В этой точке возникает один из наиболее принципиальных вопросов всей дискуссии: достаточно ли собрать вместе хорошие open source-компоненты, чтобы получить полноценную платформу?

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

«Решения – сеть, хранилище, сам гипервизор – существенно дорабатываются и интегрируются друг с другом», – отмечает Дауман.

Для банка это имеет принципиальное значение. Если компоненты платформы разработаны разными внешними командами, то при возникновении проблемы может быть непонятно, кто несёт ответственность за её устранение.

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

«С комьюнити невозможно подписать договор, где прописать условия, SLA и так далее. Но с вендором это сделать можно», – говорит он.

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

Безопасность становится проверкой зрелости

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

Максим Березин отмечает, что крупные банки при выборе решений проверяют платформы в том числе с помощью тестов на проникновение.

Ещё один важный сценарий – микросегментация. Она позволяет разделять инфраструктуру на изолированные контуры, чтобы в случае атаки злоумышленник не мог свободно перемещаться внутри всей системы.

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

Георгий Дауман предлагает ориентироваться и на наличие сертификации ФСТЭК. Он называет её базовым «гигиеническим минимумом» для платформ виртуализации, поскольку в процессе сертификации проводится анализ продукта и его кода.

Дорожная карта как показатель доверия

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

«Важно не просто держать большую дорожную карту, а чтобы она выполнялась в тех сроках, которые вендор обещает», – подчёркивает Денис Солоничкин.

Для банка это вопрос не только доверия, но и планирования собственной ИТ-архитектуры. Если определённая функция заявлена на конец года, заказчик должен понимать, сможет ли он действительно получить её в обозначенный срок.

Именно поэтому выполнение конкретных обещаний может быть важнее красивой дорожной карты до 2030 года. «Можно написать дорожную карту до 2030 года и что-то переносить, двигать. А важно: ты что-то пообещал до конца года в релизе – и это выполнил», – говорит эксперт.

Экономика перехода: считать нужно не только лицензии

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

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

«Когда иностранные вендоры нас покинули, появились риски получения "кирпича", потому что нет вендора, нет лицензии, нет технического сопровождения», – отмечает Солоничкин.

В таком случае экономику перехода нельзя оценивать только через прямое сокращение расходов. В неё необходимо включать стоимость рисков.

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

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

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

От замены VMware к частному облаку

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

Георгий Дауман отмечает, что заказчики всё чаще рассматривают виртуализацию именно в более сложных сценариях. В частности, существуют проекты, где платформа используется как основа для запуска Kubernetes как сервиса в ЦОДе заказчика. Есть и пилотный проект с банком, где российская платформа рассматривается как основа частного облака и альтернатива OpenStack. Это меняет само представление о роли виртуализации.

«Не только виртуализация важна, а то, как она помогает бизнесу», – говорит Дауман.

Максим Березин также отмечает рост требований к дополнительным функциям – от микросегментации и управления сетями до интеграции с Kubernetes. Заказчикам важно понимать, сможет ли нынешняя платформа развиваться вместе с их инфраструктурой.

Рынок становится взрослее

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

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

Это означает переход от количественного роста к качественному отбору. Наличие платформы в реестре уже само по себе не является достаточным основанием для её выбора. Банку нужны подтверждённая стабильность, крупные внедрения, понятная архитектура, безопасность, техническая поддержка и предсказуемая дорожная карта.

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

Виртуализация как фундамент новой инфраструктуры

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

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

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

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

Полная версия видеоподкаста на VK видео и RUTUBE

Текст: Оксана Дяченко

Материал также опубликован в печатной версии Национального банковского журнала (сентябрь 2026)