Привет, Хабр! Меня зовут Леонид, я ведущий PHP-разработчик в НЛМК ИТ.Наша команда отвечает за сервисы HR-направления на едином корпоративном портале (далее – ЕКП), а также занимается развитием и поддержкой корпоративных сайтов.

В предыдущей статье мой коллега рассказывал про подход к использованию гридов на крупном корпоративном портале. Со временем, помимо возможности работать с данными непосредственно на ЕКП, у бизнеса появилась другая потребность – выгружать эти данные в файлы.

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

Мы разрабатываем CV-системы (машинное зрение для производств). А ещё мы принимаем на поддержку решения, которые для нас делают подрядчики. Подрядчики присылают нам документацию, и дальше начинается бюрократический ад.

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

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

Количество итераций проверки одного документа — от 2 до 5. Серьёзно. Формулировки бывают настолько запутанными, что приходится писать кучу уточняющих вопросов.

Ещё есть ТЗ на разметку, там вообще становится понятно, почему Скайнет восстал. Например, надо обвести все надписи на вагоне. А если там мелом написано ХУZ, это должно попасть в распознавание? И вот инженеры сидят и принимают такие решения по каждой мелочи. 

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

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

Мобильный мир давно победил десктопный и в быту, и на производстве. Нет времени инструктировать рабочих на брифингах, а потом отправлять их в цеха с распечатками: каждая секунда простоя — это потерянные деньги. Теперь ремонтник ходит по цеху среди тонн металла, проводит осмотр оборудования или устраняет неисправности. В этом ему помогает терминал, которым он сканирует NFC-метки, QR-коды на оборудовании, делает фото и видео. Время от времени сканирует детали терминалом. Далее — рассказ о том, что находится внутри терминала, а также как у нас получилось сделать приложение для ремонтников и с чем пришлось столкнуться по ходу.

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

Но с каждым днём кубики становятся мельче, а модели — сложнее и реалистичнее. Работа требует всё больше концентрации и времени.

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

На первый взгляд — это вымышленная ситуация, разве сборка конструктора может быть настолько неавтоматизированной?

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

Если смотреть на наш комбинат сверху, то это не просто завод — это гигантский живой организм с собственной кровеносной системой. 596 километров железнодорожных путей с 1650 стрелочными переводами, по которым день и ночь курсируют 136 локомотивов.

Долгие годы работа этой системы обеспечивалась исключительно человеком. Представьте: «вертушка» с 15 вагонами 3-4 раза за смену уезжает со станции. И то, как она пройдет свой маршрут, целиком зависело от того, кто сидит в кабине. Один из машинистов может мастерски использовать инерцию и профиль пути, чтобы на выбеге взять подъем и сэкономить топливо. Другой будет вести состав более прямолинейно. Но это условно. Суть в том, что квалификация у всех разная, а объективно оценить «манеру вождения» и ее оптимальность было невозможно.

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

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

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

Поэтому мы сделали своего ИИ-ассистента «ДокАрхитектор» — и в этой статье расскажем, как обучить нейросеть корпоративным стандартам, сократить время проверки ТЗ с 10 часов до 3–4 и перестать бояться унаследованных проектов.

Приходят к нам мужики из цеха и говорят эту фразу.

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

Во-вторых, конвертер, который надо фотографировать. Если что, то конвертер — это такая печка в виде большого горшка восемь метров высотой. Мы туда заваливаем металлолом и заливаем жидкий чугун, затем всё это продувается кислородом, а потом на выходе получается сталь. Смысл операции — при температурах выше 1 600 градусов продуть кислородом на сверхзвуке так, чтобы он связал ненужные нам примеси.

Чего хотят цеховые: каждый раз, когда сталь готова, этот горшок наклоняется, и из него выливается расплав в ковш на железнодорожной платформе.

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

Кстати, она еще и бороду снаружи отращивает.

Пока конвертер наклоняется к платформе, горловина сзади красиво подсвечивается расплавом. Если мы сможем повесить камеру под 45 градусов и ловить точный момент во время наклона, то они будут очень счастливы. Данные наклона есть в АСУТП и, соответственно, в шине, потому что мы знаем положение механизма.

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

Заодно мы стали разбираться, зачем им это, и из этого пошла ещё серия проектов.

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

Представьте: вы засыпаете песок в сувенирную банку так, чтобы получился красивый узор. А теперь увеличьте эту банку до размеров десятиэтажки объёмом кубометров этак на 3200, а специи замените на кокс, агломерат, окатыши и руду. Надо их засыпать в доменную печь так, чтобы слоистый рисунок внутри не просто красиво ложился, а обеспечивал жизнь целой системе. Чтобы газовоздушная смесь проходила, материалы не перемешивались как попало, а стенки-холодильники не прогорели.

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

Доменная печь — это сердце металлургии. По словам наших технологов, это гигантский «живой» организм, который превращает оксиды железа в чугун при температурах выше 1500 °C. Но работает он как минимум при одном критически важном условии — если внутри всё лежит «как надо».

Кокс должен быть пористым, газопроницаемым, чтобы через него проходил восстановительный газ, который так и норовит забрать кислород у оксидов. Железорудное сырьё (агломерат, окатыши, брикеты, руда и прочее) должно распределиться так, чтобы не забить эти каналы. Представьте себе лёгкие, где бронхи забиты аллергенами, пылевыми частицами: дыхание становится невозможным. То же самое происходит с доменной печью… Наверное поэтому профессионалов-доменщиков иногда называют «докторами»: они умеют «лечить».

Ошибётесь с укладкой шихты — и печь просто перестанет «дышать». Цена такой ошибки в её апофеозе — не просто несоблюдение графика производства, а сокращение нескольких лет кампании печи, которая обычно составляет 10–15 лет.

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

Наша команда специализируется на развитии корп. портала Группы НЛМК на платформе Битрикс, и еще нескольких корпоративных сайтов.

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

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

У нас есть цех, где жидкая сталь превращается в слиток (на металлургическом языке — сляб). Это происходит в УНРС — установке непрерывной разливки стали. На УНРС жидкая сталь проходит через кристаллизатор, где формируется «корочка» (оболочка) будущего сляба, и поддерживающую систему, состоящую из роликовых сегментов, где сталь окончательно затвердевает за счёт охлаждения водо-воздушной смесью в зоне вторичного охлаждения (ЗВО)

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

Сегменты постоянно осматривают рабочие.

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

Получилась критичная ИТ-система, которая не делает ничего космического или нагруженного, но предельно важна всем в цехе.

Вот про развитие этой системы я сейчас и расскажу.

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

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

С 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 лет? На базе своего производственного опыта, данных по загруженному сырью, параметров прошлых выпусков чугуна и шлака, а также косвенных параметров предполагал, как поведёт себя печь. Но управлять процессами внутри надо, поэтому остаётся только моделирование процессов по данным входа и выхода, базируясь на принципах материального баланса и используя математические ухищрения.

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

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