Пять лет назад у нас почти не было собственной разработки бэка: очень многие вещи делались силами подрядчиков, вендорами и командами поддержки. «Почти не было» — потому что всё же было много SAP и легаси-систем, разработанных, например, на Oracle, которые не менялись по многу лет.
Если производству было нужно что-то кастомное, то можно было взять готовый кубик у вендора и аккуратно доточить его напильником силами команды интегратора либо же перетоптаться.
Сейчас у нас есть собственная микросервисная разработка. В целом в бекэнде — около 200 разработчиков, которые пишут на современном технологическом стеке.
Административно всё устроено так: есть профильные и функциональные центры компетенций, например, есть первые переделы (обработка руды и всё такое), есть прокатное производство, есть выплавка, есть ремонты, есть HR-системы и так далее. Функционально все бекэнд-разработчики объединены в нашем Центре компетенций. Я и лидеры гильдии отвечаем за соответствующие стеки.
Мы не трогаем уровень микроконтроллеров технологического оборудования, не лезем в АСУ ТП (там есть отдельное подразделение со своей атмосферой), поэтому основная часть нашей работы находится на уровне управления производством. Есть ещё системы управления закупками, продажами, логистикой, планирования на различном уровне.
Значительная часть наших задач — разработка цифровых помощников, оптимизаторов производства и многих других вещей, про которые вы уже несколько лет читаете у нас в блоге на Хабре. Мы делаем архитектуру, логику, реализацию под конкретное производство и контрибьютим это в свой набор компонентов.
Административное устройство
Тут всё сложно и достаточно запутанно, потому что производство огромное, и многие вещи долго развивались исторически по своим путям. Как я говорил, все бекэндеры объединены в нашем Центре компетенций. Я как его руководитель управляю стандартами разработки и стеком, по сути.
Конкретные задачи на разработку внутри профильных или функциональных отделов ставят руководители команд. То есть по матрице они говорят, что делать, а мы — как. Сами задачи приходят от бизнеса, от руководителей проектов. В этих рамках есть проектные, а также продуктовые треки.
Разработка ведётся на базе нескольких инфраструктурных слоёв. Например, у нас есть Единая цифровая платформа (ЕЦП) — это набор сервисов вроде Кафки, Графаны, Артифактори, контейнеризации, трассировки и так далее. Через ЕЦП делается CI/CD-процесс в технически зрелых системах. То есть вы можете накодить что-то вроде прототипа, и если он покажет ожидаемый эффект — нужно будет его индустриализовать, подготовить для запуска в корпоративной среде, покрыть документацией и, вероятно, отрефакторить на нашем стеке в правильной архитектуре, пройдя дополнительные процедуры безопасности.
У каждого направления производства есть архитекторы, у которых есть мысль. Они определяют (или подтверждают) архитектуру более-менее крупных решений.
Сейчас мы вводим институт СТО, когда в каждом домене будет ещё и техлидер. Точнее, четверо уже есть: масштабируем опыт.
Поверх всего этого у нас есть гильдии, по каждому стеку — своя. Весь бекэнд представлен несколькими гильдиями. Есть гильдия Java, есть гильдия С#, .NET, гильдия Python, есть гильдия PL/SQL общий и по используемым частям техстека.
Фронт и тестировщики живут отдельно в своих крупных центрах компетенций с похожей архитектурой.
Стек
Основа — микросервисная архитектура на базе нашей ЕЦП, Джава. Есть некоторые системы на Шарпе, Пайтоне, .NET, на Голанге, отдельно есть легаси- и вендоровские системы.
Техрадар: вот так это выглядит снаружи
У нас есть корпоративные требования и стандарты разработки, но это не железобетонные условия: в ряде случаев, когда есть целесообразность, можно защитить отступление от этого стека. То есть конкретные решения принимаются по целесообразности и защищаются на архитектурных советах соответствующего уровня, а уровней у нас три.
Например, если вам нужно затащить какой-то отличный от обычного кусок стека (вендора или язык, например), то для прототипа это можно сделать (конечно, всё равно какое-то согласование потребуется). А для индустриально зрелого решения — уже пройти полноценную валидацию и обсудить, как это будет масштабироваться.
Несмотря на то, что мы все идём в сторону Джавы, распиханной по контейнерам, в случае какой-то необходимости и невозможности запустить сервис на системе контейнеризации применяются виртуалки. Например, ML-команды чаще всего пишут на Пайтоне (и он хорошо ложится на нашу платформу, когда используются утверждённые фреймворки и подходы к разработке) — это часть основного стека.
То есть в целом мы отвечаем за всю кастомную разработку в основе своей. Вот ЕЦП, на базе которой ведутся работы:
Исторически у нас было много Оракла, включая очень древний. Я даже встречал во время рефакторинга комментарии из 1999 года: это кто-то из разработчиков передал мне привет из прошлого века. Собственно, на производстве было много ораклистов, и первые джава-разработчики как раз переучивались с него и с SAP. Сейчас штатных джаваистов — более 60 человек. Кстати, новые системы мы делаем на 21-й Джаве.
Потом был большой период, когда мы договаривались про индустриализацию и стандартизацию. Сейчас основные части более-менее устоялись, многие из самопальных решений, которые делались по производственной необходимости в то время, когда ещё не устоялись стеки и стандарты, были частично или полностью переписаны и попали в наш контур ЕЦП. Для этого нужно было отрефакторить их под наши стандарты, то есть повысить зрелость. Это тот самый процесс, когда от прототипа «на коленке» вы переходите к компоненту или сервису, который контрибьютится в платформу и может быть растиражирован по всей группе компаний:
По сути, мы участвуем в трансформации каждой ветви производства и вспомогательных систем. На каждое направление есть набор проектов, мы их развиваем или поддерживаем. Когда нужна новая система, создаётся новый проект. Начинается он с выбора архитектуры: встречаются солюшн-архитектор, системный архитектор, команда от нас, и все обсуждают варианты, просчитывают каждый, решают, как делать.
Челленджим какое-то решение: «Да, мы можем это сделать на 1С. Можем кастом. Да, на 1С дешевле и быстрее, но кастом даст вот это и это, больше синергии в дальнейшем. Сделаем из этого вот такие базовые сервисы, можно будет их переиспользовать».
Иногда к нам приходят подразделения за доработками в профильные вендорские продукты, тогда из панели подрядчиков мы выделим тех, кто может с этим помочь. У нас есть штатные сотрудники, есть разные модели сорсинга. Ресурсами подрядчиков мы управляем очень хорошо, штат стараемся без необходимости не увеличивать, но практикуем подход, чтобы на ключевых позициях были наши штатные сотрудники.
Сейчас планируется, что, кроме сервисов в ЕЦП, будут ещё платформы переиспользуемых сервисов, универсальные — как на уровне компании, так и на уровне отдельных доменов. Например, вроде сервиса нотификаций, чтобы ими могли пользоваться команды из разных доменов.
Процессы разработки всё ещё меняются: как я говорил, например, мы работаем над централизованным процессом управления техдолгом. Мы, с одной стороны, прекрасно понимаем, что это такое, и умеем ставить в него вещи вроде необходимости подтянуть версии библиотек или вообще весь стек. С другой — сейчас это делается в полуручном режиме, а хочется, чтобы был единый процесс и его понимали в том числе руководители функциональных команд. Сейчас мы иногда находим какие-то легаси-сервисы на восьмой Джаве. С ними так: каждый раз решение принимается по производственной и экономической необходимости. Если она есть — рефакторим или переписываем, а если нет и можно позвать человека, который одним метким ударом всё поправит, — скорее второе. Единого принципа пока нет, смотрим на ситуацию, решаем.
Крупные проекты, которые затрагивают всё производство, вырастают из потребностей сразу нескольких отделов. Например, HR-система выросла через первоначальное ограниченное внедрение, доказательство эффективности, а потом раскатилась на всех.
История с тем, что мы обновили физический инфраструктурный слой, а именно взяли pLTE + 5G для камер в цехах и смогли добавлять их данные в любой код, — это итерационная история. Сначала команда ML поставила несколько камер «на коленке» со странными каналами связи. Потом их камеры в сочетании с моделями начали приносить огромную пользу (например, вот или вот), и стало понятно, что всё это надо выносить в требования к инфраструктуре. В таких случаях нет единого мегамозга-архитектора, есть потребность производства, которая обсуждается группой, а дальше принимается стратегическое решение.
В целом
Я четыре года занимаюсь бэком НЛМК и вижу, как всё меняется. Самое важное — мы ушли от традиционного для производств легаси (по большей части) и смогли выстроить процессы на очень современном стеке, который постоянно актуализируется.
Второе важное — при этом мы не закрутили гайки, то есть у нас разработка намного свободнее, чем в тех же банках, и в целом свободнее, чем в производственной индустрии. Команды не обязательно очень жёстко следуют корпоративным стандартам, хотя они есть. Если целесообразно — можно отходить. Разработчик всё же создаёт, а не собирает из готовых кубиков. Да, мы стараемся не плодить зоопарк, но можем вносить реально нужное.
В качестве тимбилдинга у нас аварийные ночные чатики, когда мы вместе что-то чиним. MES, конечно, напрямую производство не останавливает, но часов 8–10 простоя всё же скажутся на том, что не придёт следующее суточное задание, поэтому некоторые вещи нужно чинить очень оперативно.
Примерно вот так у нас устроен бекэнд НЛМК.
Автор: WhiteSteel
