Миграция в Yandex Cloud: полный чек-лист 2026

Пошаговый план миграции в Yandex Cloud с проверенными приёмами для минимального простоя, точными проверками и расчётом бюджета на примерах 2025–2026 годов. Чек‑лист пригоден для средних и крупных проектов с базами от 100 ГБ до нескольких терабайт.

Почему Yandex Cloud в 2026?

Yandex Cloud предлагает в 2026 году набор управляемых сервисов, готовых заменить on‑premise решения по стабильности, репликации и безопасности с минимальными доработками. В 2025–2026 годах Yandex Cloud увеличил зоны доступности до 5 регионов в России и добавил интеграции с Terraform provider и CI/CD, что сильно упрощает автоматизированную миграцию.

Если у вас есть SLA 99.95% и требования по задержкам <20 мс внутри региона, переход в Yandex Cloud даёт готовые компоненты: VPC с private subnets, Network Load Balancer, Managed Service for PostgreSQL/MySQL/ClickHouse, Object Storage и встроенную систему учёта расходов.

Шаг 1: аудит инфраструктуры

Перед началом миграции провёл подробный аудит инфраструктуры на примере проекта с 8 серверами приложения, 2 веб‑балансировщиками и PostgreSQL 13 с объёмом данных 1.2 ТБ. На аудит ушло 11 рабочих дней (с 05.01.2026 по 15.01.2026) при участии инженера и DBA по 0.5 ставки.

1.1 Соберите метрики и точные требования

• CPU: суммарно 32 vCPU, средняя загрузка 24% по 30‑дневному окну (Prometheus/Datadog).
• RAM: суммарно 128 ГБ, peak до 200 ГБ при пакетных задачах (ETL по ночам).
• Хранилище: 1.2 ТБ активных данных, 0.6 ТБ cold snapshots, 300 IOPS на основном томе, 95% запросов чтения.
• Сеть: 2 входящих балансировщика (HTTPS), исходящий трафик 3.6 ТБ/мес, peak 300 Mbps.
• SLA и RTO/RPO: RTO = 30 минут, RPO = 5 минут для транзакционных баз.

1.2 Инвентаризация ПО и версий

Зафиксируйте версии СУБД, библиотек, JVM, OpenSSL, операционных систем. В нашем примере — PostgreSQL 13.6, tomcat 9.0.71, Ubuntu 20.04. Для суммарной совместимости с Managed Service for PostgreSQL нужна проверка на поддерживаемые версии: на момент 2026‑03 Yandex Cloud Managed PostgreSQL официально поддерживает 11–15, но для специфичных расширений (pg_cron, pg_partman) нужно заранее согласовать с техподдержкой.

1.3 Классификация данных по критичности

Разделите данные на группы: transactional (RPO ≤ 5 мин), analytical (RPO ≤ 1 ч), backup/archive (RPO допускается сутки). В нашем проекте таблицы платежей и пользователей — transactional (0.4 ТБ), логи — analytical (0.6 ТБ), архивы — backup (0.2 ТБ).

1.4 Результат аудита: артефакты

• CSV инвентаризация серверов и сервисов (примерная структура: host, role, vCPU, RAM, disk, os, SW, ports).
• Схема сетевой зоны с IP и CIDR.
• Список совместимых и несовместимых расширений СУБД.
• Оценочная смета ресурсов в Yandex Cloud (чек‑лист для расчёта стоимости — см. раздел "Как считать стоимость?").

Шаг 2: сетевая архитектура

Сетевая архитектура — ключ к безопасности и производительности. Для проекта с 8 приложениями и 2 БД я сделал приватную VPC с тремя подсетями: app (private), db (private), public (для балансировщиков). CIDR сети выбран 10.10.0.0/16, подсети 10.10.10.0/24 (app), 10.10.20.0/24 (db), 10.10.1.0/26 (public LB).

2.1 Создание VPC и подсетей

