Модернизация legacy-платформы: как ускорили систему в 50+ раз и перестроили интеграции

Заказчик — онлайн-платформа-агрегатор, на которой представлены инвестиционные проекты, консалтинговые услуги, компании из сфер торговли драгоценными металлами и недвижимости. Один из ключевых активов платформы — продуктовый реестр, агрегирующий данные из множества внешних источников.

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

АЙТИФОКС принял на поддержку и развитие legacy-платформу после двух команд разработки. Мы переработали критические запросы к базе данных и API, перестроили архитектуру интеграций и сократили загрузку ключевых страниц с 20–60 секунд до 200–500 миллисекунд.

Проблема — legacy-проект находился в критическом состоянии. Из-за архитектуры запросов страницы реестра загружались по 20–60 секунд. В проекте не было тестового контура, полноценного мониторинга ошибок и логирования, деплой выполнялся вручную. Интеграции с внешними системами работали нестабильно: часть данных не передавалась, а отдельные заявки терялись. Документации по архитектуре не было.

Организационная специфика: продукт работает в сегменте B2B с высокими регуляторными требованиями. Заказчик установил жёсткую двухнедельную отчётность с сдачей по строгим шаблонам. Каждый спринт включал протокол испытаний с тест-кейсами и детальный отчёт со скриншотами каждого изменения в коде. Задачи требовали предварительной оценки, зачастую «вслепую», и согласования на уровне высшего руководства.

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

Результат — время загрузки страниц сократилось с десятков секунд до 200–500 миллисекунд. Продукт стабильно прошёл ключевое мероприятие. За два года мы превратились из «пожарной команды» в доверенного долгосрочного партнёра, с которым заказчик продолжает работать. Вся отчётность теперь формируется по утверждённым шаблонам без переделок.

Подробнее о ходе работ и технических деталях — ниже.

Заказчик пришёл к нам с проектом реестра, который предыдущие подрядчики уже дважды пытались реанимировать, но безуспешно. Задача АЙТИФОКС заключалась не в разработке системы с нуля, а в модернизации существующего legacy-продукта без остановки его работы.

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

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

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

Мы не начали писать код сразу. Сначала нужно было понять, где корень проблемы и можно ли с этим вообще работать.

Первые две недели ушли на полный ресёрч. Картина оказалась следующей:

Неоптимальные запросы к БД и медленный поиск. Аудит показал, что универсальный шаблон роутов загружал значительно больше связанных данных, чем требовалось фронтенду. Например, для отображения карточки компании система дополнительно запрашивала данные команды, пользовательские аккаунты, историю сделок и связанные контракты. Elasticsearch также использовался неоптимально и добавлял к загрузке более 5 секунд. В результате ключевые страницы загружались по 20–60 секунд.

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

Инфраструктурный вакуум. Отсутствовал тестовый контур. Деплой на все среды, кроме одной, производился вручную. Не было Sentry или любого другого мониторинга ошибок. Grafana, внедрённая в проект, использовалась не для мониторинга, а для отрисовки 6 некрасивых графиков в разделе аналитики. Линтеры и чекеры кода не применялись вовсе.

Параллельный трек — подготовка к проектно-образовательному интенсиву. Одновременно с разбором завалов нам поставили задачу: за полтора месяца создать новую аналитику для презентации на ключевом мероприятии. Старая «аналитика» была теми самыми 6 графиками Grafana, которые не годились для презентации.

Это был кризисный момент. Мы не могли ни отказаться от мероприятия, ни отложить стабилизацию.

Мы действовали по двум направлениям:

• «Костылили» критичные места. Внедрили кэширование страниц, чтобы снизить нагрузку и «заморозить» проблему медленной загрузки до лучших времён. Это не решало проблему архитектурно, но дало пользователям приемлемый опыт.
• Форсировали новый функционал. Разработали и презентовали новую аналитическую панель на интенсиве, несмотря на сжатые сроки и нестабильную основу. В этот период команда работала овертайм, но это была краткая и разовая история — не системная практика.

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

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

После острой фазы мы приступили к плановому «ремонту», который занял около года.

