Облако · 13 мин чтения

8 шагов миграции в российское облако для МСБ

Когда я провожу очередную миграцию офиса в Yandex Cloud или Selectel, я ловлю себя на мысли, что у меня сложился жёсткий шаблон из восьми шагов, и каждый из них одинаково важен. Пропустите шаг — получите либо неконтролируемые счета, либо потерянные данные, либо неделю простоя. В этой статье разберу свой рабочий чек-лист на проектах для бизнеса от 10 до 50 рабочих мест, с реальными цифрами по бюджету и срокам, и развею самые популярные мифы, которые мешают компаниям сделать первый шаг.

Какие мифы мешают МСБ зайти в облако

За последний год я регулярно слышу одни и те же возражения от собственников и финансовых директоров. Разберу шесть самых частых.

Миф 1: «Это будет дороже». Иногда — да, иногда — нет. У бизнеса со стабильной нагрузкой 24/7 и горизонтом владения 5+ лет своё железо может выйти на 15–25% дешевле. У бизнеса с пиковой нагрузкой (магазин с распродажами, сезонный учёт) облако дешевле на 30–40% именно за счёт оплаты по факту.

Миф 2: «Vendor lock-in заберёт нас в плен». Если архитектура построена на стандартных технологиях (PostgreSQL, Kubernetes, S3-API) и описана через Terraform — переезд между провайдерами занимает 2–4 недели. Это не безболезненно, но и не катастрофа.

Миф 3: «У моих админов нет нужных навыков». Уровень входа в Yandex Cloud / VK Cloud / Selectel сейчас низкий: веб-интерфейсы переведены на русский, документация подробная, есть бесплатные курсы. За 2–3 недели обычный системный администратор освоит базовый набор для МСБ. Глубокие сценарии типа Kubernetes-оркестрации — отдельная история, для МСБ обычно не нужны.

Миф 4: «В облаке всё будет тормозить из-за интернета». Современные SSD-диски в облаке выдают 25–80 тысяч IOPS, что часто быстрее, чем местный RAID-массив на офисном сервере. Канал в нормальном офисе (от 100 Мбит/с) полностью покрывает потребности RDS-фермы и доступа к 1С. Тормозить может только тонкий клиент через 4G — но это и в офисе будет тормозить.

Миф 5: «Старые приложения никуда не переедут». Большинство легаси-систем переносятся методом lift-and-shift — ВМ как есть, без изменений. Сложности возникают редко: с привязками к конкретному железу, с лицензиями, с устаревшими ОС типа Windows Server 2003. Для них есть отдельные сценарии (изоляция, прокси, постепенная замена).

Миф 6: «Счёт прилетит непредсказуемый». Если настроены лимиты бюджета и алерты — не прилетит. Я ставлю клиентам алерты на 50%, 80% и 100% от месячного потолка, плюс жёсткий лимит на остановку ресурсов при критических порогах. За три года ни одного «бабушка, я в облаке».

Шаг 1: Планирование (1 неделя)

Самая недооценённая часть проекта. Без чёткого ответа на «зачем» вся миграция превращается в хаос. На этом шаге я с собственником и финдиректором фиксирую:

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

Шаг 2: Аудит инфраструктуры (1–2 недели)

Что собираю и как:

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

Шаг 3: Техзадание и план миграции (1 неделя)

На основании аудита формирую детальное ТЗ. В нём прописываю:

  1. Целевая архитектура в облаке провайдера (схема в Drawio или аналог).
  2. Стратегия по каждой ВМ: lift-and-shift, replatform (например, своя PostgreSQL → managed PostgreSQL), refactoring (полная переработка приложения).
  3. План тестов: smoke-тесты, нагрузочные тесты, тесты восстановления.
  4. План отката с временными метриками.
  5. График окна миграции по волнам.
  6. Ответственные за каждую ВМ и каждый этап.

