Как перенести IT-инфраструктуру компании в облако без рисков

Клиенты часто приходят к нам и говорят: «Хотим в облако!». И знаете, что они обычно представляют? Красивую картинку из рекламы: один клик — и всё работает само собой, будто по волшебству. Но на практике, после тридцати с лишним миграций для компаний от 8 до 50 рабочих мест в Москве, я прекрасно понимаю, где эта «идеальная» картинка обычно рассыпается в пух и прах. Эта статья — мой личный, проверенный временем рабочий чек-лист. Именно им я пользуюсь, ведя каждый проект по переезду в Yandex Cloud, VK Cloud, Selectel, RUVDS или Cloud4Y. Почему это важно? Такой подход защищает бизнес клиента от страшных вещей: потери данных, внезапно гигантских счетов и простоя, который может затянуться на неделю.

Зачем малому и среднему бизнесу облако в 2026 году

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

• CAPEX → OPEX. Вместо разовых трат 1,5–3 миллиона на сервер каждые 5 лет — ровный ежемесячный платёж 60–120 тысяч. Бухгалтерия счастлива.
• Устранение «единой точки боли». Сервер в офисе на Преображенской — это пожар, протечка крыши, кража, отключение электричества. ЦОД Yandex Cloud в Сасово или Selectel в Дубровке не загорится завтра утром.
• Скорость масштабирования. Открыть новый филиал — это запросить второй RDP-сервер в облаке за 10 минут, а не покупать железо два месяца.
• Готовый Disaster Recovery. В одном клике разворачивается резервная среда в другом регионе провайдера. Раньше это требовало второго ЦОД и пары инженеров.
• Соответствие 152-ФЗ. ЦОДы в РФ, аттестация по ФСТЭК, готовые поручения на обработку — гораздо проще, чем самим строить контур ПДн в офисе.

Но я всегда, абсолютно всегда говорю клиентам честно и прямо: облако – это не панацея, и НЕ всегда дешевле. Представьте: у вас стабильная нагрузка, всё работает 24/7, и, судя по всему, так будет ещё лет 4–5. Что тогда? В этом случае свой Proxmox-кластер почти всегда выигрывает по общей стоимости владения (TCO). Облако же по-настоящему выгодно, когда нагрузка постоянно «дышит», когда нужна конкретная география для серверов, или если у вас просто нет своей IT-команды, и в ближайшее время она не появится.

Три модели облака: IaaS, PaaS, SaaS — что выбрать

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

IaaS (Infrastructure as a Service). Вы получаете виртуальные машины с пустой ОС. Сами ставите 1С, SQL Server, AD, домен, IIS — всё, как на своём сервере. Этим занимается мой инженер. Контроль 100%, ответственность за всё внутри ОС — на вас.

PaaS (Platform as a Service). Провайдер даёт уже настроенную платформу: managed PostgreSQL, managed Kubernetes, managed RabbitMQ. Вы не думаете про обновления, бэкапы, патчи безопасности — но и доступ к «нутрянке» ограничен.

SaaS (Software as a Service). Готовое приложение: 1С:Фреш, Контур.Диадок, Битрикс24. Платите подписку и пользуетесь. Минимум контроля, максимум простоты.

Для компаний с числом рабочих мест до 50 мы обычно советуем гибридную конфигурацию. Что это значит? Мы берём IaaS для Active Directory, файлового сервера и, конечно, 1С — здесь нам нужен полный, абсолютный контроль. PaaS отлично подходит для PostgreSQL под различные прикладные системы. Кстати, управляемый сервис в Yandex Cloud всего за 8000 ₽/мес выходит гораздо выгоднее, чем если бы мы пытались поддерживать его своими силами. А для почты? Тут наш выбор — SaaS, например, Mail.ru для бизнеса или Яндекс 360.

Этап 1: аудит инфраструктуры (1–2 недели)

Знаете, если начать миграцию без предварительного аудита, это будет чистой воды лотерея. Вот почему мы выделяем на него от 5 до 10 рабочих дней — и размер компании здесь абсолютно не важен. Так что же именно мы там собираем?

• Полный список ВМ и физических серверов. CPU, RAM, диски, ОС, версии, прикладной софт. Если есть Hyper-V/VMware — выгружаю через PowerShell или RVTools.
• Карта зависимостей. Какая ВМ обращается к какой, по каким портам, как часто. Часто всплывает забытый сервер, через который ходят отчёты, и который никто давно не трогал.
• Реальное потребление ресурсов. Метрики Zabbix или Performance Monitor за последний месяц. Сервер с 32 ГБ RAM может реально использовать 6 — нет смысла платить в облаке за 32.
• Лицензии. Windows Server, SQL, 1С, Касперский — что куда привязано, как переводится в облако.
• SLA-требования. Какие системы можно гасить ночью, какие должны быть 24/7, какой допустимый downtime.
• Объёмы данных и сетевой трафик. Сколько ТБ перевозим, есть ли постоянный обмен с внешними системами.

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

