Возвращение бизнеса в Россию 2026: полная дорожная карта IT-инфраструктуры

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

После 2022 года значительная часть международных компаний приостановила операции в России: кто-то продал бизнес, кто-то заморозил активы, кто-то сохранил юридическое лицо и минимальное присутствие «на паузе». С тех пор рынок постепенно адаптировался: сформировались новые каналы поставок оборудования, выросли российские облачные платформы, появилась практика работы в условиях ограничений. И сейчас мы наблюдаем обратный тренд: компании — осторожно, поэтапно, часто без публичных заявлений — прорабатывают варианты возвращения.

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

Из практики можно выделить несколько драйверов возвращения:

• Рынок остался. Для многих отраслей Россия — значимая доля выручки, и конкуренты, которые не уходили или ушли формально, за эти годы усилили позиции.
• Сделки и выкупы. Локальный менеджмент или партнёры выкупают бизнес, и новой структуре нужно быстро восстановить IT — часто с нуля, потому что доступы и системы остались у прежнего владельца.
• Требования по данным. Персональные данные российских граждан должны храниться в РФ (152-ФЗ), а для ряда отраслей действуют дополнительные требования по локализации систем.
• Логистика и доступность. Сервисы, размещённые за рубежом, работают для российских пользователей медленнее и менее стабильно; часть зарубежных провайдеров ограничивает обслуживание.
• Стратегические опции. Компании держат «сухой порох»: готовят резервную площадку и план быстрого развёртывания, чтобы при принятии решения вернуться за недели, а не за год.

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

02Три типовых сценария возврата

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

Сценарий 1. «Тёплый возврат»: инфраструктура частично сохранилась

Компания сохранила юрлицо, часть оборудования, возможно — офис и людей. Сервисы были переведены в зарубежные облака или заморожены. Задача — провести аудит остатков, понять, что можно реанимировать, перенести критичные сервисы обратно в РФ, восстановить доступы и документы. Это самый быстрый сценарий: рабочую инфраструктуру реально поднять за 3–6 недель.

Сценарий 2. «Холодный старт»: бизнес возвращается с нуля

Юрлицо ликвидировано или продано, оборудования нет, команды нет. Нужно всё: юридическая структура (не наша часть, но мы синхронизируемся с юристами), офис, оборудование, облако или ЦОД, сеть, каталог пользователей, почта, рабочие места. Реалистичный срок — 6–12 недель до полноценной работы первого офиса.

Сценарий 3. «Страховка»: резервная площадка без немедленного возвращения

Решение о возвращении ещё не принято, но совет директоров хочет готовность: резервная площадка в РФ, отработанный план миграции, понятный бюджет и сроки. Здесь мы проектируем целевую архитектуру, разворачиваем минимальное ядро (домен, VPN, реплики критичных данных) и раз в квартал проводим тесты восстановления. Стоимость такой готовности несопоставима со стоимостью годового простоя при поспешном возвращении.

03Дорожная карта: 12 недель от решения до запуска

Ниже — усреднённая дорожная карта «холодного старта», самого тяжёлого сценария. Для тёплого возврата первые фазы сжимаются, для резервной площадки — растягиваются. Главный принцип: параллелим всё, что можно параллелить — закупки идут одновременно с проектированием, юридические вопросы по данным — одновременно с развёртыванием тестового контура.

Обратите внимание: этапы намеренно перекрываются. Если ждать завершения закупок, чтобы начать проектирование сети, проект растянется на полгода. В практике таких проектов критический путь обычно проходит через две вещи: договоры с площадками (особенно когда требуются согласования с головным офисом) и поставку оборудования. Поэтому оба трека запускаются в первую же неделю.

04Модель размещения: облако, colocation или гибрид

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

Публичное облако в РФ

Плюсы: старт за часы, оплата по факту потребления, готовые managed-сервисы (базы данных, Kubernetes, балансировщики, объектное хранилище), не нужно ждать железо. Минусы: при больших постоянных нагрузках дороже собственного железа; не все сервисы и образы ПО доступны; нужна проверка соответствия требованиям по данным конкретного провайдера.

Colocation: своё железо в чужом ЦОД

