Неудачи DevOps продолжают подталкивать организации к созданию команд по разработке платформ для разработчиков. Но многие из них не измеряют результаты, говорится в новом отчете Gitpod и Humanitec «State of Platform Engineering Report, Vol. 3», сообщает портал The New Stack.
Инженерам платформ предстоит нелегкий путь, поскольку лишь немногие организации достигли настоящего платформенного инжиниринга — хотя как они могли бы это сделать, если не измеряют его результаты? Но если они продолжат получать зарплату как минимум на уровень выше, чем инженеры DevOps, они, скорее всего, справятся с этой задачей. Это лишь два самых больших открытия из нынешнего отчета.
Платформенный инжиниринг: все еще блестящая новинка
Это уже третий ежегодный отчет, спонсорами которого выступили Humanitec и Gitpod; исследователи опросили 281 специалиста по платформам для разработчиков.
Большинство опрошенных организаций — 56% — имеют команды по разработке платформ менее двух лет. Лишь 13% респондентов сообщили, что работают в этой области более пяти лет.
Почему произошел такой резкий скачок? Что побуждает организации внедрять платформенный инжиниринг?
По словам Сэма Барлиена, руководителя по работе с сообществом в организации Platform Engineering, исследователи остановились на определении платформенного инжиниринга как «дисциплины создания интегрированного внутреннего продукта, который мы называем внутренней платформой разработки (IDP), представляющего собой набор инструментов и цепочек инструментов, которые используются для обслуживания клиентов, ваших разработчиков, для достижения определенной цели, которую вы ставите».
По его словам, это понятие намеренно достаточно широкое, чтобы включать в себя инжиниринг платформ данных, но оно сфокусировано на платформенных ролях, обслуживающих внутренних клиентов, которые в подавляющем большинстве являются разработчиками.
Сначала пришел DevOps, потом IDP
Результаты этого года еще раз доказывают, что платформенный инжиниринг не заменяет DevOps, а, скорее, является следующим этапом эволюции цифровой трансформации. Платформы помогают инженерным организациям приблизиться к реализации обещаний DevOps.
В целом респонденты отметили, что IDP создаются в их организациях, чтобы восполнить недостатки DevOps. Автоматизация — один из ключевых принципов DevOps, однако почти половина респондентов жалуется на то, что из-за отсутствия автоматизации им приходится выполнять слишком много повторяющихся задач.
Еще одним принципом DevOps является стремление к ответственности на протяжении всего жизненного цикла: создал — владей. Но среднестатистический технологический стек растет в геометрической прогрессии и зачастую имеет семь слоев. Это отвлекает разработчика от реальной работы с клиентами. IDP абстрагируют сложность нативных облачных технологий, чтобы уменьшить выгорание разработчиков и когнитивную нагрузку. Кроме того, они позволяют еще больше сблизить продукты, процессы и людей.
Примечательно, что 13% респондентов признались, что переименовали свою команду DevOps в команду платформенного инжиниринга, «чтобы звучало более модно», так что Gartner может быть права в том, что эта дисциплина скатилась в «впадину разочарования».
В отчете «2024 Accelerate State of DevOps», более известном как отчет DORA, были получены неутешительные результаты. Например, исследователи обнаружили, что при применении платформенного инжиниринга пропускная способность снижается на 8%, а стабильность изменений — на 14%.
Поскольку это был первый год, когда члены команды DORA измеряли платформенный инжиниринг, они не утверждают, что у них есть объяснения обнаруженным фактам, хотя и предполагают, что увеличение скорости выхода на рынок может означать, что в целом выпускается больше изменений, что может снизить общую стабильность.
От DevOps к платформенному инжинирингу
Новый отчет уникальным образом показывает платформенный инжиниринг как эволюцию DevOps с точки зрения должностных ролей. В нем инженеры инфраструктурных платформ и инженеры платформ DevEx располагаются в пирамиде занятости выше инженеров инфраструктуры, операторов и разработчиков. По сравнению с ролями в DevOps, здесь меньше «драйверов ценности» платформы, отвечающих за облегчение базовой головной боли за счет стандартизации и автоматизации.
Учитывая это, в 2024 г. платформенные инженеры в Европе зарабатывают больше, чем DevOps-специалисты, на 23%, а в Северной Америке — на 27%, говорится в отчете.
Если в 2022 г. различия между ролями инженера платформы и DevOps были неясны, то в
Разница в зарплате между инженерами платформы и DevOps сократилась вдвое по сравнению с прошлым годом, когда первые зарабатывали на 42% больше, чем вторые. Это может быть еще одним признаком того, что платформенный инжиниринг по-прежнему важен, но не настолько, как, возможно, изначально считалось в отрасли.
«То ли это сокращение разрыва из-за больших увольнений, то ли из-за того, что зарплаты в DevOps выросли, а зарплаты платформенных инженеров снизились, — точно не известно», — полагает Барлиен.
За последние три года в отчете постоянно фиксируется, что у человека с должностью платформенного инженера на годы больше опыта, чем у человека с должностью DevOps-инженера. Так, 28% платформенных инженеров, опрошенных в этом году, имеют более чем
Насколько зрелыми являются команды разработчиков платформ?
Чуть больше года назад Cloud Native Computing Foundation (CNCF) выпустила модель зрелости платформенного инжиниринга. Это схема для оценки инициатив в этой сфере и выявления областей, требующих улучшения, по следующим направлениям: инвестиции; внедрение; интерфейсы; операции; измерения.
Эти аспекты оцениваются количественно по уровням — от менее к более зрелым, а именно:
- Предварительный.
- Операционный.
- Масштабируемый.
- Оптимизируемый.
В прошлогоднем исследовании «State of Platform Engineering, Vol. 2» было обнаружено, что организации, занимающиеся платформенным инжинирингом, находятся на ранней стадии развития, и им еще предстоит внедрить лучшие практики, включая:
- Процессы управления изменениями.
- Межорганизационное взаимодействие.
- Четкая структура команды разработчиков платформы.
- Мышление «платформа как продукт».
- Стратегия внедрения платформы.
В связи с тем, что платформенный инжиниринг уже третий год является трендовой технологической темой, в отчете этого года сделана попытка дать количественную оценку его зрелости. Если коротко, то большинство команд еще далеки от зрелости.
«Результаты исследования отражают то, что для людей, которые хорошо занимаются платформенным инжинирингом и он работает для них, это впечатляюще, — говорит Барлиен. — А для тех, кто не справляется с этой задачей, результат выглядит полной противоположностью».
Только около 9% респондентов оказались действительно зрелыми по модели CNCF. У остальных видно общее отсутствие ясности относительно того, что такое платформенный инжиниринг — а ведь это те, кто, как они сами сообщают, играет роль инженера платформы. «На многие простые вопросы о платформенном инжиниринге люди отвечали „другое“, или их ответ был „я этого не понимаю“», — отмечает Барлиен.
В отчете говорится, что хотя многие компании внедряют платформенный инжиниринг, лишь немногие реализуют его потенциал в зрелом и масштабируемом виде. Но это не должно удивлять, поскольку среднестатистическая опрошенная команда существует от нуля до 24 месяцев,.
Команды разработчиков платформ не знают, как проводить измерения
Исследование, проведенное в этом году, раскрыло самый громкий секрет инженерной или любой другой науки: вы не можете улучшить то, что не измеряете.
Около 43% опрошенных платформенных команд охарактеризовали свои механизмы обратной связи как «ситуативные» или «непоследовательные». Это очень далеко от стандарта CNCF, предусматривающего количественную и качественную обратную связь. «Люди понятия не имеют, что они делают, — говорит Барлиен. — И это главный вывод».
Более того, 45% платформенных команд вообще ничего не измеряют, а 37% измеряют только показатели DORA. Хотя эти показатели, сфокусированные на пропускной способности и стабильности, являются важными аспектами опыта разработчиков, они, конечно, не дают детального представления о DevEx. «Если вы не измеряете, вы не знаете, есть ли у вас реальная разница или нет, — говорит Барлиен, — а потом вдруг, спустя шесть месяцев, вы проводите проверку, и все оказывается еще хуже».
Еще 26% участников опроса сообщили, что собирают данные, но не анализируют их.
На вопрос о том, как улучшились показатели после внедрения платформенного инжиниринга, только 22% сообщили о значительных улучшениях, в то время как 32% отметили незначительный рост. При этом 17% сообщили, что никаких заметных изменений не произошло, а 27% не определились с ответом.
Это не только снижает мотивацию команд разработчиков платформ, но и затрудняет доказательство того, что они заслужили свой бюджет и достойны сохранить работу.
В отчете также отмечается, что 39% команд сообщили, что их платформа «централизована и ориентирована на потребности пользователей». Но если они не измеряют этот показатель, то такое утверждение может быть основано на предположениях. «Этот разрыв свидетельствует о том, что многие организации представляют себя в гораздо лучшем свете, чем на самом деле», — отмечает Барлиен.
К этому следует добавить, что существует почти 10%-ное расхождение между теми организациями, которые заявили о повышении производительности благодаря внедрению платформенного инжиниринга, — 54% — и теми, кто вообще не измеряет показатели успеха, — 45%.
«Люди одновременно говорят: „О да, все замечательно“ и „О нет, мы ничего не измеряем“, — размышляет Барлиен. — Это неудивительно, если посмотреть на что-то вроде метрик DORA — нестабильность и когнитивная нагрузка растут».
Чего не хватает? Продуктового мышления
«Платформенный инжиниринг — это ступенька между управлением продуктом и чем-то сугубо техническим и инженерным», — говорит Барлиен. Но, добавляет он, многие команды разработчиков платформ все еще не понимают этого. Им не хватает навыков управления продуктом, в том числе:
- Исследование пользователей.
- Измерения для улучшения.
- Понимание того, чего хотят клиенты (ваши разработчики).
- Понимание того, используют ли ваши разработчики вашу платформу.
- Понимание того, как они ее используют.
«В отличие от DevOps или agile, с которыми инженер уже знаком, — поясняет Барлиен, — платформенный инжиниринг часто требует от него вхождения в совершенно новую область знаний».
Не используя точный термин, отчет указывает на то, что мышление «платформа как продукт» является главным отличием между теми немногими респондентами, которые успешно занимаются платформенным инжинирингом, и подавляющим большинством тех, кто не справляется с этой задачей.