Этап 2: выбор провайдера и сервисов

На сегодняшний день в России, по нашим наблюдениям, работают пять провайдеров, которые можно смело отнести к enterprise-уровню: это Yandex Cloud, VK Cloud, Selectel, RUVDS и Cloud4Y. А если мы говорим о микро- и малом бизнесе, то к ним мы бы ещё добавили Beget Cloud и SberCloud. Как мы их выбираем? Используем довольно простую, но эффективную матрицу:

Знаете, я никогда, вот прямо совсем никогда, не выбираю провайдера, ориентируясь только на ценник. Почему? Всё просто: цена может измениться уже через год, и не в лучшую сторону, а вот головная боль от нового переезда — это уже совершенно другой разговор. Мы всегда смотрим на ситуацию комплексно: оцениваем API, обязательно проверяем наличие terraform-провайдера, а как насчёт техподдержки? О, её качество мы проверяем без стеснения — не побоимся позвонить даже в 23:00 с тестового аккаунта! Ещё смотрим, есть ли нужные managed-сервисы, крайне важна география их ЦОДов и, разумеется, репутация по аптайму.

Этап 3: пилот на некритичной системе

А вот это тот самый шаг, который, кажется, пытаются проскочить вообще все. Мой вам личный совет: не дайте этого сделать ни себе, ни тем более клиенту! Что такое пилот? Это от 2 до 3 недель довольно кропотливой работы, когда мы переносим одну-две некритичные виртуальные машины в облако выбранного провайдера. Зачем это нужно? Какие же цели мы перед собой ставим?

• Как на самом деле функционируют? Мы всегда тщательно разбираемся в тонкостях работы API-интерфейсов провайдера и их веб-панелей управления. Это не просто проверить галочки, это убедиться, что всё работает как часы.
• Насколько они быстры? Мы обязательно проводим замеры реальной скорости дисковых подсистем, пропускной способности сети и того, сколько времени требуется на запуск виртуальных машин. Цифры на бумаге — это одно, а реальность, как показывает наша практика, бывает очень разной.
• Ваш типичный сценарий? И конечно же, мы прогоняем ваш стандартный нагрузочный сценарий. Взять тот же тест Гилёва для 1С — это позволяет нам увидеть, как система справится с реальными пиками нагрузки, а не только с лабораторными условиями.
• Всё ли подключено? Проверяем все ваши интеграции. Убедимся, что система дотягивается до всех контрагентов, VPN-туннели стабильно устанавливаются, а SMTP-сервер отправляет почту без задержек. Ведь без связей современный бизнес никуда.
• Совпало ли? А вот теперь самое интересное: получаем первый счёт. Сравниваем его с тем, что предсказывал калькулятор. Насколько точно? Это критически важно для планирования бюджета, верно?

Практически всегда после пилота мы вносим изменения в наш план миграции. Вот, к примеру, один из недавних случаев: у клиента Yandex Cloud отлично справлялся с их CRM. Всё работало шустро и без проблем. Но вот с 1С и базой в 280 ГБ начались сюрпризы — она ощутимо «тормозила» по сравнению с физическим железом. Что делать? Пришлось нам взять у Selectel bare-metal именно под 1С, а CRM и все остальные веб-сервисы оставить в Yandex Cloud. Представляете, если бы не пилот, мы бы узнали об этой особенности уже после того, как перенесли бы весь стек? Это был бы настоящий провал!

Этап 4: подготовка к окну миграции

Вот здесь-то и начинается самая, пожалуй, критичная часть инженерной работы. Что именно мы делаем на этом этапе?

Разворачиваю целевую инфраструктуру через terraform. Это не дань моде — это страховка от ручных ошибок и возможность пересобрать всё с нуля за час, если что-то пойдёт не так. Пример terraform для Yandex Cloud:

resource "yandex_compute_instance" "ad-dc01" {
  name        = "ad-dc01"
  platform_id = "standard-v3"
  zone        = "ru-central1-a"

  resources {
    cores         = 4
    memory        = 8
    core_fraction = 100
  }

  boot_disk {
    initialize_params {
      image_id = data.yandex_compute_image.windows2022.id
      size     = 80
      type     = "network-ssd"
    }
  }

  network_interface {
    subnet_id = yandex_vpc_subnet.office-subnet.id
    nat       = false
  }

  metadata = {
    user-data = file("cloud-init/ad-dc01.yaml")
  }
}

