Цифровая трансформация уже перестала быть модным термином, а стала необходимостью для крупных компаний. Приходится быстро внедрять новые технологии и по‑новому смотреть на роль IT. Конечно, это не всегда просто. У каждого производства своя специфика, куча устаревших систем и разнородные IT‑ландшафты, требующие гибких и масштабируемых решений. Поэтому многие компании делают ставку на создание единой технологической платформы, централизованной экосистемы сервисов и инструментов, которая позволяет ускорить разработку, повысить повторное использование решений и снизить издержки на интеграцию.
Привет, Хабр! Я Александр Лищук из команды технологической платформы НЛМК ИТ. Спойлер — это про централизованные сервисы около DevOps, Kubernetes, стриминг вокруг Kafka и так далее. Расскажу, зачем и по каким принципам мы ее строили, что получилось неплохо и что рекомендуем. Обо что споткнулись и всем советуем там не спотыкаться.
О компании
Группа НЛМК — крупный международный производитель стали. В компании работает 44 тыс. человек. Мы производим сталь всевозможных видов, большая часть из них окружает нас прямо сейчас. Компания НЛМК ИТ движет НЛМК к индустрии 4.0. У нас больше тысячи IT‑специалистов, очень широкий стек и множество различных проектов и продуктов, в том числе гильдии по IT‑компетенциям.
Начну издалека.
Мотивация
Какое-то количество лет назад в НЛМК было классическое хорошее крепкое IT, состоящее из разных функциональных направлений: системы управления предприятием, интеграции, производственные системы, различные площадки и так далее. И было принято стратегическое решение о цифровой трансформации компании.
Про цифровую трансформацию много разного интересного сказано и написано, но мне очень нравится формулировка, что это — превратить IT в полноценного бизнес-партнера. А это значит, что не только быстрее, выше и сильнее (это и так база), а позволить IT искать новые способы реализации бизнеса в цифре. А это уже подразумевает много экспериментировать, соединять несоединяемое и вообще привнести атмосферу стартапов.
Чтобы все побыстрее привыкали к словосочетанию «канареечный деплой в цехе», не спорили, как какой кубер разворачивать, не пилили одни и те же сервисы, не решали одни и те же проблемы, следующим решением было строить цифру на базе единой цифровой платформы (сокращенно ЕЦП).
Задача платформы — это перейти к shift-down парадигме разработки. Это когда мы большинство рутины, проблем и задач спускаем вниз на ребят, которые либо уже об этом заранее подумали и позаботились, либо могут предложить переиспользовать чьи-то уже готовые хорошие решения и не тратить лишнее время и деньги.
В этом ключе единая цифровая платформа — это не конкретный набор технологий и четких функций, кластеров и так далее. Это, в том числе, процессы и методологии, готовые переиспользуемые сервисы, например, application слоя или целые продукты. При этом платформа постоянно развивается и меняется.
Со временем внутри единой цифровой платформы можно обозначить отдельно выделившуюся технологическую платформу. Она базируется на инфраструктурной платформе, и расширяет ее возможности. Предоставляет централизованные сервисы для разработки, поставки кода, в целом для DevOps какие-то недостающие компоненты, или базовые сервисы для приложений. Также для runtime предоставляет системы оркестрации контейнеров Kubernetes. И дополнительно еще параллельно слой сервисов для поставки данных от источника до конечных систем, допустим, аналитических или timeseries хранилищ. Попутно ETL сервисы для обработки этих данных. Сверху мы стараемся все это максимально закрыть self-service порталом, дополнительно предоставляя также расширенный клиентский сервис.
На самом деле это один из ракурсов, как можно посмотреть на ЕЦП. На базе технологической платформы и дополнительных компонентов (например, дизайн-системы, различных процессов, и т.п.) уже развиваются прикладные платформы внутри компании.
Технологическая платформа это:
сотни проектов и систем
тысячи пользователей сервисов
тысячи предоставляемых экземпляров сервисов (такие ресурсы как, например, k8s namespace, realm в Keycloak и т.д.)
миллионы сообщений в секунду в data stream
Всем этим хозяйством управляет небольшая команда, образующая центр компетенций, так как стараемся идти в self-service и автоматизацию.
Прежде чем перейти к тому, как мы это начинали, пара слов об особенностях, которые нужно учитывать при проектировании платформы конкретно у нас.
Особенности индустрии
Реальное производство и уникальные площадки
Подразумевается, что в компании с 90-летней историей есть процессы, отлитые в граните. Каждая площадка сама по себе может быть уникальной, где-то закрытые сегменты и так далее. Соответственно, довольно сложно спроектировать платформу как какую-то коробочку, которую ты потом просто тиражируешь от площадки к площадке, предоставляя сквозной одинаковый сервис. Изначально мы приняли стратегию, что строим core (ядро), и оно постепенно расползается по всей кампании как можно более естественным путем.
Гибридные решения: industrial + legacy + new
Мы остаемся в парадигме гибридных решений. Никуда не денутся индустриальный софт, индустриальные стандарты. Плюс то, что все так любят называть legacy, на самом деле это софт, на котором производство зиждется. Он тоже никуда не денется, потихонечку будет развиваться и меняться. И тут не пройдет простая парадигма, что все что разворачивается внутри платформы; то круто, это мы отлично будем с платформой интегрировать, а все, что снаружи — ну, извините. То есть все сервисы технологической платформы должны так или иначе позволять быть используемыми точечно или частями, без необходимости миграции продукта целиком на платформу.
In-House & Outsource
Мы не ударяемся полностью в in-house разработку. Мы также гибридно развиваем внутреннюю разработку, но при этом сохраняем outsource. И от готовых хороших коробочных решений никогда нельзя отказываться. В этом случае нужно учитывать, что решения в платформе должны быть абсолютно всем понятными: как внутри, так и подрядчикам. И никакого диктата стека, стек должен поддерживаться максимально широкий.
Перейдем уже непосредственно к тому, как мы это начинали.
Старт развития стека
В первую очередь внутри команды технологической платформы мы сосредоточились на двух одновременных направлениях: сервисы для DevOps и для поставки данных.
Постепенно наращивали в рамках техрадара набор технологий и решений:
Наставничество
На начальных этапах (неважно, это коробка или вы делаете это сами) всегда есть период наставничества. Возможно, это не очень удачное слово, но смысл в том, что в начале нас спрашивают, как решить ту или иную проблему, и мы рассказываем, предлагаем технологии или подходы. Со временем все начинает смещаться больше в продуктовый подход. Когда уровень адаптации всего стека технологии возрастает, нам уже начинают рассказывать, что нужно и как.
Opensource*
Важное решение, которое мы для себя приняли, — это сохранять приверженность opensource. Тут со звездочкой, потому что вначале мы позаигрывали с OpenShift, но нам пришлось в итоге от него отказаться.
«Better value sooner safer happier»
Сам процесс формирования стека и работы над ним, его роста, был по принципу: как можно больше эффектов на старте, потом возвращаемся и допиливаем. То есть мы непрерывно, спирально ходим по нашему набору сервисов, непрерывно их дорабатываем. Нет такого, что сразу все сделали и забыли, и переходим, скажем, в уровень поддержки. И по сути, мы постоянно девопсим для девопсов.
«Eat your own dog food»
Нужно пользоваться своими сервисами самим. И именно по тем правилам, которые мы даем пользователям. Иначе мы просто не поймем, насколько они хороши. Исключений желательно не допускать. Согласно этому принципу, мы сформировали смешанную команду. То есть ребята, которые занимаются data-слоем, ребята, которые занимаются чисто devops и kubernetes, все вместе общаются и переиспользуют друг у друга сервисы.
Вовлечение мягкой силой
Говоря о процессах распространения и вовлечения, называть это стратегией мягкой силы, наверное, громко, но идея созвучная. Мы все понимаем и признаем, что съесть слона сразу довольно сложно и насильно никому мил не будешь, но:
Без лишних «велосипедов»
Спасибо коллегам, они разработали процесс интеграционного цикла. Когда прорабатывается каждая новая идея (продукта, системы, внедрения), ребята из разных команд, в том числе, платформенной, подключаются и смотрят. Если кто-то пытается что-то развернуть у себя, и это есть в стеке техплатформы, то чаще всего в этом нет никакого смысла — заходите к нам, мы, если что, это адаптируем.
Интеграция и контракты общие
Естественно, интеграции и контракты должны быть общими, без этого никуда. Это большой вызов, особенно на начальных этапах проработки, так как риски вокруг обратно несовместимых изменений максимально высоки.
Новичкам снижение порога входа
С точки зрения возможного невосприятия каких-то элементов платформы есть несколько ситуаций. Каким-то командам или разработчикам довольно сложно в первый раз зайти на платформу, изучить новые подходы и технологии. Для них каждый сервис должен иметь минимальный порог входа, не требующий высокой экспертизы. И при этом позволяющий с ними вместе это все прорабатывать, обогащать документацию и так далее.
Экспертам возможности пошире
Но обязательно всегда будут какие-то проекты, продукты или целые команды, которые либо вынуждены у себя реализовать какие-то элементы сервиса, которые есть у нас в платформе, но со своими несовместимыми особенностями, либо эти сервисы просто уже у них давно были, у них мало мотивации заезжать к нам изначально. Для таких команд мы стараемся расширять возможности каждого сервиса, стремясь предоставить какой-то инструмент или набор опций для кастомайзинга, чтобы люди могли больше и больше своих особенностей туда проецировать, и переход на платформу становился выигрышным.
Всем ценность и адаптация
Мы демонстрируем, что платформа работает. На собственном примере какими-то решениями, либо success историями продуктов. И постоянно адаптируем как сами сервисы, так и команды.
Итак, мы — молодцы, стартанули, и начался некий продуктовый бум: производственные системы на микросервисах, для каждого цеха по стартапу и т.д. Все побежали чего-то пилить. Этот этап мы называем гонкой вооружений.
Испытание ростом
Появились 4 проблемных места:
Нужно больше сервиса
Командам еще вчера нужны были какие-то сервисы, или они хотят с какими-то своими непростыми особенностями все это на платформу делегировать.
Рост консалтинга
Выросла нагрузка в плане консалтинга. Допустим, архитектурно что-то пообсуждать, или рассказать, как какой-то штукой пользоваться.
Масштабирование и тиражирование
Мы еще хотим расти вертикально и горизонтально, на какие-то площадки заехать, расширяться.
Рост нагрузки на поддержку
Банально выросла нагрузка на поддержку, учитывая, что мы еще и в парадигме Service Desk работаем.
Пройдемся по каждому пункту, как мы пытались на это дело ответить.
Проблема: Нужно больше сервиса
Решение: Проработка и работа с ожиданиями
В плане портфеля сервиса это проработка каждого сервиса, и работа с ожиданиями команд и наших пользователей, что очень важно. И одновременно учитываем, что мы рассчитываем на некий масс-маркет, поэтому каждый сервис должен быть как элемент конструктора. В итоге сервис платформы должен быть:
1. Самодостаточен
Я уже упоминал ранее, что для интеграции с legacy и т.п. вариант: «Где у вас поды крутятся, там метрики и смотрите», не подходит. Нужен вариант: "Мы собрали метрики со всей вашей гибридной архитектуры в одном удобном месте, пожалуйста". Необходимо давать возможность каждый сервис использовать в отдельности, без необходимости переезда на платформу целиком.
2. Упрощен и безопасен
Сервис должен быть максимально упрощен для входа и безопасен от выстрелов в ногу. Соответственно, нужно позаботиться о каких-то ограничениях, тут работа индивидуально с каждой технологией. Но еще нужно отметить, что никому не нужен kubernetes в вакууме или просто Git. Все могут это сделать самостоятельно, это уже давно не rocket science. Всем нужна некая магия, как это все друг с другом взаимодействует. Например, шаблоны CI/CD или модульность, где-то секретики автоматом прописались, и вот уже можно быстренько деплоиться. Интересна эта часть в ракурсе сервиса.
3. Прозрачен
Это часто забывается или сложно реализуется, в том числе, и у нас, но сервис должен быть прозрачен. Нужно поставлять все необходимые метрики, чтобы у команд было чувство, что они его сами себе развернули и используют. Чтобы не было ощущения какого-то blackbox.
4. Ограничен контрактом
Сервис обязательно в некоем смысле должен быть ограничен контрактом, потому что платформенный инженер и DevOps-инженер команды, конечно, лучшие друзья, но у них немножко разные задачи и взгляды на эти вещи. Критически желательно, чтобы платформенная команда не превращалась в функциональную команду какого-нибудь проекта или продукта. С этой целью одним из челленджей является дать командам контроллируемую возможность кастомизировать сервис под себя, например, менять какие-то настройки через Git и т.п.. Это очень помогает ограничиться неким контрактом, и оставить какую-то возможность для модификации со стороны пользователя без постоянного привлечения платформеров.
5. Изолирован
Должно быть возможно посчитать, сколько сервис хотя бы приблизительно стоит. И экземпляры какого-то сервиса разных команд не должны влиять друг на друга. Мы максимально, где только возможно, отдавали предпочтение мультитенантным решениям, инсталляциям и кластерам. Но для некоторых сервисов это сделать довольно сложно даже с десятой попытки. Приходилось их превращать в выделенные.
6. На самых первых этапах при вводе какого-то сервиса мы очень много времени должны потратить на его первичную проработку.
Тут основная проблема в том, что со временем мы можем вернуться спирально, доделать или добавить какие-то фичи в сервис, но если мы вдруг решим его поменять обратно несовместимо, то это может превратится в огромную головную боль для всех. Поэтому перед каждой реализацией новой сервисной фичи нужно потратить очень много времени совместно со всей командой, чтобы её всесторонне продумать. Даже если сервис с виду очень простой. И всю эту скрытую сложность нужно доносить до наших ожидающих пользователей.
Проблема: Рост консалтинга
Решение: Документация и community
Тут ответ простой и банальный — это евангелирование и прозрачность. С гигатонной документации на грани графомании.
Наш Вики со старта был очень большим, тысячи раз уже его правили, и продолжаем. В итоге сейчас для себя выбрали подход или фреймворк, где в идеале на каждый инструмент и сервис должны быть 4 категории документов:
Туториалы для тех, кто только в это дело въезжает.
Конкретные пошаговые step-by-step инструкции для туннельного решения популярных задач.
Разъяснения, как сервис в принципе работает, почему он сделан именно так, а не так, как в других компаниях.
Сухие справочники с описанием API, контрактов, ресурсов и т.д.
В части справочников огромной палкой-выручалкой, особенно на старте, становится генерируемый контент. Берем какой-нибудь foliant или другой инструмент, которых не мало, добавляем в пайплайны и прочее. Генерируем странички, например, с перечислением каких-то источников данных, proxy-репозиториями зависимостей и прочей информацией, чтобы люди не искали это где-то по readme или в конкретных UI сервисов. Если в компании есть общий knowledge base, там есть индексация и поиск, людям это очень понятно и приятно.
Важные моменты:
Public & private
Всю эту историю нужно умножить на два: во-первых, публичная документация для пользователей, а во-вторых, еще для внутренней команды. Потому что, во-первых, никто не отменял bus-фактора, а во-вторых, мы тоже не машины, учитывая, что стек довольно разнообразный, можно быстренько все забыть.
Community
Также важно развивать внутреннее комьюнити (митапы, чаты, встречи). У нас сейчас гильдии появились, мы в их рамках коммуницируем. Большим мотивирующим подспорьем для платформенного инженера является видеть, когда одни ребята другим ребятам отвечают, объясняют, как пользоваться тем или иным твоим сервисом — это прямо мед для глаз.
Customer feedback tool
На более поздних этапах мы применили customer feedback tool. Название громкое, но на самом деле просто разворачиваем какую-то точку, куда коллеги заходят, накидывают идеи и головные боли, голосуют за них. И там же в комментариях можно отлично похоливарить на тему, как это лучше сделать. Хороший интерфейс влияния на роадмап или техдолг платформы с обратной связью.
Проблемы: Масштабирование и тиражирование и рост нагрузки на поддержку
Решение: Infrastructure as Code и автоматизация
Тут ничего нового — инфра как код и автоматизация — наше всё.
Мы все декомпозировали условно на три слоя:
Слой, который отвечает за инфру и кластера. Мы можем все это масштабировать и тиражировать.
Прикладной конфигурирующий слой — репозитории, инвентари, которые помогают конфигурировать конкретные реализации сервиса внутри. Например, тенанты observability сервисов или namespaces в куберах.
Можно еще сделать абстрактный инвентарь сервиса, который все это дело объединяет и комбинирует под собой.
Например, берем Ansible-инвентари, GitOps-репы. Добавляем API – это может быть что угодно в любой комбинации: AWX, n8n, самописные вещи, GitLab-пайплайны. Какой-то глобальный инвентарь может поделать коммиты в компонентные части и последить за пайплайнами. Таким образом мы можем как кубики конструировать все наши сервисы и по пути еще экспериментировать. Например, сервис сбора логов состоит из кучи разных вещей. По пути где-нибудь в конце мы можем в любой момент небольшим изменением вклиниться, и начать писать одновременно и в Loki, и в старенький OpenDistro, и в новый OpenSearch, еще в SIEM.
Еще один момент. Сразу на старте все, что делаешь 3+ раза за неделю, надо автоматизировать. Как бы это глупо не выглядело, но, если это работает, это не глупо. Мы делали очень много MonkeyJob-плейбуков — практически на все стандартные операции, которыми занимаемся.
Вот мы такие молодцы — три проблемки порешали, а с ростом нагрузки поддержки нам MonkeyJob-плейбуки не особо помогали.
Service desk throttling
Происходило то, что число продуктов и пользователей у нас в геометрической прогрессии росло, соответственно, росла нагрузка с вопросами. Платформенные инженеры все больше времени сидели и что-то кому-то объясняли или что-то с кем-то выясняли на заявках. Все меньше времени у них оставалось на то, чтобы взять паузу и глобально решать проблему, которая есть у многих, и заниматься развитием самого сервиса.
Первая мысль, которая приходит на ум, — просто закидать все это людьми, сделать разные уровни поддержки и т.д. Это легко сказать, но не просто сделать, потому что, во-первых, нужны компетенции, во-вторых, мы там все равно свою специфику сделали. Плюс, мы все-таки тертые айтишники, знаем, что не всегда и не каждый bottleneck можно с помощью CPU и RAM (ресурсов) порешать. Мы решили попрофилировать, что у нас происходит, где тормоза.
Профилируем DevEx
Пользовательский опыт нашего разработчика, который работает через Service Desk.
Разработчик сначала мучает соседей или своего PM, спрашивая, как получить ту или иную штуку. Его отправляют в Вики, он там находит доки, по диагонали их читает, добирается до Service Desk, или кто-то ему подсказал ник в Telegram любимого инженера. В общем, какими-то окольными путями запрос до инженера доходит. Инженер начинает спрашивать, а ты кто такой, какие-то ритуалы нужно соблюсти, предлагает почитать документацию — в общем, стандартная вся история. Разработчик к нему возвращается, приносит какие-то нужные данные, инженер это вносит в автоматизации. Что-то падает, потому что где-то разработчик опечатался, инженер скопировал не оттуда, или вообще забыл проверить какие-то пороги. И вот спустя сколько-то итераций (а еще инженер переключается между кучей разных вещей) наконец-то сработала MonkeyJob автоматизашка, до которой добрались — ура! И дальше все это возвращается назад.
Тут мы быстренько пришли к идее self-service.
Идея self-service
Убираем лишние коммуникации.
Нам нужна одна единая точка входа, которая у всех в голове, и больше ничего. Любой вопрос по платформе — идем туда. Там должен быть уже весь портфель наших сервисов как спека в Swagger напоказ, что у нас есть, что можно сделать и т.д. Там же мы должны как-то подтягивать пользовательский контекст, с какой команды, что он делает. Быстренько все это дело валидировать на месте, нормализовать входные запросы в то, что у нас подходит под автоматизации.
В общем, идея огонь. Осталось только разобраться, как это сделать. На тот момент готового решения мы для себя не нашли. Плюс, Service Desk был еще не готов в этом поучаствовать напрямую. Поэтому мы решили попробовать сделать это сами, но очень осторожно, чтобы просто показать Proof-of-Concept, что схема огонь и рабочая.
PoC портала самообслуживания
CMDB-like БД
Первым делом собрали CMDB-like БД, написали какое-то количество разных скраперов, которые со всех наших сервисов всю нужную информацию складывают в одно место. В принципе, это win в любом случае, даже если затея с порталом самообслуживания не получится, потому что не во всем может помочь инфра как код. Много чего рождается в «runtime». Например, люди приходят и говорят: «У меня не работает такой-то url», а у тебя там ряд кластеров, сотни namespaces, если еще умножить на 2−3 ingress — пойди найди. В общем, очень полезная штука.
Каталог услуг и справочники
Во-вторых, сами для себя сформировали каталог услуг и справочники, уже как-то навели у себя порядок, в том числе в документации в Вики.
Генератор форм и UI-kit*
Привлекли frontend разработчиков сделать нам генератор форм, чтобы мы могли писать JSON, а из них рождались UI для каталога услуг. И мы с удовольствием одни из первых использовали появившуюся дизайн-систему НЛМК, за которую ребятам большое спасибо.
Интеграция с ServiceDesk
Запуск автоматизаций
Approve/Deny-контроль
Для того, чтобы проверить и показать на метриках, что это эффективно, мы мимикрировали под ServiceDesk, и интегрировались с ним. Чтобы не выпадать из общепринятого процесса, и при этом нормализовать, валидировать запросы, и запускать автоматизации. Но с неким Approve/Deny предохранителем, чтобы у дежурного инженера перед глазами была вся информация, он мог проверить, помимо автоматической валидации, не запрашивает ли человек какую-то в целом странную историю, и согласиться или нет запустить это в работу.
Неожиданно это довольно ощутимо выстрелило.
Спустя какое-то время мы вошли в кураж, очень много сервисов и инструментов туда затащили. Это привело к тому, что в целом большая часть обычных обращений, которые к нам приходили через Service Desk, можем делать в автоматическом режиме, вообще не привлекая инженеров. Только условные 12% в среднем по больнице — это консультации и инциденты, по которым нужно реально с людьми поговорить и разбираться в проблеме. Инженеры расцвели, стало больше свободного времени. Метрики взлетели до отличного уровня. Вроде все довольны, все круто.
Дальше это подхватывается идеей перевести вообще всё к единому self-service.
К единому self-service
Например, команды IIoT и инфраструктурной платформ оценили преимущества self-service. Мы вместе с ними работаем. В планах развивать это до доменных API по разному функционалу, которые были бы связаны единым контекстом. При этом генерировали доменные события, на базе которых можно было бы реализовываться сценарии посложнее, и наполнять разные базы с разным ракурсом активов. Например, для data-платформы, чтобы она могла реагировать на появление каких-то Kafka-топиков, инфраструктура могла свой CMDB развивать, расширять, наполнять актуальными данными быстро и т.д. Можно будет вернуться к идее с распространенными фреймворками и использовать API как плагины.
Что переосмыслить
Но по пути к этой цели мы столкнулись с одной небольшой проблемой, небольшим подводным камнем, хотя, может быть, даже и большим — это проблема объединения всех IT-доменов вокруг единого ведения каталога продуктов и систем, и их связей.
Сквозные данные по продуктам и системам
Например, для того, чтобы реализовать у себя некоторые фичи, подтянуть информацию о бюджетах, узнать, в какой стадии проект, чтобы сделать автоматические проверки, чтобы мы могли в другие домены сходить по API и спросить — для этого продукта или системы дай свои данные.
Второй момент, что нужно выровняться по этой информации, начиная еще от этапа архитектурного продумывания и заканчивая уже непосредственно поддержкой. У команд цифровой кураж, они пилят сервисы, экспериментируют, им нет дела до наших процессов скорее всего где-то до момента вывода своего решения в ОПЭ. Например, архитектура на стадии проектирования может не знать (или не успеть узнать) о том, что у нас есть уже решенные проблемы, какие-то сервисы, и это можно просто переиспользовать.
В-третьих, если вдруг мы начинаем требовать от атмосферы стартапа соблюдения каких-то сложных корпоративных ритуалов с неизбежными элементами бюрократии, причем у каждого домена ИТ свои особенности, то есть вариант появления некоего shadow IT, где автономные команды решают свои проблемы сами и в наши платформы не заходят, потому что мы там слишком замороченные. Это можно попробовать обойти, максимально сгладив углы на ранних этапах, простым учетом и сквозными интеграциями.
Мы все любим Single Sign-On и хороший IDM в приложениях, продуктам и проектам это тоже очень понравится в процессах и платформах.
Software catalog
Другая история, которая тесно переплетается с единой идентификацией продуктов и систем, — это Software catalog. Помимо стандартных Change Management и Change Management Database, которые всем известны, у нас появляется очень много разных интересных зависимостей от API, сервисы друг у друга начинают что-то переиспользовать и т.п.. Плюс, например, сегодня какая-то команда запилила классный PoC сервис, завтра мы моргнули, а другая система на него подписалась и завязалась, а мы об этом знать не знаем. Это добавляет необходимость того, чтобы идентификация продуктов и систем далее позволяла строить цепочки зависимости через ее ресурсы и сервисы. Что-то быстро становится частью другого, и это уже очень живая история.
И интересно во всем этом то, что вопрос сложности не столько в технике, не в том как технически реализовать эту историю, а как договориться между собой, между всеми доменами IT, у каждого из которых немножечко свой взгляд на жизнь. Это занимает какое-то время, и требует отдельного внимания и инвестиций.
Дополнительные эффекты
Упомяну некоторые дополнительные эффекты, которые дал нам платформинг, и в целом подходы выше.
1. Systems catalog
Проведение учета разных активов и систематизация данных о системах, продуктах и проектах, который мы у себя развиваем. Дополнительное придание веса проблематике и положительные локальные эффекты подтолкнули к развитию этих идей глобальнее.
2. TSDB platform
При свободе действий и возможности проводить эксперименты и проверять гипотезы внутри нашей продуктовой команды, мы смогли внести существенный вклад в развитие аналитических хранилищ. В том числе, реализовали классный MVP решения, которое позволяет собирать и очень быстро работать с временными рядами — сырыми данными с различного производственного оборудования. Позднее это переросло в развитие целой IIoT‑платформы.
3. Self‑service
Мне хочется верить в то, что мы своим примером внесли большой вклад в развитие self‑service внутри компании, потому что сейчас у нас появилось очень много различных решений, которые это реализуют.
4. SRE
Еще один из важных дополнительных эффектов, который дают платформинг и единообразие — это развитие SRE‑практик. У нас появился центр компетенций, с которым мы совместно эту тему развиваем. В том числе за счет того, что все похоже, состоит из одних блоков, переиспользуется, и стремится в shift-down. Это помогает обеспечивать нужный уровень доступности наших решений.
А нужна ли в принципе платформа?
Возможно, и не нужна. Наверное, вся эта история с платформой немного похожа на использование фреймворков в разработке.
Поднять для своего продукта Kubernetes, Git или какой-то еще инструмент — не столь великая уже наука, на самом деле можно. Можно даже купить готовый сервис. В разработке такая же история. Мы можем написать любой сервис, ничем себя не ограничивая. Но когда мы делаем это второй, третий, десятый, двадцатый раз, уже начинаем придумывать какие-то правила, какие библиотеки используем, какие не используем, прячем boilerplate, делаем свои библиотеки, шаблоны и болванки, нашим коллегам об этом рассказываем, все выравниваемся. По сути, мы уже начинаем потихонечку сами создавать какой-то фреймворк на фиксированном стеке.
Думаю, с платформой история такая же. Если у вас в компании расчет на большое количество разработки, повторяемых и переиспользуемых архитектур, технологий и ресурсов, то платформинг не то, что нужен, а даже логичен и естественен.
Резюме
Краткое резюме для тех, кто идет или пойдет таким же путем, как мы:
Платформа — это комплексная среда для shift-down
Это не просто набор из Kubernetes, Git и прочих других сервисов и решений «в вакууме». Их желательно постараться между собой соединить, приправить методологиями, процессами и переиспользуемыми решениями для разрешения какой‑то более верхнеуровневой рутины разработки и эксплуатации.
От евангелирования к продуктовому подходу
Плавно переходим от евангелирования к уже продуктовому подходу. Выходим к командам и стейкхолдерам. Спрашиваем, что им нужно доработать, допилить, какие проблемы решить и эффекты принести.
Делаем сервис как элемент конструктора со всеми особенностями
Сервис должен быть единообразен, ограничен контрактом, изолирован и, по возможности, прост и безопасен.
“Eat your own dog food”
Нужно обязательно самим пользоваться тем, что делаем. Именно по тем же правилам игры, которые даем нашим пользователям и командам.
Стелим неизбежный self‑service заранее
Неизбежен тут ключевое слово. Мне кажется, это в принципе самый естественный и правильный путь развития IT.
Системы — тоже пользователи, и тоже с идентификацией.
Наконец, крамольная мысль, что система, в принципе, тоже пользователь для платформы, тоже нуждается в общей сквозной идентификации, и я призываю всех к этому заранее подойти.