Использовал yc CLI и Terraform provider. Команды, которые выполнял вручную при прототипировании:

yc vpc network create --name prod-vpc --description "VPC для production"
yc vpc subnet create --name subnet-app --zone ru-central1-a --range 10.10.10.0/24 --network-name prod-vpc
yc vpc subnet create --name subnet-db --zone ru-central1-b --range 10.10.20.0/24 --network-name prod-vpc

В Terraform это выглядит так (фрагмент):

provider "yandex" {
  token = var.yc_token
  cloud_id = var.yc_cloud_id
  folder_id = var.yc_folder_id
}

resource "yandex_vpc_network" "prod" {
  name = "prod-vpc"
}

2.2 NAT, маршруты и доступ к Интернету

Для приватных инстансов настроил Cloud NAT через managed NAT gateway, чтобы исходящие обновления шли через контролируемый адрес и логировались. Для 8 приложений и пикового исходящего трафика 300 Mbps хватает одного NAT c пропускной способностью 600 Mbps. Настройка занимает 2–4 часа.

2.3 Балансировка и публичный доступ

Использовал Application Load Balancer для HTTPS с TLS termination на LB и пересылкой на приватные backend‑инстансы по HTTP. Для тарифного расчёта предусчитал 2 LB (для blue/green) — это даёт возможность переключать трафик без простоя.

2.4 Безопасность: endpoint policies, security groups

• Входной трафик: 443 на LB, 22 только из корпоративного IP (jumpbox).
• Межсервисный трафик: настройка security groups по принципу least privilege — app → db только по 5432 (Postgres) и 3306 (MySQL) где нужно.
• Включил logging Flow Logs и настроил хранение в Object Storage с lifecycle 365 дней.

Шаг 3: миграция БД

Миграция базы — наиболее критичный этап. Для PostgreSQL 13 (1.2 ТБ) я выбрал стратегию: начальный дамп + параллельное копирование больших таблиц + logical replication для минимизации RPO до ≈5 минут. На подготовку и тестовую миграцию ушло 14 дней.

3.1 Варианты подходов и когда их выбирать

• Полный дамп и restore (pg_dump/pg_restore) — простой, но RTO/ RPO зависят от размера; для <200 ГБ подходит.
• Файловая репликация (pg_basebackup, physical replica) — быстро восстановить, но требует совместимости версий и доступа к WAL.
• Logical replication (publication/subscription) — лучший баланс: онлайн‑репликация таблица‑за‑таблицей, допустимый RPO 0–20 с, требует возможности создать подписку и публикацию.

3.2 Подготовка Managed PostgreSQL в Yandex Cloud

Создал Managed Service for PostgreSQL с кластером из 3 нод: 2 реплики и 1 мастер. Конфигурация: 8 vCPU, 32 ГБ RAM, SSD 1.5 ТБ (с учётом WAL). Параметры availability zone: ru-central1-a/b/c. Время создания — 18–22 минут по консоле.

3.3 Пошаговый план миграции (пример для PostgreSQL 13 → Managed PG)

1. Создать целевой кластер в Yandex Cloud, включить logical_replication и создать пользователя репликации: CREATE ROLE repl WITH REPLICATION LOGIN PASSWORD 'strongpass';
2. На исходной БД создать публикацию:

   CREATE PUBLICATION app_pub FOR ALL TABLES;

3. Сделать initial copy: для больших таблиц использовал pg_dump с параллелизмом:

   pg_dump -h source -U app -j 8 -F d -f /tmp/dump_dir dbname
   # на целевой машине
   pg_restore -h target -U app -d dbname -j 8 /tmp/dump_dir

4. Запустить подписку на целевой стороне:

   CREATE SUBSCRIPTION app_sub CONNECTION 'host=source hostaddr=192.0.2.10 port=5432 dbname=dbname user=repl password=strongpass' PUBLICATION app_pub WITH (copy_data = false);
   -- затем вручную импортировать большие таблицы и дождаться catchup

