Почему проект импортозамещения не заканчивается запуском

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

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

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

Импортозамещение как инструмент экономии на операционных затратах в кризисные времена

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

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

После запуска появляются новые требования

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

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

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

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

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

Как это выглядит в крупном банке

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

Проект стартовал в конце 2022 года. Сначала прошли этапы концепции, HLD и LLD, затем пилот и промышленное масштабирование. В 2024 году контур вырос от первых десятков гипервизоров до 1500. В 2025 году масштабирование продолжилось: 3 227 гипервизоров в первом квартале, 5 008 — во втором, 7 301 — в третьем и 8 074 — в четвертом. Ко второму кварталу 2026 года платформа работала уже более чем на 20 000 гипервизоров. Количество виртуальных машин превысило 200 000.

Для проекта такого масштаба важен не только сам факт миграции. Намного важнее, как система ведет себя при росте нагрузки. В этом банковском контуре по мере масштабирования снижалось число инцидентов: в 2026 году показатель инцидентов на 1000 гипервизоров оказался более чем в 100 раз ниже, чем в 2024 году.

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

Цифры поддержки показывают качество эксплуатации

В портфеле ITKey две ключевые платформы: KeyStack и KeyVirt. KeyStack — облачная платформа на базе OpenStack для частных, публичных и гибридных облаков. KeyVirt — платформа виртуализации серверов и рабочих станций, в том числе для миграции с проприетарных решений.

Оба продукта разработаны в России и включены в реестр отечественного ПО. У KeyStack есть сертифицированная ФСТЭК версия, что важно для госсектора, КИИ и компаний с повышенными требованиями к информационной безопасности. Сертифицированная версия KeyVirt находится в разработке.

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

По одному из внедрений ITKey инфраструктура заказчика превышает 20 000 хостов. За последние полгода эксплуатации по этому контуру было всего 34 обращения в техническую поддержку. По всей клиентской базе ITKey в 2026 году при 23 452 хостах под управлением KeyStack число обращений составило 79.

Динамика по всей клиентской базе выглядит так:

* По данным на момент подготовки материала.

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

Поддержка — не тикеты, а снижение риска

У малого числа обращений есть обратная сторона. У заказчика может возникнуть вопрос: если мы почти не обращаемся, зачем платить за поддержку?

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

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

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

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

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

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

Станислав Красненков
руководитель отдела технической поддержки (SRE TeamLead) ITKey

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

79 обращений и 12 инцидентов на 23 452 хоста — это не отсутствие работы. Это результат постоянной инженерной работы. 34 обращения на инфраструктуре свыше 20 000 хостов у одного заказчика показывают, что платформа в продуктиве ведет себя стабильно. За этой стабильностью стоит не только продукт, но и процессы поддержки, обновлений и анализа эксплуатации.

Ошибка — считать внедрение разовой поставкой

В проектах импортозамещения до сих пор встречается подход: выбрали продукт, купили лицензии, внедрили, закрыли проект. Для небольших систем он иногда работает. Для инфраструктуры масштаба enterprise — почти никогда.

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

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

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

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

От отдельного элемента до полного контура

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

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

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

Учебный центр снижает зависимость от отдельных инженеров

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

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

У ITKey есть учебный центр с программами по OpenStack и KeyStack. В линейке обучения — вводные курсы и практические программы по настройке и администрированию платформы. Для enterprise это особенно важно: инженеры получают не общую теорию про облака, а прикладные знания, которые нужны для эксплуатации конкретной инфраструктуры.

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

Партнерства превращают платформу в экосистему

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

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

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

Автоматизация закрывает часть кадрового дефицита

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

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

Для решения этой задачи мы интегрировали в платформу KeyStack AI Agent — специализированный ИИ-ассистент, построенный на мультиагентной архитектуре Re-Act с механизмом DeepResearch.

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

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

Результат — ощутимое снижение MTTR и минимизация затрат на подготовку и онбординг инженеров. Пилотирование AI Agent уже заканчивается внутри компании и скоро поступит заказчикам.

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

Успешное импортозамещение видно в эксплуатации

79 обращений и 12 инцидентов на 23 452 хоста — это и есть наша репутация.

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

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

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

Подробности читайте в статье CNews.