Говорят, что в России и в мире дефицит IT-специалистов. Врут, разумеется. Специалистов достаточно, просто IT-задач слишком много.
Шутки шутками, но мы в ЕВРАЗе думаем исходя из конкретных задач. Однако задача — это странный предмет. Иногда её вроде бы нет, а на самом деле она есть. Вот некий техпроцесс, он работает, даёт продукт, приносит прибыль. Кажется, работает — не трогай. А потом трогаешь, цифровизируешь — и он начинает работать лучше. Как понять, что такая возможность есть? Это нужно технологам разговаривать с дата-сайентистами.
С другой стороны, иногда задача вроде бы есть, а на самом деле её нет. Кажется, вот тут используешь machine learning — и станет хорошо. А на деле — гипотеза не подтвердилась, корреляции нет, эффекта нет. Только потраченное время IT-команды. Конечно, отрицательный электрод — тоже электрод, но вот стоимость такого электрода хотелось бы уменьшить.
А с третьей стороны — бывают задачи, которые технолог своими руками в Excel, конечно, не решит, но вот ещё немного — и решил бы. И очень не хочется платить за аутстафф или ждать месяцы, пока у штатных айтишников освободится время. Хочется, чтобы «вот ещё немного».
О том, как мы в ЕВРАЗе научились справляться с такими «задачами Шрёдингера», что значит SSA помимо серверной авторизации и о прочих поразительных вещах — читайте под катом.
Знакомьтесь — Татьяна
Татьяна работает на Западно-Сибирской ТЭЦ. Её должность звучит как «инженер по ремонту, комплектации оборудования и метрологии». На деле это примерно так же серьёзно, как и звучит. Много скрупулёзной работы с документацией — такого человека чтением мануалов не запугаешь.
На дворе — прекрасный 2021 год. Однажды Татьяна слышит, что происходит набор на внутриевразовскую стажировку. Будут учить технологов анализу данных, разработке no-code приложений и другим загадочным вещам. «Звучит интересно», — подумала Татьяна. Мы в своём 2022 году можем с уверенностью сказать, что она не ошиблась.
Татьяна подала заявку и прошла конкурсный отбор. Первичный отбор — по полученному образованию, затем тесты по теории вероятности и математической статистике. После — третий, самый важный этап отбора: кого из специалистов руководство отпустит на стажировку. Татьяна оказалась в десятке тех, кто начал стажировку, и в тройке тех, кто её закончил. После этого она получила право именоваться гордой аббревиатурой CDS — и вернулась в родную дирекцию, но уже на другую, вновь созданную должность — ведущего специалиста по аналитике.
Это что за покемон?
Термин Citizen Data Scientist (сокращённо CDS) впервые был употреблён консалтинговой компанией Gartner в 2018 году. Он обозначает специалиста внутри компании, который имеет одновременно и опыт в некоторой предметной области, и навыки анализа данных, которые позволяют ему в этой предметной области что-то оптимизировать. Там, где обычно происходит сотрудничество технолога и дата-сайентиста, CDS справляется за двоих. То, чем он занимается, называется ещё одной трёхбуквенной аббревиатурой — SSA, Self-Service Analytics.
Основной инструмент CDS — это голова. В ней содержатся знания. При подготовке CDS получает крепкие базовые знания в области анализа данных. Как выдвигать и проверять гипотезы, строить и валидировать модели. И, разумеется, как пользоваться другими инструментами.
Помимо думания, CDS занимается разработкой приложений: как правило, в рамках no-code идеологии, «программируя мышкой». Типичное SSA-приложение умеет получать данные, обрабатывать их, визуализировать, строить прогнозы, давать рекомендации.
Татьяна, как и другие CDS в ЕВРАЗе, научилась использовать связку KNIME, AutoML и Power BI. Вероятно, про последний нет смысла рассказывать подробно, это одно из наиболее распространённых средств визуализации данных. Power BI умеет преобразовывать наборы чисел в красивые графики и диаграммы для конечного пользователя. Очевидно, что в SSA-приложении он служит в качестве пользовательского интерфейса.
KNIME — более интересная штука. В каком-то смысле это Excel на стероидах. С виду не очень похоже: в Excel таблички, а в KNIME — блоки и стрелочки.
Однако в основе лежит схожая идеология — конструирование конвейера по обработке данных из неких функциональных примитивов. В Excel с помощью функций вроде СУММ или СРЗНАЧ строятся зависимости одних ячеек от других. В KNIME данные путешествуют между нодами. Каждая нода делает какую-то одну простую (или не очень) вещь: получает данные из БД, переименовывает столбцы, производит арифметические операции, обращается к REST API…
KNIME легко расширяем. Новые типы нод создаются обычными «yes-code» программистами для последующего no-code использования. Мы в ЕВРАЗе создали несколько нод специально для CDS’ов, которые делают всякие не вполне тривиальные вещи: ML, задачи оптимизации, взаимодействие с фреймворками… Одна из наших «крафтовых» нод, например, занимается поиском оптимальных управляемых параметров на основе ML-модели. Другая на имеющейся модели ищет входные параметры, максимизирующие заданную целевую функцию. Есть ещё нода (также разработанная нами), импортирующая модели из Azure ML: мы пользовались этим сервисом ранее, но в связи с недавними событиями он стал недоступен в России, и мы переключились на использование встроенных средств KNIME.
Вернёмся к Татьяне
На Западно-Сибирской ТЭЦ Татьяна, имея на руках (точнее, в голове) новые навыки, приступила к давно намеченной задаче в составе небольшой команды из трёх специалистов.
Как работает современная ТЭЦ? Как нетрудно догадаться по буквам «Т» и «Э» в аббревиатуре, она преобразует тепло в электричество. Тепловая энергия сжигаемого топлива превращает воду в пар. Пар вращает турбины. Турбины генерируют электроэнергию. Затем пар конденсируется обратно в воду, и всё повторяется.
Для конденсирования пара в турбинах необходима вода. Она не возникает там волшебным образом сама по себе, её надо откуда-то брать. В случае Западно-Сибирской ТЭЦ она берётся из реки Томь: закачивается оттуда специальными насосами. Вот здесь-то и начинается задача Татьяны.
Для работы насоса требуется электроэнергия. Конечно, на ТЭЦ этого добра навалом — но, разумеется, хотелось бы как можно меньше энергии тратить на самообслуживание и как можно больше — передавать потребителям. ТЭЦ не всегда работает с одинаковой интенсивностью. Выработка электроэнергии зависит от спроса на неё, а спрос неравномерен, колеблется в течение суток и между ними. При этом насосы, подающие воду для турбин, работают постоянно с одинаковой мощностью. Возникает довольно логичная мысль: а может, стоит некоторые из них иногда отключать?
Для начала следовало понять, сколько воды нужно, чтобы турбины хорошо работали. Это довольно сложная задача с точки зрения физики. Какими бы умными ребятами ни были дата-сайентисты, знание продвинутой гидро-, термо- и ещё Бог знает какой динамики не входит в их компетенции. Так что сделать математическую модель турбин заказали Томскому политехническому университету. Но это был единственный чит — дальше пришлось работать самим.
Отрицание, гнев, торг
В ЕВРАЗе выделяют четыре стадии реализации цифровых инициатив:
Ретроспективный анализ данных. Чтобы перейти к следующему этапу, нужно показать на этих данных гипотетическую полезность инициативы, защитить proof of concept.
Построение MVP. Сделать что-то, что работает и уже приносит хоть какую-то пользу.
Продуктивизация решения. Доработать MVP таким образом, чтобы он был удобен и хорош для конечного пользователя.
Внедрение и устойчивое использование. Продукт отправляется на производство, и вскоре люди забывают, как когда-то обходились без него.
Первые две стадии целиком ложатся на плечи CDS. Собственно, в этом и заключается смысл его деятельности. На первой стадии он обеспечивает быструю, дешёвую и сердитую проверку гипотез. Выделить специалиста из IT-отдела — в большой компании дело небыстрое, это может затянуться на месяц или даже месяцы. CDS может проверить гипотезу на коленке без бюрократических проволочек. На второй стадии навыков CDS достаточно, чтобы своими руками создать прототип. На третьей стадии по необходимости уже могут подключиться IT-специалисты, но им не придётся всё делать с нуля: у них на руках уже будет более-менее рабочая модель. CDS — пионер, первопроходец, его задача — закрепиться на земле, которую затем, возможно, будут осваивать другие.
Татьяна с помощью Data Engineer’а от производства собрала все данные по давлению в водоводах, температуре воды и окружающего воздуха, выработке электроэнергии и т. д. Часть данных была записана от руки в журналах, так что поработать пришлось не только головой. Данные очистили от аномалий, сделали ресемпл. Обученная на них модель делала предсказания по текущему (фактическому) режиму работы с точностью 98%. Но это был лишь промежуточный этап. Дальше на модели стали ставить эксперименты, начали проверять гипотезы по оптимизации процесса. Что будет, если выключить насос? Сколько насосов необходимо, чтобы поддерживать нужное давление? Как давление изменяется во времени? Модель предсказала, что отключение части насосов возможно, а следовательно — и положительный экономический эффект. Таким образом команда защитила PoC и приступила к разработке прототипа на вышеупомянутой связке KNIME + Power BI.
<скрин прототипа>
Когда MVP был создан, возникла неожиданная проблема — человеческий фактор. Технологи ТЭЦ отказывались верить модели и её предсказаниям. По их мнению, постоянная работа всех насосов была критична для функционирования электростанции. Следовать рекомендациям, сформированным MVP, они отказывались. «Работает — не трогай».
Татьяне помогло то, что в науке называют естественным экспериментом. Один из насосов вышел из строя. Обычно в таких происшествиях нет ничего хорошего, но для проекта Татьяны это обернулось благом. Технологи ТЭЦ увидели, что с одним отключенным насосом электростанция работает в нормальном режиме, выработка энергии идёт по плану, а показатели согласуются с предсказаниями модели. После этого цифровой инициативе был дан зелёный свет, и она начала приносить реальную пользу. Вторая стадия была официально завершена.
Продуктивизация
Power BI — довольно простая и очень удобная штука, но в качестве фронтенда она имеет несколько очевидных недостатков. Во-первых, производительность. Power BI предназначается для аналитики, для создания графиков, диаграмм. В приложении реального времени Power BI начинает нещадно тормозить. Это касается и клиентской части (перерисовка графиков ресурсоёмка), и, что более важно, серверной. MVP с Power BI неистово жрут серверные ресурсы — а на серверах ЕВРАЗа, помимо «наколеночных» приложений CDS’ов, работает много более важных и критичных продуктов. В итоге дошло до того, что руководящим решением частота обновления каждого интерфейса Power BI была ограничена до одного раза в час (а в какие-то моменты — до раза в два или даже четыре часа).
Кроме того, есть ещё одна вещь, которую Power BI не умеет — обратная связь. Конечно, в идеальном мире данные всех датчиков непосредственно поступают в технологическую сеть. Однако в реальности технологу часто приходится смотреть их глазами и вбивать руками: как простому гражданину, который ежемесячно вписывает в квиток показания электрического счётчика. В Power BI компоненты для ввода просто не предусмотрены — чукча не читатель, чукча писатель.
Эти проблемы (а также многие другие) решены в нашем фреймворке SSA ML Toolbox (cокращённо — SSAMaLeT), который используется во второй волне SSA ЕВРАЗа. Он более легковесен как в клиентской, так и в серверной части. Фронтенд написан на React, но CDS об этом знать не обязательно: всё генерируется автоматически. Что требуется от пользователя, так это передать данные с помощью специальных узлов-коннекторов из KNIME и указать, в какой форме они должны быть представлены в UI, и SSA ML Toolbox соберёт страницу из готовых визуальных компонентов. Конечно, есть и ограничения: например, нельзя управлять размещением элементов на странице. Однако зачастую возможностей фреймворка вполне достаточно.
Данные, сгенерированные в процессе работы подсказчика, сохраняются в БД SSAMaLeT. При желании их можно получить через API — для этого мы сделали специальный узел-коннектор в KNIME. Таким образом можно поиграть с историческими данными, проанализировать их, обучить на них модели без каких-то дополнительных телодвижений.
Конечно, если бы всё этим ограничивалось, фреймворк назывался бы как-то типа SSA UI Toolkit. Возможности нашего инструмента гораздо шире. Он управляет деплоем, версионированием конфигураций, автоматизацией, хранением данных. В общем, всем, что необходимо, чтобы Data Science проект пошёл в прод.
Проект Татьяны относится к первой волне SSA, он не был основан на SSA ML Toolbox. Когда пришла пора его продуктивизации, можно было прикрутить фронтенд из Toolbox, однако вместо этого решили сделать всё по-взрослому и написать настоящий, не автогенерированный UI. Для этого подключили полноценную команду разработки.
Настоящее и будущее
Четвёртая стадия — внедрение и устойчивое использование — помимо доработки напильником предполагает также более существенные улучшения. Сейчас Татьяна и её коллеги работают над тем, чтобы придать насосам индивидуальности. Текущая модель предполагает, что все насосы одинаковы и равноправны. Её подсказки — это количество насосов, которые должны быть включены на той или иной насосной станции. Это необходимое, но довольно грубое упрощение. Насосы отличаются и по базовым техническим характеристикам, и в динамике: например, степенью износа.
Татьяна работает над тем, чтобы индивидуальные характеристика насосов учитывались в реальном времени. Однако это уже не только софтовая, но и железная проблема. Насосы необходимо дооснастить датчиками, регистрирующими их текущее состояние. Датчики — подключить к технологической сети. Пока эти работы ведутся, Татьяна готовит всё со своей стороны.
Помимо проекта управления насосами, Татьяна также занимается и другими проектами. Например, подсказчиком потребления доменного газа на паровоздуходувной станции (ПВС). Станция использует разные виды топлива: природный, коксовый, доменный газ. Последний представляет особый интерес: он является побочным продуктом выплавки чугуна на нашем металлургическом комбинате. По сути для нас он бесплатный, если образуются излишки — их приходится сжигать на т. н. «свече». Поэтому хочется приоритизировать использование доменного газа в качестве топлива ПВС. Однако есть множество технологических ограничений, и Татьяна работает над тем, чтобы подсказчик корректно их учитывал и выдавал оптимальный план. А на подходе ещё два проекта третьей волны SSA…
Эпилог
Новая работа захватила и увлекла Татьяну. Строго говоря, она уже выросла за пределы CDS. Вышеупомянутый подсказчик для ПВС уже не относится к её родной ТЭЦ, так что это уже не аналитика на месте. Но компетенции дата-сайентиста в этом случае оказались важнее и нужнее, чем технологические.
Подобное произошло со многими CDS первой волны. Работа с данными стала их призванием. Собственно, с точки зрения ЕВРАЗа это даже немножко проблема. Если все уйдут в вольное плавание, кто останется на местах? В настоящее время мы работаем над тем, чтобы создать позиции аналитиков в службе технико-технического развития при каждом подразделении: CDS с большой C, укоренённых в своей предметной области.
На Хабре много историй про «войти в айти». Некоторые из них смешные и нелепые, другие поучительные. Мы надеемся, что история Татьяны для читателей окажется во второй категории. Это «войтишничество» не стало данью моде, а выросло из конкретной потребности, конкретной боли. И благодаря Татьяне наша боль стала меньше.