Настраиваю VPN между офисом и облаком. Для большинства провайдеров это либо site-to-site IPsec через их шлюз, либо OpenVPN/WireGuard на отдельной ВМ. У Yandex Cloud есть managed VPN Gateway, у Selectel — собственный сервис.

Готовлю золотые копии. Полный бэкап всех данных в трёх местах: исходный сервер, локальный NAS, ещё одна копия на внешний носитель или во второй ЦОД. Всё с проверкой восстановления — нерабочий бэкап хуже отсутствующего.

Прописываю процедуру отката. На бумаге, по шагам, с временными оценками. «Если через 2 часа после переключения 1С не работает — выключаем облачную ВМ, поднимаем локальную, переключаем DNS обратно». Без этого плана в стрессовой ситуации в 4 утра люди принимают плохие решения.

Настраиваю budget-алерты. Это мой персональный пункт после пары неприятных сюрпризов. У всех российских провайдеров есть алерты на превышение бюджета — настраиваем 50%, 80%, 100% от ожидаемого месячного счёта на e-mail и Telegram. Один забытый k8s-кластер на 16 ядрах может за неделю съесть месячный бюджет.

Этап 5: окно переключения

Я всегда предпочитаю проводить миграцию не одним махом, пытаясь перенести «всё за одну ночь», а аккуратными волнами. Это гораздо надёжнее. Вот типовой план, который мы используем, скажем, для 12–15 виртуальных машин:

1. Волна 1 (некритичное). Файлсервер, тестовые ВМ, dev-окружения. Если что-то сломается — бизнес не пострадает.
2. Волна 2 (поддерживающее). Контроллер домена (поднимаем второй DC в облаке через dcpromo, потом снижаем приоритет старого), почта, печать.
3. Волна 3 (продуктовое). 1С, ERP, CRM, RDS-ферма. Это критическое окно — обычно ночь с пятницы на субботу или ночь с субботы на воскресенье.

Для переноса данных мы используем несколько разных техник. Выбор зависит, конечно, от конкретной виртуальной машины:

• Выгрузка-загрузка для 1С. Через Конфигуратор → Администрирование → Выгрузить информационную базу (DT-файл). Передача через S3 провайдера. Загрузка в новой 1С в облаке.
• Native backup-restore для SQL Server. Полный бэкап + дифференциальный + лог через одну минуту до окна — всё передаём в облако, восстанавливаем по цепочке.
• Robocopy для файлсерверов. Предварительно за неделю синхронизируем с многократными запусками robocopy /MIR /MT:32 /R:1 /W:1, в окно — последний догон 10–15 минут.
• Импорт VM через API провайдера. Yandex Cloud, VK Cloud и Selectel умеют принимать готовые qcow2/vmdk через S3.
• Hystax Acura для критичных нагрузок. Live-репликация с переключением за 60 секунд, лицензия порядка 300 долларов на ВМ.

Мы всегда стараемся, чтобы окно миграции укладывалось максимум в 6–8 часов. Как правило, это ночь с пятницы на субботу. Если же я вижу, что по нашим расчётам мы рискуем не уложиться, это очень чёткий и тревожный сигнал: значит, мы что-то упустили или недоработали на этапе подготовки. И тогда эту волну необходимо срочно разбивать на несколько более мелких.

Этап 6: тестирование и стабилизация

Утро после миграционного окна — момент истины. Мы сразу же запускаем обязательный smoke-тест по нашему чек-листу: быстро проверяем работоспособность всех ключевых сервисов. Сбоев быть не должно!

• Легко ли войти? Проверяем, как пользователи заходят в домен. Работает ли вход через VPN? Или через RDP? Главное, чтобы не было задержек и проблем с авторизацией.
• Типовая задача. Открываем 1С, проводим тестовый документ, отправляем на печать. Наша цель — убедиться, что этот ежедневный рабочий процесс идёт без сучка и задоринки.
• Доступ к файловым шарам.
• Отправка-получение почты.
• Как работают внешние связи? Смотрим на работу всех интеграций: банк-клиент, системы ЭДО, маркетплейсы. Всё должно синхронизироваться, без ошибок и зависаний. Ваши бизнес-процессы зависят от этого.
• Печатаем ли? Проверяем печать на сетевые принтеры прямо из облачного RDS. Это часто бывает камнем преткновения, но для нас важно, чтобы всё работало корректно.
• Бэкапы готовы? И конечно, контролируем, чтобы все бэкапы прошли в новой среде точно по расписанию. Ведь данные — это основа вашего бизнеса, а их сохранность для нас приоритет.

