• Между двумя цехами проложена железная дорога длиной три километра.
• Тепловозы, везущие лом, на этом промежутке пространства иногда «теряются», и никто не может точно сказать, где они едут и когда прибудут.
• Все данные записаны в бумажный журнал, который существует в единственном экземпляре.

Представьте себе: у вас железнодорожная станция, сотни вагонов, десятки пользователей в системе, каждый раз кто-то нажимает кнопку "Обновить", чтобы узнать — разгрузили ли нужный вагон.

Вся логика обновления построена на "manual refresh". Да-да, пользователь сам жмёт кнопку, чтобы получить свежие данные. Система автоматической разгрузки или другой человек разгрузил что-то на другом конце станции, но вы об этом не узнаете, пока не перезагрузите страницу.

А ещё — избыток HTTP-запросов, polling, перегруженные серверы и полное отсутствие real-time взаимодействия.

Есть вариант! Масштабируемая и отказоустойчивая архитектура с использованием Redis Sentinel + Pub/Sub + WebSocket/SSE.

В статье расскажем какие проблемы возникают с real-time в Kubernetes, почему стандартные WebSocket-подходы не работают при нескольких подах, как построить отказоустойчивую систему с Redis Sentinel, как сделать real-time UI, сохранив отказоустойчивость и масштабируемость, и как всё это запустить локально для отладки.

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

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

Чтобы своевременно удовлетворять потребность сталеплавильного производства в чугуне определенного количества и качества, необходимо планировать объемы поступления сырья, включая планы отгрузки, поступления, выгрузки, шихтования и вовлечения в доменные печи. В связи с тем, что в данном процессе традиционно много участников, каждый из которых отвечает за свой участок и планирует его, долгое время на комбинате не было единой системы планирования обеспечения сырьем. Каждый работал в своей «таблице», а для формирования консолидированных планов тратили много времени и сил, чтобы подготовить итоговый план производства и обеспечения сырьем, который всех бы устроил. Нам нужно было разработать систему, которая стала бы единым источником правды по планам производства и обеспечения сырьем нашего металлургического ресторана.

Представьте: новый проект, сжатые сроки, десятки задач. Нужно создать компоненты, модули, классы, подготовить документацию — и всё это с нуля. Всё кажется стандартным, но на практике такие процессы забирают массу времени и сил.

Мы оказывались в этой ситуации не раз. Вместо того чтобы смириться с рутиной, решили действовать. Так появился наш набор CLI-команд для автоматизации разработки на 1C-Битрикс. Это не просто утилиты, а инструмент, который ускорил выполнение типичных задач, сделал процессы предсказуемыми и уменьшил вероятность ошибок.

Меня зовут Низамов Артур, я ведущий разработчик в НЛМК ИТ. Я расскажу, что нас мотивировало, какие команды мы добавили, как они работают и какой эффект это нам дало.

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

Привет, меня зовут Евгений, я разработчик из Байовэр в компании НЛМК ИТ.

Довелось мне тут столкнуться с разработкой системы опытно-промышленных испытаний на производстве, и если описать это коротко, то в целом большое количество людей разного уровня допуска должны совершить определенные действия в строгой последовательности (или местами асинхронно) для вынесения вердикта относительно качества продукта, и при этом управляться все это должно из одного места (как странно-то прозвучало:) Так как это достаточно инерционный процесс, который может занимать от нескольких месяцев до года, система, которая может рассылать ответственным за текущий шаг уведомления (а в случае простоя, и их руководству), позволяет ускорить прохождение большинства шагов бизнес-процессов (БП).

Приведу пример – требуются лакокрасочные покрытия от стороннего поставщика для работы цеха, но перед заключением контракта на массовые поставки, нужно убедиться, что товар не разбавлен. Ну то есть надлежащего качества:) Заранее прошу прощения за качество юмора, вы привыкнете.

Для этого закупается небольшая опытная партия, она проходит определенные испытания, и если результаты устраивают, процесс масштабируется на опытно-промышленную партию, побольше. Если же и в этом случае все испытания пройдены, то поставщик признается годным и материал одобряется к серийному применению. Собственно процесс испытаний мы и реализовали с помощью смарт-процессов. В данный момент у нас внедрено три категории материалов для испытаний (лакокрасочные материалы, огнеупорные материалы, наконечники медных фурм), они гораздо сложнее примера, который я хочу здесь описать, но его должно быть достаточно для масштабирования под нужды бизнеса.

