Python в металлургической промышленности

Kate

Administrator
Команда форума
Когда речь заходит о тяжелой промышленности и технологиях в ней, в большинстве случаев мы ожидаем услышать Java, а может быть и Java EE, или наоборот что-то очень низкоуровневое. Именно такие предположения я чаще всего слышу от друзей, когда рассказываю, где работаю.

Однако, в реальности всё немного иначе и на практике мои коллеги используют множество технологий. Это может быть C++ для низкоуровневой обработки данных или скрипты синхронизации, написанные на Bash, различные десктопные приложения, написанные на C# или PyQt, часто можно встретить серверы на NodeJS, но редко - приложения на R. Весь фронт мы стараемся писать на TypeScript (JavaScript), но иногда это реализовано через серверный рендеринг шаблонов и простой HTML. Это еще раз подтверждает очевидный факт - для каждой задачи свой инструмент.

Но что же с Python? В действительности мы часто используем Python. В этой статье я расскажу о том, зачем на металлургическом комбинате Python и с какими проблемами я столкнулся при работе над задачами.

a4c36faa4a72c5466eaff38579d3ef4e.jpg

Меня зовут Лев и я - 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 - математическая модель, которая позволяет решить ту или иную проблему
Описанную структуру имеют не все проекты, некоторые имеют более сложную структуру и иные механики или, наоборот, более простую. В части проектов используется Machine Learning модель, а где-то используется Deep Learning.

Проблематика​

После анализа проектов и сбора информации, я смог сегментировать технические проблемы по следующим группам:

  • всё, что связанно с выбором библиотек и подходов;
  • качество кода - нарушение принципов программирования и общепринятых практик;
  • безопасность - авторизация, уязвимости - 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 приложениях?
Статьи - это прекрасно, но нужны инструменты, которые помогут разработчикам избежать рутинных задач. Для решения данной проблемы мы создали типовой pyproject.toml, в котором описали настройки для различных линтеров и форматтеров. Для запуска всех необходимых проверок у нас рекомендуется использовать pre-commit. Примерный список плагинов, которые мы используем в pre-commit:

  • 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
Мы стараемся придерживаться использования отдельных библиотек, а не “комбайнов”. Это одна из причин, почему в рекомендуемом стеке технологий нет Django. Django - великолепный фреймворк. Но, к сожалению, данный фреймворк не подходит под наши цели и задачи.

Приложения, которые мы пишем, делятся на два типа:

Простые приложения, реализующие API интерфейс
Простые приложения, реализующие API интерфейс
Более сложные приложения
Более сложные приложения
Для разрабатываемых приложений важна отказоустойчивость и возможность горизонтального масштабирования, к тому же почти все приложения запускаются в OpenShift. Чтобы реализовать подобные решения желательно придерживаться stateless концепции, а для оптимальной утилизации ресурсов наилучшим решением будет использовать асинхронные возможности Python, которые появились с 3.7 версии.

Проведя исследование и сравнив различные библиотеки и фреймворки, я остановился на двух представителях - AIOHTTP и FastAPI. Однако, в рамках наших проектов приоритет отдается именно AIOHTTP.

FastAPI. Всё же это фреймворк, хоть и легковесный. С другой стороны, как только заходит речь про асинхронную сторону вопроса, например, получать события из Kafka и отправлять пользователю по WS/SSE - с FastAPI появляются сложности.

В подавляющем большинстве случаев в качестве WEB сервера и клиента мы используем AIOHTTP. На текущем этапе развития данный пакет закрывает большую часть потребностей. Кроме того, большинство пакетов из aio-libs регулярно используются в нашей повседневной работе. Для работы с базами данных и миграциями применяются SQLAlchemy и Alembic соответственно.

После того, как был сформирован рекомендуемый стек и заполнены основные разделы, коллеги стали выражать большую заинтересованность и задавать вопросы. Таким образом стало формироваться внутреннее Python-сообщество.

Внутреннее сообщество​

На данный момент, наше Python-сообщество состоит из трех частей:

  • пространство в Confluence - много статей и ссылок, книги
  • тематические чаты - у кого-то есть вопрос или смешной мем
  • регулярные еженедельные миты - в неформальной обстановке каждый участник может рассказать про свой продукт или послушать про использование конкретной технологии
Для поддержания интереса к технологиям и развития команд проводятся отдельные тематические сессии, доклады и презентации.

Заключение​

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

Количество просмотров страниц Confluence в течение года
Количество просмотров страниц Confluence в течение года
Однако у данного подхода есть и минусы - это сложно, отнимает много сил и требует достаточного количества знаний, и, к сожалению, все процессы проходят медленнее, чем хотелось бы.

P.S.:​

Выражаю благодарность коллегам из ЕЦП и ЦТ за помощь и участие.

 
Сверху