После миграции мы включаем режим повышенного внимания на целых две недели. Наш дежурный инженер буквально живёт на телефоне. Мы мониторим всё с очень короткими интервалами, и каждый день проверяем бэкапы — это святое! А ещё активно собираем фидбек от ваших пользователей: где что замедлилось, что стало неудобно, вдруг чего-то не хватает? Важна каждая мелочь.

На третьей неделе приходит время для финального обзора. Мы сверяем, сколько вы реально потратили, с тем, что прогнозировали. И тут начинается самое интерес: оптимизация ВМ! По нашим метрикам почти всегда получается «усадить» vCPU и RAM на 20–30%. А если часть виртуальных машин некритична, мы переводим их на «прерываемые» (preemptible) — это даёт скидку до 70%. Представляете, какая экономия?

Этап 7: вывод старой инфраструктуры из эксплуатации

Нет, нет, не спешите выключать старые серверы! Я настоятельно рекомендую держать их в режиме «спящего отката» как минимум 30 дней. И это даже после того, как миграция успешно завершилась. Что это вообще значит? Это ваша страховка, если вдруг что-то пойдёт не так в новом облаке — мы всегда сможем быстро вернуться на старое железо.

• Старое отключено. Убеждаемся, что старые серверы полностью выключены физически или же приостановлены на уровне гипервизора. Никаких «висящих» систем быть не должно.
• Запасной вариант. Бэкапы, сделанные за неделю до самой миграции, сохраняем отдельно и защищаем от перезаписи. Это наш страховой полис, если вдруг что-то пойдёт не так.
• Все на месте. Все исходные данные аккуратно лежат на NAS. Они полностью готовы к максимально быстрому развёртыванию, если вдруг понадобится.
• Мостик в прошлое. VPN-туннель до старой площадки мы не разбираем сразу. Конфигурации сохраняем. Мало ли, вдруг понадобится быстро вернуться или что-то проверить? Лучше перестраховаться.

Обычно, если спустя 30 дней претензий к новой системе нет, мы их выключаем, можно продавать или разбирать. Держать дольше, честно говоря, бессмысленно. Почему? Просто данные за такой срок уже устаревают. А для полноценного отката всё равно пришлось бы «догонять» огромную дельту из облака — слишком трудозатратно.

Семь типичных ошибок, которые я больше не делаю

Ошибка 1. Один большой пилот без обкатки на dev. Если тестируете сразу с реальной нагрузкой — рискуете остановить бизнес. Я делаю микро-пилот на одной тестовой ВМ, потом полноценный на 2–3 некритичных.

Ошибка 2. Полагаться на калькулятор провайдера. Реальный счёт всегда выше прогнозного на 15–25% из-за сетевого трафика, снапшотов, балансировщиков, неучтённых IP. Закладываю запас в смете.

Ошибка 3. Не настроить лимиты и алерты на бюджет. Один забытый Kubernetes-кластер с 8 нодами по 8 ядер съел у клиента 280 тысяч рублей за две недели. Теперь алерт на 50% бюджета — обязательный шаг.

Ошибка 4. Перенос «как есть». Если на сервере 32 ГБ RAM из которых 5 реально используется — нет смысла брать 32 в облаке. Аудит реальной нагрузки экономит до 40% месячного счёта.

Ошибка 5. Игнорирование сетевой латентности. Если 1С в облаке, а пользователи в офисе через тонкий канал — будет тормозить. Решение: терминальный сервер рядом с 1С, пользователи в RDS, в офис только картинка.

Ошибка 6. Не проверить интеграции с банк-клиентами и маркетплейсами. Многие банки белый список IP, и переезд в облако ломает обмен. Заранее запрашивайте новый IP через CFM/CCM банка.

Ошибка 7. Пренебрегать обучением сотрудников. Через неделю после переезда в офисе зреет недовольство, потому что «всё стало по-другому». Я провожу 1–2 коротких обучения для ключевых пользователей и оставляю инструкции на 3 страницы.

Сколько это всё стоит на практике

Хотите увидеть реальную картину? Вот цифры по проектам, которые мы реализовали в 2025–2026 годах. Они идеально подходят для типовых сценариев малого и среднего бизнеса. Вам будет интересно!

