В последнее время слово «инженер» мало употребляется в IT-индустрии. Есть программист, разработчик ПО, техлид, архитектор. Но одно только знание технологий не дает гарантии, что человек хорошо выполнит бизнес-задачу. Инженерное мышление — это особый дар, который позволяет решить сложную, возможно, даже ранее не решенную проблему с использованием существующих технологий.
Проведу параллель с автоиндустрией. Довольно долгое время привод у автомобилей был только на одно колесо, так как не было механизма, позволявшего ведущим колесам на одной оси вращаться с разной угловой скоростью при поворотах. Были развитые технологии металлообработки и специалисты, способные изготавливать шестерни, валы и прочее. Но задача не решилась, пока инженеры не изобрели дифференциал.
Задача
Представьте, что вас попросили заменить большую ERP-систему с кучей модулей на новую при следующий условиях:
Нельзя останавливать ERP-систему, так как она критична для непрерывности бизнеса заказчика. То есть днем и ночью, в праздники и будни, система должна функционировать.
В системе много функциональности, но документация практически отсутствует.
Нет исходников.
Старые технологии (двухслойка на нереляционной БД Btrieve).
Менять схему легаси-БД нельзя.
Все расчеты, которые делает старая система, новая должна повторить точь-в-точь (напоминаю, что нет ни исходников, ни документации).
Довольно высокая update activity на легаси-БД (150 inserts 300 updates per second).
В статье речь пойдет именно о таком проекте и об инженерном подходе к его решению.
О проекте
Крупная британская такси-компания решила заменить устаревшую ERP-систему на современную, написанную под собственные требования. Было дано 3 недели на экспресс-анализ и 3 недели на написание КП. Уже на этапе экспресс-анализа стало понятно, что потребуются героические усилия, но мы решили взять проект.
Была собрана сильная команда спецов, и мы бросились в бой. Кто-то анализировал старую систему и писал функциональные требования к новой, кто-то думал над архитектурой и выбором технологий. Но был самый неприятный вопрос: как поменять старую систему на новую без остановки?
Вот с какими вызовами мы столкнулись при разработке и как их решили в итоге с помощью инженерного подхода.
Вызов 1: Сложность и режим 24/7. Нельзя было позволить бизнесу остановиться ни на секунду
Любая ошибка парализовала бы диспетчеризацию тысяч машин. Классический «Большой взрыв» с полным переходом c одной системы на другую в один день был неприемлем. Мы не могли рисковать неделями простоя и мучительными обратными миграциями данных.
Решение: замена ERP методом Parallel Running
Реализовали архитектуру, где новая и старая системы работали параллельно на логически едином наборе данных. Для этого мы с нуля разработали сервис синхронизации xDbStream, который в реальном времени реплицировал данные между двумя абсолютно разными БД (наша новая Sybase и их старая Btrieve). Это дало:
Безопасность: Если операция (например создание заказа) неправильно исполнялась в новой системе, её всегда можно было выполнить в старой. Бизнес-процессы не прерывались.
Итеративность: Мы выводили модули в прод по мере готовности, а не ждали финальной точки годами.
Снижение стресса: У команды и заказчика всегда был «план Б».
Архитектура Parallel running
Ключевым компонентом является сервер репликации, который выполняет однонаправленную отложенную репликацию. Логика работы следующая:
Если данные изменяются через интерфейс легаси-системы, то репликация их находит и накатывает изменения на новую БД.
Если изменения инициируются в новой системе, то через шлюз вначале меняется легаси-БД, после чего данные пишутся в новую БД.
Важно понимать, что, когда мы делали проект, не было готового решения по репликации между БД Btrieve и Sybase, да и сейчас, скорее всего, его нет. Если это не так, напишите в комментариях. Часто в таких случаях архитектор говорит: «Посмотрел на продукты для репликации, ничего не нашел». Звучит как тупик и невозможность реализовать красивую задумку. Вот тут-то как раз и выходит на сцену инженер, который придумает алгорит�� и реализует его с использованием существующих технологий (помните историю про дифференциал для автомобилей?).
Нам предстояла нетривиальная задача — быстро находить изменения и накатывать их на новую БД при следующих ограничениях:
Менять структуру легаси-БД нельзя
Таблицы в легаси-БД довольно большие — порядка 10 млн записей
Довольно высокая update activity на легаси-БД (150 inserts 300 updates per second)
Схемы легаси-БД и новой сильно отличаются, например, текстовое поле 1000 символов из легаси-БД «распадется» на 23 таблицы в новой БД
Система должна иметь возможность гарантированно приводить базы данных в консистентное состояние при любых сбоях.
В цели этой статьи не входит полное описание алгоритма работы сервера репликации, поэтому скажу кратко: основная проблема была в том, чтобы реализовать быстрый и надежный способ поиска изменений в легаси-БД (так называемый CDC). После недолгих изысканий решили применить подход сверки образов как самый надежный и универсальный.
Выделили на репликацию отдельную команду, и ребята смогли за полгода написать движок репликации и настроить его для всех таблиц легаси-БД.
Вызов 2: Огромное количество функциональности. 600+ экранов, которые нужно было понять и перенести
Подготовка гигантского ТЗ, на 100% описывающего функциональность старой системы, была mission impossible. Это привело бы к многолетнему циклу разработки и гарантированно устаревшему результату.
Решение: Фреймворк GEAR
Чтобы снизить трудозатраты на написание шаблонных задач, было решено разработать общий фреймворк и сделать все на его базе. Назвали фреймворк GEAR, в его основе использовали стандартные на то время технологии Java.
Фреймворк обеспечил единообразную генерацию пользовательского интерфейса по модели данных, data-aware компоненты, централизованный контроль доступа. Все это позволило в итоге реализовать множество экранов в приемлемый срок, и обеспечить пользователям консистентный опыт, а нам – возможность широко вовлекать джунов в проект. В результате получилась вот такая архитектура:
Фреймворк GEAR позволил обеспечить:
Скорость: Резко сократить время разработки каждого из сотен экранов.
Консистентность: Обеспечить пользователям единообразный опыт.
Масштабируемость команды: К разработке можно было подключать джунов, не боясь, что они нарушат архитектуру — фреймворк сам задавал правильные паттерны.
Вызов 3: Как извлечь пользу из новых качественных данных?
В результате проекта данные стали консистентными и чистыми. Но сами по себе они не приносят ценность. Встал вопрос: какую «сверхзадачу» решить?
Решение: «Auto Allocator» — система интеллектуального планирования
Стоит пояснить, что в отличие от такси-агрегаторов, компания полностью контролирует свой парк, поэтому эффективная диспетчеризация дает огромный прирост финансовых результатов. Именно поэтому уделялось пристальное внимание эффективности распределения нагрузки на автопарк и модулю Auto Allocator.
Задача этого модуля — в автоматическом режиме назначать водителей на заказы, оптимизируя множество критериев, таких как:
Выполнение SLA, учитывая разные уровни заказчиков и типы заказов (срочный и ко времени)
Снижение пустого пробега машин
Справедливость распределения заказов среди водителей
Мы использовали различные алгоритмы оптимизации, а также эвристики и метаэвристики. Получилось очень красивое решение, которое развивалось дальше, добавлялось еще больше фич, таких как Early Promising и Driver Swarm Management. Как результат — 99.5% автоматически распределяемых заказов, повышение эффективности автопарка на 5%, что было эквивалентно 100–200 «бесплатных» водителей, то есть миллионы фунтов в год. И да, новый алгоритм также работал какое-то время параллельно со старым.
Early Promising
Технология Early Promising базируется на идее построения оптимизированного распределения водителей по заказам, включая частично введенные и еще не подтвержденные заказы. То есть пока клиент еще только вводит детали заказа, система уже подбирает ему конкретного водителя и сообщает точное время прибытия. Результат — существенное увеличение уровня удовлетворенности клиентов.
Driver Swarm Management
Нам была поставлена задача подачи машин бизнес-класса на срочные заказы премиальных корпоративных клиентов в течение 15 минут. Машин бизнес-класса в парке такси-компании было порядка 200, что для Лондона мало, поэтому обеспечить гарантированную подачу машины в течение 15 минут очень сложно.
Проанализировав данные, выявили места и время всплеска заказов на такие машины.
Но просто подгонять машины в места вероятного появления заказа оказалось нельзя по следующим причинам:
В таких местах обычно негде парковаться (например, Лондон Сити).
Водители находятся на сдельной оплате труда и их демотивирует принуждение к перегону пустой машины в другую локацию и бесплатное ожидание.
Для решения этой задачи разработали механизм с кодовым названием Driver Swarm management. Его суть в том, что у пользователей системы появилась возможность создавать так называемые «hot spot», проще говоря, указывать, сколько машин бизнес-класса надо собрать, в какой точке и к какому времени. Также система умеет определять такие точки автоматически на основе анализа предзаказов и исторических данных. Далее система назначала машины бизнес-класса на простые заказы, если требовалось ехать в нужную локацию к нужному времени. То есть клиент заказал машину экономкласса, но так как он едет в точку, где нам сейчас нужны машины бизнес-класса, мы отдаем этот заказ водителю мерседеса. Клиент получил service upgrade, а машина бизнес-класса сама подъехала туда, куда надо такси-компании.
Снижение рисков благодаря Parallel Running
Примером успешности использования подхода Parallel Running можно считать замену модулей расчета стоимости поездки и зарплаты водителей. Этот процесс занял самое долгое время, так как требовалось полностью повторить логику расчета легаси-системы с точностью до пенни.
В течение 2 лет расчет шел параллельно в 2 системах, в случае выявления расхождений делался анализ и вносились изменения, пока расхождения не прекратились.
Вызов 4: Пропасть между разработчиками и бизнесом. Как избежать создания «IT-коней в вакууме»?
Самая большая опасность — когда программисты, не понимая предметной области, делают то, что просили в ТЗ, а не то, что нужно бизнесу.
Решение: Погружение разработчиков в бизнес-процессы с головой
Мы сломали этот барьер радикально:
Обязательные командировки: Разработчики ездили в офисы, сидели рядом с диспетчерами, смотрели, как они работают, и слышали их боль.
Прямое общение: Аналитики не были «бутылочным горлышком». Программисты общались с пользователями напрямую, чтобы понять суть задачи.
Участие во внедрении: Те, кто писал код, сами же его и внедряли, проводили обучение и получали фидбэк лицом к лицу.
Результат оказался круче, чем мы ожидали. Наши разработчики за пару лет превратились из технических специалистов в матерых экспертов в логистике такси. Они не просто кодили — они предлагали бизнесу новые, более эффективные решения высокого уровня. Джуны росли до сеньоров не за 5 лет, а за 2. Это был колоссальный рывок в компетенциях.
Итоги и результаты
Спустя годы мы можем уверенно подвести итоги:
Успешный запуск: Замена ключевой ERP прошла без остановки бизнеса.
Долгосрочное партнёрство: Клиент остается с нами уже 15 лет.
Новые продукты: Опыт вдохновил на создание фреймворка JMIX (продукт-преемник Gear) и выделение xDbStream в отдельное решение.
Сильная команда: Мы не просто сделали проект — у нас выросли уникальные специалисты, глубоко понимающие бизнес.
Вместо планируемых 2 лет переезд на новую ERP-систему занял более 5 лет. Это не значит, что проект был неуспешным. Новая система стала приносить пользу уже через 6 месяцев и сняла множество ограничений, мешающих бизнесу двигаться вперед.
Благодаря современной ERP заказчик стал безоговорочным лидером индустрии и продолжает с нами работать. Система также развивается и переживает переезд на более современные технологии (микросервисы, in-memory data grids и т. д.).
Успех в таких проектах определяет не столько выбор технологий, сколько инженерное мышление — способность разбить невозможную на первый взгляд задачу на решаемые вызовы и найти для каждого нестандартное и практичное решение. Parallel Running, Gear, Allocator — это не просто инструменты, это пример такого подхода.
