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

Объёмный план затрагивает весь производственный цикл: от закупки сырья и управления запасами до отгрузки продукции клиентам и, конечно, включает производство. Все должно быть согласованно, четко подогнано одно к другому и работать как часы. Без крутой ИТ-системы здесь не обойтись.

С 2016 года мы пользовались зарубежным софтом, но система устарела, а обновления стали недоступны. Нам предстояли муки выбора российского решения, инженерные компромиссы и кастомизация. И тут мы первыми в России рискнули сделать ставку на систему объемного планирования In.Plan. Только вот нюанс: решение было облачным, а нам был нужен крепкий on-premise прямо в нашей промышленной инфраструктуре, ну и других требований к кастомизации было миллион.

Со мной случилось приключение — настоящий промышленный туризм.  На экскурсию по цехам Новолипецкого металлургического комбината не купить билет, но для сотрудников такие экскурсии случаются. Мой путь к этому дню оказался таким: полтора года работы деврелом в НЛМК ИТ и подготовка статей для Хабра, во время создания которых я ловила термины вроде MES, КЦ, ДЦ и не всегда понимала, что они означают, пока не увидела все своими глазами.

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

Сейчас я изучаю английский так, как давно мечтал — через чтение книг. Читаю для души всё, что всегда хотел прочитать. Если бы не английский, выбрал бы те же произведения на русском.

Обсуждать книги мне нравится не меньше, чем читать. В одиночку быстро становится скучно. Обычно я читаю одну-две книги в месяц и каждую обсуждаю с кем-то.

Так у нас с коллегами и появился клуб по интересам: читаем на английском и делимся впечатлениями. В этой статье расскажу, как мы прошли путь от идеи до увлекательных живых обсуждений.

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

Так началась моя история знакомства с НЛМК. Вообще о комбинате я уже что-то слышал ранее — ведь именно в моем родном городе находится Стойленский ГОК. И, когда мне пришло письмо о возможности постажироваться в НЛМК, я сразу же подал заявку.

Но обо всем по порядку. Почему я на 100% уверен, что не ошибся с местом стажировки, через что пришлось пройти, чтобы туда попасть, и что меня ждало по окончании практики — расскажу ниже.

TL;DR Стажировка в НЛМК — не галеры и не манеж с детскими задачками, а возможность по-настоящему понять, что дизайн — это не про красоту, а про пользу для настоящих, живых людей.

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

Копились и другие проблемы.

Например, пользователи стали продвинутыми и жаловались на дружелюбность интерфейса. На самом деле тяжело представить в одном предложении слова «дружелюбность интерфейса» и нашу старую систему заявок на транспорт.

Всё это работало только под IE/Edge, не поддерживало Хромиум, конфликтовало с требованиями ИБ.

Бизнес регулярно генерировал новые фичи, но некоторые из них было проблематично реализовывать в действующей системе.

Мы давно задумывались о рефакторинге или миграции, суть споров сводилась к самопису или «коробке».

Мы всё проанализировали и решили, что надо взять готовую «коробку», которую потом нужно будет допилить процентов этак на 10.

В итоге оказалось, что сначала мы допилили процентов на 20, а потом от исходной «коробочной» версии осталось процентов 10, и вся разработка переехала к нам внутрь.

Сейчас я расскажу о дьявольском опыте использования чужой «коробочной» версии как фреймворка для своей разработки. Забегая вперёд — второй раз мы в это не полезли бы.

Большие данные не равняются долгим ожиданиям! Эту простую истину мне раскрыл такой инструмент как ClickHouse, и жизнь заиграла новыми миллисекундами.

Если коротко, то это мощная аналитическая база данных, которая умеет проглатывать миллионы строк за секунды и возвращать результат, пока вы не успели сосчитать до трёх: с ClickHouse запросы, агрегации и графики работают в режиме настоящего времени.

Расскажу, почему этот инструмент стал для меня настоящей находкой. Статья будет полезна разработчикам, инженерам данных и аналитикам, которые ищут эффективные инструменты для обработки больших объёмов данных.

Не так давно в моем календаре появилась встреча под названием «Эффективность дизайнеров». И это выглядело как личное оскорбление. Мы всегда работали по спринтам, закрывали задачи, и вопросов к нашей эффективности ни у кого не возникало. До этого дня.

На встрече мне поставили задачу — разработать систему для подсчета производительности каждого дизайнера. Я была уверена, что это невозможно: разный профиль дизайнеров, разный объем проектов.

В каких таких попугаях я должна считать, насколько эффективно отрисовал дизайнер MES-интерфейс или сгенерировал картинки для сайта?!

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

Но я ошибалась. Это было не концом, а началом истории о том, как самая ненавистная и абсурдная идея превратилась в главный инструмент, который понятен бизнесу. Но при этом защищает, а не угнетает команду.

Чтобы абсолютно точно выплавить нужный сорт стали, надо очень строго соблюсти долю всех компонентов.

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

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

