Как перенести инфраструктуру в Yandex Cloud без простоя

Кратко

Миграция в облако — это не «выключить сервер в офисе и включить в Yandex Cloud». Это управляемый проект: аудит текущей инфраструктуры, пилот на части нагрузки, перенос данных и переключение трафика (переключение) с минимальным или нулевым простоем. Большинство руководителей боятся не стоимости, а непредсказуемости: «сайт упадёт на выходных», «база потеряется», «счета вырастут вдвое». Ниже — как устроен процесс на практике, какие этапы обязательны и где чаще всего ломаются сроки.

SmartProektSystems — официальный партнёр Yandex Cloud. Мы ведём миграции для интернет-магазинов, корпоративных порталов, CRM/ERP-систем и стенд разработки/test-сред. Работаем по договору с юрлицами и ИП, готовим отчёты для директора без лишнего жаргона.

Когда миграция имеет смысл

• физический сервер или VPS на исходе: железо устарело, гарантия закончилась, аренда в ЦОД дорожает;
• нет резервирования: один сервер = одна точка отказа, бэкапы «где-то есть», но восстановление не проверяли;
• сезонные пики (распродажи, отчётность) — текущая инфраструктура не масштабируется;
• требования регуляторов или заказчиков: данные в РФ, изоляция, аудит доступа;
• команда разработки просит тестовый контур, CI/CD и отдельные среды — на одном сервере это неудобно и опасно;
• выход с зарубежных облаков (AWS, GCP, Azure) на российскую площадку.

Миграция не нужна «потому что все в облаке». Если один стабильный сайт на WordPress, нагрузка предсказуема, админ знает сервер наизусть — иногда достаточно модернизации и нормальных бэкапов. Решение принимается после аудита, а не до него.

Что такое «миграция без простоя»

«Zero downtime» в маркетинге звучит абсолютно, на практике это означает: пользователи не замечают переключения, а критичные сервисы остаются доступны в согласованное окно (часто ночью или в низкую нагрузку). Полностью без единой секунды недоступности можно мигрировать не всё — например, legacy-систему с монолитной БД без репликации проще перенести с коротким окном 15–60 минут, чем месяцами бороться за идеал.

Типовая схема без простоя для веб приложения:

1. разворачиваем копию в Yandex Cloud (Compute Cloud, Managed Service for PostgreSQL/MySQL, Object Storage);
2. настраиваем репликацию или периодическую синхронизацию данных;
3. прогоняем нагрузочные и функциональные тесты на копии;
4. переключаем DNS или балансировщик на новую площадку;
5. держим старую среду «на подхвате» 3–14 дней, затем выводим из эксплуатации.

Этап 1: аудит и инвентаризация

Без аудита миграция — лотерея. За 3–10 рабочих дней (зависит от масштаба) фиксируем:

• список серверов, ролей, ОС, версий ПО;
• зависимости между сервисами (сайт → API → БД → очередь → файловое хранилище);
• объёмы данных, скорость роста, пиковые RPS/IO;
• интеграции: 1С, платёжные шлюзы, SMS, почта, внешние API;
• лицензии и ограничения (Windows Server, Oracle, 1С на SQL и т.д.);
• требования к допустимая потеря данных и время восстановления (сколько данных можно потерять и за сколько восстановиться);
• текущие затраты: железо, Colo, канал, администрирование.

Результат аудита — не «красивая презентация», а карта миграции: что переносим as-is, что переписываем, что выводим из эксплуатации, оценка сроков и бюджета по фазам.

Этап 2: проектирование в Yandex Cloud

На основе аудита собираем целевую архитектуру. Для МСБ часто достаточно:

• Compute Cloud — виртуальные машины или Instance Groups с автомасштабирование;
• Managed Service for PostgreSQL / MySQL / ClickHouse — БД без возни с бэкапами и патчами ОС;
• Object Storage — медиа, бэкапы, статика;
• Application Load Balancer — распределение трафика, SSL-termination;
• Cloud DNS или внешний DNS с низким TTL перед переключение;
• VPC — изоляция сетей, security groups, NAT для исходящего трафика.

На этом этапе закладываем мониторинг (Yandex Monitoring, алерты в Telegram/MAX), политику бэкапов и IAM: кто имеет доступ к продакшену, кто — только к dev.

Как партнёр Yandex Cloud мы помогаем с оформлением грантов на пилот — часть первых месяцев облака может быть покрыта программой Yandex Cloud для старта миграции. Условия меняются, актуальность уточняем на момент проекта.

Этап 3: пилот

Пилот — перенос не всего, а репрезентативной части: один микросервис, тестовая копия, модуль 1С, вторичный сайт. Цели пилота:

• проверить сеть, latency, доступ к внешним системам из облака;
• отработать процедуру деплоя и отката;
• сравнить фактическую стоимость с расчётом аудита;
• обучить команду заказчика работе с консолью и регламент'ами.

Типичная длительность пилота — 2–4 недели. Если пилот провалился — лучше остановиться и пересмотреть архитектуру, чем тащить весь прод «на вере».

На своих серверах, VPS и зарубежные облака: откуда чаще всего переезжают

Три типичных сценария, с которыми мы работаем:

