Миграция затягивается месяцами: как переехать в Yandex Cloud без риска

Миграцию в Yandex Cloud анонсировали на «шесть недель». Через четыре месяца всё ещё «почти готово»: часть сервисов в облаке, часть на своих серверах, DNS переключали дважды, откат не прописан, бизнес уже не верит срокам.

Так бывает не потому, что облако «сложное». Так бывает, когда перенос начинают с виртуалок, а не с карты зависимостей, окон простоя и критерия «готово». Без откат каждый шаг — ставка на удачу.

Для компании цена не в строке счёта облака. Цена — в затянутой неопределённости: двойная инфраструктура, усталые люди, риск остановить продажи в неудачное окно.

Как растягивается типичный перенос

Сначала переносят «простой» сервер — и празднуют. Потом выясняется, что он ходит в лицензионный ключ на старом железе, в локальную 1С и в VPN, который никто не описал. Каждый новый сервис открывает ещё три скрытые связи.

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

Окно простоя назначают на ночь без репетиции. Утром откатываться некуда: бэкап не проверяли, TTL DNS не уменьшали заранее, команду поддержки не предупредили.

Ошибки, которые гарантируют месяцы

Начинать с выбора тарифов и красивых схем VPC вместо инвентаризации приложений и интеграций.

Считать миграцию «переездом VM as is» без вопроса, что можно выключить, упростить или заменить managed-сервисом.

Не фиксировать откат: что делаем, если после переключения заказы не создаются. Без этого команда боится переключать и тянет «ещё неделю тестов» бесконечно.

Делать всё большим взрывом. Чем больше сервисов в одном окне, тем выше шанс, что один хвост отложит весь релиз.

Рабочий каркас миграции

Сначала карта: приложения, данные, интеграции, лицензии, время восстановления и допустимая потеря данных, владельцы. Без владельца бизнес-процесса миграция становится IT спектаклем.

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

Для каждого переключение письменно:

• что переключаем и в каком порядке;
• как проверяем успех за 15–30 минут (бизнес проверки, не только ping);
• как откатываемся и за сколько;
• кто принимает решение «едем / назад».

DNS, сертификаты, секреты и CI переносят по чеклисту, а не «вспомним по ходу». TTL уменьшают заранее. Секреты не копируют в заявки.

Как вернуть сроки под контроль

Если проект уже вязнет, остановите расползание объём работ. Зафиксируйте текущий список волн и заморозьте «заодно перепишем». Разведите прод и эксперименты.

Проведите одну короткую репетицию переключения на некритичном сервисе — это быстро вскрывает дыры в документации и правах. Дальше критичные волны идут уже не вслепую.

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

Критерии «готово» для каждой волны

Пока критерий готовности звучит как «вроде работает», миграция не закончится. Для волны заранее запишите бизнес проверки: создаётся заказ, проходит оплата, открывается отчёт, входит сотрудник. Технические ping и SSH — необходимые, но недостаточные условия.

Сделайте репетицию на копии или на низкорисковом сервисе с полным прогоном переключения и отката. Именно репетиция вскрывает отсутствующие права, забытые DNS записи и секреты в старых конфигах.

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

Ведите единый журнал рисков и решений. Когда через два месяца спросят, почему перенесли базу так, а не иначе, ответ должен быть в журнале, а не в чате, который никто не найдёт.

Люди и окна простоя

Миграция буксует не только из-за техники. Нужны согласованные окна с бизнесом, дежурство поддержки и понятный канал статуса для сотрудников. Если отделы узнают о переключение из жалоб клиентов, доверие к проекту падает.

Назначьте роли на окно: кто переключает, кто проверяет бизнес сценарии, кто принимает решение об откате, кто пишет статус. Без ролей все «немного помогают» и никто не решает.

Уменьшите TTL DNS заранее, подготовьте сертификаты и секреты, проверьте, что мониторинг нового контура уже пишет метрики. Переключение вслепую без наблюдаемости — лотерея.

После успешной волны сделайте короткую ретроспективу и обновите шаблон следующей. Так месяцы сжатия хаоса превращаются в повторяемый процесс.

Отдельный тормоз — лицензии и привязки. ПО, которое «просто работало» на своих серверах, в облаке вдруг требует другого типа лицензирования, других IP или доступа к ключу на старом железе. Эти проверки нужны до волны, а не в ночь переключение.

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

Если проект уже в красной зоне по срокам, сократите объём работ до минимально ценного результата: один критичный сервис в облаке end-to-end с откатом. Лучше один завершённый контур, чем десять полуперенесённых.

И главное — публикуйте следующую дату волны только вместе с готовым откат. Дата без отката почти всегда сдвигается и сжигает доверие бизнеса.

Если команда устала от бесконечного «ещё неделя», смените метрику успеха: не процент перенесённых машин, а число волн, закрытых с проверкой и откатом. Так миграция снова становится управляемой.

Итог

Миграция тянется месяцами там, где нет карты зависимостей, волн и плана отката. Облако тут ни при чём — ломается управление переносом.

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