Что обычно входит в арендную плату за облако? Обычно это ВМ, диски, сетевой трафик, балансировщик и, конечно, бэкапы. А вот чего там точно не будет? Лицензии Microsoft (их можно купить отдельно через SPLA-партнёра или использовать BYOL), 1С Сервер, а также весь ваш специфический софт. Само же сопровождение — это наш IT-аутсорсинг от ITfresh, с надёжным SLA 99,5%.

FAQ

Безопасно ли держать данные компании в чужом облаке?

Давайте начистоту: это куда безопаснее, чем держать сервер прямо в офисе. Крупные российские провайдеры — тот же Yandex Cloud, Selectel, VK Cloud — обеспечивают круглосуточную охрану ЦОДа, используют биометрию, видеонаблюдение. У них всегда дублированное питание и охлаждение, да и штатные специалисты по безопасности на месте. А ваш локальный сервер? Частенько он пылится где-то в кладовке, замок которой отвёрткой открывается на раз-два. Главное, что вам нужно сделать — настроить шифрование дисков, включить двухфакторную аутентификацию для админов и, само собой, регулярно делать внешние бэкапы.

Что будет, если провайдер обанкротится или закроется?

Конечно, сценарий тотального краха для гигантов вроде Yandex или Selectel (это же публичные компании с миллиардной выручкой!) крайне маловероятен. Но мы всегда закладываем его в архитектуру. Как мы решаем эту задачу? Вся инфраструктура описана в terraform и хранится в Git. Мы делаем регулярные внешние бэкапы на ваш NAS в офисе или вообще к другому провайдеру. А ещё заранее готовим «обратный» план миграции. В случае настоящего апокалипсиса полная пересборка инфраструктуры у нового провайдера с нашей помощью займёт всего 2–5 дней. Вот что значит подготовка!

Можно ли мигрировать постепенно, не сразу всё?

Именно такой подход я и рекомендую! Это наша гибридная схема: пока критичные системы вроде 1С и AD остаются на вашем физическом железе, а все новые сервисы — CRM, веб-сайты, аналитика — сразу запускаем в облаке. На нашей практике, после 6–12 месяцев такой гибридной работы становится абсолютно ясно: всё остальное тоже гораздо проще держать в облаке. Есть, конечно, и вариант постоянного гибрида, когда часть систем действительно требует локального присутствия. Например, видеонаблюдение или станочное ЧПУ.

Кто отвечает за безопасность данных в облаке — мы или провайдер?

Здесь работает принцип shared responsibility, или модель общей ответственности. Понимаете, провайдер отвечает за безопасность самой инфраструктуры: физическая защита ЦОДа, гипервизор, сеть, базовые сервисы. А вот вы, как заказчик, отвечаете за безопасность уже внутри ваших ВМ. Это ваша операционная система, её обновления, антивирус, правила для паролей, шифрование данных и, конечно, доступы пользователей. У всех российских провайдеров есть очень подробный раздел об этой модели в договоре. Обязательно прочитайте его от корки до корки!

Сколько занимает полная миграция офиса на 30 РМ?

По моему опыту, весь путь — от самого старта проекта до подписания финального акта — обычно занимает 6–10 недель. Выглядит это примерно так: сначала 1–2 недели уходит на аудит, потом пара недель на проектирование и покупку лицензий. Ещё 2 недели пилота, неделя на подготовку к «окну». Само переключение происходит за одну ночь. И, наконец, 2 недели на стабилизацию. А если при этом меняется что-то крупное, скажем, почтовая система или ERP, добавьте к этому ещё 4–6 недель.

Что делать дальше

Если вы всерьёз задумались о миграции в облако, у меня есть простой совет: начните с аудита. Я провожу бесплатные встречи по Москве, обычно на 1–2 часа, для компаний с числом сотрудников до 50 человек. Мы вместе посмотрим, что у вас сейчас есть, рассчитаем оптимальную конфигурацию и я дам вам примерный ориентир по бюджету. Вам это ни к чему не обязывает! Просто получите чёткое понимание, во что именно вы планируете ввязаться.

Наша команда ITfresh занимается облачными технологиями с 2018 года. У нас работают сертифицированные инженеры по Yandex Cloud, VK Cloud, Selectel. Каждый проект мы ведём строго по нашему проверенному чек-листу, который упомянут выше. За последние 4 года это позволило нам не допустить ни одной потери данных и ни одного незапланированного простоя дольше 2 часов. Вот это результат, верно?

Автор: Семёнов Е.С., технический директор ITfresh, 15+ лет опыта IT-аутсорсинга для юридических лиц до 50 рабочих мест в Москве.