Плюсы: полный контроль над оборудованием, предсказуемая стоимость при высокой утилизации, возможность разместить специфическое железо (GPU, СХД, legacy). Минусы: нужны закупка, логистика, монтаж; масштабирование — недели, а не минуты. Подробнее — на странице про colocation в ЦОД.

Гибрид: облако + ЦОД + зарубежные площадки

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

Практическая эвристика: стартовать в облаке, стабилизировать — в гибриде. Облако даёт скорость на этапе запуска; когда нагрузки стабилизируются и становятся понятны реальные объёмы, тяжёлые и постоянные части (базы данных, хранилища, бэкапы) экономически выгоднее уносить на собственное железо в ЦОД, а в облаке оставлять фронтенды, пики и managed-сервисы.

05Сравнение российских облачных провайдеров

Рынок облаков в России за последние годы заметно вырос: у крупных игроков появились зрелые платформы с managed-сервисами, Kubernetes, объектным хранилищем, ML-инструментами и сертификатами соответствия. Ниже — ориентировочное сравнение ключевых платформ по критериям, которые важны при возвращении бизнеса. Условия, состав сервисов и сертификаты меняются быстро — перед решением проверяйте актуальную информацию у провайдеров.

Как выбирать на практике — не по бренду, а по чек-листу требований:

• Данные. Есть ли у провайдера аттестованные среды под ваши категории данных (персональные данные, отраслевые требования)? Где физически расположены зоны?
• Сервисы. Есть ли managed-версии именно ваших технологий: PostgreSQL, Kafka, Kubernetes, объектное хранилище, совместимое с S3?
• Сеть. Как организуется подключение: интернет, выделенный канал, direct connect из вашего ЦОД? Какие есть варианты VPN и маршрутизации?
• SLA и поддержка. Реальные условия SLA, наличие русскоязычной поддержки 24/7, опыт работы с международными клиентами, документооборот с иностранными юрлицами.
• Выход. Насколько легко забрать данные и перенести нагрузку к другому провайдеру или в ЦОД — lock-in в условиях быстро меняющегося рынка стоит дорого.

Наш подход к подбору облачного провайдера: формализуем требования бизнеса в таблицу критериев с весами, запрашиваем у 3–4 провайдеров расчёты под ваш профиль нагрузки, поднимаем тестовый стенд у двух финалистов и только потом рекомендуем. Решение принимаете вы — на цифрах, а не на презентациях.

06Выбор ЦОД: на что смотреть в 2026 году

Если проект включает colocation, выбор дата-центра становится критичным: менять ЦОД после переезда — это новый проект миграции. Рынок коммерческих ЦОД в России сконцентрирован в Москве и Санкт-Петербурге, есть площадки в регионах. Среди известных игроков — DataLine, IXcellerate, Selectel, «3data», «ММТС-9», площадки крупных операторов связи; состав и условия рынка меняются, поэтому оценивайте конкретные площадки по критериям ниже, а не по бренду.

Практический совет: берите стойку с запасом по мощности. Типовая ошибка — заказать стойку ровно под текущее железо, а через полгода упасть в лимит по киловаттам при добавлении пары серверов. Запас 30–40% по питанию стоит немного, а спасает от переезда стойки. И второе: закладывайте в договор возможность расширения на соседнюю стойку или переноса в большую без штрафов.

Отдельный вопрос — география. Москва даёт лучшую связность и выбор площадок, но для резервной копии и DR логично смотреть на второй регион: Санкт-Петербург, Новосибирск, Казань, Екатеринбург. Резервная площадка в том же городе и тем более в том же ЦОД — слабая страховка от региональных инцидентов.

07Оборудование: закупка, логистика, гарантия

После 2022 года закупка серверного оборудования в России перестала быть тривиальной задачей «позвонить вендору». Официальные поставки многих брендов прекращены, работают параллельный импорт, дистрибьюторы со складскими остатками и рынок восстановленного (refurbished) оборудования. Это рабочая реальность, но она требует грамотного управления рисками.

