Who are you, Platform Engineering: разбираемся с одним из главных технологических трендов. Часть 1

Platform Engineering — один из главных технологических трендов 2024 года. По оценке Gartner, к 2026 году 80% компаний, занимающихся разработкой, будут иметь внутренние платформенные сервисы и команды для повышения эффективности разработки. 

Мы в VK Cloud предлагаем Dev Platform — платформу для разработки, которой смогут пользоваться другие компании. В серии статей о методологии  Platform Engineering и создании Internal Development Platform (IDP), мы поделимся своим подходом построения платформенных решений, расскажем о сложностях и о том, почему даже правильный подбор компонентов и архитектурных решений для IDP — не панацея.

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

Про эффективность разработки

Внедрение Agile, DevOps и TeamFirst-подходов вместе с активным развитием облаков и инструментов деплоя привело к взрывному росту разработки ПО во всех сегментах экономики. Бизнес стал активно наращивать In-house-разработку в попытке повысить собственную эффективность и занять новые рыночные ниши. 

Как правило, типовая команда разработки кросс-функциональна и включает до 15 человек разных ролей — от менеджера продукта и разработчиков до QA и DevOps. Такой состав специалистов позволяет команде достичь высокой автономности и высокой степени ответственности за продукт, что существенно сокращает Time-to-market. Примечательно, что привлекать в команды более 15 человек нежелательно: результаты исследований показывают, что в таком случае выстраивать коммуникации внутри команды становится сложнее, участники начинают «кластеризоваться» по узлам коммуникаций, а доверие между ними падает. Это неизбежно сказывается на показателях всей команды. Более того, нужно учитывать ограниченность когнитивных способностей мозга: человек не способен одновременно решать более 7–9 задач средней сложности без снижения качества результата. Поэтому большие команды с большим пулом задач не лучший путь.

Одновременно с «типизацией команды» технические специалисты и бизнес, как правило, сталкиваются и с типовыми проблемами, свойственными командам независимо от задач и сферы деятельности:

• Эффективность разработки напрямую зависит от того, сколько времени команда уделяет разработке ценной для бизнеса функциональности ПО. При этом у команд есть обязательные активности, которые никак не связаны с созданием ценности для бизнеса: онбординг новых сотрудников, настройки Observability-сервисов для продукта, построение конвейеров CI/CD, получение ресурсов и разного рода согласований от ИТ- и ИБ-подразделений. На все эти активности команда обычно тратит очень много времени и ресурсов, отвлекаясь от разработки. При этом допустимый объем когнитивной нагрузки у команд лимитирован (в первую очередь из-за лимита участников команды). 
  
• Бизнесу важно, чтобы Time-to-market разрабатываемых решений и функций был минимальным. Но на практике команда разработки упирается в зависимость от специалистов других подразделений: достичь полной автономности в поставке и сохранить высокую эффективность трудно, так как сложность ПО и условия его производства и эксплуатации постоянно растут. 
  
• В работе команд разработки по умолчанию много рутины, которая нередко не только влияет на производительность команды в части поставки продукта (что приводит к задержкам в релизах), но и снижает качество поставляемых решений. Если проблема рутины нерешаема, можно получить ситуацию с постоянными овертаймами и, как следствие, падением морали, выгоранием и апатией. Все это имеет существенные негативные последствия для продукта и бизнеса.
  

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

О Platform Engineering и Internal Development Platform

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

Одним из примеров реализации платформенного подхода является создание внутренней платформы разработки (Internal Development platform, IDP), с помощью которой команда разработки может решать все непрофильные вопросы в режиме самообслуживания — от запроса инфраструктуры и стендов до получения доступа к Observability-сервисам, необходимым инструментам разработки и использования типовых конвейеров сборки и деплоя. 

Internal Development Platform (IDP) как платформа «единого окна» для разработчиков:

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

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

Рассмотрим подробнее реализацию платформенного подхода на примере IDP.

Зарождение Internal Development Platform

Тренд на создание Internal Development Platform молодой, но индустрия двигалась к внутренним платформам разработки достаточно давно. 

Уже на этапе зарождения тренда на цифровую трансформацию (2012–2015 гг.) стали очевидными три момента:

1. Команды внутри компании проходят один и тот же путь: онбординг сотрудников, получение доступов к инструментам, получение ресурсов для сборки и деплоя и так далее.
   
