Зачем переходить?
Системы управления производством в НЛМК были созданы более 20 лет назад. Они были реализованы на устаревшем стеке, и если забегать дальше, то до сих пор попадаются фрагменты кода из прошлого века.
Они справлялись со своими задачами, но логика систем была реализована на уровне баз данных. Этот подход накладывал ряд ограничений в области совместной разработки, контроля версий и переиспользуемости компонентов. Для фронтенда же использовались Oracle Forms с устаревшими и неинтуитивными интерфейсами.
Развивать старую систему — не самое эффективное решение. Старый код сильно сужает пул специалистов, которые могут работать над его обслуживанием и улучшением, к тому же не все готовы разбираться с таким легаси. Некоторые решения уже не справляются с современными требованиями и нагрузками.
Поэтому было принято решение создавать новую систему управления производством с нуля. Для этого была выбрана единая микросервисная архитектура. Созданная таким образом единая цифровая платформа (ЕЦП) представляет собой совокупность инфраструктурных сервисов, реализующих весь цикл работы с приложениями — от создания кодовой базы до запуска и мониторинга готовых систем.
Еще одна предпосылка перехода на новую, микросервисную архитектуру связана с тем, что ее компоненты могут применяться по несколько раз и использоваться многократно в различных продуктах.
Если раньше для каждого цеха был свой монолит, то теперь заранее созданные микросервисы можно интегрировать в новые решения без необходимости изобретать велосипед. Многие сервисы становятся универсальными и переиспользуемыми.
Особенности проектирования производственных систем
Система управления производством базируется на международном стандарте ISA-95. Он описывает информационные системы по управлению производством.
Стандарт выделяет пять уровней управления. На первом и втором уровнях речь идет об управлении исполнительными механизмами и сборе информации с датчиков через ПЛК. Такие решения, как правило, идут в комплексе с оборудованием и разрабатываются производителем. Четвертый и пятый уровни описывают верхнеуровневые системы, которые в основном используются для бизнес-аналитики и контроля за финансово-хозяйственным управлением.
Переход на Java происходил на третьем уровне, который аккумулирует MES-системы (manufacturing execution system). Здесь происходит управление производством на уровне цеха. Данные системы выполняют аналитические и учетные функции, агрегируют и отображают информацию о производственном процессе. Впоследствии они также смогут использоваться для организации управляющего воздействия на нижестоящие системы.
Как происходил переход?
Старые системы были написаны на Oracle-стеке. Часть из них существует до сих пор — процесс перехода еще не завершен.
Помимо инструментов разработки и развертывания в ЕЦП выделяется платформа данных, а основной ее частью является платформа оркестрации контейнеров, где непосредственно запускаются все наши вновь разрабатываемые микросервисы.
При миграции на новый технологический стек в микросервисной парадигме применяются различные подходы.
Первый подход — послойная миграция, когда для определенной системы создается новый фронтенд. При этом база данных остается старой, и для корректной работы между фронтом и бэком создается middleware-прослойка. Она, с одной стороны, содержит BFF (backend-for-frontend), а с другой — адаптирует данные для работы со старой системой и базой. Этот подход применяется в ситуации, когда подразделению необходимо сразу видеть продукт, который им нужен.
Второй подход — функциональный. Из старой системы выделяется одна конкретная функция, конкретный процесс, и переформатируется в изолированный микросервис. У этого подхода есть минус: поскольку старая монолитная система продолжает работать, иногда один и тот же процесс выполняется параллельно в старой и новой системе, что требует дополнительной синхронизации.
Жесткой логики в выборе конкретного подхода нет — все исходит из запросов и потребностей бизнеса, учитывая специфику каждой конкретной системы.
Тестирование
Центр компетенций по тестированию проводит тесты на всех уровнях — от unit-тестов до интеграционного и модульного тестирования полноценных микросервисов.
Имитируется взаимодействие с другими системами, проводится нагрузочное тестирование. Код попадает на продуктивную среду только после успешного прохождения всех этапов QA.
Переобучение сотрудников
При внедрении нового софта необходимо проводить переобучение сотрудников, которые с ним работают, — что уж говорить о тех, кто этот обновленный софт будет разрабатывать с нуля.
Есть специалисты, которые работают в компании уже десятилетиями, хорошо знают логику и специфику работы, понимают происходящие на производстве процессы. При этом очевидно, что потребность в работе со старым стеком падает — и будет падать дальше.
Чтобы не терять опытных людей, которые знакомы с устройством промышленных процессов, был взят вектор на их переобучение.
Для этого НЛМК совместно со сторонним подрядчиком разработал собственный курс продолжительностью чуть менее года. Программа была создана конкретно под нужды компании — не просто «Java с нуля для чайников», а более конкретные и узкоспециализированные знания. В том числе потому, что в роли учеников выступали уже действующие высококлассные специалисты.
Создание курса с нуля важно еще и потому, что целью было не просто дать базовые знания о Java и на их основе дать инструменты для решения специфичных задач. Необходимо было рассказать еще и о смежных технологиях: работе с Git’ом, контроле версий, фреймворках, логировании и т. д. Иными словами, разработчикам прививались лучшие практики именно enterprise-разработки.
Большинство сотрудников оценило инвестиции в свое переобучение положительно, даже невзирая на и без того высокую рабочую нагрузку и малое количество свободного времени.
Специалисты переключились на разработку новых систем и включились в новые команды. Но часть команды продолжает работать над поддержанием старого софта: масштабы трансформационного процесса указывают на то, что старый стек еще будет актуален.
Сложности в обучении заключались в смене парадигмы, подхода к созданию программных продуктов. PL/SQL — язык, ориентированный на работу со структурированными табличными базами данных. Java — объектно-ориентированный язык, для работы на нем важно понимать логику и принципы работы ООП, использовать другие паттерны и подходы к разработке. Для работы в микросервисной парадигме также важно понимать специфику сетевого взаимодействия между сервисами, применять специфические микросервисные паттерны, которые отсутствуют в монолитных приложениях.
Итоги
Процесс трансформации идет уже более двух лет. Но работы еще много, предстоит перевести значительную часть старых систем на микросервисную архитектуру.
Благодаря переходу на новый стек и новую парадигму разработки, бизнес может быстрее получать необходимые ему программные продукты и функционировать эффективнее. А за счет использования популярного языка с большим числом специалистов на рынке развивать новую систему будет менее сложно. Кроме того, сама логика построения микросервисной архитектуры предполагает более эффективное развитие и поддержание систем.
Иван Белов, руководитель отдела backend-разработки НЛМК.
Материалы по теме
- 🔥 Вместо кофе — раскаленное железо, а вместо чашки — огромный ковш. Data Science на службе у сталеваров
- ☕ Пример проекта Java Backend: DDD, микросервисы, Spring Cloud и AWS (Часть 1)
- Что такое микросервисная архитектура и когда ее применять
Комментарии