• Спецификация под наличие, а не под презентацию. Проектируйте конфигурации на основе того, что реально есть в канале: конкретные модели серверов, процессоров, дисков, сетевых карт. Идеальный BoM, которого нет на складах, стоит проекту недели.
• Аналоги и вендор-нейтральность. На большинство позиций есть работающие альтернативы — серверы российской сборки, оборудование брендов, сохранивших поставки, качественный refurbished. Мы ведём матрицу совместимости под типовые нагрузки.
• Запасные части. В закупку сразу закладывайте ЗИП: диски, блоки питания, память, трансиверы. Ждать замену диска три недели — непозволительная роскошь для продуктива.
• Гарантия и сервис. Уточняйте, кто и как исполняет гарантию: складской возврат, сервисный контракт с интегратором, собственный ЗИП. Для критичного железа сервисный контракт с SLA по замене обязателен.
• Документы. Для бухгалтерии и compliance нужны корректные первичные документы, декларации, прослеживаемость. Работайте с поставщиками, которые это обеспечивают.

Типовые сроки: складские позиции — 1–2 недели, позиции под заказ — 4–10 недель в зависимости от канала. Поэтому закупки запускаются параллельно с проектированием, а критичный путь проекта страхуется облачным контуром: сервисы стартуют в облаке и переезжают на железо, когда оно приходит. Подробнее — на странице о закупке серверного оборудования.

08Сеть, VPN и связность с головным офисом

Сеть в проекте возвращения решает три задачи: связать российские площадки между собой, связать их с глобальной инфраструктурой компании и обеспечить доступ сотрудников. Типовая архитектура:

• Офисная сеть. Управляемые коммутаторы, Wi-Fi с WPA3-Enterprise, сегментация VLAN (сотрудники, гости, IoT, VoIP), резервирование канала провайдера.
• Site-to-site VPN. IPsec или WireGuard между офисами, ЦОД и облаком; маршрутизация через центральный хаб. Для критичных связок — выделенные каналы (L2VPN) поверх, VPN как резерв.
• Связь с головным офисом. Зашифрованные туннели до глобальных площадок; учитывайте, что часть зарубежных провайдеров ограничивает работу с российскими IP — тестируйте маршруты заранее.
• Удалённый доступ. VPN-клиенты с MFA, или ZTNA-решение (Zero Trust Network Access) — для новых проектов это часто разумнее классического VPN.
• DDoS-защита. Для публичных сервисов — подключение к scrubbing-сервису: российский сегмент интернета регулярно видит атаки, и защита должна быть включена с первого дня.

Ключевое правило: документируйте сеть с первого дня. В проектах на скорость соблазн «потом описать» велик — и через полгода никто не помнит, почему туннель №3 идёт через резервный канал. Схемы, адресный план, реестр туннелей и правил межсетевого экранирования — обязательный артефакт проекта. Подробнее — на странице про развёртывание сети и VPN.

09Базовые сервисы: Active Directory, почта, рабочие места

Инфраструктура — это фундамент, но бизнес видит сервисы: вход в систему, почту, файлы, приложения. Восстановление базового стека обычно идёт в таком порядке.

Active Directory и идентификация

Первый вопрос: восстанавливать старый домен или строить новый. Если есть резервные копии AD и доступ к ним — восстановление быстрее, но вы наследуете все старые проблемы: мёртвые учётки, хаотичные GPO, избыточные права. Для «холодного старта» мы обычно рекомендуем новый домен с чистой моделью прав и миграцией пользователей и групп по списку, согласованному с бизнесом. Обязательно: tiered-модель администрирования, MFA для администраторов, защищённые рабочие станции админов. Подробнее — восстановление Active Directory.

Почта и коммуникации

Варианты: развернуть почту в российском облаке или на своих серверах (например, на открытых платформах групповой работы), подключить российский сервис корпоративной почты, либо оставить глобальный почтовый сервис, если он доступен и это согласовано с compliance. В любом случае: корректные SPF/DKIM/DMARC, антиспам, архивация, миграция истории почты (это часто самый долгий этап — десятки гигабайт на ящик). Подробнее — корпоративная почта.

Рабочие места

Закупка ноутбуков, единый образ ОС с нужным ПО, полнодисковое шифрование, управление устройствами (MDM), антивирус/EDR, удалённый доступ. Для скорости используем заранее подготовленный «золотой образ»: новый сотрудник получает ноутбук, который настраивается за час, а не за день. Подробнее — подготовка рабочих мест.

Файлы, бэкап, мониторинг

