Перестройка на ходу: как модернизировать промышленное ПО без остановки производства
Перестройка на ходу: как модернизировать промышленное ПО без остановки производства https://globalmsk.ru/news/id/82520 Трансформация зрелого IT‑продукта — это не запуск с чистого листа, а тонкая работа по перестройке действующей системы без остановки её эксплуатации. В интервью — практический разбор того, как модернизировать промышленное ПО: от поэтапного ухода от монолита и адаптации инфраструктуры до прагматичного внедрения ИИ под конкретные производственные задачи. Алексей Лисицын, технический директор «КЛ Бизнес Солюшнс»: От идеи до первого миллиарда: как создавался продукт? У нас история вообще не про классический стартап, который начался с идеи на салфетке. Всё было почти наоборот. В 2022 году наша команда выкупила компанию вместе с продуктом, которому на тот момент было около 15 лет. У него уже были свои клиенты, накопленная предметная экспертиза и, естественно, большой технический долг. Одна из первых находок хорошо показала масштаб задачи: часть логики APS-планирования была зашита в один SQL-запрос примерно на 5000 строк. На тестовых данных - 50 станков и 200 заказов - расчёт занимал около 15 минут. Но реальное производство - это уже сотни единиц оборудования, тысячи операций в смену и планирование на несколько недель вперёд. При такой нагрузке расчёт мог идти несколько часов, а по итогу и вовсе остановить работу системы. Тогда стало понятно, что просто поддерживать существующую архитектуру дальше не получится. Но и сказать действующим клиентам: «подождите пару лет, мы всё перепишем» - мы тоже не могли. Поэтому CLBS начали пересобирать постепенно: начали разделять функциональные области, выносить MES и планирование из монолита, переводить новые функции на сервисную архитектуру. К концу 2024 года CLBS стал гибридной системой: часть проверенной логики по-прежнему работает в существующей системе, а новые функции и планирование уже развиваются отдельно. И этот переход продолжается. Поэтому у CLBS нет одной красивой даты, когда продукт «создали». Мы продолжаем его пересобирать и развивать сейчас, уже понимая ограничения старой архитектуры и реальные требования производства. Для меня это, пожалуй, самая интересная часть истории: мы не создавали продукт в идеальных условиях, а меняли работающую промышленную систему без возможности поставить её развитие на паузу. Как мотивировать разработчиков годами работать над одним продуктом? Я довольно скептически отношусь к идее, что инженера можно надолго мотивировать корпоративной культурой, лозунгами или какими-то специальными механиками. Сильному разработчику прежде всего нужна задача, в которой ему есть что решать. А в промышленном ПО таких задач много. Здесь код существует не сам по себе. От него может зависеть, как будет построен производственный план, куда система назначит операцию, насколько быстро диспетчер увидит изменение ситуации или сколько времени технолог потратит на подготовку новой детали. Когда разработчик видит эту связь, продукт воспринимается совсем иначе. У нас, например, был случай, когда ведущий разработчик примерно за неделю собрал прототип агента для анализа договоров, который находил в документах нестыковки. Появилась прикладная гипотеза, разработчику было интересно её проверить, и за короткое время появился работающий прототип. По моему опыту, такие задачи мотивируют команду гораздо лучше любых формальных инструментов. При этом у инженеров должна быть возможность сказать, что принятое решение не сработало или оказалось сложнее, чем ожидалось. У нас это тоже было. При переходе к микросервисам мы недооценили сложность синхронизации данных. В монолите многое решалось одной транзакцией, а в распределённой системе приходится отдельно следить за тем, чтобы несколько сервисов оставались согласованными. Первая концепция работы с ИИ тоже оказалась не той, которая нам была нужна. Если такие вещи не обсуждать и продолжать защищать решение только потому, что на него уже потрачено время, продукт от этого лучше не станет. Поэтому для меня мотивация к...