Готовим сервис перевозок к переходу на новую инфраструктуру

О клиенте

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

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

Задача: сменить облачного провайдера за один месяц

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

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

При этом остановить приложение на время переезда было нельзя. Пользователи должны были продолжать оформлять поездки и пользоваться другими возможностями сервиса без перерывов.

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

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

Эта платформа автоматизирует доставку кода, создание окружений и развертывание приложений в Kubernetes. Поэтому было недостаточно просто скопировать существующие настройки: каждый сервис требовалось адаптировать к новому способу запуска и новым требованиям инфраструктуры.

Проект в цифрах

Вызов: масштаб зависимостей

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

Каждый сервис имел собственный набор конфигураций и зависимостей:

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

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

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

С чего начали: провели аудит сервисов

На старте Evrone получила backlog сервисов и доступ к старой и новой версиям инженерной платформы.

Наша команда изучила окружения, принципы развертывания и требования новой инфраструктуры. Для каждого сервиса мы анализировали:

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

Результаты анализа превращались в конкретные задачи для разработчиков и инфраструктурной команды.

Например, один из сервисов зависел от Redis, который должен был находиться в том же namespace. В новой инфраструктуре необходимого компонента не было. Мы зафиксировали требование, передали его команде платформы и проконтролировали подготовку нужного окружения до production-развертывания.

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

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

Синхронизировали продуктовые и инфраструктурные команды

Миграция затрагивала не только DevOps-инженеров. Для каждого сервиса требовалось объединить знания нескольких сторон:

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

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

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

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

Егор Репьев CCO Evrone

Выстроили последовательный процесс миграции

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

Такой процесс помогал контролировать общий прогресс и не пропускать важные проверки даже при жестком графике.

Определили критерии готовности к переключению

Сервис переводился на новую платформу только после технической проверки.

Команда убеждалась, что:

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

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

Проводили каждое развертывание вместе с ответственными инженерами

Развертывание  на прод проходило в рамках совместных сессий со всеми заинтересованными специалистами.

Во время запуска команда:

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

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

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

Переключали сервисы без простоя для пользователей

Для обеспечения нулевого простоя старые и новые версии сервисов некоторое время существовали параллельно.

Сначала приложение разворачивалось в новом окружении. Команда проверяла его состояние, логи, подключения и основные сценарии. Только после подтверждения готовности трафик направлялся на новое приложение.

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

После периода наблюдения старый сервис отключался.

Для пользователей переход оставался незаметным: приложение продолжало работать 24/7 на протяжении всей миграции.

Результат: вся система переехала в установленный срок

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

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

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

Нужна помощь с миграцией инфраструктуры?

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

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

Свяжитесь с нами, чтобы обсудить миграцию вашего проекта.

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