2. Команды используют схожие CI/CD-процессы по сборке и деплою продукта, а также идентичные техники Observability. Более того, многие команды решают одни и те же архитектурные задачи — например, в контексте создания отказоустойчивого PostgreSQL или разработки Stateless-микросервисов.
   
3. Темпы разработки часто тормозятся на стороне ИТ и ИБ — эти подразделения становились узким горлышком на пути к поставке продукта. Если разработка смогла перестроиться на быстрые изменения и развертывания, то ИБ и ИТ отставали. В этих подразделениях многие операции были ручными, а процессы — медленными и не адаптированными для работы на больших масштабах.
   

Таким образом, компаниям требовалось минимизировать подобное дублирование работы и обойти ограничения без ущерба для безопасности. Решением стала идея консолидации всех лучших архитектурных практик, шаблонов настроек, зашивание требований ИБ в Workflow развертывания инфраструктуры и автоматизация выделения инструментов разработки с последующим предоставлением всего упомянутого по модели as a service (aaS). 

Так начали зарождаться внутренние платформы, а команды разработки получили единый портал, через который можно запросить все необходимое для работы без месяцев настроек и согласований, например виртуальную машину, Kubernetes Cluster, СУБД, создать репозиторий в GitLab, развернуть репозиторий и т. д. 

Особенности реализации Internal Development Platform

Сейчас почти все крупные компании смотрят или уже используют IDP. В России тренду активно следуют крупные компании, у которых есть собственные центры In-house-разработки и накоплена широкая экспертиза по автоматизации ИТ-инфраструктуры — в таком случае затраты ресурсов и времени на построение IDP и ее поддержку будут полностью оправданы. 

В Enterprise-сегменте IDP-платформы зачастую строятся на базе облачных оркестраторов (HP CSA, VMware vRA, OpenStack и др.), которые предоставляют «конструктор» ИТ-услуг и широкий стек плагинов для быстрого создания собственных порталов самообслуживания с каталогом услуг. Как правило, на этом пути компаниям в Enterprise-сегменте помогают интеграторы, которые обладают необходимыми компетенциями.

В то же время многие компании создают платформы разработки с нуля, без использования готовых решений — как правило, это компании с высоким уровнем культуры разработки, которые имеют точное представление, что они хотят получить от платформы, а также готовы инвестировать значительные ресурсы на ее создание и поддержку. Это позволяет им интегрировать в IDP собственные самописные инфраструктурные сервисы (Observability, IaM и т. д.), CI/CD-инструменты и другие решения. 

Иными словами, IDP в таких компаниях адресно заточены на бизнес-процессы внутренней разработки. 

Почему Platform Engineering в тренде?

Подход Platform Engineering стал трендом, потому что вызовы, на которые он отвечает, стали массовыми, а профит от внедрения очевиден.

К положительным результатам использования Platform Engineering можно отнести:

• Выравнивание технологического стека между командами. Использование разными командами одних и тех же сервисов и инструментов, доступных в IDP, позволяет повысить эффективность кросс-командной работы, минимизировать «теневое ИТ», сократить «колодцы компетенций», в которых варятся отдельные специалисты и даже команды. 
  
• Минимизация «зоопарка технологий». Построение портала самообслуживания позволяет выработать унифицированный набор инструментов, применяемых в компании. Это дает возможность сократить стек за счет отказа от лишних и дублирующих решений — например, когда в разных департаментах компании используют разные инструменты с идентичным функционалом. Уход от «зоопарка технологий» упрощает поддержку стека, его администрирование и сокращает расходы на лицензии. В то же время растет экспертиза команды поддержки этого инструментария со стороны IDP, так как нет необходимости распылять ресурсы на изучение разных продуктов и решений.
  
• Обеспечение Knowledge Sharing. Создание IDP-платформы подразумевает и разработку подробной сопутствующей документации, которая проводит пользователей «за ручку» по типовым кейсам — от построения CI/CD-конвейера до деплоя в продуктив. Это обеспечивает преемственность экспертизы и гарантирует, что команда сможет продолжать работу с инструментами, даже если часть сотрудников — носителей экспертизы уволится. Минимизируется Bus-фактор-эффект.
  
• Повышение безопасности. IDP-платформа фактически представляет собой единую точку доступа к инструментам. Это дает возможность встраивать в цепочку «пользователь — инструмент» решения безопасности — например, для проверки прав доступа и выполнения процедур согласования. Также пользователи IDP могут использовать уже одобренные сотрудниками ИБ-ресурсы и ИТ-сервисы. 
  