Оптимизация API и запросов к базе данных. АЙТИФОКС переписал критические запросы в новой версии API (v2) с использованием паттерна «сервис — репозиторий». Теперь каждый роут запрашивал только данные, необходимые фронтенду. В результате время загрузки ключевых страниц сократилось с 20–60 секунд до 200–500 миллисекунд — более чем в 50 раз.

Оптимизация поиска. Для пользовательского поиска АЙТИФОКС заменил Elasticsearch на полнотекстовый поиск PostgreSQL. Это позволило убрать дополнительную задержку более 5 секунд и упростить архитектуру. Elasticsearch сохранили в административном контуре, где его использование оставалось оправданным.

Интеграции через Kafka. АЙТИФОКС внедрил шину данных на базе Kafka для централизованного обмена с внешними системами. Отправка данных, запрос статусов и получение ИИ-описаний проходят через единый контролируемый контур. Система сохраняет сообщения, статусы и ошибки, благодаря чему внешние интеграции стали прозрачными и отслеживаемыми.

Интеграция CRM, SOAP/REST API и внешних систем:

• Ключевая система обмена данными. Полностью переписали формирование файлов для SOAP и REST API. Внедрили предобработку данных: исключение запрещённых символов, валидацию по справочникам сервиса. Настроили полный цикл обмена. Все процессы замкнули на шину данных и тестовые контуры.
• CRM-система. Наладили полный цикл: отправка заявки, отслеживание статуса, получение данных и их валидация. Обработали нестабильность API (сервер мог вернуть 500 ошибку, но данные при этом записать — мы реализовали обработку таких коллизий).
• Внешние шины проектов. Там, где возможно, перевели получение данных с периодического опроса API на чтение очередей Kafka. Это дало гарантию доставки и снизило нагрузку.

Выстраивание процессов разработки:

• Подняли нормальный тестовый контур и «связали» его с тестовыми средами внешних систем.
• Внедрили Sentry и логирование — впервые появилась прозрачность по ошибкам.
• Настроили автоматический деплой и внедрили использование alembic для версионирования миграций БД.

Решили вопрос с отчётностью: после многократных переделок (до 5 раз на один документ) мы изучили все нормативные требования и создали собственные шаблоны, которые утвердили у заказчика. Это сняло проблему «придирок к запятым» раз и навсегда.

После стабилизации архитектуры и ускорения ключевых страниц АЙТИФОКС перешёл к развитию интеллектуального поиска на основной платформе заказчика. Требовалось научить систему понимать сложные профессиональные запросы — от поиска стартапов по технологиям до анализа объектов недвижимости по доходности.

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

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

Архитектура RAG-поиска и подготовка данных:

• Разработали собственный скрапер, который обошёл сайты компаний и автоматически собрал актуальные данные по 98 000 профилей
• Выстроили многоуровневую очистку: удалили дубли через TF-IDF, отфильтровали технический мусор, унифицировали структуру анкет
• Перевели очищенные данные в векторное представление с помощью YandexGPT PRO и сохранили в ChromaDB
• Внедрили интеллектуальный поиск на базе RAG (Retrieval-Augmented Generation), при котором модель ищет ответ не в своей «памяти», а в актуальных данных платформы

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

В результате внедрения RAG-поиска АЙТИФОКС снизил долю отказов на платформе на 24%, а конверсия выросла на 18%. Поиск начал учитывать контекст профессиональных инвестиционных запросов и формировать ответы на основе очищенных данных по 98 000 профилей.

Подробнее об этом — в кейсе: Очистили 98 000 «шумных» профилей и внедрили ИИ-поиск, который понимает инвестиционные запросы.

АЙТИФОКС принял legacy-проект с загрузкой страниц по 20–60 секунд, нестабильными интеграциями и отсутствием полноценного тестового контура. После модернизации критические страницы стали загружаться за 200–500 миллисекунд — более чем в 50 раз быстрее.

Команда переработала API и запросы к БД, внедрила шину данных на Kafka, восстановила обмен с внешними системами, настроила тестовый контур, мониторинг и автоматический деплой.

После стабилизации платформы АЙТИФОКС внедрил RAG-поиск по очищенным данным 98 000 профилей. Доля отказов снизилась на 24%, а конверсия выросла на 18%.