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

Начните с карты зависимостей, а не с каталога замен

Прежде чем выбирать, на что мигрировать, поймите, от чего вы зависите. Соберите реестр: ОС, СУБД, серверы приложений, middleware, прикладные системы, средства виртуализации, сетевое и серверное оборудование. По каждой позиции зафиксируйте три параметра – лицензионную модель, источник поддержки и стоимость переключения.

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

Архитектура решает больше, чем выбор вендора

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

Разделите систему на сервисы с чёткими границами и контрактами – тогда замена СУБД или брокера сообщений станет локальной задачей, а не проектом на полгода. Об этом подходе мы подробно писали в материалах о декомпозиции монолита и о характеристиках микросервисов. Те же принципы применимы и к инфраструктуре: контейнеризация и оркестрация – например, недавно анонсированный Amazon ECS – позволяют описывать развёртывание декларативно и переносить нагрузку между площадками без переписывания приложений. Чем меньше код знает о том, на каком железе и в каком ЦОДе он работает, тем дешевле смена платформы.

Разложите план на три горизонта

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

  • Год первый – фундамент. Замещаете низкорисковые слои: ОС, веб-серверы, средства мониторинга и резервного копирования. Параллельно вводите границы сервисов в самых критичных системах.
  • Год второй – ядро данных. Переносите СУБД и прикладную логику, опираясь на уже выделенные сервисы. Здесь сосредоточены главные риски, поэтому идёте системой за системой, а не всем фронтом.
  • Год третий – оборудование и закрепление. Завершаете замену там, где сроки диктуют поставки, и фиксируете результат регламентами закупок, чтобы новые зависимости не накапливались снова.

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

Вывод

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