• Сервер в офисе или Colo. Закончился ресурс, нет резервирования, кондиционирование и ИБП — зона ответственности «как получится». Миграция в Yandex Cloud даёт SLA площадки и managed-сервисы.
• VPS у локального хостера. Один инстанс, ручные бэкапы, слабая сеть к внешним API. Переезд на Compute Cloud + ALB + Managed DB — первый шаг к масштабированию.
• AWS / GCP / Azure. Санкционные и юридические риски, оплата, поддержка. Переносим на российскую площадку с сохранением архитектурных паттернов (VPC, Object Storage, управляемая БД).

В каждом случае аудит начинается с вопроса «что нельзя просто выключить в пятницу» — и это обычно 1С, почта, VPN или пара legacy-сервисов без документации.

Роли: кто что делает в проекте миграции

Чёткое разделение ролей снижает риск «все ждут друг друга» в ночь переключение.

Этап 4: перенос данных и синхронизация

Данные — главный источник риска. Подход зависит от типа:

• БД: logical replication, streaming replication, или для небольших объёмов — pg_dump/mysqldump с последующей догонкой изменений;
• Файлы: начальный bulk-копирование в Object Storage, затем инкрементальный rsync до переключение;
• Очереди и кэш: часто проще пересоздать на новой стороне, если допустима краткая потеря необработанных задач (согласуется заранее).

Перед переключение обязательны: checksum выборки данных, быстрые проверки после выкладки критичных сценариев (оформление заказа, авторизация, выгрузка в 1С), замер времени отклика.

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

Переключение — финальное переключение боевой контур трафика на Yandex Cloud. Стандартный регламент:

1. за 48–72 часа снижаем TTL DNS до 300–600 секунд;
2. останавливаем запись на старую БД (read-only mode) или фиксируем lag реплики = 0;
3. финальная синхронизация delta;
4. переключение DNS / балансировщика / reverse proxy;
5. мониторинг ошибок, latency, очередей 2–4 часа «в боевом режиме»;
6. при проблемах — откат по заранее отрепетированному сценарию (откат).

Окно переключение для большинства МСБ сайтов и порталов — от 15 минут до 2 часов. Для высоконагруженных магазинов выбираем ночь или утро понедельника с минимальными продажами — согласуем с маркетингом и складом.

Типовые ошибки, из-за которых «падает» миграция

• Нет карты зависимостей. Перенесли сайт, забыли cron на старом сервере — раз в сутки «ломаются» отчёты.
• Жёстко прошитые IP и пути. В конфигах .env, 1С, файрволах партнёров остались старые адреса.
• Недооценка лицензий. Windows, SQL Server, антивигус — в облаке тоже нужно учитывать.
• Нет плана отката. «Поехали вперёд» без снимок состояния'ов и старой среды на standby.
• Переключение в пятницу вечером. Классика. Переносим в согласованное окно с дежурной командой.
• Игнорирование безопасности. Публичные bucket'ы, SSH с 0.0.0.0/0, пароли в terraform без vault.

Сроки и бюджет: ориентиры

* Работы подрядчика, без учёта потребления Yandex Cloud. Инфраструктура в облаке часто сопоставима или дешевле Colo+админ при правильном sizing — но это отдельный расчёт после аудита.

Что получает руководитель по итогам

• документ «as-is / to-be» и карта сервисов;
• регламент переключение и откат;
• настроенные бэкапы и мониторинг с алертами;
• доступы и регламент (кто что может в консоли);
• отчёт о фактическом простое и отклонениях от плана;
• рекомендации на 90 дней: оптимизация затрат, резервирование, DR.

FAQ

Можно ли мигрировать по частям? Да, и это предпочтительно: сначала dev/тестовый контур, потом вторичные сервисы, в конце — боевой контур.

Нужен ли штатный админ с нашей стороны? Желательно контактное лицо, знающее бизнес критичные процессы. Техническую часть можем взять на себя полностью или в формате co-managed.

Что с 152 ФЗ и локализацией данных? Yandex Cloud — площадка с дата центрами в РФ. Архитектура и договоры оформляются с учётом вашей модели обработки ПДн — юридическую часть согласуем с вашими юристами.

Сколько стоит сам Yandex Cloud после миграции? Зависит от ресурсов. После переноса часто делаем пересмотр облачных затрат — типичная экономия 20–40% без потери SLA при грамотном sizing. Подробнее — в статье про оптимизацию расходов.

Чем отличается миграция «под ключ» от консультаций? Под ключ — мы ведём все этапы, переключение и post-support 7–14 дней. Консультации — вы делаете руками, мы ревьюим архитектуру и регламент. Формат выбирают по зрелости внутренней команды.

Чеклист готовности к переключение

• регламент переключение и откат согласованы и отрепетированы на тестовом контуре;
• TTL DNS снижен, сертификаты на новой площадке валидны;
• мониторинг и алерты настроены до переключения, а не после;
• партнёры (банк, 1С, SMS) знают новые IP или whitelist обновлён;
• дежурная связь: Telegram/MAX-чат, ответственные с обеих сторон;
• бэкап «точки ноль» на старой площадке сделан непосредственно перед переключением.

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

Если облако кажется «дорогим и непонятным» — начните с аудита, а не с покупки десяти VM. За 1–2 недели вы получите цифры, а не догадки: стоит ли мигрировать, в какие сроки и с каким риском простоя.

SmartProektSystems — официальный партнёр Yandex Cloud. Проведём аудит, пилот и переключение под ключ или подключимся на отдельный этап. Подробнее об услуге миграции или раздел об облачных решениях — оставьте заявку, вернёмся с планом первых шагов в течение 1–2 рабочих дней.