Подобные ожидания часто бывают у людей из других индустрий. Когда ты разрабатывал всю жизнь приложения для банков и финтеха, кажется странным делать IT на реальном производстве. Мне в этом плане было проще, я АСУшник на ЖД по специальности и практику мы проходили гоняя локомотивы и снимая с них кучу данных, потом случалось проектировать и реализовывать системы управления зданиями, заводами и т.п. Т.е. для финтеха и банкинга я тоже много чего сделал, но честно могу сказать, что именно в НЛМК нашел тот самый баланс между реальным производством и действительно крутым ИТ, с нейросетями и AI. А на собеседованиях многие разработчики из других индустрий искренне удивляются зрелости наших процессов и технологий.
Там, где управляющие воздействия идут на уровень 1-2 (исполнительные механизмы, пром контроллеры и т.п.) это уровень АСУТП и тех. сегмент, туда глубоко не лезем. А мы обычно начинаем с уровня 3 (MES) и выше.
Используем экосистему Spring, для новых проектов это Spring 6, Spring boot 3. Были эксперименты с другими фреймворками, тот же Micronaut, но они не прижились.
Спасибо за комментарий, а я то думаю, почему вполне реальные и довольно дорогие вакансии иногда долго закрываются. Оказывается дело в том, что зп не пишем и люди думают, что это муляж)
Группа НЛМК в рынке по оплате. Те вакансии, которые были до того, как решили экстренно пригласить тех, кто остался без работы, есть с подробным описанием. Можно посмотреть на hh.ru или даже тут, на Хабре https://habr.com/ru/company/nlmk/vacancies/
Если свою позицию не нашли среди конкретных вакансий, кидаете резюме или даже указываете стек и специалист их hr свяжется.
Единая MES сразу не получится и не факт, что она необходима. Мы стараемся сейчас выделить переисползуемые и инфраструктурные сервисы, которые могут использоваться различными MES'ми. Определенное количество прикладных сервисов скорее всего будет писаться под конкретные цеха и системы, но мы стараемся свести эту долю к минимуму за счет переиспользования и конфигурирования существующих сервисов.
Если говорить про бэк, то это микросервисы на Java 11, Spring boot. Синхронное взаимодействие через REST, асинхронное - Kafka. На фронте обычно React, дизайн система и библиотека компонентов про которые потом еще расскажем. Довольно много используем NiFi, на некоторых проектах Redis. БД на уровне сервисов обычно Postgres, легаси системы на Oracle. Для ряда специфичных задач применяем Cassandra, ClickHouse, Hadoop. Обо всем этом постараемся рассказать в следующих статьях.
Скорость соответствует требованиям бизнеса, нареканий нет. Ранее асинхронное взаимодействие также проходило также через кафку, так что тут координальных изменений нет. А наши монолиты представляли собой в основном БД Oracle и вся логика была там, и тоже были накладные расходы по скорости выполнения запросов, которые требовали оптимизации, нормализации/денормализации таблиц и т.п. Основные узкие места это интеграции с другими системами, а не межсервисное синхронное взаимодействие.
Про платформу еще отдельно расскажем, тут только общий обзор) Если вкратце, то есть ELK для логирования, Prometheus и Grafana для мониторинга, Sentry для ошибок и Jaeger для трассировки.
Обязательно расскажем про фронт, дизайн систему, мультипортал и другие интересные вещи. А еще отдельно расскажем про технологическую платформу на которой крутятся все прикладные сервисы - это тоже тема для нескольких статей.
Раньше очень многие функции повторялись в различных системах. С микросервисным подходом мы уже сейчас делаем сервисы, которые используются многими системами, даже легаси. На конкретных кейсах видно, что вместо серьёзной доработки 7-8 систем, мы делаем один сервис и простую интеграцию с его API. Как раз сейчас делаем такой сервис по реализации алгоритма расчета веса перехода. Конечно это приносит выгоду бизнесу.
Стало лучше и проще в плане документации, которая типовая и полная на все микросервисы, и разработчику проще погрузиться в конкретный сервис, чем в большую систему. Многие сервисы переиспользуются на различных системах - тут явное удешевление.
Подобные ожидания часто бывают у людей из других индустрий. Когда ты разрабатывал всю жизнь приложения для банков и финтеха, кажется странным делать IT на реальном производстве. Мне в этом плане было проще, я АСУшник на ЖД по специальности и практику мы проходили гоняя локомотивы и снимая с них кучу данных, потом случалось проектировать и реализовывать системы управления зданиями, заводами и т.п. Т.е. для финтеха и банкинга я тоже много чего сделал, но честно могу сказать, что именно в НЛМК нашел тот самый баланс между реальным производством и действительно крутым ИТ, с нейросетями и AI. А на собеседованиях многие разработчики из других индустрий искренне удивляются зрелости наших процессов и технологий.
Там, где управляющие воздействия идут на уровень 1-2 (исполнительные механизмы, пром контроллеры и т.п.) это уровень АСУТП и тех. сегмент, туда глубоко не лезем. А мы обычно начинаем с уровня 3 (MES) и выше.
У нас полный цикл.
Используем экосистему Spring, для новых проектов это Spring 6, Spring boot 3. Были эксперименты с другими фреймворками, тот же Micronaut, но они не прижились.
JS (React)
Спасибо за комментарий, а я то думаю, почему вполне реальные и довольно дорогие вакансии иногда долго закрываются. Оказывается дело в том, что зп не пишем и люди думают, что это муляж)
Группа НЛМК в рынке по оплате. Те вакансии, которые были до того, как решили экстренно пригласить тех, кто остался без работы, есть с подробным описанием. Можно посмотреть на hh.ru или даже тут, на Хабре https://habr.com/ru/company/nlmk/vacancies/
Если свою позицию не нашли среди конкретных вакансий, кидаете резюме или даже указываете стек и специалист их hr свяжется.
Лицензия SAP у нас действующая на несколько лет вперед.
Лендинг действительно за 2 дня сделан, тк. это ситуационная история. Мы хотим поддержать тех, кто остался без работы.
Можно встречный вопрос: а вы уже перевели свой бизнес на 1С?
Это новые вакансии для бывших сотрудников компаний, которые сейчас ушли с рынка. А так никто никуда не делся.
Единая MES сразу не получится и не факт, что она необходима. Мы стараемся сейчас выделить переисползуемые и инфраструктурные сервисы, которые могут использоваться различными MES'ми. Определенное количество прикладных сервисов скорее всего будет писаться под конкретные цеха и системы, но мы стараемся свести эту долю к минимуму за счет переиспользования и конфигурирования существующих сервисов.
Если говорить про бэк, то это микросервисы на Java 11, Spring boot. Синхронное взаимодействие через REST, асинхронное - Kafka. На фронте обычно React, дизайн система и библиотека компонентов про которые потом еще расскажем. Довольно много используем NiFi, на некоторых проектах Redis. БД на уровне сервисов обычно Postgres, легаси системы на Oracle. Для ряда специфичных задач применяем Cassandra, ClickHouse, Hadoop. Обо всем этом постараемся рассказать в следующих статьях.
Обязательно расскажем в следующих статьях.
Скорость соответствует требованиям бизнеса, нареканий нет. Ранее асинхронное взаимодействие также проходило также через кафку, так что тут координальных изменений нет. А наши монолиты представляли собой в основном БД Oracle и вся логика была там, и тоже были накладные расходы по скорости выполнения запросов, которые требовали оптимизации, нормализации/денормализации таблиц и т.п. Основные узкие места это интеграции с другими системами, а не межсервисное синхронное взаимодействие.
Про платформу еще отдельно расскажем, тут только общий обзор) Если вкратце, то есть ELK для логирования, Prometheus и Grafana для мониторинга, Sentry для ошибок и Jaeger для трассировки.
Обязательно расскажем про фронт, дизайн систему, мультипортал и другие интересные вещи. А еще отдельно расскажем про технологическую платформу на которой крутятся все прикладные сервисы - это тоже тема для нескольких статей.
Раньше очень многие функции повторялись в различных системах. С микросервисным подходом мы уже сейчас делаем сервисы, которые используются многими системами, даже легаси. На конкретных кейсах видно, что вместо серьёзной доработки 7-8 систем, мы делаем один сервис и простую интеграцию с его API. Как раз сейчас делаем такой сервис по реализации алгоритма расчета веса перехода. Конечно это приносит выгоду бизнесу.
Стало лучше и проще в плане документации, которая типовая и полная на все микросервисы, и разработчику проще погрузиться в конкретный сервис, чем в большую систему. Многие сервисы переиспользуются на различных системах - тут явное удешевление.