Platform Engineering от А до Я. Часть 1: знакомство с передовой методологией организации команд разработки

Всего 32% рабочего времени разработчиков уходит на написание кода, а остальное время специалисты тратят на непрофильные задачи. Это сильно «бьет» по производительности команд и приводит к сопутствующим издержкам. Поэтому бизнес всё чаще стремится оптимизировать организацию команд разработки и инструментов для них, в том числе с помощью внутренних платформенных сервисов. Так, ожидается, что к 2026 году у 80% компаний, так или иначе связанных с ИТ, будут свои внутренние платформы.

Мы запускаем серию материалов о Platform Engineering, в которой подробно рассмотрим все аспекты: от нюансов методологии до алгоритмов построения своей платформы разработки.

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

Что нужно знать об эффективности команд разработки

Мировая и российская отрасль разработки программного обеспечения динамично развивается и постепенно охватывает все сферы бизнеса. Этому способствует множество факторов, например, использование ИИ-инструментов для упрощения работы с кодом.

Ответом на глобальную цифровизацию и востребованность повсеместной разработки ИТ-продуктов, для многих компаний стал переход от аутсорса к In-house-разработке.

Примечание: Команды In-house-разработки зачастую кросс-функциональны и включают не более 15 специалистов разных ролей (команды большего размера менее эффективны — это подтверждают исследования). Такая «автономная командная экосистема» дает возможность выстраивать полный пайплайн разработки без зависимости от других отделов и стороннего влияния на скорость релизов.

Вместе с тем, компании в целом и команды разработки в частности, независимо от специфики разрабатываемых продуктов, обычно сталкиваются с похожими вызовами.

• Эффективность команды определяется только временем, затраченным непосредственно на разработку полезных функциональностей. Но на практике специалистам также приходится решать много задач, которые никак напрямую не влияют на прибыль бизнеса или развитие продукта. К таким можно отнести различные согласования, обучение новых сотрудников, подготовку инфраструктуры, настройку инструментов. Соответственно, чем больше разработчики отвлекаются на непрофильные задачи, тем ниже их эффективность.
• Time-to-market зависит не только от разработчиков. Приоритет любого бизнеса — быстрая выкатка разрабатываемых продуктов и фич. Но одной быстрой работы разработчиков недостаточно — специалисты также зависят от тестировщиков, DevOps-инженеров, ИБ и других департаментов. Соответственно, чем больше людей задействовано в этой «цепочке», тем больше «узких горлышек».
• Рутина влияет на качество продукта. В работе разработчиков много рутины. И лучшая практика — максимально автоматизировать ее или сократить. В противном случае можно довольно быстро столкнуться с выгоранием специалистов, апатией, снижением интереса к разрабатываемому продукту. Со временем качество продукта будет падать.

Таким образом, чтобы повысить эффективность создания продуктов, бизнесу важно минимизировать в процессах команд разработки однотипную работу, непрофильные задачи, искусственные барьеры и зависимости.

Чем могут помочь Platform Engineering и Internal Development Platform

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

Один из способов внедрения методологии — построение внутренних платформ разработки (Internal Development platform, IDP).

IDP — внутренняя платформа для разработчиков, на которой собраны и доступны готовые инструменты, шаблоны, пайплайны сборки и не только. IDP:

• помогает разработчикам быстрее и проще создавать и запускать приложения, автоматизируя рутинные задачи;
• стандартизирует стек используемых инструментов и помогает уйти от «зоопарка технологий»;
• выступает в качестве единой точки входа и источника истины;
• снижает непрофильную нагрузку и предоставляет разработчикам готовые решения, которые сразу можно использовать в своих проектах.

Примечание: IDP напоминает конструктор LEGO для разработчиков: вместо того чтобы каждый раз собирать всё с нуля, они могут использовать уже готовые «кирпичики» и сосредоточиться на разработке новых функций.

Немного подробнее об Internal Development Platform

Тенденция на построение внутренних платформ начала формироваться не так давно — около 10 лет назад, одновременно с началом глобальной цифровизации бизнеса. Становлению тренда во многом способствовало несколько факторов.

• Независимые команды внутри компании обычно проходят одинаковый путь: найм новых специалистов, запрос доступа к инструментам и ресурсам, развертывание окружений для разработки и выкатки продукта и другие.
• Многие команды не просто сталкиваются с типовыми задачами (в том числе архитектурными), но и решают их схожим образом.
• Часто «узкое горлышко» в процессах разработки оказывается на стороне смежных команд. Например, всегда нужно закладывать время, чтобы релиз мог пройти проверку отделом ИБ. Сократить время на этот этап почти невозможно без глобального пересмотра политик и регламентов. Можно сказать, что это обязательная потеря времени, с которой приходится считаться всем компаниям.

