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

Что говорят первые поручения

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

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

С чего начать: инвентаризация и развязка зависимостей

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

Развязать эти зависимости заранее дешевле, чем под давлением сроков. Здесь работают те же инженерные принципы, которые мы разбирали раньше. Проектирование интеграций через стабильные контракты, как в подходе API-first, позволяет менять СУБД или внешний сервис под капотом, не переписывая половину системы. А управление доступом и ротация секретов одинаково важны и для зарубежного, и для отечественного контура – при переезде эти процессы нельзя терять.

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

Как готовить миграцию без аврала

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

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

Вывод

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