5. Мониторить lag: select pg_stat_subscription(); и раз в 30 с проверять lag WAL.
6. Тестировать на целевом кластере: 48 часов нагрузочного теста, проверка целостности данных (row counts, checksums).
7. Запланировать cutover в окно 02:00–04:00 по рабочему времени; за 30 минут до cutover ввести режим maintenance для приложения.

3.4 Команды и примеры для MySQL и MariaDB

Для MySQL (8.0) рекомендую настроить replica через binlog: настроить CHANGE MASTER TO ... и стартовать репликацию на Managed MySQL. Для увеличения скорости initial load использовал Percona XtraBackup для горячего бэкапа и восстановление в целевой инстанс. Пример команды для экспорта структуры и данных (для небольших БД):

mysqldump --single-transaction --hex-blob --routines --events -u root -p --databases appdb | pv | mysql -h target -u root -p

3.5 Технические проверки до cutover

• Сравнение row_count и checksum для 25 критичных таблиц.
• Проверка индексов: EXPLAIN план на целевом кластере — сравнить время ответа на 20 ключевых запросов; цель — не более 20% ухудшения латентности.
• Мониторинг латентности репликации: average lag < 5 s.

Шаг 4: cutover plan

Cutover — это сценарий переключения трафика и последующая валидация. Для минимального простоя я делаю dry‑run, затем основную операцию в заранее согласованное окно. В моём проекте реальный cutover занял 11 минут downtime для транзакционной части (переход на read-only на 5 минут, переключение DNS и запуск health‑checks).

4.1 План действий на 72/24/1/0 часов

• 72 часа до: коммуникация с пользователями и командами поддержки, резервный план rollback, подготовка переносимых конфигураций и скриптов.
• 24 часа до: финальная синхронизация данных, тесты health check, репликация lag < 5 с.
• 1 час до: перевести систему в maintenance mode, заблокировать крон‑джобы, поставить запреты на записи из сторонних интеграций.
• 0 часов (cutover): остановка приложений на исходном окружении, последний flush/commit, переключение DNS и LB (TTL 60 s заранее), проверка 40 контрольных запросов на целевом окружении.

4.2 Rollback сценарий

Rollback всегда предусматривать заранее. В моём проекте rollback занимал следующие шаги:

1. Если переключение DNS/LoadBalancer прошло некорректно, вернуть LB в blue‑pool и вернуть DNS A записи назад (TTL 60 s позволяет вернуть трафик в ≤2 мин).
2. Если в целевой БД обнаружены ошибки данных, откат — запускается read-only режим на целевом кластере и перевод продакшн‑трафика обратно на исходный мастер с флагом maintenance.
3. Зафиксировать точное время отката, детально записать логи и причину — это ускоряет postmortem.

4.3 Проверки после cutover (0–72 часов)

• Мониторинг SLA: проверять 1, 6, 24, 72 часа после cutover — latency p50/p95/p99 для ключевых API.
• Проверка целостности данных каждые 6 часов первые 48 часов: row counts, контрольные суммы, бизнес‑тесты.
• Наличие rollback triggers: если p99 увеличился более чем на 50% или >2% ошибок 5xx, откат/mitigation план.

Cutover должен быть автоматизирован скриптами и runbook'ом: manual steps свести к минимуму, оставить только подтверждения оператора.

Шаг 5: проверка и оптимизация

После миграции важно не останавливаться на успехе. Последующий этап — 30‑дневный период проверки производительности и оптимизации запросов. В моём случае первые улучшения дали перераспределение ресурсов: увеличение RAM на БД на 20% и пересоздание 3 индексов, что снизило p95 latency на 37%.

5.1 Мониторинг и alerting