Таким образом, в больших компаниях можно было встретить ситуацию, при которой несколько команд разработчиков одновременно, но независимо настраивают одинаковые инструменты, одновременно ждут развертывания нужной среды, одновременно ждут согласований от ИБ. Очевидно, требовалась определенная стандартизация, которая бы позволяла сократить дублирование работы и уменьшить «привязку» разработчиков к другим департаментам.

Ответом на это и стало появление внутренних платформ разработки — общего рабочего пространства, в котором сотрудникам доступны лучшие архитектурные практики, общепринятые библиотеки, шаблоны настроек, пайплайны, инструменты и не только. Причем в IDP, как в основной среде для разработчиков, это всё не просто доступно по модели as a service (например, развернуть нужную среду можно по клику без DevOps-инженера), но и предварительно проверено на соответствие требованиям ИБ. То есть внутренние платформы ИТ-команд одновременно:

• избавляют от рутины и дублирования работы;
• снимают зависимость от других отделов;
• улучшают производительность разработки.

Варианты реализации IDP

Построение IDP — довольно трудоемкий и ресурсозатратный процесс. Поэтому логично, что реализация IDP сейчас — прерогатива больших компаний Enterprise-уровня, у которых есть свои центры In-house-разработки и продвинутая экспертиза.

При этом к разработке IDP есть два подхода.

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

Преимущества от построения IDP

По прогнозам аналитиков, к 2026 году у большинства компаний, занимающихся разработкой, будут свои внутренние платформы. Столь востребованным и популярным решением IDP становятся благодаря тому, что отвечают на типовые вызовы и дают комплексный профит.

• Выработка корпоративных стандартов стека. IDP предполагает, что всем командам внутри компании доступны одни и те же инструменты, сервисы, шаблоны, библиотеки, пайплайны и другие компоненты. Это помогает в реализации кросс-командной работы и исключении фактора «теневого ИТ». Одновременно это позволяет сократить «зоопарк технологий», и, как результат, уменьшить расходы на лицензии и поддержку.
• Шаринг экспертизы. IDP подразумевает не только единый стек внутри компании, но и подготовку подробной документации для каждого инструмента и решения, включенного в единое пространство командной работы. Это упрощает онбординг новых специалистов, помогает прокачивать экспертизу и гарантирует, что даже уход отдельных сотрудников не повлияет на процессы.
• Повышение безопасности. Добавлять новые инструменты в IDP обычно может только платформенная команда. Соответственно, такая реализация позволяет выстроить процесс, при котором в платформу добавляются только те инструменты, шаблоны и библиотеки, которые предварительно проверены и одобрены отделом ИБ. То есть, всё, что могут получить разработчики, по умолчанию безопасно и разрешено. Более того, IDP-платформа является единственной точкой доступа к стеку, наработкам и библиотекам. Это дает возможность «обвесить» ее всевозможными проверками прав доступа.
• Стандартизация совместной работы разработчиков. Наличие единого стандартизованного стека не только упрощает администрирование, но и обеспечивает предсказуемость разработки. То есть всем командам заранее понятно, какой инструмент для реализации каждой фичи можно выбрать — не надо тратить время на сравнение, поиск актуальной версии сервиса, обеспечивать совместимость библиотек с решениями, которые используют другие команды.
• Ускорение подключения новых сотрудников. Как правило, при реализации IDP встраиваются механизмы SSO и проверки прав доступа. Это позволяет существенно быстрее подключать к проектам новых людей или даже целые команды, то есть дает ускорение онбординга.
• Получение ресурсов без бюрократии. Обычно в рамках IDP все инструменты предустановлены, проинтегрированы, преднастроены, а шаблоны — согласованы. Поскольку все компоненты фактически готовы к работе, каждый разработчик может самостоятельно, без DevOps-инженеров, в несколько кликов развернуть нужное окружение, получить IaaS- и PaaS-сервис и любой другой компонент.

Таким образом, внедрение внутренних платформ помогает бизнесу создать для разработчиков идеальные условия и кратно повысить бизнес-ценность, получаемую от них.

Основные сложности построения IDP

На пути к внедрению платформенного подхода и разработке IDP бизнес может сталкиваться как с организационными, так и с финансовыми блокерами. Но барьеры, как правило, типовые.

