8 шагов миграции в российское облако для МСБ
Облако · 13 мин чтения

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

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 недели, и это я вам точно говорю.

Миф 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 рабочих мест в Москве.

Похожие статьи

Подпишитесь на рассылку ITfresh

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

Реквизиты оператора персональных данных

ООО «АЙТИ-ФРЕШ», ИНН 7719418495, КПП 771901001. Юридический адрес: 105523, г. Москва, Щёлковское шоссе, д. 92, корп. 7. Контакт: info@itfresh.ru, +7 903 729-62-41. Оператор обрабатывает e-mail подписчика в целях рассылки информационных и рекламных материалов до момента отзыва согласия.