Настройте метрики: CPU, RAM, disk IOPS, latency p50/p95/p99, репликационный lag. Использовал Yandex Monitoring + Prometheus (через Exporter) и настроил алерты: CPU > 70% в течение 5 минут, disk IOPS > 400 sustained, replication lag > 10 s.

5.2 Оптимизация запросов

Соберите slow query log и проанализируйте 20 самых дорогих запросов. В нашем проекте 5 запросов были переписаны или получили покрывающие индексы. Среднее ускорение для этих запросов — 2.5×. Ввел регулярную ревизию планов запросов раз в 30 дней.

5.3 Обслуживание и бэкапы

Настроил automated backups: ежедневный full backup и incremental каждые 6 часов с хранением full 14 дней, incremental 30 дней. Для 1.2 ТБ полный бэкап занимает ~4 часа и требует дополнительного дискового пространства +30% (то есть ≈1.6 ТБ) для snapshot.

Какие подводные камни?

На практике самые частые проблемы при миграции в Yandex Cloud — несовместимые расширения СУБД, неправильные настройки сети и неожиданные расходы на egress. Ниже — конкретные случаи и как их избежать.

Несовместимые расширения и функции

Пример: расширение postgis или custom C‑extension, которое не поддерживается в управляемом сервисе. В 2025‑2026 годах у меня был кейс, где custom C‑extension требовал перекомпиляции и сопровождения. Решение: вынести функциональность в отдельный микросервис (Go/Rust) и использовать API вместо расширения, или держать отдельный unmanaged VM в VPC для этой функции.

Сеть и DNS

Ошибка: TTL DNS был 86400 и переключение заняло 6 часов — это привело к простоям. Перед cutover уменьшите TTL до 60–300 секунд за 48 часов до операции. Также проверьте, что health check на LB правильно настроен и время ожидания health check <10 с.

Дорогостоящий egress

В примере проекта исходящий трафик 3.6 ТБ/мес стал дороже на 18% после миграции из‑за распределения загрузок по нескольким зонам. Профилактика: использовать CDN для статического контента, держать резервные копии в том же регионе и оптимизировать межзональные запросы.

Мониторинг и алерты при первом пике

После релиза первой версии в облаке поднялся p99 latency, потому что autoscaling настроен с задержкой 300 s. Настройте быстрый autoscale policy: scale up trigger = CPU 70% 60 s; scale down = CPU < 40% 600 s.

Как считать стоимость?

Точный расчёт стоимости зависит от набора ресурсов, трафика и SLA. Ниже — таблица расчёта с примерными ставками и формулами для оценки в марте 2026 года; используйте их как шаблон для собственной сметы.

6.1 Основные компоненты расходов

• Compute: vCPU × часы × цена/vCPU·час.
• RAM: часто включён в цену инстанса, уточняйте для конкретного типа.
• Block storage: GB·month и IOPS (если provisioned IOPS есть).
• Load balancer: час × ставка + входящий/исходящий трафик.
• Object Storage: GB·month + операции (PUT/GET).
• Egress: GB исходящего трафика за пределы региона.

6.2 Пример расчёта для малого production (4 vCPU × 8 инстансов, 1.5 ТБ диска, 3.6 ТБ egress)

В качестве примера использую допущения по цене на 03.2026 (примерные): vCPU = 0.03 USD/час, диск SSD = 0.10 USD/GB·month, egress = 0.08 USD/GB. Курсы валют и точные тарифы уточняйте на странице цен Yandex Cloud.

Шаги расчёта:

1. Compute: 4 vCPU × 8 инстансов = 32 vCPU. Часы в месяце = 720. Стоимость = 32 × 720 × 0.03 = 691.2 USD/мес.
2. Диск: 1.5 ТБ = 1500 GB × 0.10 = 150 USD/мес.
3. Egress: 3.6 TB = 3600 GB × 0.08 = 288 USD/мес.
4. LB и сетевые сервисы: грубо 80 USD/мес (2 LB + NAT + IP).
5. Object Storage для бэкапов: 2 ТБ долговременного хранения = 2000 GB × 0.02 = 40 USD/мес.

