Comments 15
Тема применения Python в металлургии не раскрыта. Если статью назвать "Python в машиностроении, станкостроении, приборостроении, угольной промышленности и тд", ничего не поменяется.
Я ожидал описания ПО на Python для получения данных с реверсивных станов холодной прокатки или контролем вентиляции в литейном цехе. Т.е. непосредственным взаимодействем специализированного ПО, оборудования и Python.
Благодарю за конструктивную критику. Однако столь широкую тему невозможно описать в одной статье. Начал с самого главного - людей и компетенций, в последующих статьях я и мои коллеги планируем затронуть более конкретные темы.
спасибо за статью. возможно когда-нибудь я смогу разработать что-то похожее и попроще для своей организации (но проблемы 2: я ни разу не программист и не у кого спросить), а в статье я как раз увидел то, что хотел - стек технологий.
пока что сам пользую python в jupyter notebooks, но жесть как не хватает нормальной бд, все лежит в экселях((
на сколько процентов сократились издержки или увеличилась прибыль(выручка, любой показатель роста) организации после всех этих изменений? Как считали экономическую выгоду?
Издержки моего рабочего времени сократились процентов на 20-30%.
Что касается команд, то тут все немного сложнее: стандарты, статьи, доклады и обмен опытом конвертируются в качество кода, а это достаточно субъективная оценка. Все, описанное в статье - это не про быстрый эффект, это про создание культуры разработки и унификацию подходов для снижения издержек не только прямо сейчас, но и в будущем.
Однако, все отзывы, которые я получал от разработчиков, руководителей проектов и высшего руководства, говорят об одном - стало лучше.
Прежде всего спасибо за интересный вопрос.
В продуктовых командах НЛМК может быть от одного до трех разработчиков, занимающихся развитием новых решений или поддержкой уже готовых. При малом количестве разработчиков в команде может уйти довольно много времни на нестандартный траблшутинг или на перепиливание функционала в случае выбора неверной архитектуры приложения или разногласия с админами и безопасниками. По всем необходимым вопросам мы всегда можем проконсультироваться на ретро, а также оценить качество кода, разобраться в новых библиотеках, познакомиться best practice и новыми подходами в разработке. Невозможно однозначно оценить экономиечскую выгоду, но путем несложных логических рассуждений можно выдвинуть следующие тезисы:
Лояльность пользователей приносит эконоимеческую выгоду
Качество разработки позитивно влияет на лояльность пользователей
Уровень разработчиков влияет на качество разработки
Доклады, статьи, ретро влияют на уровень и мотивацию разработчиков
Ну и всегда приятно пообщаться с единомышленниками, разумеется)
Спасибо за статью. Было интересно почитать о стеке технологий.
Еще интереснее было бы узнать, как вы используете Prometheus. Храните ли вы в нем данные от "технологического сегмента" (тренды технологических параметров, полученные от АСУТП), и если да, как осуществляется интеграция?
Это очень интересный вопрос, благодарю!
Если говорить о метриках приложений, то используются Prometheus/VictoriaMetrics и Grafana для отображения данных.
Но если мы говорим о различных данных тех или иных агрегатов из технологического сегмента, то тут все сильно сложнее. И поэтому как централизованное решение был создан отдельный внутренний продукт на базе ClickHouse, который позволяет решать большой спектр проблем. Подробнее об этом продукте, о причинах его создания и о принципах работы, мои коллеги расскажут в другой статьей.
А сколько у вас девопсов на "вот это все", если не секрет ? За статью спасибо.
Спасибо за интересную статью! А можно чуть подробнее узначть про сравнительный анализ в части выбора в пользу AIOHTTP? И еще очень интересно почитать про то как вы пришли к использованию orjson, ujson для сериализации json.
Про фреймворки. Сравнение различных библиотек и фреймворков проходило в несколько этапов. Сначала получил полный список модулей, которые удовлетворяют нашему стеку. Далее была составлена небольшая сравнительная таблица, где учитывались различные факторы, например, дата последнего коммита, частота выхода релизов, количество открытых issue на github, наличие адекватной документации, размер сообщества. Затем были отобраны те модули, которые удовлетворяли внутренним требованиям. И заключительный этап - реализация нескольких типовых приложений на каждом фреймворке. Со всеми испытаниям справился только aiohttp, поэтому он был выбран как основной инструмент.
Про orjson и ujson. Некоторые наши сервисы работают под высокой нагрузкой, а количество инстансов каждого измеряется десятками. Поэтому сериализация и десериализация JSON одно из мест, которое можно оптимизировать. Как правило, (де-)сериализация используется в двух местах - при получении/отправке сообщений из/в Kafka в формате JSON и при обработке запросов/ответов веб-сервера. В первом случае все сильно зависит от приложения, а вот со вторым случаем ситуация прозрачнее. В среднем, в наших сценариях удалось получить прирост производительности веб-сервера на 5-10%.
Если говорить о процедуре выбора, то все стандартно. Находим все интересующие библиотеки, пишем тест, прогоняем тесты и сравниваем результаты. По совокупности факторов выбираем желаемое.
Что-то из вредных советов, "Однако, в реальности всё немного иначе и на практике мои коллеги используют множество технологий. Это может быть C++ для низкоуровневой обработки данных или скрипты синхронизации, написанные на Bash, различные десктопные приложения, написанные на C# или PyQt, часто можно встретить серверы на NodeJS, но редко - приложения на R. "
Вот так точно не надо делать. Нужно собраться и решить на чем писать, должен быть стандарт, один-два языка, например для низкоуровневого один, для интерфейсов другой, хотя смотря какой язык выбрать, он может быть универсальным. Выбрать одну СУБД.
А так получится уйдет от вас программист который например на C# писал, а надо будет или расширить код или еще что-то....и возникнет большая проблема.
Благодарю за комментарий.
Если мы возьмем одно конкретное направление, то действительно все примерно так, как вы и сказали - единый стек технологий, который используют все разработчики этого направления для реализации типовых решений. Но если мы будем говорить о нестандартных ситуациях, то неправильно и вредно заставлять использовать инструмент, не подходящий для конкретной задачи, или инструмент, не удовлетворяющий требованиям задачи. Еще бывают ситуации, когда подходящего инструмента в нужном стеке нет вообще.
Для примера проиллюстрирую ситуацию. Мы создаем продукт и выбираем в качестве основной технологии Python, т.к. данный язык позволяет просто и быстро создать MVP продукта. Мы реализовали основные функции, однако на этапе разработки мы уже понимаем, что у нас есть одно узкое место, в котором нужен совершенно другого уровня язык - либо Go, либо С++. У нас микросервисная архитектура, поэтому не так важно на каком языке будет написан каждый сервис.
Точно так же, как и выбор СУБД. Для каждой задачи есть свой инструмент. Например, если мы создаем простой микросервис - в большинстве случаев подходит PostgreSQL, но это не означает, что PostgreSQL нужно использовать везде и всегда. Например, если нам важна транзакционность и скорость выполнения запроса, и при этом требуется построить большой кластер на терабайты данных, то скорее всего для этих целей подойдет сценарий, когда бизнес-логика будет расположена в процедурах Oracle DB или SQL Server. А если у нас большой объем данных и мы может осуществлять запись сразу большими порциями и мы знаем, что данные никогда не будут меняться, но при этом придется часто читать данные - для этих целей лучше подойдет ClickHouse. И таких ситуаций очень большое количество.
А так получится уйдет от вас программист который например на C# писал, а надо будет или расширить код или еще что-то....и возникнет большая проблема.
К счастью, такая ситуация крайне маловероятна, у нас много C# разработчиков.
Python в металлургической промышленности