Технологи — особенные пользователи. У них огромная ответственность, руки в перчатках, на лице — защитные очки. В цехе полутемно или светится раскалённый металл, а им нужно отследить сотни параметров техпроцесса. И им очень хочется, чтобы всё работало как часы. Правда, представления об идеальной работе у них сильно отличаются от привычного UI/UX. 

Некоторые мастера внезапно просили нас усложнить интерфейсы. 

Прямо реально усложнить: добавить меню, подменю, передвинуть кнопку, сделать крупнее. Ответ очень простой: они привыкли к старой оракловой системе с интерфейсами из кучи выпадающих меню. Некоторые по 20 лет тыкали в эти менюшки и сформировали мышечную память. Где-то людей просто бесил порядок кнопок, например: «Кнопка «Отменить» всегда была справа. Переставьте, пожалуйста!» 

Аналогично — с горячими клавишами. Если восемь лет назад мастер запомнил, что Ctrl+R означает «Контроль реза», то так и будет нажимать в новой системе, рассчитывая на знакомое поведение. Поэтому мы подняли все старые комбинации и добавили их в новый софт. Теперь работают и новые горячие клавиши, и привычные опытным мастерам аккорды. 

А тут — хороший пример ещё одного принципа. Верх страницы для технологов — визуальный мусор. На макете заголовок смотрится очень хорошо. На практике эту страницу они открывают на мониторе на стене либо каждый день видят много тысяч раз. Им важно, что находится на экране, внутри контентной области. То есть заголовок в проминтерфейсе в такой ситуации надо делать не просто маленьким, а очень маленьким, чтобы он не занимал драгоценного места.

В цехах мы узнали ещё много нового про UI/UX, а заодно про себя и свою работу.

Привет, Хабр!

Меня зовут Михаил, я ведущий разработчик в НЛМК ИТ. Команда, в которой я состою, занимается разработкой и поддержкой различных информационных систем, одной из которых является Единый корпоративный портал ГК НЛМК на базе Битрикс24.

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

Ранее мы уже начинали рассказывать о том, что для унификации и ускорения разработки отдельных сервисов у нас активно применяется модуль бизнес-процессов Битрикса. 

Как раз этот инструмент помогает нам превращать сложные и многоэтапные процессы в чёткую и понятную структуру. Бизнес-процессы помогают не только быстрее реализовать требуемую бизнес-логику для каждого конкретного случая за счет предоставления унифицированных интерфейсов, но и значительно упрощают поддержку сервисов. Наглядное представление бизнес-процессов, как карта метро, позволяет быстро понять жизненный цикл заявки, происходящие действия на каждом этапе ее обработки и при необходимости корректировать их. В первую очередь это важно для больших команд, когда сервис начинает разрабатываться одним разработчиком, дорабатываться вторым, поддерживаться третьим — издержки на ведение документации, передачу знаний и вникание в процессы значительно сокращаются.

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

Чугун – сплав железа с углеродом, в котором содержание углерода более 2,14%. Так звучит точное определение для металлургов. А для обывателей слово «чугун» ассоциируется с бабушкиной сковородкой или радиатором с закосом под старину. Это прежде всего металл, который затем становится сталью. Однако на качество сплава напрямую влияет время промежуточных операций с расплавленным чугуном. Чем быстрее мы довезем его от доменной печи до конвертерного цеха, тем лучше получится сталь, меньше потратится ресурсов на ее производство и лучше сохранится ковш, в котором едет чугун.

Почему для отслеживания ковшей с расплавленным чугуном мы выбрали технологию RFID и почему наши метки не горят — расскажу в этой статье.

Привет, Хабр!

Простая истина: когда какой-то элемент инфраструктуры или бизнес-сервис простаивает из-за сбоя, то компания несёт потери. Чем понятнее текущее состояние ИТ, тем быстрее можно реагировать на возникающие проблемы и не допускать простоев. Для этого, конечно, нужен мониторинг. 

Рассказываем, какой концептуальный подход к мониторингу мы применяем в команде НЛМК ИТ и как идёт один из наших проектов по внедрению зонтичного мониторинга и автоматизации на базе российской платформы Monq. Читать всем, кто хочет агрегировать данные из различных инструментов мониторинга в одном месте и автоматизировать управление этими данными. 

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

