Миграция в облако: этапы и подход

Миграция в облако (cloud migration) — это перенос ИТ-сервисов компании с собственных серверов на арендованную облачную инфраструктуру. Под «сервисами» понимаются базы данных, учётные системы, файловые хранилища, почта, веб-приложения и всё остальное, что раньше работало на железе в серверной. Цель миграции — не «уйти в облако ради облака», а получить нужный уровень гибкости, доступности и стоимости.

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

Зачем компании мигрируют в облако

Типичные причины — устаревшее железо, которое пора менять (а закупка нового — это крупная разовая трата), неровная нагрузка с сезонными пиками, потребность в быстром масштабировании, отсутствие подходящей серверной или желание не содержать её. Иногда триггером становится переезд офиса или уход прежнего поставщика оборудования.

Важно: облако выгодно не всем и не всегда. Прежде чем мигрировать, стоит честно сравнить модели — своя серверная, облако и гибрид — по деньгам и рискам. Это сравнение мы разбираем в материале «Своя серверная или облако: что выгоднее среднему бизнесу». Миграция оправдана, только когда облако реально решает задачу компании, а не просто «модно».

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

Первый и самый недооценённый этап. Нельзя перенести то, чего не описал. На аудите фиксируется:

• полный список сервисов, серверов и приложений, их версии и зависимости;
• реальная нагрузка — процессор, память, диск, сеть в пиках и в среднем (а не «по ощущениям»);
• объёмы данных и скорость их роста;
• связи между системами — кто с кем общается, что нельзя разрывать;
• требования по безопасности и локализации данных;
• текущие RPO и RTO — сколько данных и времени допустимо потерять при сбое.

Результат аудита — карта инфраструктуры, на основе которой принимаются все дальнейшие решения. Без неё миграция идёт вслепую.

Этап 2. Выбор модели и площадки

На этом этапе решается, что и куда переносить. Сначала выбирается уровень облачной услуги — арендуете ли вы «голые» виртуальные машины, готовую платформу или готовый сервис. Разницу между этими уровнями разбираем в статье про IaaS, PaaS и SaaS.

Затем выбирается стратегия переноса для каждого сервиса:

• «Как есть» (lift-and-shift) — переносим виртуальную машину в облако без переделок. Быстро, но не использует преимущества облака.
• С доработкой — адаптируем приложение под облачные сервисы (управляемые базы данных, объектное хранилище). Дольше, но эффективнее в эксплуатации.
• Замена — отказываемся от своего сервиса в пользу готового облачного (например, почта вместо своего почтового сервера).

Для российских компаний отдельный вопрос — выбор площадки с учётом требований к локализации данных; обзор отечественных провайдеров есть в статье про российские облака. Если в основе инфраструктуры лежит виртуализация, важно учитывать совместимость гипервизора — см. вики про VMware vSphere.

Этап 3. Подготовка целевой среды

В выбранном облаке разворачивается «принимающая» инфраструктура: виртуальные сети, сегментация, виртуальные машины или управляемые сервисы, права доступа, шифрование, мониторинг. Параллельно настраивается канал переноса данных и проверяется связность между текущей площадкой и облаком.

Здесь же закладывается резервирование под нужные RPO и RTO — нельзя переносить сервис в облако и забывать про резервные копии и аварийное восстановление. Что означают эти метрики и как под них проектируют резерв — в вики про RPO и RTO.

Этап 4. Перенос данных и сервисов

Сначала переносят данные, затем переключают сервисы. Типовая последовательность:

• Предварительная синхронизация. Большой объём данных копируется заранее, пока старая система продолжает работать.
• Дельта-синхронизация. Перед переключением догоняются изменения, накопившиеся с момента первой копии, — чтобы окно простоя было минимальным.
• Переключение (cutover). В согласованное окно (обычно ночь или выходной) сервисы останавливают на старой площадке, синхронизируют последнюю дельту и поднимают в облаке.
• Перенаправление трафика. DNS и маршруты переводятся на облако.

Ключевое правило этапа — старая площадка не выключается сразу. Она остаётся как путь отката, пока облако не подтвердит стабильную работу.

Этап 5. Тестирование и приёмка

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

Риски миграции и как их закрыть

• Простой при переключении. Закрывается предварительной и дельта-синхронизацией плюс выбором окна в нерабочее время. Полностью нулевой простой возможен не всегда, но его сводят к минутам.
• Потеря данных. Закрывается проверенными резервными копиями до начала миграции и сохранением старой площадки как точки отката.
• Несовместимость приложений. Выявляется на аудите и в тестовой среде до боевого переключения, а не во время него.
• Рост счёта в облаке. Закрывается правильным выбором модели под реальную нагрузку и контролем «забытых» включённых ресурсов.
• Проблемы с доступом и безопасностью. Закрываются настройкой прав, шифрования и сегментации на этапе подготовки среды, а не «потом».

Связанные термины

• [[iaas-paas-saas]] — модели облачных услуг, между которыми выбирают при миграции
• [[russian-clouds]] — отечественные облачные площадки
• [[vmware-vsphere]] — виртуализация, совместимость которой важна при переносе
• [[rpo-rto]] — метрики допустимой потери данных и времени восстановления

Чем помогает Кибер Авангард

Мы не облако и не продаём аренду мощностей. Кибер Авангард — IT-аутсорсер и NOC 24/7, который ведёт миграцию под ключ: проводит аудит, честно сравнивает модели, проектирует целевую среду, переносит данные и сервисы с минимальным простоем и затем обслуживает инфраструктуру в облаке круглосуточно. Если миграция не нужна — мы об этом прямо скажем.