Мы смогли выстроить процессы на очень современном стеке, а не сидеть на легаси вечно

— Меня зовут Юрий Дворжецкий, я руковожу отделом бэкенд-разработки на НЛМК. Ещё пять лет назад у нас было мало собственной разработки бэка, а сейчас две сотни специалистов, которые пишут код.

Немного о нашей истории и структуре подразделения

— Всего пять лет назад в НЛМК многое делалось подрядчиками, вендорами и командами поддержки. Сейчас у нас собственная микросервисная разработка. Мы занимаемся разработкой информационных систем — как непосредственно связанных с производственными процессами (например, обработка руды, прокатное производство, выплавка, ремонты), так и вспомогательных (для HR, логистики, планирования и прочее). Пишем микросервисы преимущественно на Java и размещаем это на своей платформе, которая обеспечивает выполнение прикладных микросервисов

В целом в бэкенде около 200 разработчиков (внутренняя команда и подрядчики), которые пишут на современном технологическом стеке. Каждый разработчик работает в продуктовой или проектной команде, прикрепленной к определенному функциональному направлению.

Структурно у нас есть гильдии разработки, в том числе несколько гильдий бэкенда — Java, Python, Докнет. Гильдии отвечают за стандарты, развитие сотрудников, горизонтальные перемещения. А функционально сотрудники находятся в профильных центрах компетенции и работают над проектами и продуктами конкретных направлений. Задачи на разработку внутри функциональных отделов ставят руководители команд. То есть по матрице они говорят, что делать, а мы — как.

Есть некоторые отличия в проектных и продуктовых командах. В проектном треке все строго: сначала идет этап проработки задачи, а потом проекты выполняются по утвержденному ТЗ. А в продуктовом треке история более гибкая. Задачи формируются владельцем продукта и приходят в команды разработки через деливери-менеджера, тут мы придерживаемся гибких методологий разработки и скрамоподобных фреймворков.

«А вы перепрошиваете станки?» — о задачах и стеке

— Нет. Мы не трогаем уровень микроконтроллеров технологического оборудования, не лезем в АСУ ТП (там есть отдельное подразделение), поэтому основная часть нашей работы находится на уровне управления процессами в производстве, закупках, продажах, логистике, планировании и т.д. на различном уровне.

Значительная часть наших задач — разработка цифровых помощников, оптимизаторов производства и многих других вещей. Мы делаем архитектуру, логику, реализацию под конкретное производство и контрибутим это в свой набор компонентов.

У нас есть единая цифровая платформа — это совокупность инфраструктурных сервисов вроде Kafka, Grafana, Artifactory, контейнеризации, трассировки и так далее, которые обеспечивают весь жизненный цикл прикладных сервисов и приложений — от этапа создания до продуктивной эксплуатации, логирования, мониторинга и т.д.

Основа микросервисной архитектуры на Java. Есть некоторые системы на .NET, с Sharp, Python, на Go, отдельно есть легаси-системы и системы подрядчиков.

Несмотря на то, что мы все идем в сторону Java, разложенной по контейнерам, в случае какой-то необходимости и невозможности запустить сервис на системе контейнеризации применяются виртуалки. Например, ML-команды постоянно пишут на Python (и он хорошо индустриализуется, если использовать паттерны, позволяющие осуществлять нормальный мониторинг), это часть основного стека. Из редкого, например, для определённой видеообработки на HighLoad, понадобилось использовать C и физическую машину с кластером видеокарт. Обсудили с архитектором, поняли, что масштабировать это шансов мало, но для конкретного решения целесообразность перекрывает все минусы для корпоративной среды. И теперь это крутится на C на своей машине. И так далее.

У нас есть корпоративные требования и стандарты разработки, но это не железобетонные условия — в ряде случаев, когда есть целесообразность, можно защитить отступление от этого стека. То есть конкретные решения принимаются по целесообразности. Например, если вам нужно затащить какой-то отличный от обычного кусок стека (вендора или язык, например), то для прототипа это можно сделать (конечно, всё равно какое-то согласование потребуется). А для индустриально зрелого решения — уже пройти полноценную валидацию и обсудить, как это будет масштабироваться.

Самое важное — мы ушли от традиционного для производств легаси (по большей части) и смогли выстроить процессы на очень современном стеке, который постоянно актуализируется.

Наши новые проекты

— Мы активно разрабатываем новые информационные системы, есть много программ и проектов, в которых непочатый край работы. Они охватывают весь спектр задач и по управлению производством, и смежных тоже, которых очень много на таком крупном предприятии. Используем продуктовые и проектные подходы, делаем POC и MVP, убеждаемся в том, что концепция рабочая и переходим в полномасштабные проекты или продукты.

Мы не закрутили гайки, и у нас разработка намного свободнее, чем в тех же банках, и в целом свободнее, чем в производственной индустрии. Команды не обязательно очень жестко следуют корпоративным стандартам, хотя стандарты, конечно, есть. Но если целесообразно — можно отходить. Разработчик все же создает, а не собирает из готовых кубиков. Мы стараемся не плодить зоопарк, но можем вносить реально нужное.

Кто определяет архитектуру

— У нас есть несколько уровней архитектурных советов, на которых принимаются различные ADR и решаются архитектурные развилки. Внутри каждого направления производства — архитекторы: кооперативные, ИБ, инфраструктурные и солюшн-архитекторы, которые непосредственно проектируют решения и осуществляют архитектурный надзор над их реализацией.

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

Как устроена работа

— Айтишники в основном работают на удаленке. Для тех, кто работает на площадках и часто бывает в московском или в липецком офисах, есть вся необходимая для работы техника и девайсы.

Распределение рабочего времени зависит от конкретной команды. Лишними встречами не перегружаем. Обычно есть короткие дейли и участие в ритуальных встречах вроде стендапов и ретро плюс общение с коллегами, остальное — самостоятельная работа.