За последние две недели западные вендоры один за другим объявили о приостановке продаж и поддержки в России: остановлены поставки лицензий, заморожены новые контракты, под вопросом обновления и техподдержка по уже оплаченным подпискам. Для ИТ-директора это не повод для паники, а сигнал к холодной инвентаризации. Прежде чем выбирать, что и на что менять, нужно точно знать, чем вы владеете, где у вас критическая зависимость и сколько времени есть до того, как риск превратится в инцидент. Эта статья – про первые две недели работы, а не про стратегию на годы.
Соберите карту зависимостей за две недели
Начните с реестра, а не с совещаний. Выгрузите данные из CMDB, системы учёта лицензий и договоров с поставщиками. По каждому активу зафиксируйте пять полей: вендор и страна происхождения, тип лицензии (бессрочная, подписка, по ядрам), дата окончания поддержки, наличие действующего контракта на обновления и бизнес-процесс, который этот актив обслуживает.
Разделите ландшафт на четыре слоя: инфраструктура (виртуализация, ОС, СУБД), прикладные системы (ERP, CRM, BI), средства разработки и облачные сервисы. Облачные SaaS-подписки – самый острый участок: их могут отключить дистанционно и без предупреждения, тогда как локально установленный софт с бессрочной лицензией продолжит работать, пусть и без обновлений. Отдельно отметьте всё, что завязано на онлайн-активацию или лицензионные серверы за рубежом, – это кандидаты на немедленную проверку.
Оцените риск, а не панику
Не все зависимости одинаково опасны. Оцените каждую систему по двум осям: критичность для бизнеса и скорость наступления риска. СУБД под биллингом, отключаемая по подписке, – красная зона. Среда разработки с бессрочной лицензией без обязательных обновлений – жёлтая, у вас есть месяцы. Офисный пакет на изолированной машине – зелёная.
Для красной зоны сразу проверьте три вещи: работает ли система без связи с внешними серверами, есть ли локально сохранённый дистрибутив и ключ, и существует ли зрелая отечественная или open-source альтернатива. По итогам прошлого года статус импортозамещения по ключевым классам ПО уже показывал, где замена реальна, а где придётся ждать или дорабатывать. Сверьтесь с этой картиной, чтобы не тратить время на заведомо незрелые варианты.
Зафиксируйте быстрые меры и точку входа в миграцию
Пока идёт инвентаризация, примите защитные меры, которые ничего не ломают. Скачайте и сохраните все дистрибутивы и ключи локально. Снимите резервные копии конфигураций. Отключите автообновление там, где обновление может прийти с функцией блокировки. Зафиксируйте текущие рабочие версии – откатиться к ним позже будет нечем, если их не сохранить сейчас.
Дальше – приоритизация замены. Системы с чистой архитектурой мигрируют быстрее: если ваши приложения уже разбиты на сервисы, отдельный модуль можно перенести на новую СУБД или платформу без остановки всего ландшафта. Мы разбирали этот эффект в материале про микросервисы против монолита. Для аналитики важно понимать зрелость ваших данных: перенос BI без наведённого порядка в источниках лишь повторит старые проблемы – про это есть отдельный разбор зрелости данных и BI.
Результат двух недель – не план импортозамещения целиком, а проверяемый реестр рисков с приоритетами и сроками. С ним вы переходите к проектной фазе осознанно: от аудита зависимостей до пилотного контура выстраивается миграция критичных систем на отечественные платформы, где каждый перенос опирается на проверенный реестр рисков.
