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

Как связаны DevOps и платформенный инжиниринг

В 2009 мир начал активно говорить о DevOps. Основная идея была в том, чтобы автоматизировать процессы между разработчиками и эксплуатацией и наладить коммуникацию между ними. Предтечей DevOps, по всей вероятности, стал lean manufacturing, суть которого — оптимизация процессов на всех уровнях.
DevOps стал попыткой переосмыслить то, как надо выстраивать процессы внутри компании. Начали появляться инструменты, автоматизирующие ключевые процессы разработки и эксплуатации (например, Kubernetes). В известной книге про DevOps, Accelerate, были введены новые метрики — lead time, change failure rate, mean time to recovery. Коллеги из Puppet использовали эти метрики в своем регулярном отчете по DevOps, чтобы оценить, кто и насколько успешен.

В процессе внедрения DevOps в массы было обнаружено любопытное явление, которое было названо DevOps Mountain of Tears. Его суть состоит в следующем: когнитивная нагрузка на разработчиков стала настолько высока и понадобилось изучать и держать в памяти столько деталей, что люди стали сопротивляться внедрению DevOps-практик.

В 2022 в повестку вошел термин «платформенный инжиниринг». Он продолжает идеи lean manufacturing, выстраивая новые принципы проектирования внутренних процессов на основе DevOps.

Платформенный инжиниринг рассматривает вызовы уровня, который следует уже после этапа достижения командой или компанией некоей зрелости по DevOps.

DevOps-специалисты сфокусированы на том, как автоматизировать процессы, отнимающие лишнее время, и как более эффективно выстроить процесс разработки. Они продумывают и внедряют решения, выполняющие данные задачи.

Команды DevOps обычно небольшие, и зачастую они перегружены. Разработчики вынуждены ждать команду DevOps или настраивать процессы самостоятельно. Это оптимизирует время разработчиков, но тормозит улучшение разработки и эксплуатации на уровне организации. Платформенный инжиниринг, в свою очередь, направлен на то, чтобы дать разработчику полную автономность в задаче построения программного проекта. Ему больше не нужно ждать DevOps инженера – теперь он может эффективно выполнить задачу сам с помощью платформы. Платформа представляет собой набор программных инструментов (приложений, баз данных, средств разработки и пр.), которые упрощают и автоматизируют процессы. Некоторые платформы позволяют выстраивать новые процессы в стиле конструктора.

Задача платформы — снизить когнитивную нагрузку на пользователей. Благодаря платформам пользователи могут сосредоточиться только на своих непосредственных задачах. Им не нужно заботиться о совместимости, актуальности версий инструментов и их обновлении. Обычно, чтобы разработчику развернуть приложение в облаке, нужно изучить тонну правил и документации, в том числе по нерелевантным ему задачам. Это могут быть даже юридические вопросы, например, если речь идет о разработке с использованием Open Source технологий. Платформенный же подход автоматизирует либо скрывает реализацию непрофильных действий от разработчика.

Уровень популярности платформенного инжиниринга в мире и России

По оценке Gartner, на мировом уровне платформы перешли от роли "триггер инноваций" к роли "пик ожиданий". В этом смысле в России платформенные решения вписываются в мировой тренд — компании активно накапливают экспертизу и делятся ею. При этом некоторые компании, такие как VK или Авито, делают это уже много лет, поэтому можно смело говорить о концептуальном паритете. В 2022-2023 гг. появились конференции PlatformCon, а в 2023 в России на конференции Highload был выделен специальный трек Platform Engineering, где специалисты ведущих компаний делятся своим опытом в построении комплексных платформ. Кажется, что хотя платформенный инжиниринг существует уже относительно давно, организаторы конференций не сразу решились на его полноценное внедрение в мероприятия, предпочитая переждать хайп.

На что обратить внимание при разработке платформы?

При самостоятельной разработке платформы важно обратить внимание на несколько принципиальных моментов. Их игнорирование может затянуть процесс или свести пользу от применения платформы к нулю.

Нюанс 1. Цель создания платформы

