Подготовка международного сервиса перевозок к миграции на новую облачную инфраструктуру без простоя

1. Вводная задача от заказчика, проблематика, цели

Wayo* — международная технологическая платформа, которая объединяет пользователей и исполнителей услуг в сфере пассажирских и грузовых перевозок. В основе пользовательского приложения работает распределенная система из десятков взаимосвязанных сервисов. Эти сервисы используют базы данных, брокеры сообщений, KV-хранилища, внутренние и внешние API и другие инфраструктурные компоненты.

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

Перед командой Evrone стояли две основные задачи:

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

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

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

Аутсорсинг

Python

Java

2. Описание реализации кейса и творческого пути по поиску оптимального решения

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

Для каждого приложения мы изучили:

• текущую конфигурацию;
• внутренние и внешние зависимости;
• базы данных и другие хранилища;
• Redis и KV-компоненты;
• брокеры сообщений и шины;
• требования к namespaces;
• сетевые подключения и правила доступа;
• параметры запуска в Kubernetes;
• readiness- и liveness-проверки;
• различия между старой и новой инженерными платформами;
• потенциальные блокеры для production-развертывания.

Аудит позволил заранее выявить зависимости, которые не всегда были очевидны из исходной конфигурации. Например, один из сервисов требовал Redis в том же namespace, однако в новом окружении соответствующего компонента не было. Evrone зафиксировала эту инфраструктурную потребность, передала требование команде платформы и проконтролировала подготовку окружения до выхода сервиса в production.

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

Чтобы ускорить миграцию и одновременно сохранить контроль над качеством, Evrone выстроила единый последовательный процесс для всех компонентов. Каждый сервис проходил одинаковый путь — от анализа зависимостей и адаптации конфигурации до развертывания и переключения production-трафика.

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

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

• стабильный запуск приложения;
• корректное прохождение health checks;
• доступность сервиса внутри Kubernetes-кластера;
• соединения с базами данных и хранилищами;
• корректную отправку и получение сообщений;
• доступность внутренних и внешних API;
• отсутствие критических ошибок в логах;
• выполнение основных пользовательских сценариев;
• готовность приложения принимать production-трафик;
• сохранение старой версии для возможного отката.

Каждое production-развертывание Evrone проводила совместно с ответственными инженерами. Во время запуска мы контролировали состояние Kubernetes-ресурсов, анализировали логи, проверяли подключения к зависимостям и наблюдали за ключевыми пользовательскими сценариями.

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

Для минимизации рисков Evrone использовала поэтапное переключение. Новая версия сервиса сначала запускалась в новом окружении и проходила техническую проверку, а старая версия продолжала работать. Только после подтверждения готовности production-трафик направлялся на новое приложение.

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

QA

Backend

Ruby

3. Результаты сотрудничества

За четыре недели Evrone помогла заказчику завершить весь запланированный объем миграции.

В результате:

• все сервисы из миграционного backlog были переведены на обновленную инженерную платформу;
• распределенная система была развернута в новом облачном окружении;
• старая инфраструктурная платформа была выведена из эксплуатации;
• все ключевые зависимости были проверены в новом окружении;
• production-сервисы переключались последовательно и контролируемо;
• возможность быстрого отката сохранялась до подтверждения стабильности новой версии;
• пользовательское приложение продолжало работать без остановки на протяжении всего процесса миграции.

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

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

Разработка облачных сервисов

Цифровая трансформация

DevOps