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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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