Предыдущие части: 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.”
Причём, перенос функциональности на уровень платформы («сдвиг вниз») может выглядеть противоположным принципу «ты создаёшь — ты управляешь». Однако платформенная инженерия позволяет масштабировать такие подходы, предоставляя встроенные возможности всем командам без дополнительных усилий с их стороны.
Platform engineering позволяет пересмотреть подход к тому как реализована работа с платформой и инфраструктурой в компании.
Я бы выделил несколько ключевых аспектов, которые позволяют получить максимальную бизнес пользу:
1. Централизация и унификация: единая точка входа и стандартизация SDLC позволяют как снять издержки с каждой команды на реализацию стандартных и рутинных процессов, так и получить необходимый контроль над качеством, технологическим стеком и митигировать риски внедрения плохих практик.
2. Self service — режим самообслуживания критически необходим для возможности масштабирования платформы. Иначе есть большой риск навредить и получить бутылочное горлышко.
3. DevX centric — важно, чтобы платформа была удобной и помогала эффективно решать бизнес задачи. DevX метрики напрямую показывают насколько продуктивна разработка.
Кстати, в отчёте ещё много интересных полезняшек. К нему можно возвращаться не раз, чтобы изучать всё глубже и глубже.
Вот, например, в исследовании приведена статья об отличии Shift Left и Shift Down. В ней говорится, что «смещение влево» перегружает разработчиков дополнительными обязанностями, такими как безопасность и контроль качества на ранних этапах разработки. А Shift Down — это про то, как облегчить этот процесс с помощью самообслуживания и автоматизации, предоставленных платформой.
В PE большое внимание уделяется улучшению опыта разработчиков через автоматизацию и упрощение доступов к ресурсам, позволяя им сосредоточиться на коде. Это включает подготовку приложений, управление базами данных и инфраструктуру для развертывания. Успех достигается благодаря продуктовому подходу, ориентации на пользователя и независимости разработчиков.
Исследование показало, что пользователи внутренних платформ имеют на 8% выше индивидуальную производительность и на 10% выше производительность команд.
Независимость разработчиков значительно повышает продуктивность на индивидуальном и командном уровнях при использовании внутренней платформы. Независимость определяется как способность выполнять задачи без помощи других.
Производительность возрастала на 5%, когда пользователи могли завершать задачи самостоятельно, подтверждая важность самообслуживающихся рабочих процессов.
Но! Вот неприятный сюрприз:
Сюрпризы
Производительность доставки и эксплуатации ПО возрастает на 6%, но пропускная способность и стабильность изменений снижаются на 8% и 14% соответственно.
И тут авторы приводят несколько гипотез.
Возможные причины уменьшение пропускной способности поставок на 8% по сравнению с теми, кто не использует платформу:
Добавление промежуточных систем для тестирования, проверок безопасности, деплоя и мониторинга увеличивает количество «переходов» между системами и командами. Каждый из этих переходов увеличивает общее время выполнения процесса, что снижает пропускную способность, но в итоге повышает общую способность выполнять работу.
У респондентов, обязанных использовать исключительно единую платформу для выполнения задач на протяжении всего жизненного цикла приложения, не переключаясь на другие инструменты, было снижение пропускной способности на 6%, а не на 8.
Для борьбы с этими проблемами важно ориентироваться на пользователей и стремиться к независимости разработчиков в инициативе платформенной инженерии.
Нестабильность изменений и выгорание:
Использование внутренней платформы разработки привело к снижению стабильности изменений на 14%. Это означает, что частота отказов изменений и объём доработок значительно увеличиваются. Более того, нестабильность в сочетании с платформой связана с повышенным уровнем выгорания. Хотя платформы сами по себе не приводят к выгоранию, их комбинация с нестабильностью особенно проблематична.
Возможные причины:
1. Платформа позволяет разработчикам с уверенностью вносить изменения, зная, что при необходимости их можно быстро исправить. Это может привести к увеличению числа неудачных изменений и повторных работ.
2. Платформа может быть неэффективна в обеспечении качества изменений или развертываний в производство, что приводит к увеличению числа плохих изменений, требующих доработок.
3. Команды с высокой нестабильностью и выгоранием могут создавать платформы, пытаясь улучшить стабильность и снизить выгорание. Платформенная инженерия рассматривается как способ уменьшения выгорания и повышения стабильности изменений.
В первых двух сценариях повторная работа, разрешаемая платформой, может быть обременительной и способствовать выгоранию. В третьем сценарии, высокая нестабильность изменений и выгорание предвещают инициативу платформенной инженерии, видя её как решение проблем.
Но у меня, есть еще предположение: платформы становятся все более популярны и организации постепенно вкладываются в PE, однако на первых порах это может приводить к тех.долгу и проблемам выше и это отчасти подтверждает та самая J-curve про которую неоднократно упоминается в этом и в прошлых отчетах: при внедрении платформ есть кусочек, где производительность может просесть, но при должном подходе в дальнейшем все станет хорошо и платформа начнет приносить плоды.
По поводу снижения качества и пропускной способности — интересный инсайт, который на мой взгляд полностью нивелируется по мере увеличения зрелости платформы. Далее эффект наоборот идет в плюс, так как централизация позволяет легко внедрять автоматическую валидацию нужных контролей и Quality Gates.
Влияние выделенной платформенной команды
Для платформенных команд ключевым является сбор обратной связи от пользователей. Способы сбора обратной связи включают неформальные разговоры, отслеживатели проблем, совместную разработку, опросы, телеметрию и интервью. Отсутствие сбора обратной связи негативно сказывается на производительности.
Интересно, что влияние наличия выделенной платформенной команды на индивидуальную продуктивность было незначительным, но на уровень командной продуктивности оно увеличило эффективность на 6%. Это неожиданно из-за неравномерного воздействия, указывающего на то, что выделенная платформенная команда полезна для отдельных лиц, но более значимо в целом для команд.
Так как команды включают разработчиков с разными обязанностями и навыками, они имеют более разнообразные задачи по сравнению с индивидуальными инженерами.
Выводы
Platform Engineering — социально-техническая дисциплина.
Платформы — не просто набор инструментов, дающих автоматизацию и повторяемость процессов, платформы также дают клиентам (инженерам других команд) слой самообслуживания и следовательно автономность.
Платформы — это клиентоцентричный продукт, делайте их удобными для инженеров, постоянно и чаще собирайте и анализируйте обратную связь с пользователями платформы.
Производительность доставки и эксплуатации ПО при использовании платформ возрастает на 6%,но пропускная способность и стабильность изменений снижаются на 8% и 14% соответственно. При использовании единой платформе, а не нескольких - снижение не на 8, а на 6 %
Тщательно мониторьте нестабильность изменений и её причины. Платформы могут поддерживать эксперименты и повышение производительности, но могут также привести к нестабильности и выгоранию. Определите свою терпимость к рискам, используя цели уровня обслуживания (SLO) и бюджеты ошибок от инженерии надежности сайтов (SRE).
Формируйте культуру улучшений и ориентированности на пользователей для всех команд. Это поможет платформе лучше служить нуждам как отдельных разработчиков, так и команд в целом, поддерживая доставку программного обеспечения и бизнес-ценности.
Внутренние платформы разработчиков сосредоточены на опыте разработчиков, но для эффективной доставки и эксплуатации ПО также необходимы усилия других команд, включая администраторов баз данных, специалистов по безопасности и операционную поддержку.
Вопросы и мнения
PE выявляет проблемы. Могли и не обращать внимания на проблемы без PE?
Негативные эффекты платформы, связаны с начальными этапами внедрения платформ?
Платформа — это продукт, иногда надо научить пользователя, что ему нравится.
«Мы сегодня многое поняли»
Что ж это была довольно интересная часть исследования и не без сюрпризов. Получили очень крутое и четкое определение Platform Engineering и зачем он нужен. PE — это социально-техническая дисциплина, которая фокусируется на объединении автоматизации, самообслуживания и улучшения взаимодействия между командами. Её цель — предоставить удобные платформенные решения, которые упрощают и ускоряют работу разработчиков.Внедрение PE помогает масштабировать команды за счёт централизации процессов и предоставления инструментов самообслуживания.
Однако на начальных этапах это может привести к временным проблемам, таким как снижение пропускной способности и стабильности изменений, требующих корректировки подходов. В общем как и в любом процессе, в Platform Engineering очень важно следить за метриками, чтобы понимать какую пользу это наносит и куда двигаться дальше. В конечном счете при должных усилиях и со временем - все будет круто ;)
Полезняшки
DevOops 2024 круглый стол - Platform Engineering: Кому, зачем и как?
IT Friday - мой канал про тренды в ИТ-индустрии, практики, инструменты и другие полезняшки
Что ж, а в следующей и последней части мы поговорим о трансформационном лидерстве, DevExp и клиентоцентричности. Всем хорошего дня.
Stay tuned ;)
