Перенос рабочих приложений в облако пугает заказчиков одним словом – простой. Биллинг, ЕРП, портал госуслуг не имеют права молчать ни ночью, ни в выходные. Но остановка бизнеса – не плата за миграцию, а следствие плохого плана. Ниже мы разбираем, как переносить системы поэтапно, сохраняя их доступность на всём пути.

Сначала инвентаризация, потом переезд

Миграция начинается не с виртуальных машин, а со списка. Мы описываем каждое приложение: как оно хранит данные, с чем интегрируется, какие у него требования к задержкам и какой объём трафика оно генерирует. Приложения без сложных связей переезжают первыми – они дают команде опыт и быстрый результат. Системы с десятками интеграций откладываем на потом.

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

Для госсектора отдельно фиксируем требования к персональным данным по 152-ФЗ: какие системы их обрабатывают и могут ли они вообще покинуть периметр заказчика. Это определяет архитектуру переезда сильнее, чем технические ограничения.

Гибридная схема и параллельная работа

Резкое переключение «всё разом» – главный источник простоя. Мы избегаем его за счёт гибридной модели: часть нагрузки уже работает в облаке, часть – на площадке заказчика, и обе видят общие данные. Такой подход мы описывали в статье про гибридное облако – он позволяет переключать пользователей постепенно, группами.

Данные переносим заранее и держим синхронизацию между старой и новой средой. Сначала идёт полная репликация базы, затем – непрерывное копирование изменений. К моменту переключения новая копия отстаёт от рабочей на секунды. Само переключение – это смена записи в DNS или маршрута на балансировщике, а не многочасовая остановка.

Под каждое приложение мы заранее готовим окно отката. Если после переключения нагрузка повела себя не так, как на тестах, трафик возвращается на исходную площадку за минуты – старая среда продолжает работать, пока мы не убедимся в стабильности новой.

Где разворачивать нагрузку

Выбор площадки зависит от профиля приложения. Системы с предсказуемой нагрузкой выгоднее держать на постоянных мощностях, а вычисления с пиками – на средах с почасовой тарификацией вроде недавно анонсированной Google Compute Engine. Для данных, ограниченных требованиями регулятора, мы оставляем приватный сегмент в России. Чаще всего итог – комбинация из нескольких площадок, а не один поставщик.

Полный цикл такой миграции – от аудита ландшафта до сопровождения приложений в облаке – держится на фиксации метрик доступности на каждом шаге.

Вывод

Миграция без простоя – это дисциплина, а не везение. Инвентаризация связей, развязка интеграций, синхронизация данных до переключения и готовый откат снимают риск остановки. Переезжайте поэтапно, по одному приложению, и бизнес даже не заметит, что инфраструктура сменила адрес.