Шесть версий платформы за один переход: как мы приняли и оживили большой туристический портал

В 2025 году нам передали онлайн-платформу бронирования путешествий: авиабилеты, отели, трансферы, страхование, приём платежей. Тридцать одна сборка, три тысячи файлов, пять внешних интеграций — и всё это на версии платформы, поддержку которой производитель прекратил ещё в конце 2022 года. Отдельная сложность: часть ядра системы существовала только в виде скомпилированных пакетов предыдущего разработчика, без исходников.

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

Отрасль: онлайн-бронирование путешествий

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

Год: 2025

Масштаб: 32 сборки, более трёх тысяч файлов, пять внешних интеграций

Объём изменений: затронуто около половины кодовой базы

Роль Nabla Lab: приём проекта, модернизация платформы, доработка функциональности, перенос на собственную инфраструктуру

Что нам передали

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

Система живая, продающая, с реальными клиентами. Заменить её или остановить на время переделки было нельзя.

И три проблемы, которые заказчик уже осознал.

Платформа без поддержки. Все сборки решения были собраны на версии .NET Core 3.1. Производитель прекратил её поддержку 13 декабря 2022 года. То есть систему передали нам, когда она уже больше двух лет не получала ни исправлений безопасности, ни совместимости с новым окружением.

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

Следы прежнего подрядчика. В подвале сайта стоял его водяной знак, а рядом — ссылки на сервисы, работа с которыми в России ограничена.

Почему обновление платформы — это не строчка в конфигурации

Со стороны задача «обновить .NET Core 3.1 до девятой версии» выглядит как правка одного значения в файле проекта. На практике это шесть мажорных версий подряд, и на каждой производитель что-то менял: удалял устаревшие интерфейсы, менял поведение по умолчанию, переносил функциональность между пакетами, ужесточал правила.

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

Итог: затронуто около половины кодовой базы. Почти тысяча триста файлов изменена, больше сотни добавлено. Это и есть честный ответ на вопрос, сколько стоит перепрыгнуть через шесть версий: не «поменяли строчку», а прошли систему насквозь.

Главное ограничение: бинарники, которые нельзя тронуть

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

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

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

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

Свой слой общих механизмов

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

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

Оптимизация по данным, а не на глаз

Отдельным пунктом задачи стояло ускорение модуля отелей.

Первое, что мы сделали, — встроили в систему профилировщик. До этого разговор о скорости шёл в терминах «кажется, стало быстрее». Профилировщик показывает, сколько времени занимает каждый запрос к базе и каждый участок обработки, — и дальше становится видно, что чинить.

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

Оптимизация без измерений — это ремонт наугад. Сначала измерительный прибор, потом ремонт.

Переезд на свои серверы

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

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

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

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

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

Отдельный эффект — за приложение и за инфраструктуру под ним отвечает одна команда. Когда что-то работает медленно, никто не выясняет, виноват разработчик или администратор.

Доработки по задачам заказчика

Параллельно с модернизацией шла работа по списку заказчика.

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

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

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

Обновление всей внешней обвязки: библиотеки, клиенты, инструменты логирования и тестирования приведены к актуальным версиям.

Что получил заказчик

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

Почему это важно для вас

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

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

Расскажите, что у вас за система и в каком она состоянии, — посмотрим, что с ней делать.