• Стандартизация и улучшение совместной работы. Platform Engineering предполагает использование определенного набора инструментов и фреймворков. Это упрощает разработку приложений и позволяет выработать четкий стандарт компонентов, например для мониторинга, логирования, трейсинга. Команды разработки могут использовать готовые компоненты и функциональности для быстрого создания приложений и сервисов, что также упрощает интеграцию создаваемых решений между собой. Это снимает часть когнитивной нагрузки с команд разработки и повышает их эффективность.
  
• Ускорение онбординга. Внедрение IDP-платформы с единым стеком и общими правилами работы с инструментами сокращает сроки подключения к проекту новых пользователей или целых команд. Это достигается за счет механизмов SSO и тесной интеграции с инструментами разработки, а также заранее согласованными правами и доступами со стороны ИБ.
  
• Быстрое и небюрократизированное получение ресурсов. Platform Engineering позволяет легко получать доступ к вычислительным ресурсам за счет заранее согласованного каталога ИТ-услуг (со стороны ИБ- и ИТ-блоков), в котором опубликованы адаптированные под компанию IaaS- и PaaS-сервисы. В этом случае на получение необходимых ресурсов надо несколько минут, а не недель.
  

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

Барьеры на пути внедрения и разработки Internal Development Platform

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

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

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

Отдавая построение IDP-платформы на аутсорс, компания может нивелировать часть недостатков и ускорить принятие концепции Platform Engineering.

Сроки внедрения и оценка эффективности

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

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

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

• Соотношение количества разработчиков и DevOps-инженеров. Например, если до внедрения IDP-платформы на 10 команд разработки надо было 10 DevOps-специалистов, то после реализации решения при масштабировании разработки в 3 раза количество DevOps-инженеров будет расти незначительно — например, до 15 человек (без платформы был бы почти пропорциональный рост).
  
• Частота релизов. За счет сокращения согласований, проверок и второстепенных задач, улучшения взаимодействия команд разработки между собой, Time-to-market также сокращается. Это позволяет увеличить количество релизов без ущерба качеству и кратного повышения нагрузки на разработчиков.
  
• Количество допускаемых ошибок. Унификация инструментов и технологий, а также возможность получить нужные ресурсы без сложных манипуляций позволяет кратно сократить число допускаемых при развертывании и деплое ошибок. 
  
• Оценка эффективности. Формализация подходов и инструментов позволяет задавать и отслеживать метрики (как технические, так и бизнес-), которые, в свою очередь, помогут оценить эффективность изменений или же помогут быстро определить узкие места.
  

Примеры успешных кейсов

Основными стейкхолдерами внедрения IDP-платформ, как правило, выступают:

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

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

• «ЕвроХим». Международная химическая компания, один из крупных производителей минеральных удобрений. Компания начала разработку IDP-платформы в соответствии со стратегией цифровизации производственных процессов. В рамках внутренней платформы разработки «ЕвроХим» объединяет решения и инструменты для построения всевозможных систем — от систем управления производственным процессом до систем KPI и диспетчерских центров. По оценкам компании, работа с IDP-платформой позволяет на 40% сократить сроки реализации проектов и на 20% уменьшить трудозатраты.
  
• «Авито». Лидирующая российская онлайн-платформа для коммерции. Компания имеет большой штат ИТ-специалистов, задействует широкий стек технологий и работает с огромным массивом данных. Чтобы снизить оверхед на интеграцию с инфраструктурой, переиспользовать лучшие инженерные практики, а также централизованно контролировать технологии и решения, компания построила свою внутреннюю платформу разработки. Внедрение IDP позволило «Авито» экономить время и ресурсы со стороны продукта, легче контролировать «зоопарк» и быстро вносить любые платформенные изменения на всю компанию.
  
• «Тинькофф». Крупный банк, который обслуживает миллионы клиентов и предоставляет им десятки различных ИТ-сервисов. «Тинькофф» во многом ориентирован на Digital, поэтому в компании большой штат ИТ-специалистов и большой пул ИТ-задач. Чтобы объединить Self-service API, инструменты, сервисы, наработки и компетенции, в «Тинькофф» создали внутреннюю платформу, которая успешно решает задачи тысячи внутренних разработчиков. О защите IDP в рамках своего доклада на VK Kubernetes Conf рассказывал ведущий специалист обеспечения Kubernetes и Cloud безопасности в «Тинькофф» Николай Панченко.
  

Главное из статьи

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

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

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