Натренировать нейросеть, которая советовала бы, сколько вешать в граммах отдавать ферросплавов в плавку, до нас пытались уже дважды.

Но не взлетело.

Модель считала дозировки по тем данным, что были, а данных часто не хватало. То замер опоздал, то бригадир не успел внести информацию. В итоге рекомендации модели мазали мимо, а сталевар попадал точнее. Естественно, сталевары не доверяли советчику и к новым попыткам относились скептически: мол, опять пришли какие-то айтишники с идеями.

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

Машинное зрение работает, и работает хорошо. За год количество проектов выросло с 5 до 36. Мы привлекли много подрядчиков и знатно пробежались по граблям.

А теперь я хочу рассказать про эти самые грабли.

Первые же серьёзные — проверка качества решений. Как оценить чужое решение и работает ли оно так, как надо нам? Тут много подходов и способов, например, использовать скрытые выборки, оценка на потоке и базовое — проверка кода и всего пайплайна, от разметки до метрик обученной модели.

Вторые — что не стоит оставаться наблюдателем на протяжении всей разработки. Если вы начинаете изучать систему только на приёмке, вас наверняка ждёт дивный мир сюрпризов. Включаемся сразу, ещё и раньше разработчиков (ТЗ никто не отменял).

А самая большая для меня боль года — донести и согласовать фразу «понятный и читаемый код» с каждой командой со своим чувством «прекрасного», и это не только про длину строк или формат докстрингов, но и про общие понятия в разработке.

Но давайте по порядку.

Работа команды производственных айтишников на металлургическом производстве иногда тесно сплетается с командой технологической автоматизации и электрооборудования: устанавливаем датчики уровня, нужные для детального анализа технологического процесса

С точки зрения ИТ доменная печь — это огромный «чёрный ящик». Вы кладёте сырьё и топливо, получая на выходе чугун и шлак. Измерить внутри все можно почти ничего нельзя: датчики просто «умирают» от температуры, воздействия шихты и прочих условий. Измерить снаружи тоже сложно (да и нужно ли?): большие печи имеют диаметр порядка 15 метров и высоту 35 метров, — что нам дадут граничные условия для таких размеров?! По опыту на малых печах можно измерять уровень расплава (без разделения на шлак и чугун) по ЭДС внешними датчиками, но у нас так не выйдет, и нам пришлось провести целое исследование, чтобы понять, почему.

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

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

Но цифровые возможности развиваются, и мы пробуем применить самые современные цифровые решения, даже если они на грани возможного.

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

Когда вам нужно доставлять сырьё на большое производство, сложно остановиться.

Как вы знаете из компьютерных игр, для этого нужна большая железная дорога.

У нас она своя. В 1933 году было 10 километров рельсов, 10 вагонов и два паровоза.

Сейчас — 136 локомотивов, 3 065 вагонов, 19 станций, 580 километров путей и 1 585 стрелочных переводов. 130 миллионов тонн грузов в год.

А машинистами у нас теперь становятся роботы.

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

Если вы хотя бы раз сталкивались с интеграцией данных в Bitrix, то знаете: простых задач не бывает. А когда речь идёт о тысячах товаров, нестабильных источниках, сроках и необходимости всё держать в актуальном состоянии — без автоматики не обойтись.

Я — Алексей Яриков, ведущий разработчик команды внешних сайтов НЛМК. Мы ежедневно работаем с веб-платформами компании, отвечая за их надёжность, производительность и свежесть данных. В этой статье расскажу, как мы решили задачу регулярной загрузки и обработки большого объёма данных с FTP в рамках Bitrix — наглядно, с кодом, архитектурой и ошибками, которые мы учли.

Таблица для цеха отличается от обычной таблицы. Очень сильно:

— «Модные» тонкие шрифты — сразу на свалку. Числа должны читаться даже в маске сварщика.

— Освещение в цехах адаптировано под специфику задач— почти всегда нужна ночная тема.

— Минимум цветов, новый цвет — только привлечь внимание к реально критичной вещи.

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

Есть ещё много принципов, когда вы начинаете делать интерфейс для цеха, и примерно половину нам подсказали сами же заводчане. Мы с командой детально изучали, как работают с таблицами их пользователи в производственных условиях, с какими проблемами они сталкиваются. Ходили в цеха, спрашивали на местах, как они это всё смотрят, что делают, что им удобно, что неудобно.

Cтандартные подходы не всегда решали эти задачи.

Не сказать, что разработка таблиц далась нам легко: были проблемы и спорные моменты, когда приходилось выкручиваться. Но нам удалось получить результат, который подходит нашему производству и удобен пользователям. Сейчас расскажу детали.

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

Я из команды технологической платформы НЛМК ИТ. Спойлер — это все, что про централизованные сервисы около DevOps, Kubernetes, стриминг вокруг Kafka и так далее. Расскажу, зачем и по каким принципам мы ее строили, что получилось неплохо и всем советуем. Обо что споткнулись и всем советуем там не спотыкаться.

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

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

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

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

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

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

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

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

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