• Отсутствие экспертизы. IDP — специфический проект, который строится, а также наполняется инструментами и компонентами под нужды каждой конкретной компании. Соответственно, строгих стандартов разработки подобных платформ и работы с ними нет и быть не может. Поэтому бизнесу не всегда очевидно, что получится на выходе и будет ли итоговая реализация IDP полезной.
• Саботаж на уровне сотрудников. Одной из целей внедрения IDP является снижение зависимости разработчиков от DevOps-инженеров и других отделов. Понимая это, многие специалисты полагают, что построение платформы неизбежно приведет к сокращению штата. Но такое мнение ошибочно: цель IDP не отказаться от DevOps-инженеров и других сотрудников, а просто перераспределить их ресурсы. Тут всё логично: DevOps-инженерам всё так же надо будет готовить окружения, ИБ-специалистам всё так же надо будет проверять внедряемые в платформу компоненты, но однотипных задач для всех становится меньше.
• Опасение, что внедрение IDP негативно повлияет на выстроенные процессы. Платформенная инженерия и внедрение внутренних платформ подразумевают перестраивание отдельных процессов, пайплайнов разработки и согласования. Из-за этого компании нередко опасаются влияния на бизнес. Но правильно реализованная IDP позволяет выстроить замкнутый цикл разработки без негативного влияния на бизнес, а переход на новую методологию делает предельно бесшовным.
• Неопределенные инвестиции и сроки получения профита. На создание и внедрение платформы команды разработки действительно нужно много времени, вложений и ресурсов. Нередко требуется и создание отдельной платформенной команды. Но все операционные издержки вполне оправдываются ускорением релизных циклов, улучшением качества выпускаемых продуктов, снижением сложности их администрирования.

Таким образом, большинство распространенных возражений ошибочны. Более того, многие из них касаются только подхода с разработкой платформы «с нуля» без применения готовых решений. Вместе с тем, компаниям необязательно заниматься реализацией с нуля — чтобы перейти к концепции более бесшовно и преодолеть возможные сложности, можно воспользоваться готовыми решениями для построения IDP, например, Dev Platform от VK Cloud.

Как определить сроки и эффективность внедрения

Теперь о двух «неизвестных» при разработке и внедрении IDP.

Сроки

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

Оценка эффективности

Оценить рентабельность разработки и внедрения IDP нельзя напрямую. Поэтому окупаемость вложенных инвестиций обычно определяют по ряду косвенных признаков.

• Количество DevOps-инженеров на команду разработчиков. Без IDP разработчики неизбежно зависят от DevOps-инженеров. Поэтому при масштабировании команды вместе с новыми разработчиками нужно нанимать и дополнительных DevOps-специалистов (нередко соотношение достигает 1:1). С IDP зависимость разработчиков от других команд становится слабее, поэтому на 30-40 разработчиков будет вполне достаточно и 10-15 DevOps-инженеров (соотношение примерно 3:1).
• Time-to-market. Перестраивание процессов на работу через IDP помогает сократить подготовку стека, второстепенные задачи, согласования, проверки. Это позволяет не только увеличить частоту релизов, но и выпускать больше ИТ-продуктов силами текущей команды без повышения нагрузки на нее.
• Качество продуктов. Любая ошибка на этапе разработки и выкатки продукта в прод может привести к необходимости откатывать и дорабатывать обновления. Это неизбежно сопряжено с издержками, влияет на репутацию компании и лояльность пользователей. Выстраивание пайплайна разработки в IDP и использование только предварительно настроенных и согласованных компонентов позволяет кратно снизить количество ошибок, то есть повысить качество продуктов.
• Бизнес-метрики. Косвенно определить, какой эффект дает внедрение IDP, можно и по бизнес-метрикам. Например, по тому, как изменяются релизные циклы, вложения в разработку, инвестиции в лицензирование инструментов.

Примеры успешных реализаций

Зачастую от внедрения платформенного подхода и развертывания платформы разработки в компании выигрывают все:

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

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

• «Тинькофф». Большой цифровой банк предоставляет клиентам десятки всевозможных ИТ-сервисов, развитием и поддержкой которых занимается многочисленный штат ИТ-специалистов. Поскольку ИТ-задач в «Тинькофф» много, компания использует довольно разрозненный и сложный ИТ-ландшафт. Разработка IDP позволила компании объединить весь используемый стек, наработки и компетенции в единой среде и сделать их доступными для всех специалистов. О том, как «Тинькофф» выстроил защиту IDP, можно почитать здесь.
• «ЕвроХим». Компания является одним из лидеров в сфере производства минеральных удобрений. Для сохранения флагманских позиций на рынке компания начала цифровизацию производственных процессов, в рамках которой инициировала разработку IDP-платформы, в которой объединила решения и сервисы для построения любых внутренних систем. По прогнозам «ЕвроХима», внедрение IDP в перспективе позволит на 20% уменьшить трудозатраты и почти вдвое сроки реализации ИТ-продуктов.
• «Авито». Развитие и администрирование крупного интернет-сервиса подразумевает привлечение большого штата ИТ-специалистов, работу с big data и использование широкого стека инструментов. Чтобы уменьшить затраты на интеграцию с инфраструктурой, повторно использовать наработки команд и в формате единого окна администрировать стек, в «Авито» реализовали собственную IDP, с внедрением которой смогли ускорить и удешевить разработку, упростить управление технологиями и оперативно внедрять любые изменения.

Резюме

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

IDP — один из примеров реализации Platform Engineering. Строить подобные платформы нередко сложно и долго. Но Internal Development Platform позволяют «выкрутить возможности разработчиков на максимум» и получать от их работы больше бизнес-ценности, опережая конкурентов.

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