State of DevOps 2024. Platform Engineering
Предыдущие части: 1. DORA-метрики и элитность и 2. Искусственный интеллект.
Всем привет, с вами Сергей Задорожный, руководитель отдела платформенных решений банка «Центр-инвест» и один из авторов курса «DevOps для эксплуатации и разработки» от Яндекс Практикума.
А вот и моя любимая тема! Я с нетерпением ждал новый State of DevOps ради неё. Одна из самых ценных вещей в новом исследовании — это шикарнейшее определение платформенной инженерии (PE, Platform Engineering) как социально-технической дисциплины. Здесь инженеры думают не только о технических аспектах автоматизации, но и о повторяемости процессов и о том, как предоставить самообслуживание клиентам платформенных решений.
«Platform engineering is a sociotechnical discipline where engineers focus on the intersection of social interactions between different teams and the technical aspects of automation, self- service, and repeatability of processes.»
Причём, перенос функциональности на уровень платформы («сдвиг вниз») может выглядеть противоположным принципу «ты создаёшь — ты управляешь». Однако платформенная инженерия позволяет масштабировать такие подходы, предоставляя встроенные возможности всем командам без дополнительных усилий с их стороны.
Александр ЛукьянченкоHead of Platform, Авито
Platform engineering позволяет пересмотреть подход к тому как реализована работа с платформой и инфраструктурой в компании.
Я бы выделил несколько ключевых аспектов, которые позволяют получить максимальную бизнес пользу:
1. Централизация и унификация: единая точка входа и стандартизация SDLC позволяют как снять издержки с каждой команды на реализацию стандартных и рутинных процессов, так и получить необходимый контроль над качеством, технологическим стеком и митигировать риски внедрения плохих практик.
2. Self service — режим самообслуживания критически необходим для возможности масштабирования платформы. Иначе есть большой риск навредить и получить бутылочное горлышко.
3. DevX centric — важно, чтобы платформа была удобной и помогала эффективно решать бизнес задачи. DevX метрики напрямую показывают насколько продуктивна разработка.
По поводу снижения качества и пропускной способности — интересный инсайт, который на мой взгляд полностью нивелируется по мере увеличения зрелости платформы. Далее эффект наоборот идет в плюс, так как централизация позволяет легко внедрять автоматическую валидацию нужных контролей и Quality Gates.
Кстати, в отчёте ещё много интересных полезняшек. К нему можно возвращаться не раз, чтобы изучать всё глубже и глубже.
Вот, например, в исследовании приведена статья об отличии Shift Left и Shift Down. В ней говорится, что «смещение влево» перегружает разработчиков дополнительными обязанностями, такими как безопасность и контроль качества на ранних этапах разработки. А Shift Down — это про то, как облегчить этот процесс с помощью самообслуживания и автоматизации, предоставленных платформой.
В самом исследовании очень много интересных полезняшек
В PE большое внимание уделяется улучшению опыта разработчиков через автоматизацию и упрощение доступов к ресурсам, позволяя им сосредоточиться на коде. Это включает подготовку приложений, управление базами данных и инфраструктуру для развертывания. Успех достигается благодаря продуктовому подходу, ориентации на пользователя и независимости разработчиков.
Исследование показало, что пользователи внутренних платформ имеют на 8% выше индивидуальную производительность и на 10% выше производительность команд.
Независимость разработчиков значительно повышает продуктивность на индивидуальном и командном уровнях при использовании внутренней платформы. Независимость определяется как способность выполнять задачи без помощи других.
Производительность возрастала на 5%, когда пользователи могли завершать задачи самостоятельно, подтверждая важность самообслуживающихся рабочих процессов.
оценка продуктивности (0–10)
Но! Вот неприятный сюрприз:
СюрпризыПроизводительность доставки и эксплуатации ПО возрастает на 6%, но пропускная способность и стабильность изменений снижаются на 8% и 14% соответственно.
И тут авторы приводят несколько гипотез.
Возможные причины уменьшение пропускной способности поставок на 8% по сравнению с теми, кто не использует платформу:
Добавление промежуточных систем для тестирования, проверок безопасности, деплоя и мониторинга увеличивает количество «переходов» между системами и командами. Каждый из этих переходов увеличивает общее время выполнения процесса, что снижает пропускную способность, но в итоге повышает общую способность выполнять работу.
У респондентов, обязанных использовать исключительно единую платформу для выполнения задач на протяжении всего жизненного цикла приложения, не переключаясь на другие инструменты, было снижение пропускной способности на 6%, а не на 8.
Для борьбы с этими проблемами важно ориентироваться на пользователей и стремиться к независимости разработчиков в инициативе платформенной инженерии.
Нестабильность изменений и выгорание:
Использование внутренней платформы разработки привело к снижению стабильности изменений на 14%. Это означает, что частота отказов изменений и объём доработок значительно увеличиваются. Более того, нестабильность в сочетании с платформой связана с повышенным уровнем выгорания. Хотя платформы сами по себе не приводят к выгоранию, их комбинация с нестабильностью особенно проблематична.
Возможные причины:
1. Платформа позволяет разработчикам с уверенностью вносить изменения, зная, что при необходимости их можно быстро исправить. Это может привести к увеличению числа неудачных изменений и повторных работ.
2. Платформа может быть неэффективна в обеспечении качества изменений или развертываний в производство, что приводит к увеличению числа плохих изменений, требующих доработок.
3. Команды с высокой нестабильностью и выгоранием могут создавать платформы, пытаясь улучшить стабильность и снизить выгорание. Платформенная инженерия рассматривается как способ уменьшения выгорания и повышения стабильности изменений.
В первых двух сценариях повторная работа, разрешаемая платформой, может быть обременительной и способствовать выгоранию. В третьем сценарии, высокая нестабильность изменений и выгорание предвещают инициативу платформенной инженерии, видя её как решение проблем.
Но у меня, есть еще предположение: платформы становятся все более популярны и организации постепенно вкладываются в PE, однако на первых порах это может приводить к техдолгу и проблемам выше и это отчасти подтверждает та самая J-curve про которую неоднократно упоминается в этом и в прошлых отчетах: при внедрении платформ есть кусочек, где все производительность может просесть, но при должном подходе в дальнейшем все станет хорошо и платформа начнет приносить плоды. И вот
Производительность организации в зависимости от возраста платформы
Влияние выделенной платформенной команды
Для платформенных команд ключевым является сбор обратной связи от пользователей. Способы сбора обратной связи включают неформальные разговоры, отслеживатели проблем, совместную разработку, опросы, телеметрию и интервью. Отсутствие сбора обратной связи негативно сказывается на производительности.
Интересно, что влияние наличия выделенной платформенной команды на индивидуальную продуктивность было незначительным, но на уровень командной продуктивности оно увеличило эффективность на 6%. Это неожиданно из-за неравномерного воздействия, указывающего на то, что выделенная платформенная команда полезна для отдельных лиц, но более значимо в целом для команд.
Так как команды включают разработчиков с разными обязанностями и навыками, они имеют более разнообразные задачи по сравнению с индивидуальными инженерами.
ВыводыPlatform Engineering — социально-техническая дисциплина.
Платформы — не просто набор инструментов, дающих автоматизацию и повторяемость процессов, платформы также дают клиентам (инженерам других команд) слой самообслуживания и следовательно автономность.
Платформы — это клиентоцентричный продукт, делайте их удобными для инженеров, постоянно и чаще собирайте и анализируйте обратную связь с пользователями платформы.
Производительность доставки и эксплуатации ПО при использовании платформ возрастает на 6%, но пропускная способность и стабильность изменений снижаются на 8% и 14% соответственно. При использовании единой платформе, а не нескольких — снижение не на 8, а на 6%
Тщательно мониторьте нестабильность изменений и её причины. Платформы могут поддерживать эксперименты и повышение производительности, но могут также привести к нестабильности и выгоранию. Определите свою терпимость к рискам, используя цели уровня обслуживания (SLO) и бюджеты ошибок от инженерии надежности сайтов (SRE).
Формируйте культуру улучшений и ориентированности на пользователей для всех команд. Это поможет платформе лучше служить нуждам как отдельных разработчиков, так и команд в целом, поддерживая доставку программного обеспечения и бизнес-ценности.
Внутренние платформы разработчиков сосредоточены на опыте разработчиков, но для эффективной доставки и эксплуатации ПО также необходимы усилия других команд, включая администраторов баз данных, специалистов по безопасности и операционную поддержку.
Вопросы и мненияPE выявляет проблемы. Могли и не обращать внимания на проблемы без PE?
Негативные эффекты платформы, связаны с начальными этапами внедрения платформ?
Платформа — это продукт, иногда надо научить пользователя, что ему нравится
«Мы сегодня многое поняли»
Что ж это была довольно интересная часть исследования и не без сюрпризов. Получили очень крутое и четкое определение Platform Engineering и зачем он нужен. PE — это социально-техническая дисциплина, которая фокусируется на объединении автоматизации, самообслуживания и улучшения взаимодействия между командами. Её цель — предоставить удобные платформенные решения, которые упрощают и ускоряют работу разработчиков.Внедрение PE помогает масштабировать команды за счёт централизации процессов и предоставления инструментов самообслуживания.
Однако на начальных этапах это может привести к временным проблемам, таким как снижение пропускной способности и стабильности изменений, требующих корректировки подходов. В общем как и в любом процессе, в Platform Engineering очень важно следить за метриками, чтобы понимать какую пользу это наносит и куда двигаться дальше. В конечном счете при должных усилиях и со временем — все будет круто ;)
Полезняшки
Что ж, а в следующей и последней части мы поговорим о трансформационном лидерстве, DevExp и клиентоцентричности. Всем хорошего дня.
Stay tuned;)