Это 15–25 страниц документа, по которому потом сверяемся каждый день. ТЗ согласовывается с собственником под подпись — это защита и для меня, и для клиента.

Шаг 4: Проектирование инфраструктуры через IaC (1–2 недели)

Здесь я закладываю фундамент для всего проекта — Infrastructure as Code через Terraform. Вот пример простой конфигурации для Selectel под 1С + AD:

terraform {
  required_providers {
    selectel = { source = "selectel/selectel", version = "~> 5.0" }
    openstack = { source = "terraform-provider-openstack/openstack" }
  }
}

resource "selectel_vpc_project_v2" "main" {
  name        = "company-prod"
  auto_quotas = true
}

# Сеть для офисной инфраструктуры
resource "openstack_networking_network_v2" "office_net" {
  name           = "office-net"
  admin_state_up = "true"
}

resource "openstack_networking_subnet_v2" "office_subnet" {
  network_id = openstack_networking_network_v2.office_net.id
  cidr       = "10.20.0.0/24"
  ip_version = 4
}

# Сервер AD
resource "openstack_compute_instance_v2" "ad-dc01" {
  name              = "ad-dc01"
  image_name        = "Windows Server 2022 Standard"
  flavor_name       = "SL1.2-4-50"  # 4 vCPU, 8 ГБ RAM, 50 ГБ SSD
  key_pair          = "office-key"
  availability_zone = "ru-1a"

  network { uuid = openstack_networking_network_v2.office_net.id }
}

# Сервер 1С (более мощный)
resource "openstack_compute_instance_v2" "srv-1c" {
  name              = "srv-1c-prod"
  image_name        = "Windows Server 2022 Standard"
  flavor_name       = "SL1.8-32-200"  # 8 vCPU, 32 ГБ RAM, 200 ГБ NVMe
  key_pair          = "office-key"
  availability_zone = "ru-1a"

  network { uuid = openstack_networking_network_v2.office_net.id }
}

# Балансировщик RDS-фермы
resource "selectel_lb_listener_v2" "rds-listener" {
  name             = "rds-3389"
  protocol         = "tcp"
  protocol_port    = 3389
  loadbalancer_id  = selectel_lb_loadbalancer_v2.rds_lb.id
}

Преимущества IaC для МСБ конкретные: можно пересобрать инфраструктуру с нуля за час при катастрофе, видеть все изменения в git, передавать проект между инженерами без потери знаний, тестировать конфигурации в отдельном окружении.

Альтернативы Terraform для российских облаков: у Yandex Cloud есть собственный CLI и нативный terraform-провайдер, у VK Cloud — поддержка OpenStack-инструментов (Heat, OpenStack Client), у Selectel — собственные модули и terraform.

Шаг 5: Подготовка к миграции (1 неделя)

Что делаю в эту неделю:

Шаг 6: Миграция волнами (1–2 ночных окна)

Я не перевожу всё сразу. Стандартное разбиение для офиса 25–40 РМ:

Волна 1 (некритичное). Файлсерверы, тестовые среды, dev/staging. Если что-то сломается, бизнес не пострадает. Это первая ночь, обычно с пятницы на субботу.

Волна 2 (поддерживающее). Контроллер домена (поднимаем второй DC в облаке через dcpromo, переносим FSMO), почтовый сервер, сервер печати. Параллельно с волной 1 или на следующую ночь.

Волна 3 (продуктовое). 1С, ERP, CRM, RDS-ферма, БД. Самое критичное окно, обычно ночь с субботы на воскресенье. Здесь концентрируется основной риск проекта.

Методы переноса данных, которые я применяю:

В каждое окно я работаю не один — со мной 1–2 инженера, и обязательно дежурный сотрудник со стороны клиента (для тестов от лица бизнеса и согласования решений в моменте).

Шаг 7: Тестирование (1–2 дня)

После закрытия окна миграции запускается полный цикл проверок. У меня готовый чек-лист на 40+ пунктов, основные категории:

