Тема замены иностранного ПО отечественными решениями пока не оформлена в жёсткие требования, но сигналы уже есть. Министерство связи говорит о поддержке российских разработчиков, в техзаданиях на крупные госпроекты всё чаще появляется пункт о «независимости от конкретного вендора». Для CIO в госсекторе это значит одно: готовиться надо сейчас, пока выбор добровольный, а не под давлением сроков и регламента. Ниже – что именно стоит проверить в инфраструктуре и закупках.
Где сидят риски прямо сейчас
Первый риск – проприетарные СУБД и серверы приложений. Лицензии Oracle и Microsoft привязывают вас к ядру, миграция с которого занимает месяцы. Второй – закрытые BI и аналитические платформы: данные внутри них становятся заложником формата вендора. Третий – отсутствие исходников и права на доработку. Если подрядчик ушёл с рынка, а контракт не передаёт вам код, система превращается в чёрный ящик.
Практика показывает: дешевле зафиксировать независимость на этапе ТЗ, чем переписывать систему позже. Закладывайте в требования открытые форматы обмена, стандартные протоколы (SQL, REST, S3-совместимое хранилище) и обязательную передачу исходного кода заказчику.
Открытые технологии – рабочая альтернатива уже сегодня
Зрелость open source за последние два-три года выросла настолько, что он закрывает большинство задач госзаказчика. PostgreSQL давно держит нагрузку уровня коммерческих СУБД. Для аналитики на больших объёмах данных экосистема Hadoop вышла из стадии эксперимента – мы разбирали это в материале про Hadoop как mainstream. Там же, где нужна обработка событий в реальном времени, применимы открытые движки потоковой обработки.
Отдельно стоит присмотреться к инструментам изоляции и переноса приложений. Молодой проект Docker, вышедший в open source этой весной, уже показывает, как упаковать сервис вместе с окружением и переносить его между площадками без привязки к конкретной ОС вендора. Для импортозамещения это прямой плюс: меньше связанности с платформой – проще замена.
Что делать госзаказчику в ближайший год
Начните с инвентаризации. Составьте реестр систем с пометкой, какие из них критичны и на каком проприетарном ПО держатся. Это даёт честную картину зависимости и приоритеты.
Дальше – пилот. Возьмите одну некритичную систему и перенесите её на открытый стек: PostgreSQL вместо коммерческой СУБД, веб-сервер на открытом ПО, отчётность на open source BI. Пилот покажет реальную трудоёмкость и риски без угрозы для основной деятельности.
Третий шаг – закупочная дисциплина. Внесите в типовые ТЗ требование открытых форматов и передачи исходного кода. Так каждый новый контракт перестаёт усиливать зависимость от одного поставщика.
По опыту перенос нагруженных систем на отечественные и открытые платформы – это не разовый «переезд», а программа на несколько лет: от аудита и приоритизации по критичности до постепенного переключения сервисов без их остановки.
Вывод
Жёстких требований по импортозамещению пока нет, но направление очевидно. У госзаказчика есть редкое окно – менять архитектуру в спокойном режиме, на своих условиях и сроках. Кто начнёт с инвентаризации и пилота сегодня, через год будет выбирать решения, а не догонять регламент.
