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

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

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

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

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

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

Три модели облака: 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 для AD, файлового сервера и 1С (полный контроль), PaaS для PostgreSQL под прикладные системы (managed-сервис в Yandex Cloud за 8000 ₽/мес дешевле, чем сами поддерживаем), SaaS для почты (Mail.ru для бизнеса или Яндекс 360).

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

Без аудита миграция — игра в рулетку. Я выделяю на него 5–10 рабочих дней независимо от размера компании. Что собираю:

На выходе — Excel-таблица с матрицей миграции, в которой по каждой ВМ видно: куда едет, в каком конфиге в облаке, кто отвечает, в каком окне.

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

Российских провайдеров уровня enterprise сейчас пять: Yandex Cloud, VK Cloud, Selectel, RUVDS, Cloud4Y. Для микро- и малого бизнеса добавлю Beget Cloud и SberCloud. Я выбираю по простой матрице:

СценарийМой выборПочему
Современный стек, Kubernetes, аналитикаYandex CloudЗрелый managed K8s, ClickHouse, Data Lens
Гибрид с локальным железомVK CloudOpenStack API, легче связать с on-premise
1С + RDS + AD на постоянной нагрузкеSelectel или Cloud4YГотовые конфиги под 1С, дешёвый bare-metal
Работа с ПДн УЗ-1, госзаказCloud4YАттестация на УЗ-1, опыт с КИИ
Несколько географий, в т.ч. зарубежRUVDSПлощадки в РФ, КЗ, Швейцарии, Лондоне
Минимальный бюджет, простой проектSelectel + BegetСамые доступные тарифы среди надёжных

Я никогда не беру одного провайдера на основании только цены. Цена меняется через год, а боль миграции на нового провайдера остаётся. Смотрю в комплексе: API, terraform-провайдер, качество техподдержки (звоню в 23:00 на тестовый аккаунт), наличие нужных managed-сервисов, географию ЦОДов, репутацию по аптайму.

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

Это шаг, который пытаются пропустить почти все. Не давайте этого делать ни клиенту, ни себе. Пилот — это 2–3 недели работы с одной-двумя некритичными ВМ в облаке провайдера. Цели:

Чаще всего после пилота в плане миграции что-то меняется. Например, у одного клиента выяснилось, что 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-ферма. Это критическое окно — обычно ночь с пятницы на субботу или ночь с субботы на воскресенье.

Для переноса данных я использую несколько техник в зависимости от ВМ:

Окно у меня всегда укладывается в 6–8 часов ночью с пятницы на субботу. Если по расчётам не укладывается — значит, что-то не доделано на этапе подготовки, и волну надо разбивать дальше.

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

Утром после окна — обязательный smoke-тест по чек-листу:

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

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

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

Не торопитесь выключать старые серверы. Я держу их в режиме «спящего отката» минимум 30 дней после успешной миграции. Это значит:

Через 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 годов для типовых сценариев МСБ.

Размер компанииКол-во ВМАренда облака, ₽/месМиграция «под ключ», ₽Сопровождение, ₽/мес
10–15 РМ4–635 000 – 55 000120 000 – 180 00020 000 – 35 000
15–25 РМ6–1055 000 – 90 000180 000 – 280 00030 000 – 50 000
25–40 РМ10–1480 000 – 130 000250 000 – 380 00040 000 – 65 000
40–50 РМ12–18120 000 – 180 000320 000 – 450 00050 000 – 80 000

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

FAQ

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

В среднем — безопаснее, чем на сервере в офисе. Российские провайдеры уровня Yandex Cloud, Selectel, VK Cloud имеют физическую охрану ЦОДа 24/7, биометрию, видеонаблюдение, дублированное питание и охлаждение, штатных безопасников. Локальный сервер обычно стоит в кладовке с замком, который открывается отвёрткой. Главное — настроить шифрование дисков, двухфакторную аутентификацию для административного доступа и регулярные внешние бэкапы.

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

Сценарий маловероятный для крупных провайдеров (Yandex и Selectel — публичные компании с миллиардной выручкой), но я закладываю его в архитектуре. Решение: terraform-описание всей инфраструктуры в гите, регулярные внешние бэкапы на NAS в офисе или ко второму провайдеру, настроенный «обратный» план миграции. При катастрофическом сценарии полная пересборка инфраструктуры у нового провайдера занимает 2–5 дней с нашей помощью.

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

Да, это и есть рекомендуемый подход. Гибридная схема: критичные системы (1С, AD) пока на железе, новые сервисы (CRM, веб, аналитика) — сразу в облаке. Через 6–12 месяцев работы с гибридом обычно становится ясно, что и оставшееся проще держать в облаке. Альтернатива — постоянный гибрид, когда часть систем требует локального присутствия (например, видеонаблюдение или станочное ЧПУ).

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

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

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

По моему опыту — 6–10 недель от старта проекта до закрытия акта: 1–2 недели аудит, 2 недели проектирование и закупка лицензий, 2 недели пилот, 1 неделя подготовка к окну, 1 ночь окно переключения, 2 недели стабилизация. Если параллельно меняется почтовая система или ERP — добавляйте ещё 4–6 недель.

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

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

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

Нужен план миграции в облако? Оставьте заявку на бесплатный аудит через форму на главной странице. Подберём провайдера, посчитаем бюджет, разработаем дорожную карту миграции с минимальными рисками для вашего бизнеса.

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