Очень жаль, что большая часть комментаторов так однобоко смотрит на ситуацию.)
Минцифры нужно отдать должное, они сделали невероятно много хорошего для ИТ специалистов работающих на российские компании. Более того, в определенные моменты показали высочайший уровень квалификации и понимания ситуации, например, когда началась мобилизация.
От себя, как от руководителя довольно крупного ИТ подразделения могу сказать разве что спасибо всем сотрудникам минцифры и лично Максуту Игоревичу :) Мои специалисты благодаря их действиям чувствуют себя существенно лучше и спокойнее, благодаря их усилиям.
Если получится создать конкурента ASML в любом смысле этого слова - никто не будет говорить про "выпуск только для армии". Экспорт начнется в тот же момент, когда за рубежом появится спрос, скорее всего :)
Но создать конкурента ASML... В мире это прямо сейчас никому не нужно настолько, чтобы в это инвестировать действительно серьезные средства, т.е. много триллионов долларов :)
Теоретически, в современной России может сложиться единственная точка на земле в обозримом будущем, где подобное может стать оправданным и осмысленным :) не более того
Хотя история с безмасочной фотолитографией и звучит действительно очень перспективно, но подводных камней на этом пути - умопомрачительное количество. А потому ни одной оценке "за столько лет и денег - мы сделаем" я бы не верил :)
Любой кто хоть раз умудрился спроектировать и реализовать что-то более сложное, чем ножка для стула, понимает, что в серьезных разработках разброс затрат и сроков начинается от двухкратного х)
А не в курсе кто именно такие заявления делает? Я тут давече у коллег спрашивал, но первоисточника подобных высказываний мне так и не сдали :) а я бы посотрудничал :)
Теория - даёт тебе точную и строгую формулу с парой констант, которые работают "условно всегда" При этом в формуле есть множество значений, которые на предприятии ТОЧНО измерить невозможно =) И если подставлять неточные значения - получается неточный результат: Garbage in - garbage out =)
Дооборудовать более точными измерительными средствами обычно капец как дорого =) В итоге, как правило, для тех значений, которые не могут точно измерить, подбирают "поправочные коэффициенты", которые дают похожий на правду результат в большинстве случаев =) А остальную формулу используют "как есть" =)
У технологов процент попадания в этом наборе данных порядка 70 :)
У нашей команды результаты оцениваются несколько иначе, нежели было на хакатоне, мы используем кросс-валидацию результатов, потому напрямую сравнивать числа нельзя :)
Финальная точность на кросс-валидации у нас до хакатона чуть-чуть не дотягивала до опытного технолога, но при этом их (модели и технолога) ошибки нескоррелированы, что в целом все ещё может позволить улучшить производственные результаты за счёт такой модели :)
Участники подали несколько интересных идей с точки зрения генерации признаков, которые мы ранее не использовали, так что вероятно мы ещё улучшим качество)
А по температуре попадание - это меньшая из бед, там можно почти идеально качества добиться) с углеродом сложнее)
Во-первых, у нас используется не нейросеть, а ансамбль деревьев решений :)
В статье есть ссылка на библиотеку SHAP - она очень полезна для оценки влияния факторов на работу моделей :)
И строит очень удобные графики, которые мы с технологами нередко обсуждаем.
Что касается новых зависимостей: металлургия - очень старая и стабильная область :) глобальные зависимости уже все описаны, а локальные - непостоянны, а потому их описание не всегда имеет смысл :)
Как правило, если "новая" локальная зависимость сильно изменяет ход процессов, то в ее корне лежит поломка или нарушение регламентов, и это один из результатов ввода в эксплуатацию подобных экспертных систем: они позволяют диагностировать, если привычный ход процесса нарушен :)
А если что-то где-то сломано, то нужно не описывать это, а починить :)
Записать, что была поломка и провести расследование, конечно, тоже нужно, но это уже касается не оптимизации КХП, а задач predictive maintenance ;)
А про публичность и секретность приглашаю пообщаться через две недели на конференцию Saint HighLoad++ 2021, я там как раз чуть подробнее расскажу про технику касающуюся этого проекта и про "направленность на opensource" ;)
Есть, конечно, ретрограды принципиальные, но в большинстве случаев в руководстве сидят люди, по крайней мере, хорошо понимающие экономику :) и если объяснить им какую пользу для их интересов принесет проект (в данном случае повышение экономической эффективности предприятия) - одобрение получается довольно легко :)
А "в штыки" воспринимаются как правило идеи, которые не учитывают интересов спонсора/ЛПРа :)
И это так не только в бизнесе работает, как правило :)
По второму пункту - тоже все не очевидно, как раз потому, что первый пункт - далеко не всегда справедлив :) и большинство идей проектов "к нам в ИТ" приходят как раз с производства, а мы предлагаем только реализацию :)
И вот в этой ситуации получается прекрасный симбиоз, как получилось с пользователями нашего решения КХП: мы сделали реализацию, технологи используют и отслеживают совпадение поведения модели, их опыта и реальности, и в случае расхождений - приходят и говорят нам где нужны корректировки
И в такой ситуации в третьем пункте будет другой вопрос: не "что ещё можете предложить?", а "а вот это можете?" :)
И это прекрасно, потому что в финале наша общая цель сделать так, чтобы всем было хорошо :)
Доменная печь и коксовая печь - это разные вещи :) в данном случае это не доменная печь, а именно коксовая, то, что ниже названо "батареей"
Но "непрерывность" с математической точки зрения, то есть отсутствие "скачков" в параметрах, действительно отсутствует, т.к. периодически состав шихты меняется как раз резко, например, при смене сырьевой базы или смены бункера с которого подаются концентраты
За счёт чего модели опирающиеся на предыдущий результат по качеству ведут периодически к драматическим ошибкам :)
Ваше опасение понятно, но, на мой взгляд, не обосновано :)
Мы даже в посте постоянно обращаем внимание - модель не есть "истина в последней инстанции" :)
Модель - просто ещё один инструмент в руках человека.
Задача анализа данных и машинного обучения - не заменить, но обогатить человека, его знания и автоматизировать простые и легко формулируемые словесно действия :)
Если угодно - это "станок 21го века" :) и разве люди разучились шить, когда изобрели ткацкий станок?:) Нет, просто механика изменилась :) и появился "инженер по настройке ткацких станков" :)
Всю человеческую историю индивидуальное мастерство "запечатывается" в инструменты. Мастерство при этом не пропадает, просто становится нишевым, а массовый рынок заполняет товар ремесленный.
Но разве это плохо, что литой колесный диск стоит 3-4 тысячи рублей, а 40-50 как его кованые братья? :)
Боюсь, без измерений все заявления, что «будет быстрее» или «будет затрачиваться столько же времени» — беспочвенны, пока мы не проведём конкретный эмпирический тест, чистота которого, так или иначе, будет весьма сомнительна.
Однако, в целом, вы пишите фактически только про изолированность, документированность и чистоту кода.
Однако, микросервисы — это уход, в первую очередь, от инфраструктурных проблем.
Потому что монолит — требует, чтобы одна единственная машина могла предоставить все необходимые пакеты(модули) и все необходимые ресурсы требуемые для решения задачи одновременно.
Когда речь идёт о каком-нибудь многоуровневом стэке технологий(когда одни библиотеки опираются на кодовую базу других) — все хорошо.
А вот как только вы используете разноплановые библиотеки из разных технологических стеков — запуск и развертывание монолитного решения становится задачей почти фантастической, т.к. постоянно вылезают противоречивые требования или прямые несовместимости библиотек.
А вот когда дело доходит до обработки больших данных… ух. Тут микросервисы, каждый из которых должен анализировать свой кусок данных на недорогих инстансах 4+4(4 vCPU+4GB RAM), или давать быстрый ответ для пользователей в своей географической зоне — незаменимы.
К тому же, в тех же направлениях распределенных вычислений фрагментация пакетов-модулей — гораздо выше, чем в «традиционных» областях, что создаст огромное количество проблем при попытке обновления каких-то библиотек в монолите.
Так что — все зависит от поставленной задачи, которая диктует выбор технологического стэка(или россыпи).
Если ваша задача решается стэндалон, или единичным сервером на «стратифицированном» технологическом стэке — вполне вероятно, что монолит — будет хорошим решением.
Если же нужна распределенная система, или большое количество несвязных модулей/библиотек — добро пожаловать в микросервисную архитектуру.
Ну и CI/CD, как правило, все-таки гораздо легче, как минимум по машинным ресурсам — решается на микросервисах.
Лично не знаком с обсуждаемыми материалами, но знаю массу профессионалов, глядя на действия которых кажется, что они с ума сошли и им нужно подарить как минимум десять книг по ТБ.
Но когда спрашиваешь у них почему они так себя вели — они вполне обосновано объясняют почему не могло произойти того, от чего ты хотел защищаться)
Как известно — нет ничего более постоянного, чем временное =)
Видимо, при печати — ошиблись и записали не ту версию ОС, потом зачеркнули временно, с намерением потом перепечатать… да так и прижилось…
Слава богу, теперь такой проблемы не возникает и изменения вносятся сильно проще.
Есть давным-давно сформулированный закон научности:
Если гипотеза не может быть опровергнута в рамках эксперимента(наблюдения) — она не научна.
Так называемый принцип фальсифицируемости.
Я не работаю в Яндекс.Здоровье, но как понять успешность или безуспешность эксперимента должно быть сформулировано на этапе его постановки.
Например, «Если подбросив любой объект(и не воздействовать на него другими силами) в воздух на Земле — объект упадёт, то на Земле действует сила притяжения, если не упадёт — не действует».
В такой формулировке — все ещё возможна ошибка, если бросок намагниченного предмета произойдёт над линиями электропередач, которые сработают как магнит и оттолкнут его, но это поведение явно будет не вписываться в постановку эксперимента, а значит будет все ещё полезно, т.к. приведёт к пересмотру гипотезы.
Это, кстати, очень важная штука, о которой повсеместно забывают.
И тут речь не только о работе архитектора, но и о работе PM-а/TL-а, т.к. разработчик, который пишет код, в достаточно большом проекте единовременно может или охватить головой реализацию конкретной функции, или охватить её смысл в рамках проекта(а иногда в принципе этого не может, т.к. не обладает необходимыми познаниями в части технологического стэка). Точно также, как PM/TL/архитектор не может охватить реализацию конкретной функции.
В своей работе сейчас сталкиваюсь с этим.
В идеале, должно получаться разделение труда: Архитектор/PM/TL продумывает разделение решения на модули, каждый из которых решает конкретную задачу. На каждый из этих модулей составляется ТЗ/req.list, после чего разработчик уже не думает о том как этот модуль будет взаимодействовать с остальной системой — он думает о том, как наиболее эффективно и красиво реализовать функционал.
Это, конечно, не гарантирует, что решение будет легко поддерживать/разрабатывать и так далее, но, по крайней мере, снижает вероятность того самого страха из-за невозможности охватить мыслью всю структуру решения разом.
Очень жаль, что большая часть комментаторов так однобоко смотрит на ситуацию.)
Минцифры нужно отдать должное, они сделали невероятно много хорошего для ИТ специалистов работающих на российские компании. Более того, в определенные моменты показали высочайший уровень квалификации и понимания ситуации, например, когда началась мобилизация.
От себя, как от руководителя довольно крупного ИТ подразделения могу сказать разве что спасибо всем сотрудникам минцифры и лично Максуту Игоревичу :) Мои специалисты благодаря их действиям чувствуют себя существенно лучше и спокойнее, благодаря их усилиям.
Если получится создать конкурента ASML в любом смысле этого слова - никто не будет говорить про "выпуск только для армии". Экспорт начнется в тот же момент, когда за рубежом появится спрос, скорее всего :)
Но создать конкурента ASML... В мире это прямо сейчас никому не нужно настолько, чтобы в это инвестировать действительно серьезные средства, т.е. много триллионов долларов :)
Теоретически, в современной России может сложиться единственная точка на земле в обозримом будущем, где подобное может стать оправданным и осмысленным :) не более того
Обещания и реальность - штука сильно разная :)
Хотя история с безмасочной фотолитографией и звучит действительно очень перспективно, но подводных камней на этом пути - умопомрачительное количество. А потому ни одной оценке "за столько лет и денег - мы сделаем" я бы не верил :)
Любой кто хоть раз умудрился спроектировать и реализовать что-то более сложное, чем ножка для стула, понимает, что в серьезных разработках разброс затрат и сроков начинается от двухкратного х)
А не в курсе кто именно такие заявления делает? Я тут давече у коллег спрашивал, но первоисточника подобных высказываний мне так и не сдали :) а я бы посотрудничал :)
Я чуть-чуть перефразировал бы =)
Теория - даёт тебе точную и строгую формулу с парой констант, которые работают "условно всегда"
При этом в формуле есть множество значений, которые на предприятии ТОЧНО измерить невозможно =)
И если подставлять неточные значения - получается неточный результат: Garbage in - garbage out =)
Дооборудовать более точными измерительными средствами обычно капец как дорого =)
В итоге, как правило, для тех значений, которые не могут точно измерить, подбирают "поправочные коэффициенты", которые дают похожий на правду результат в большинстве случаев =)
А остальную формулу используют "как есть" =)
Надо понимать с чем сравниваться :)
У технологов процент попадания в этом наборе данных порядка 70 :)
У нашей команды результаты оцениваются несколько иначе, нежели было на хакатоне, мы используем кросс-валидацию результатов, потому напрямую сравнивать числа нельзя :)
Финальная точность на кросс-валидации у нас до хакатона чуть-чуть не дотягивала до опытного технолога, но при этом их (модели и технолога) ошибки нескоррелированы, что в целом все ещё может позволить улучшить производственные результаты за счёт такой модели :)
Участники подали несколько интересных идей с точки зрения генерации признаков, которые мы ранее не использовали, так что вероятно мы ещё улучшим качество)
А по температуре попадание - это меньшая из бед, там можно почти идеально качества добиться) с углеродом сложнее)
Во-первых, у нас используется не нейросеть, а ансамбль деревьев решений :)
В статье есть ссылка на библиотеку SHAP - она очень полезна для оценки влияния факторов на работу моделей :)
И строит очень удобные графики, которые мы с технологами нередко обсуждаем.
Что касается новых зависимостей: металлургия - очень старая и стабильная область :) глобальные зависимости уже все описаны, а локальные - непостоянны, а потому их описание не всегда имеет смысл :)
Как правило, если "новая" локальная зависимость сильно изменяет ход процессов, то в ее корне лежит поломка или нарушение регламентов, и это один из результатов ввода в эксплуатацию подобных экспертных систем: они позволяют диагностировать, если привычный ход процесса нарушен :)
А если что-то где-то сломано, то нужно не описывать это, а починить :)
Записать, что была поломка и провести расследование, конечно, тоже нужно, но это уже касается не оптимизации КХП, а задач predictive maintenance ;)
А про публичность и секретность приглашаю пообщаться через две недели на конференцию Saint HighLoad++ 2021, я там как раз чуть подробнее расскажу про технику касающуюся этого проекта и про "направленность на opensource" ;)
По первому пункту - очень и очень спорно :)
Есть, конечно, ретрограды принципиальные, но в большинстве случаев в руководстве сидят люди, по крайней мере, хорошо понимающие экономику :) и если объяснить им какую пользу для их интересов принесет проект (в данном случае повышение экономической эффективности предприятия) - одобрение получается довольно легко :)
А "в штыки" воспринимаются как правило идеи, которые не учитывают интересов спонсора/ЛПРа :)
И это так не только в бизнесе работает, как правило :)
По второму пункту - тоже все не очевидно, как раз потому, что первый пункт - далеко не всегда справедлив :) и большинство идей проектов "к нам в ИТ" приходят как раз с производства, а мы предлагаем только реализацию :)
И вот в этой ситуации получается прекрасный симбиоз, как получилось с пользователями нашего решения КХП: мы сделали реализацию, технологи используют и отслеживают совпадение поведения модели, их опыта и реальности, и в случае расхождений - приходят и говорят нам где нужны корректировки
И в такой ситуации в третьем пункте будет другой вопрос: не "что ещё можете предложить?", а "а вот это можете?" :)
И это прекрасно, потому что в финале наша общая цель сделать так, чтобы всем было хорошо :)
Мы делаем допущение, что параметры коксования за исключением помола и периода коксования достаточно стабильны :)
Как показывает практика такое допущение вполне оправдано :)
Технологии тоже не высказали к этому допущению критики.
Есть ещё соотношение сухого и мокрого коксования, они в нашем случае специфичны для каждого блока коксовых батарей и тоже фактически не меняются
Спасибо за то, что ответили :)
Доменная печь и коксовая печь - это разные вещи :) в данном случае это не доменная печь, а именно коксовая, то, что ниже названо "батареей"
Но "непрерывность" с математической точки зрения, то есть отсутствие "скачков" в параметрах, действительно отсутствует, т.к. периодически состав шихты меняется как раз резко, например, при смене сырьевой базы или смены бункера с которого подаются концентраты
За счёт чего модели опирающиеся на предыдущий результат по качеству ведут периодически к драматическим ошибкам :)
Ваше опасение понятно, но, на мой взгляд, не обосновано :)
Мы даже в посте постоянно обращаем внимание - модель не есть "истина в последней инстанции" :)
Модель - просто ещё один инструмент в руках человека.
Задача анализа данных и машинного обучения - не заменить, но обогатить человека, его знания и автоматизировать простые и легко формулируемые словесно действия :)
Если угодно - это "станок 21го века" :) и разве люди разучились шить, когда изобрели ткацкий станок?:) Нет, просто механика изменилась :) и появился "инженер по настройке ткацких станков" :)
Всю человеческую историю индивидуальное мастерство "запечатывается" в инструменты. Мастерство при этом не пропадает, просто становится нишевым, а массовый рынок заполняет товар ремесленный.
Но разве это плохо, что литой колесный диск стоит 3-4 тысячи рублей, а 40-50 как его кованые братья? :)
Не, зарплату не урезают, вроде :)
Такой цели точно не стояло!)
Вообще, в металлургии конкретные агрегаты оптимизированы вдоль и поперек, но между агрегатами простор для улучшений впечатляющий :)
Если есть вопросы - задавайте, будем рады ответить :)
Однако, в целом, вы пишите фактически только про изолированность, документированность и чистоту кода.
Однако, микросервисы — это уход, в первую очередь, от инфраструктурных проблем.
Потому что монолит — требует, чтобы одна единственная машина могла предоставить все необходимые пакеты(модули) и все необходимые ресурсы требуемые для решения задачи одновременно.
Когда речь идёт о каком-нибудь многоуровневом стэке технологий(когда одни библиотеки опираются на кодовую базу других) — все хорошо.
А вот как только вы используете разноплановые библиотеки из разных технологических стеков — запуск и развертывание монолитного решения становится задачей почти фантастической, т.к. постоянно вылезают противоречивые требования или прямые несовместимости библиотек.
А вот когда дело доходит до обработки больших данных… ух. Тут микросервисы, каждый из которых должен анализировать свой кусок данных на недорогих инстансах 4+4(4 vCPU+4GB RAM), или давать быстрый ответ для пользователей в своей географической зоне — незаменимы.
К тому же, в тех же направлениях распределенных вычислений фрагментация пакетов-модулей — гораздо выше, чем в «традиционных» областях, что создаст огромное количество проблем при попытке обновления каких-то библиотек в монолите.
Так что — все зависит от поставленной задачи, которая диктует выбор технологического стэка(или россыпи).
Если ваша задача решается стэндалон, или единичным сервером на «стратифицированном» технологическом стэке — вполне вероятно, что монолит — будет хорошим решением.
Если же нужна распределенная система, или большое количество несвязных модулей/библиотек — добро пожаловать в микросервисную архитектуру.
Ну и CI/CD, как правило, все-таки гораздо легче, как минимум по машинным ресурсам — решается на микросервисах.
Но когда спрашиваешь у них почему они так себя вели — они вполне обосновано объясняют почему не могло произойти того, от чего ты хотел защищаться)
Видимо, при печати — ошиблись и записали не ту версию ОС, потом зачеркнули временно, с намерением потом перепечатать… да так и прижилось…
Слава богу, теперь такой проблемы не возникает и изменения вносятся сильно проще.
Если гипотеза не может быть опровергнута в рамках эксперимента(наблюдения) — она не научна.
Так называемый принцип фальсифицируемости.
Я не работаю в Яндекс.Здоровье, но как понять успешность или безуспешность эксперимента должно быть сформулировано на этапе его постановки.
Например, «Если подбросив любой объект(и не воздействовать на него другими силами) в воздух на Земле — объект упадёт, то на Земле действует сила притяжения, если не упадёт — не действует».
В такой формулировке — все ещё возможна ошибка, если бросок намагниченного предмета произойдёт над линиями электропередач, которые сработают как магнит и оттолкнут его, но это поведение явно будет не вписываться в постановку эксперимента, а значит будет все ещё полезно, т.к. приведёт к пересмотру гипотезы.
И тут речь не только о работе архитектора, но и о работе PM-а/TL-а, т.к. разработчик, который пишет код, в достаточно большом проекте единовременно может или охватить головой реализацию конкретной функции, или охватить её смысл в рамках проекта(а иногда в принципе этого не может, т.к. не обладает необходимыми познаниями в части технологического стэка). Точно также, как PM/TL/архитектор не может охватить реализацию конкретной функции.
В своей работе сейчас сталкиваюсь с этим.
В идеале, должно получаться разделение труда: Архитектор/PM/TL продумывает разделение решения на модули, каждый из которых решает конкретную задачу. На каждый из этих модулей составляется ТЗ/req.list, после чего разработчик уже не думает о том как этот модуль будет взаимодействовать с остальной системой — он думает о том, как наиболее эффективно и красиво реализовать функционал.
Это, конечно, не гарантирует, что решение будет легко поддерживать/разрабатывать и так далее, но, по крайней мере, снижает вероятность того самого страха из-за невозможности охватить мыслью всю структуру решения разом.