Идеальное состояние платформы — это интеграция инструментов, знаний и процессов, предоставляемая как сервис. Важно не забыть, что цель создания платформы — не просто технологическое объединение инструментов, а снижение нагрузки на пользователя. Он должен получить в едином окне доступ к большому количеству функций, относящихся к его бизнес-задачам. При этом максимум непрофильных функций должны быть от него скрыты. В проектировании платформы индустрия рекомендует выбирать продуктовый подход. Пользователи, будь то аналитики, data-инженеры или разработчики, это клиенты платформы.

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

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

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

Kubernetes — это платформа, но для ее использования нужен большой опыт, причем эксплуатационный. Поэтому появляются различные инструменты типа Backstage, которые позволяют настроить поверх кластера платформу самообслуживания для разработчика. Это сильно снижает требования к знанию Kubernetes. Разумеется, существуют облачные сервисы, которые тоже помогают снять с разработчиков эксплуатационные задачи. Но практика показывает, что эксплуатация все равно остается, просто видоизменяется. Например, в облаке часто недоступен к контролю etcd, база данных Kubernetes, что усложняет анализ производительности в некоторых ситуациях. И разработчик приходит в ту же ситуацию, откуда ушел, — пишет удобный функционал «поверх».

Нюанс 2. Формирование команды и ее позиционирование

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

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

Нюанс 3. Создание технологического бренда и вовлечение пользователей. Теория когнитивной нагрузки

Задача платформ — снижение когнитивной нагрузки на пользователей.

Но на практике нагрузка почему-то часто наоборот возрастает. Это происходит по ряду причин:

Сложности с пониманием. С приходом облачных платформ и cloud native- инструментов и технологий специалистам теперь необходимо понимать не только, как это все функционирует, но и как интегрировать сервисы и продукты, причем часто находящиеся у разных провайдеров. Запутанное распределение ролей и обязанностей. Раньше всё было просто — разработчики разбирались в разработке, системные администраторы — в обслуживании инфраструктуры. Но сейчас разработчикам часто необходимо изучать и ops-технологии. И не всегда понятно, что находится в ведении разработчиков, а что — DevOps-инженеров. Отсутствие конкретного распределения задач и ролей привело еще к одному эффекту — появлению «теневых» запросов новых специалистов к более опытным. Причем это запросы не по конкретному профилю (разработке), а по эксплуатационным задачам. Еще есть вариант с добавлением DevOps-инженера в команды разработки, чтобы такой специалист выравнивал используемые подходы с центральным стандартом. Такой подход работает, но не всегда — зависит от ответственности и опыта конкретной команды. Можно дорабатывать с помощью гайдансов и правил, но все кейсы не закрыть. А еще это сильно повышает когнитивную нагрузку на разработчиков. К счастью, для этих проблем уже существуют способы решения.

Вовлечение и обучение пользователей — часть стратегии change management. Разработчиков нужно обучить новых процедурам и воркфлоу платформы. И это не просто новый инструмент, это изменение привычек внутри ключевых ежедневных процессов.

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

Намного эффективнее, когда появляются люди, которые отвечают за вовлечение пользователей на кросс-командном уровне. Внутри классической организационной структуры создаются новые роли — Developer Advocate, Platform Advocate и так далее. Их задача — создать технологический бренд продукта (в данном случае платформы), вовлекая новых пользователей совместно с коллегами из маркетинга, обучения, HR и команды платформы. Без должного внимания к обучению и вовлечению сотрудников новый продукт рискует остаться без пользователей. Руководителям, которые инвестировали в проект много средств, придется перейти к директивным мерам. Они ломают привычные процессы пользователей. В результате эффект от внедрения платформы, в лучшем случае, будет нулевым.

Tarantool — пример платформы для выстраивания процессов хранения и обработки данных в Enterprise-сегменте бизнеса. На базе Tarantool, пользуясь готовыми модулями, можно реализовать отказоустойчивое распределенное хранилище информации, персистентный кэш для “горячих” данных, графовое или колоночное хранилище, очередь событий любой конфигурации.

Пример реализации на базе Tarantool — платформа дистанционного банковского обслуживания Газпромбанка. Она сама передает данные во внутренние и клиентские приложения из разных источников — от биржевых курсов до СУБД с данными пользователей.