Файловые сервисы — на базе доменных прав доступа; бэкап по правилу 3-2-1 (три копии, два носителя, одна за пределами площадки), с обязательным тестом восстановления; мониторинг с алертами в мессенджер дежурной смены. Эти три сервиса — страховка всего проекта, их нельзя откладывать «на потом».

10Данные и регуляторика: 152-ФЗ, трансграничная передача

Юридический блок в IT-проекте возвращения — не формальность, а проектный параметр, который влияет на архитектуру. Ключевые точки:

• 152-ФЗ «О персональных данных». При сборе персональных данных граждан РФ запись, систематизация, накопление, хранение, уточнение и извлечение должны выполняться с использованием баз данных, находящихся на территории России. На практике это значит: первичная БД с ПДн российских клиентов и сотрудников — в РФ.
• Уведомление Роскомнадзора. Оператор ПДн подаёт уведомление об обработке; при трансграничной передаче — отдельное уведомление, а для ряда стран действуют ограничения. Формы и требования уточняются — сверяйтесь с актуальными редакциями и юристами.
• 187-ФЗ о критической информационной инфраструктуре. Если компания относится к КИИ (банки, телеком, энергетика, здравоохранение и др.), действуют дополнительные требования к защите систем.
• Отраслевые требования. Платёжные системы, медицина, госсектор имеют свои правила локализации и защиты данных — проверяйте применимость к вашему бизнесу.
• Трансграничная передача внутри группы. Передача данных между российским юрлицом и головным офисом — отдельный процесс: правовые основания, техническая схема (что именно передаётся), минимизация объёмов.

Практическая схема, которая работает для большинства международных компаний: в РФ локализуется «ядро» с персональными данными (HR, CRM, клиентские базы), а в глобальные системы передаются обезличенные или агрегированные данные. Это позволяет соблюсти букву закона, не разрывая глобальную аналитику.

11Безопасность и отказоустойчивость

Быстрый запуск не отменяет базовой гигиены безопасности — наоборот, инфраструктура «сборная солянка» особенно уязвима. Минимальный стандарт, который мы закладываем в каждый проект:

• Сегментация сети и принцип минимальных привилегий: между офисом, серверным сегментом, гостевой сетью и управлением — явные правила.
• MFA для всех административных доступов, VPN и критичных сервисов — без исключений.
• EDR/антивирус на серверах и рабочих станциях, централизованный сбор событий.
• Резервное копирование 3-2-1 с изолированной копией, недоступной для шифровальщика, и регулярными тестами восстановления.
• Управление обновлениями: патч-цикл для ОС и ПО, окна обслуживания.
• DDoS-защита публичных сервисов с первого дня.
• Журналирование действий администраторов и доступа к данным — для расследований и compliance.

Отказоустойчивость проектируется под бюджет: минимум — резервирование каналов и питания, бэкап и план DR; для критичных систем — кластеризация, репликация между площадками, автоматический failover. Главное — честно определить RTO/RPO с бизнесом: сколько часов простоя и сколько минут потери данных вы можете себе позволить. От этих двух цифр зависит стоимость инфраструктуры сильнее, чем от выбора вендора.

12Типовые ошибки при возвращении

Собрали ошибки, которые встречаются чаще всего. Большинство из них — организационные, а не технические.

1. Начать с закупки железа, а не с архитектуры. Купленные «по случаю» серверы потом не вписываются в проект. Сначала — целевая архитектура и профиль нагрузки.
2. Ставить проект «на одного героя». Если весь проект держится на одном инженере или одном подрядчике-одиночке, любой форс-мажор останавливает его. Нужна команда и документация.
3. Игнорировать данные до последнего. Вопрос «где будут лежать персональные данные» всплывает за неделю до запуска — и перекраивает архитектуру. Подключайте юристов на этапе проектирования.
4. Не тестировать восстановление из бэкапа. Бэкап без теста восстановления — это надежда, а не защита.
5. Забыть про доступы. Старые учётки, сертификаты, домены, DNS-зоны, платёжные реквизиты сервисов — их восстановление занимает недели, если не начать в первый день.
6. Выбрать провайдера по презентации. Без тестового стенда под вашу нагрузку выбор облака или ЦОД — лотерея.
7. Не заложить поддержку. Проект закончился, подрядчик ушёл, а дежурить некому. Модель эксплуатации (своя команда или аутсорс поддержки) должна быть определена до запуска.
8. Стремиться к идеалу вместо «достаточно хорошо». В проекте на скорость идеальная архитектура — враг работающей. Запускайтесь на достаточном уровне и улучшайте итерациями.