По итогам тестов — короткий отчёт для собственника: что прошло, что не прошло, что устраняем в каком приоритете.

Шаг 8: Поэтапное переключение трафика (canary / blue-green)

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

Canary deployment. Сначала 5% пользователей идут в облако, остальные — на старую инфраструктуру. Через сутки без жалоб увеличиваем до 25%, затем 50%, 100%. На каждом этапе мониторим ошибки, латентность, обращения в поддержку. Если что-то идёт не так — мгновенно возвращаем 100% на старую инфраструктуру.

Blue-green deployment. Старая (blue) и новая (green) инфраструктуры работают параллельно. Балансировщик на DNS-уровне переключает трафик мгновенно: 0% green / 100% blue → 100% green / 0% blue. Откат — за 2 минуты сменой DNS обратно. Я предпочитаю этот подход для офисных сервисов: проще объяснить пользователям и быстрее откатываться.

Для МСБ blue-green обычно избыточен — мы переключаем всех пользователей одномоментно ночью, а не порциями. Но если у клиента есть 24/7 интернет-сервис (магазин, личный кабинет) — обязательно делаем canary или blue-green.

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

ПровайдерvCPU/час1 ГБ RAM/час1 ГБ SSD/месСильные стороны
Yandex Cloud~1,3 ₽~0,45 ₽~6 ₽Зрелый K8s, ML, Data Lens, terraform
VK Cloud~1,2 ₽~0,40 ₽~5 ₽OpenStack API, managed DB
Selectel~1,1 ₽~0,35 ₽~5 ₽Дешёвый bare-metal, готовые конфиги под 1С
RUVDS~1,0 ₽~0,30 ₽~5 ₽Низкие базовые тарифы, география
Cloud4Y~1,4 ₽~0,50 ₽~7 ₽Аттестация УЗ-1, КИИ, госзаказ

Цены ориентировочные на апрель 2026, могут отличаться по регионам и в зависимости от тарифного плана. На preemptible-машинах у Yandex Cloud и Selectel скидка до 60–70%.

Реальный кейс: 22 РМ, торговая компания, миграция в Selectel

В марте 2026 я закончил проект для торговой компании на Юго-Западной — 22 рабочих места, ассортимент электроники для маркетплейсов. Было: один сервер Hyper-V (1С + AD + файлсервер + терминал на 12 пользователей) и второй для бэкапов. Стало: облачный кластер в Selectel из 4 ВМ + S3 для бэкапов.

Цифры по проекту:

ПараметрДо (свой сервер)После (Selectel)
Месячные расходы на инфраструктуру~22 000 ₽ (амортизация + электричество)~74 000 ₽
Стоимость замены железа в горизонте 5 лет1 800 000 ₽0 ₽
Доступность по итогам года98,7% (3 инцидента)99,95% (1 инцидент 22 минуты)
Время восстановления после сбоя~3 часа~12 минут
Проектная стоимость миграции—240 000 ₽
TCO за 5 лет~3,12 млн ₽~4,68 млн ₽
Бизнес-эффект от 99,95% SLA—+~1,8 млн ₽ выручки за год

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

Сколько закладывать на проект миграции в облако

Размер компанииСрок проектаСтоимость миграцииАренда облака, ₽/мес
10–15 РМ, 4–6 ВМ5–7 недель120 000 – 180 000 ₽35 000 – 60 000
15–25 РМ, 6–10 ВМ6–9 недель180 000 – 280 000 ₽55 000 – 95 000
25–40 РМ, 10–14 ВМ8–10 недель250 000 – 380 000 ₽80 000 – 140 000
40–50 РМ, 12–18 ВМ9–12 недель320 000 – 500 000 ₽120 000 – 200 000

В стоимость миграции входят: аудит, проектирование, настройка terraform, перенос данных, тесты, обучение пользователей, 2 недели сопровождения после переключения. Не входит: лицензии Microsoft (через SPLA или BYOL), 1С Сервер, специализированный софт.