Современный ритм жизни зачастую напоминает бесконечную гонку, где важно не перегореть. Но что делать, если вы уже чувствуете, что подошли к кондиции слегка обугленного тоста? Первым делом — глубокий вдох и поиск ближайшего дивана. Шутки шутками, но реально лучше сделать паузу и пересмотреть свои приоритеты. Обратитесь за поддержкой к коллегам или близким, а если дела совсем плохи то и к профессионалу для консультации. Как вариант можно взять отпуск или отгул для полной разгрузки и перезагрузки.

Работа frontend-разработчика часто требует высокого уровня концентрации, необходимости решать задачи в сжатые сроки и постоянного самосовершенствования. Всё это может отвлекать нас от реальной жизни за пределами экрана. Ключевым является грамотное распределение времени и приоритетов. Вот основные принципы, которые помогают мне в этом.

Семья на первом месте. Независимо от загрузки, я стараюсь каждый вечер проводить с семьёй. Пусть это будет совместный ужин, игры с детьми или тихий вечерний разговор с женой, где мы делимся впечатлениями о дне — как позитивными, так и не очень. Такие моменты дают эмоциональную разрядку и напоминают о том, ради чего все усилия.

Физическая активность. Это залог крепкого здоровья и отличного самочувствия. Регулярные занятия в фитнес-зале и бассейне делают меня более энергичным и готовым к новым вызовам. Это отличный способ «перезагрузиться» и восстановить силы. Да и, честно говоря, никакой стресс не выдержит борьбы с гантелями!

Представьте, что вы возвращаетесь домой и замечаете, что кто-то съел ваш ужин или полежал на вашей кровати. Не нравится? Вот и владельцам информационных систем не нравится, когда они не могут понять, кто же хулиганит в их бизнес-процессах. Меня зовут Светлана Мелешкина, и я ведущий разработчик Банка Идей НЛМК. Именно в Банке Идей иногда происходили такие детективные истории.

Банк Идей — это уникальная внутренняя система, где любой сотрудник может поделиться своими предложениями для улучшения производственных процессов или условий труда. Во время работы с этой ИС мы столкнулись с постоянными вызовами в отслеживании изменений данных. Нам нужен был простой и доступный для сотрудников инструмент. Для этого мы решили использовать MongoDB — мощное решение в мире NoSQL.

В этой статье я расскажу о нашем пути к внедрению журнала изменений на базе MongoDB, о том, как мы сделали реальные шаги к улучшению нашего внутреннего процесса и наконец поняли, кто съел ужин.

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

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

Статья будет полезна архитекторам, руководителям и разработчикам.

Для фронта MES у нас на заводе используются мнемосхемы производственных цехов. Мы очень любим их проектировать.

Допустим, надо отследить позиционирование ковша. Оператор может посмотреть детали, кликнув на нужный ковш, чтобы сразу увидеть его начальное, конечное и текущее положения в производственной цепочке. Или он может быстро просмотреть весь процесс в большом цехе размером с пару стадионов, и сразу отреагировать, если что-то пойдет не так.

Ещё лет пять назад было бы трудно поверить, что такое возможно. У нас был Oracle, для отображения состояния оборудования и процессов применялись таблицы, графики, диаграммы, были даже текстовые описания. Это было низкоэффективно, требовало изрядно времени и усилий для обработки. Потом пришёл MES и понемногу всё закрутилось. Для MES-интерфейсов потребовался новый подход, т.к. в мире нет унифицированных решений для их разработки.

Чтобы внедрить мнемосхемы на производстве, пришлось изрядно поработать. Но задача была вдохновляющая, и оно того стоило.

Поговорим об IT в промышленности с архитектором решений из команды Технологической Платформы НЛМК. Александр Лищук поделится своим мнением по вопросам, которые интересуют многих инженеров, решающих, стоит ли выбрать в качестве направления развития IT в промышленности:

● типичный стек разработки в промышленности

● дресс-код и субординация

● развитие IT в реальном секторе

Привет, Хабр, меня зовут Иван Белов, я руководитель Backend-разработки в НЛМК ИТ. Регулярно принимаю на работу новых специалистов из различных отраслей и хорошо знаю, какие заблуждения есть у тех, кто мало знаком с нашей отраслью. Давайте попробуем развенчать самые распространенные мифы и послушаем истории наших айтишников.

Привет, Хабр!

В этой статье я рассказываю про свой опыт чтения неадаптированной литературы на английском языке с целью пополнить словарный запас до уровня свободного владения.

Подход можно применять начиная с уровня Upper Intermediate. Подход идеально подойдет тем, у кого есть желание сделать наконец передышку в учебе и просто «почилить» месяц-другой за чтением хорошей книги.

Всем добра,
Владимир