Итого приближённо: 691.2 + 150 + 288 + 80 + 40 = 1,249.2 USD/мес (~в диапазоне 1.1–1.4k USD в зависимости от скидок и commitment).

6.3 Экономия и оптимизация затрат

• Reserved instances / savings plans: при годовой предоплате можно снижать стоимость compute на 30–50%.
• Выбор типов дисков: для большого объёма cold data используйте Object Storage вместо SSD.
• Сжатие и дедупликация: уменьшайте размер бэкапов, настройте lifecycle правила в Object Storage (архивирование через 30 дней).

6.4 Контроль бюджета (пример alert'ов)

Настройте оповещения при достижении 50%, 75%, 90% бюджета. Используйте tag/labels для биллинга по проектам: app:payments, env:prod. Ежедневный отчет по расходам в Slack/Teams ускорит реакции на неожиданные пиковые расходы.

Частые вопросы

Как снизить downtime до менее чем 5 минут?

Чтобы добиться downtime ≤ 5 минут, используйте logical replication или binlog‑replication для непрерывной синхронизации данных, а также заранее подготовленные скрипты cutover. Последовательность: 1) обеспечить catchup подписки до lag < 5 s; 2) ввести режим readonly на исходной БД (1–2 минуты) и сделать последний commit; 3) переключить приложения на целевой endpoint и запустить health checks. Важно уменьшить TTL DNS до 60 с за 48 часов до операции и иметь готовый rollback plan. На практике у меня был cutover 11 минут — это можно сократить до 3–5 минут при полном тестировании и автоматизации runbook.

Что делать при несовместимости расширений СУБД?

Если расширение несовместимо с управляемым сервисом, есть три варианта: 1) вынести функциональность в отдельный сервис (API) и удалить расширение из БД; 2) оставить часть логики на выделенной VM в той же VPC (hybrid approach); 3) согласовать с техподдержкой Yandex Cloud custom extension через managed support (в некоторых случаях возможно). Решение зависит от критичности: если расширение отвечает за 10% логики и его легко переписать — оптимальнее рефакторинг в сервис.

Где хранить бэкапы и как часто их тестировать?

Храните ежедневные full‑бэкапы и инкрементальные на Object Storage в том же регионе, чтобы избежать egress при восстановлении. Для long‑term архивов используйте более дешёвый класс хранения с lifecycle через 30–90 дней. Тестируйте восстановление хотя бы раз в квартал: восстановление full 1.2 ТБ занимает ~3–5 часов в Managed PostgreSQL и требует дополнительных 1.6 ТБ рабочей области, поэтому нужно заранее резервировать windows и инфраструктуру восстановления.

Сколько времени занимает миграция для 1–5 ТБ данных?

Оценки на основе практики: для 1 ТБ полный план миграции (аудит, тестовая миграция, оптимизация, cutover) — 4–6 недель при команде 2 инженера + 1 DBA частичная занятость. Для 3–5 ТБ — 6–12 недель с учётом сложностей с сетевым трафиком, оптимизацией индексов и нагрузочного тестирования. Конкретные сроки зависят от пропускной способности сети и выбранной стратегии (full dump vs logical replication).

Чем автоматизировать деплой инфраструктуры?

Используйте Terraform с официальным yandex provider и храните конфигурации в git. Для CI/CD подойдёт GitLab CI или GitHub Actions. Пример: terraform plan/apply в pipeline с переменными окружения для folder_id, token и key. Автоматизация сокращает время развертывания среды на 70–90% и уменьшает вероятность ошибок ручной конфигурации.

Если нужно, подготовлю готовый Terraform‑шаблон для базовой VPC, двух подсетей, LB и Managed PostgreSQL под ваш проект — укажите объём данных, peak‑нагрузку и текущие версии ПО.