🛠️☁️ Четыре недели до миграции: как перевести распределенную систему на новую инфраструктуру без простоя

🚦🔄 От аудита до production: что происходит внутри сложной облачной миграции

Облачная миграция становится особенно сложной, когда система состоит из десятков сервисов, а бизнес не может позволить себе остановить приложение.

Международная платформа Wayo* столкнулась именно с такой задачей. Компания решила сменить инфраструктурного провайдера и одновременно перевести приложения на обновленную инженерную платформу.

На весь проект команда получила один месяц.

⏱️ При этом система должна была продолжать работать 24/7.

🎯 Две задачи вместо одной

Команда должна была одновременно:

перенести сервисы из старого Kubernetes-кластера в новое облачное окружение;
подготовить приложения к требованиям обновленной внутренней платформы.

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

Каждый сервис требовал адаптации.

🔗 Главный вызов — зависимости

Распределенная система включала множество взаимосвязанных компонентов.

Команда проверяла:

Kubernetes namespaces;
сетевые настройки;
secrets и переменные окружения;
базы данных;
Redis и KV-хранилища;
брокеры сообщений;
внутренние сервисы;
внешние API;
health checks;
мониторинг и логирование.

Особенность таких систем заключается в том, что одна зависимость может находиться совершенно в другом месте.

Приложение может успешно запуститься, но затем обнаружить, что оно не видит базу данных, не может отправить сообщение в брокер или потеряло доступ к соседнему сервису.

Поэтому миграция каждого компонента проходила как отдельная техническая проверка.

🔍 Первый этап — аудит

Evrone начала работу с анализа сервисов и окружений.

Команда для каждого приложения определяла:

1️⃣ текущую конфигурацию;

2️⃣ список зависимостей;

3️⃣ используемые хранилища;

4️⃣ сетевые подключения;

5️⃣ различия между платформами;

6️⃣ потенциальные блокеры.

Анализ превращался в конкретные задачи.

Например, один сервис требовал Redis в том же namespace. В новом окружении компонент отсутствовал. Команда выявила проблему заранее и передала требование владельцам инфраструктуры.

Такой подход позволил решать блокеры до production.

🤝 Синхронизация участников

В миграции участвовали разные специалисты: разработчики приложений, инженеры старой и новой платформ, DevOps-команда и владельцы внешних систем.

Evrone помогала соединять эти группы в едином процессе. Разработчики объясняли особенности приложений, инфраструктурные специалисты готовили окружение, а команда миграции проверяла результат.

Для аутстаф-команды здесь особенно важна скорость погружения. Специалисту необходимо быстро понять незнакомую архитектуру и при этом встроиться в уже существующие процессы.

🚀 Единый сценарий развертывания

Каждый сервис проходил одинаковый путь:

Аудит → подготовка → развертывание → проверка → переключение → наблюдение → отключение старой версии.

Перед переключением команда проверяла:

запуск приложения;
health checks;
подключения;
обмен сообщениями;
внутренние API;
критические ошибки;
пользовательские сценарии.

Старая версия продолжала работать до завершения проверки. Такой подход сохранял возможность быстрого отката.

✅ Что получилось

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

Старая инфраструктура была выведена из эксплуатации.

Главный результат заключался не только в завершении миграции в срок. Пользовательское приложение продолжало работать без остановки на протяжении всего перехода.

Этот проект хорошо показывает, что сложная миграция — это одновременно техническая и организационная задача. Архитектура, зависимости, коммуникация и контроль каждого этапа должны работать как единая система.

* Название компании и отдельные идентифицирующие детали изменены в соответствии с NDA.