FAQ

Можно ли начать с бесплатного триала, чтобы оценить облако?

Да, у всех крупных российских провайдеров есть стартовые бонусы. Yandex Cloud даёт 4000 рублей и 60 дней бесплатного использования. Selectel — стартовый бонус 500–1000 рублей. VK Cloud — 3000 рублей. RUVDS — гибкие пробные тарифы. Этого хватит для базовой обкатки одной-двух ВМ. Для полноценного пилота с 1С и AD на пару недель закладывайте 5–15 тысяч рублей бюджета.

Что делать с привязкой 1С к MAC-адресу при переезде в облако?

Лицензии 1С обычно привязаны к серверной аппаратной лицензии (HASP) или к программной защите. Аппаратные ключи в облако не переезжают — нужно либо купить программную лицензию (если ещё на аппаратной), либо разместить HASP-сервер в офисе и пробросить через VPN. Я предпочитаю программные лицензии — они мобильные и поддерживают перенос между серверами через ИТС.

Какие гарантии доступности дают российские облака?

Стандартный SLA: Yandex Cloud — 99,95% для compute, 99,99% для managed-сервисов. VK Cloud — 99,95%. Selectel — 99,98% для bare-metal, 99,9% для виртуальных серверов. При нарушении SLA провайдер возвращает компенсацию в виде бонусов на счёт. Я в договорах с клиентами всегда фиксирую именно SLA провайдера + наш SLA на устранение инцидентов внутри ВМ.

Нужно ли менять провайдера почты при миграции серверов в облако?

Не обязательно. Если используете Mail.ru для бизнеса, Яндекс 360 или Microsoft 365 (через посредников) — почта продолжает работать независимо от облачной инфраструктуры. Если у вас собственный Exchange или Postfix — обычно тоже переносим вместе со всем остальным. Для МСБ я рекомендую перейти на SaaS-почту (Яндекс 360 или Mail.ru) и не держать собственный сервер — это меньше работы и больше надёжности.

Как защитить облачную инфраструктуру от взлома?

Базовый набор: двухфакторная аутентификация на портале провайдера (обязательно), VPN до облака без открытия RDP/SSH в интернет, минимальные открытые порты во внешних security-группах, регулярные обновления ОС и софта, отдельный учёт администраторов через privileged access management, бэкапы в отдельный аккаунт провайдера или к стороннему провайдеру. Для критичных систем — антивирус Касперский или Dr.Web на каждой ВМ, EDR-агент, периодические pentest.

С чего начать прямо сейчас

Если вы серьёзно задумались о миграции в облако — делайте первый шаг сегодня. Это не покупка нового айфона, а проект на 2–3 месяца с серьёзными последствиями для бизнеса. Я предлагаю простой алгоритм:

  1. Сделайте короткий внутренний документ: зачем нам облако, какой бюджет на проект, какой бюджет в месяц после.
  2. Соберите базовый список: сколько у вас серверов, какие задачи, какой объём данных.
  3. Запросите бесплатный аудит у трёх потенциальных подрядчиков. Сравните, что предлагают.
  4. Возьмите того, кто говорит конкретными цифрами и показывает реальные кейсы, а не общие слова.

Команда ITfresh обслуживает бизнес до 50 рабочих мест в Москве с 2010 года. Облачные миграции — наша рутина, у нас сертификации по Yandex Cloud, VK Cloud и Selectel, и за последние 4 года мы провели больше 30 проектов перехода в облако без потерь данных и без простоев более 2 часов.

Готовы обсудить миграцию в облако? Бесплатный двухчасовой аудит для компаний до 50 РМ в Москве — посмотрю вашу инфраструктуру, посчитаю TCO в трёх облаках, дам план миграции с конкретными сроками и бюджетом. Заявка через форму на главной странице или звонок в офис.

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