13FAQ: частые вопросы

14Чек-лист возвращения IT в Россию

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

• Назначен владелец проекта и утверждён бюджет (или рамка бюджета)
• Определён сценарий: тёплый возврат / холодный старт / резервная площадка
• Проведён ИТ-аудит остатков: оборудование, данные, доступы, лицензии
• Составлен реестр активов: домены, DNS, сертификаты, облачные аккаунты
• Юристы определили требования по данным (152-ФЗ, отраслевые, трансграничная передача)
• Выбрана модель размещения: облако / colocation / гибрид
• Проведено сравнение 3–4 облачных провайдеров по формализованным критериям
• При colocation — выбран ЦОД по чек-листу (Tier, питание, связность, remote hands)
• Спецификация оборудования сверена с реальным наличием в канале поставок
• Заложен ЗИП: диски, БП, память, трансиверы
• Спроектирована сеть: сегментация, VPN, связность с головным офисом, DDoS-защита
• Определена схема идентификации: новый домен AD или восстановление старого
• Выбрана почтовая платформа; настроены SPF/DKIM/DMARC; спланирована миграция истории
• Подготовлен «золотой образ» рабочего места: ОС, ПО, шифрование, EDR, MDM
• Настроено резервное копирование 3-2-1 с изолированной копией
• Проведён тест восстановления из резервной копии
• Определены RTO/RPO и спроектирован DR (резервная площадка)
• MFA включена для всех административных доступов и VPN
• Подготовлена документация: схемы сети, адресный план, реестр доступов, инструкции
• Определена модель эксплуатации: своя команда или аутсорс поддержки 24/7
• Проведён нагрузочный тест и тест отказоустойчивости перед полноценным запуском
• Составлен план развития инфраструктуры на 6–12 месяцев

14Кейсы: реальный опыт возвращения IT в Россию

За последние два года мы реализовали более 20 проектов по возвращению и восстановлению IT-инфраструктуры в России. Ниже — четыре характерных кейса, которые показывают типовые сценарии, сроки и результаты.

Кейс 1: Ритейл — 6 недель от аудита до первого заказа

Ситуация: Международная сеть магазинов одежды возвращалась в РФ через нового дистрибьютора. Устаревшие серверы, отсутствие доступа к домену, требование локализации клиентской базы по 152-ФЗ.

Решение: Провели ИТ-аудит, подобрали Yandex Cloud под e-commerce нагрузку, восстановили Active Directory, мигрировали почту 120 сотрудников, подготовили рабочие места.

Результат: Магазины принимали заказы через 6 недель. Экономия на инфраструктуре — 35% по сравнению с прежними затратами.

Кейс 2: Производство — IT-инфраструктура завода за 7 недель

Ситуация: Европейский производитель строительных материалов открывал завод под Москвой. Нужен ЦОД для ERP и MES, сеть на 200+ мест, VPN в Германию.

Решение: Закупили серверное оборудование российской сборки, разместили в ЦОД DataLine Tier III, развернули домен, файловые сервисы, резервное копирование.

Результат: Простой производства — 0 дней. Запускали цеха параллельно с монтажом IT.

Кейс 3: Фармацевтика — миграция из AWS за 4 недели

Ситуация: Фармацевтическая компания мигрировала из AWS из-за требований по локализации данных пациентов (152-ФЗ) и нестабильности доступа.

Решение: Аудит 47 ВМ, карта зависимостей, выбор SberCloud, миграция в 3 волны с тестовым стендом.

Результат: Downtime критичных сервисов — менее 15 минут. Прошли проверку на соответствие требованиям по данным.

Кейс 4: Восстановление после ухода подрядчика

Ситуация: Логистическая компания потеряла доступы ко всей инфраструктуре после ухода IT-директора.

Решение: Восстановление административного доступа за 48 часов, полный аудит, устранение 12 критичных уязвимостей, развёртывание мониторинга и бэкапа, перевод на аутсорсинговую поддержку 24/7.

Результат: Инцидентов за первый год — 0. Полное восстановление контроля над инфраструктурой.