Когда речь заходит о тяжелой промышленности и технологиях в ней, в большинстве случаев мы ожидаем услышать Java, а может быть и Java EE, или наоборот что-то очень низкоуровневое. Именно такие предположения я чаще всего слышу от друзей, когда рассказываю, где работаю.
Однако, в реальности всё немного иначе и на практике мои коллеги используют множество технологий. Это может быть C++ для низкоуровневой обработки данных или скрипты синхронизации, написанные на Bash, различные десктопные приложения, написанные на C# или PyQt, часто можно встретить серверы на NodeJS, но редко - приложения на R. Весь фронт мы стараемся писать на TypeScript (JavaScript), но иногда это реализовано через серверный рендеринг шаблонов и простой HTML. Это еще раз подтверждает очевидный факт - для каждой задачи свой инструмент.
Но что же с Python? В действительности мы часто используем Python. В этой статье я расскажу о том, зачем на металлургическом комбинате Python и с какими проблемами я столкнулся при работе над задачами.
Меня зовут Лев и я - Python разработчик в группе компаний НЛМК. Так вышло, что в зону моей ответственности попадает много различных проектов, а также в нее входит помощь коллегам с реализацией их задач. Поэтому моя работа сильно отличается от классической разработки по готовому техническому заданию. В этом есть свои плюсы и минусы, но в любом случае это интересно и, безусловно, это огромный опыт для меня.
Я мог бы рассказать про какой-то интересный случай использования Python для решения конкретной проблемы производства с применением Deep Learning. Но решил посвятить эту статью иным проблемам, а именно проблемам унификации подходов при разработке и внутреннего роста компетенций разработчиков.
Если сегментировать нашу разработку на Python, то ее можно разделить на три основные группы: оптимизация производства, внутренние продукты и интеграции.
Ежедневно появляются новые запросы на перенос данных из одного хранилища в другое, на получение доступа из одной подсистемы к другой, на потоковую обработку тех или иных данных. Большинство таких запросов выливаются либо в отдельные микросервисы, либо в полноценные внутренние продукты. Как правило, далеко не все потребности производства мы можем закрыть готовыми продуктами. Причин на это множество: от невозможности использовать готовое решение из-за огромного объема обрабатываемых данных до банального отсутствия таких решений на рынке.
Концептуально все подсистемы комбината делятся на 2 части - технологический и бизнес сегменты. Возможен только односторонний доступ из технологического сегмента в бизнес-сегмент, обратное невозможно из соображений информационной безопасности.
Бизнес-сегмент - зона, в которой мы можем строить связи между различными подсистемами. Именно об этой части и пойдет дальнейшее повествование.
Изначально, компоненты бизнес-сегмента представляли из себя набор виртуальных машин, выделяемых под тот или иной проект/команду с дальнейшей эксплуатацией систем. Если проектов немного, тогда никаких проблем в данной схеме не возникает. Однако, ранее я говорил, что у нас несколько десятков команд. Если каждой команде под каждый продукт будет выделяться отдельная виртуальная машина, то очень быстро это превратится в нечто не поддерживаемое. Для решения данной проблемы в НЛМК была создана Единая Цифровая Платформа, которая предоставляет большинство систем как сервисы.
Если коротко, то произошло примерно следующее:
Общая схема проектов
За время анализа я встретил значительное количество странного кода. Один раз я встретил Python код, который был полностью написан в стилистике Java. Иной раз это был файл на несколько тысяч строк с несколькими десятками функций, которые использовали глобальные переменные в качестве аргументов. В некоторых проектах разом использовались все парадигмы параллелизма и конкуренции - многопоточность, многопроцессорность и асинхронность. И многое-многое другое.
Все мы когда-то писали что-то странное и сложно объяснимое, однако, в рамках рабочих проектов такой подход вызывает много сложностей и болей. Сказать, что данный код не является поддерживаемым, это ничего не сказать. Как мне кажется, один из важнейших критериев любого проекта - его сопровождаемость. Поддерживать и как-либо модифицировать проект без документации, тестов и понятной структуры крайне сложно, а что более важно - дорого. Мы тратим время разработчика не на написание кода, а на понимание как этот код работает и зачем здесь тот или иной атрибут.
Самым первым и простым действом было создать пространство в Confluence и заполнить его базовой информацией. Затем создать проекты, которые показывают как работать с той или иной технологией правильно. После был сформирован план - определить стек технологий, разработать стандарты и начать развивать Python-сообщество.
С каждой неделей статей становилось всё больше и на данный момент в нашем пространстве содержится около 100 статей, посвященных разработке на Python. Кроме Python, конечно же, есть мир и вокруг, поэтому мы уделяем время и другим вопросам:
[tool.black]
multi-line-output = 3 # Многострочный вывод (3 - вертикально висячий) для совместимости с isort.
[tool.isort]
multi_line_output = 3 # Многострочный вывод (3 - вертикально висячий).
include_trailing_comma = true # Включает конечную запятую перед скобками в многострочных импортах.
force_grid_wrap = 0 # Принудительное оборачивание импортов в таблицу.
use_parentheses = true # Использует скобки вместо слеша для продолжения линии, превысившей лимит.
ensure_newline_before_comments = true # вставляет пустую строку перед комментарием после импорта.
line_length = 88 # Максимальная длина линии импорта.
[tool.pylint.messages_control]
disable = "C0330, C0326" # Отключить некоторые проверки для совместимости с SonarQube
[tool.pylint.format]
max-line-length = "88" # Максимальное количество символов в одной строке.
[tool.pytest.ini_options]
minversion = "6.2.5" # Версия pytest, начиная с которой будет работать этот файл (лучше указывать версию, которая установлена у вас).
testpaths = ["tests"] # Путь до папки с тестами (в данном примере папка лежит в корне).
[tool.coverage.run]
branch = true # Включает анализ покрытия по веткам, а не по стокам кода.
omit = [".venv/*", "tests/*"] # Файлы, которые не должны быть в отчетности или изменяться.
[tool.coverage.report]
omit = [".venv/*", "tests/*"] # Файлы, которые не должны быть в отчетности.
[tool.mypy]
ignore_missing_imports = true
# …
Кроме написания статей и ответов на конкретные вопросы, весь функционал, который может быть использован в других проектах, выделяется в отдельные библиотеки. Это в значительной степени снижает дублирование кода. Создаваемые библиотеки развиваются по модели OpenSource внутри компании, что позволяет привлекать значительное количество разработчиков для повышения качества кода.
Мы стараемся придерживаться использования отдельных библиотек, а не “комбайнов”. Это одна из причин, почему в рекомендуемом стеке технологий нет Django. Django - великолепный фреймворк. Но, к сожалению, данный фреймворк не подходит под наши цели и задачи.
Приложения, которые мы пишем, делятся на два типа:
Простые приложения, реализующие API интерфейс
Более сложные приложения
Для разрабатываемых приложений важна отказоустойчивость и возможность горизонтального масштабирования, к тому же почти все приложения запускаются в OpenShift. Чтобы реализовать подобные решения желательно придерживаться stateless концепции, а для оптимальной утилизации ресурсов наилучшим решением будет использовать асинхронные возможности Python, которые появились с 3.7 версии.
Проведя исследование и сравнив различные библиотеки и фреймворки, я остановился на двух представителях - AIOHTTP и FastAPI. Однако, в рамках наших проектов приоритет отдается именно AIOHTTP.
FastAPI. Всё же это фреймворк, хоть и легковесный. С другой стороны, как только заходит речь про асинхронную сторону вопроса, например, получать события из Kafka и отправлять пользователю по WS/SSE - с FastAPI появляются сложности.
В подавляющем большинстве случаев в качестве WEB сервера и клиента мы используем AIOHTTP. На текущем этапе развития данный пакет закрывает большую часть потребностей. Кроме того, большинство пакетов из aio-libs регулярно используются в нашей повседневной работе. Для работы с базами данных и миграциями применяются SQLAlchemy и Alembic соответственно.
После того, как был сформирован рекомендуемый стек и заполнены основные разделы, коллеги стали выражать большую заинтересованность и задавать вопросы. Таким образом стало формироваться внутреннее Python-сообщество.
Количество просмотров страниц Confluence в течение года
Однако у данного подхода есть и минусы - это сложно, отнимает много сил и требует достаточного количества знаний, и, к сожалению, все процессы проходят медленнее, чем хотелось бы.
habr.com
Однако, в реальности всё немного иначе и на практике мои коллеги используют множество технологий. Это может быть C++ для низкоуровневой обработки данных или скрипты синхронизации, написанные на Bash, различные десктопные приложения, написанные на C# или PyQt, часто можно встретить серверы на NodeJS, но редко - приложения на R. Весь фронт мы стараемся писать на TypeScript (JavaScript), но иногда это реализовано через серверный рендеринг шаблонов и простой HTML. Это еще раз подтверждает очевидный факт - для каждой задачи свой инструмент.
Но что же с Python? В действительности мы часто используем Python. В этой статье я расскажу о том, зачем на металлургическом комбинате Python и с какими проблемами я столкнулся при работе над задачами.
Меня зовут Лев и я - Python разработчик в группе компаний НЛМК. Так вышло, что в зону моей ответственности попадает много различных проектов, а также в нее входит помощь коллегам с реализацией их задач. Поэтому моя работа сильно отличается от классической разработки по готовому техническому заданию. В этом есть свои плюсы и минусы, но в любом случае это интересно и, безусловно, это огромный опыт для меня.
Я мог бы рассказать про какой-то интересный случай использования Python для решения конкретной проблемы производства с применением Deep Learning. Но решил посвятить эту статью иным проблемам, а именно проблемам унификации подходов при разработке и внутреннего роста компетенций разработчиков.
Если сегментировать нашу разработку на Python, то ее можно разделить на три основные группы: оптимизация производства, внутренние продукты и интеграции.
Оптимизация производства
Больше нескольких десятков разработчиков в дюжине команд, которые ежедневно работают над конкретными продуктами, цель которых - улучшить производство. Достичь этого можно различными методами - ускорить процессы, повысить безопасность участка, снизить количество брака, снизить количество вредных выбросов или уменьшить количество ручного труда. В данной группе значительно преобладает количество Python разработчиков и данное направление очень важное по многим причинам.Внутренние продукты
Кроме оптимизации производства, существуют различные проекты, связанные с внутренними продуктами. Над этими задачами работают несколько команд.Ежедневно появляются новые запросы на перенос данных из одного хранилища в другое, на получение доступа из одной подсистемы к другой, на потоковую обработку тех или иных данных. Большинство таких запросов выливаются либо в отдельные микросервисы, либо в полноценные внутренние продукты. Как правило, далеко не все потребности производства мы можем закрыть готовыми продуктами. Причин на это множество: от невозможности использовать готовое решение из-за огромного объема обрабатываемых данных до банального отсутствия таких решений на рынке.
Интеграции
В данную группу попадают разработчики, которые привлекаются для интеграции с различными системами. Например, для взаимодействия с SAP. Из-за того, что в данных направлениях используются специфические технологии, такие как IronPython и другие, это заслуживает отдельной статьи, поэтому оставим на будущее.Анализ
Работу над своими задачами я начал с анализа технологического ландшафта и проектов.Концептуально все подсистемы комбината делятся на 2 части - технологический и бизнес сегменты. Возможен только односторонний доступ из технологического сегмента в бизнес-сегмент, обратное невозможно из соображений информационной безопасности.
Ландшафт
Технологический сегмент - это всё, что связано с тем или иным агрегатом и его подсистемами управления.Бизнес-сегмент - зона, в которой мы можем строить связи между различными подсистемами. Именно об этой части и пойдет дальнейшее повествование.
Изначально, компоненты бизнес-сегмента представляли из себя набор виртуальных машин, выделяемых под тот или иной проект/команду с дальнейшей эксплуатацией систем. Если проектов немного, тогда никаких проблем в данной схеме не возникает. Однако, ранее я говорил, что у нас несколько десятков команд. Если каждой команде под каждый продукт будет выделяться отдельная виртуальная машина, то очень быстро это превратится в нечто не поддерживаемое. Для решения данной проблемы в НЛМК была создана Единая Цифровая Платформа, которая предоставляет большинство систем как сервисы.
Если коротко, то произошло примерно следующее:
- код приложений переехал в GitLab репозитории;
- bash скрипты запуска приложений превратились в Docker образы с хранением в jFrog Artifactory;
- виртуальные машины превратились в OpenShift кластера;
- файлы с логами переехали в ELK/Sentry/Jaeger;
- файловые хранилища переехали в S3 на базе Minio и HDFS;
- Basic Auth авторизация мутировала в SSO + ADFS на базе KeyCloak.
- Kafka
- NiFi
- SonarQube
- Matomo, аналог “Яндекс.Метрики”
- Prometheus/VictoriaMetrics
- Grafana
Проекты
По результатам анализа нескольких десятков различных продуктов стало понятно, что значительная часть Python продуктов, которые посвящены улучшению производства, имеют общую структуру:
- API - отвечает за авторизацию и общую полезную нагрузку
- Consumer - часть, которая потребляет данные из очередей, чаще всего из Kafka
- Model - математическая модель, которая позволяет решить ту или иную проблему
Проблематика
После анализа проектов и сбора информации, я смог сегментировать технические проблемы по следующим группам:- всё, что связанно с выбором библиотек и подходов;
- качество кода - нарушение принципов программирования и общепринятых практик;
- безопасность - авторизация, уязвимости - Cmd-Injection, SQL-Injection, etc …
- сопровождение - тесты, миграции, метрики, логи;
За время анализа я встретил значительное количество странного кода. Один раз я встретил Python код, который был полностью написан в стилистике Java. Иной раз это был файл на несколько тысяч строк с несколькими десятками функций, которые использовали глобальные переменные в качестве аргументов. В некоторых проектах разом использовались все парадигмы параллелизма и конкуренции - многопоточность, многопроцессорность и асинхронность. И многое-многое другое.
Все мы когда-то писали что-то странное и сложно объяснимое, однако, в рамках рабочих проектов такой подход вызывает много сложностей и болей. Сказать, что данный код не является поддерживаемым, это ничего не сказать. Как мне кажется, один из важнейших критериев любого проекта - его сопровождаемость. Поддерживать и как-либо модифицировать проект без документации, тестов и понятной структуры крайне сложно, а что более важно - дорого. Мы тратим время разработчика не на написание кода, а на понимание как этот код работает и зачем здесь тот или иной атрибут.
Пути решения
Потратив значительное время на размышления и попытки как-то всё систематизировать, я пришел к двум мыслям: что наилучшим решением будет двигаться поступательно и что быстрого решения нет.Самым первым и простым действом было создать пространство в Confluence и заполнить его базовой информацией. Затем создать проекты, которые показывают как работать с той или иной технологией правильно. После был сформирован план - определить стек технологий, разработать стандарты и начать развивать Python-сообщество.
Стандартизация
Стало очевидно, для снижения временных издержек необходимо прийти к некоторым стандартным практикам. Начал с простого, со списка принципов разработки - DRY/DIE, KISS, YAGNI, SOLID и Дзен Python. Следующими шагами стали введение общего Style Guide и написание различных внутренних статей о повышении качества кода.С каждой неделей статей становилось всё больше и на данный момент в нашем пространстве содержится около 100 статей, посвященных разработке на Python. Кроме Python, конечно же, есть мир и вокруг, поэтому мы уделяем время и другим вопросам:
- Как правильно писать Dockerfile?
- Зачем использовать [git|github|gitlab…] flow?
- Чем отличается Pod в OpenShift от виртуальной машины?
- Что такое идемпотентный метод в RESTful приложениях?
- trailing-whitespace
- end-of-file-fixer
- check-yaml
- check-added-large-files
- check-ast
- mypy
- black
- isort
- pylint
- darglint
- bandit
- vulture
Пример pyproject.toml
# …[tool.black]
multi-line-output = 3 # Многострочный вывод (3 - вертикально висячий) для совместимости с isort.
[tool.isort]
multi_line_output = 3 # Многострочный вывод (3 - вертикально висячий).
include_trailing_comma = true # Включает конечную запятую перед скобками в многострочных импортах.
force_grid_wrap = 0 # Принудительное оборачивание импортов в таблицу.
use_parentheses = true # Использует скобки вместо слеша для продолжения линии, превысившей лимит.
ensure_newline_before_comments = true # вставляет пустую строку перед комментарием после импорта.
line_length = 88 # Максимальная длина линии импорта.
[tool.pylint.messages_control]
disable = "C0330, C0326" # Отключить некоторые проверки для совместимости с SonarQube
[tool.pylint.format]
max-line-length = "88" # Максимальное количество символов в одной строке.
[tool.pytest.ini_options]
minversion = "6.2.5" # Версия pytest, начиная с которой будет работать этот файл (лучше указывать версию, которая установлена у вас).
testpaths = ["tests"] # Путь до папки с тестами (в данном примере папка лежит в корне).
[tool.coverage.run]
branch = true # Включает анализ покрытия по веткам, а не по стокам кода.
omit = [".venv/*", "tests/*"] # Файлы, которые не должны быть в отчетности или изменяться.
[tool.coverage.report]
omit = [".venv/*", "tests/*"] # Файлы, которые не должны быть в отчетности.
[tool.mypy]
ignore_missing_imports = true
# …
Кроме написания статей и ответов на конкретные вопросы, весь функционал, который может быть использован в других проектах, выделяется в отдельные библиотеки. Это в значительной степени снижает дублирование кода. Создаваемые библиотеки развиваются по модели OpenSource внутри компании, что позволяет привлекать значительное количество разработчиков для повышения качества кода.
Рекомендуемый стек
Разработка | Дополнительное |
| Web server: aiohttp, fastapi, flask Web client: aiohttp, requests DB: aiopg, asyncpg ORM: SQLAlchemy, alembic (De-)Serialization: marshmallow, pydantic Configuration: dynaconf, pydantic Template: jinja2 Redis: aioredis, redis-py RabbitMQ: pika, aio-pika Avro: avro, fastavro Kafka: aiokafka, confluent-kafka MinIO: aiobotocore, minio, boto3 SOAP Client: zeep SOAP Server: spyne JSON: orjson, ujson | Test libs: pytest, unittest Mock: unittest.mock Fake data: faker, factory_boy Coverage: coverage, pytest-cov Exceptions: sentry-sdk Metrics: prometheus-client, aioprometheus Trace: jaeger-client, opentelemetry-python Docs: pydoc3, sphinx |
Приложения, которые мы пишем, делятся на два типа:
Для разрабатываемых приложений важна отказоустойчивость и возможность горизонтального масштабирования, к тому же почти все приложения запускаются в OpenShift. Чтобы реализовать подобные решения желательно придерживаться stateless концепции, а для оптимальной утилизации ресурсов наилучшим решением будет использовать асинхронные возможности Python, которые появились с 3.7 версии.
Проведя исследование и сравнив различные библиотеки и фреймворки, я остановился на двух представителях - AIOHTTP и FastAPI. Однако, в рамках наших проектов приоритет отдается именно AIOHTTP.
FastAPI. Всё же это фреймворк, хоть и легковесный. С другой стороны, как только заходит речь про асинхронную сторону вопроса, например, получать события из Kafka и отправлять пользователю по WS/SSE - с FastAPI появляются сложности.
В подавляющем большинстве случаев в качестве WEB сервера и клиента мы используем AIOHTTP. На текущем этапе развития данный пакет закрывает большую часть потребностей. Кроме того, большинство пакетов из aio-libs регулярно используются в нашей повседневной работе. Для работы с базами данных и миграциями применяются SQLAlchemy и Alembic соответственно.
После того, как был сформирован рекомендуемый стек и заполнены основные разделы, коллеги стали выражать большую заинтересованность и задавать вопросы. Таким образом стало формироваться внутреннее Python-сообщество.
Внутреннее сообщество
На данный момент, наше Python-сообщество состоит из трех частей:- пространство в Confluence - много статей и ссылок, книги
- тематические чаты - у кого-то есть вопрос или смешной мем
- регулярные еженедельные миты - в неформальной обстановке каждый участник может рассказать про свой продукт или послушать про использование конкретной технологии
Заключение
От момента первых шагов прошло немногим меньше года и я могу с уверенностью сказать - описанный подход работает! Компетенции команд значительно выросли за этот период, а разработчики стали более вовлеченными в сообщество - пишут статьи, готовят доклады, спорят и вместе обсуждают технические решения. Систематизировались подходы и продолжают унифицироваться решения, как следствие, код становится чище, функциональнее и безопаснее.
Однако у данного подхода есть и минусы - это сложно, отнимает много сил и требует достаточного количества знаний, и, к сожалению, все процессы проходят медленнее, чем хотелось бы.
P.S.:
Выражаю благодарность коллегам из ЕЦП и ЦТ за помощь и участие.
Python в металлургической промышленности
Когда речь заходит о тяжелой промышленности и технологиях в ней, в большинстве случаев мы ожидаем услышать Java, а может быть и Java EE, или наоборот что-то очень низкоуровневое. Именно такие...
habr.com