Платформы самообслуживания разработчиков (также называемые платформами внутренней разработки, IDP) могут сделать процесс разработки ПО более эффективным, однако у них есть и потенциальные подводные камни. О том, как убедиться в том, что эти платформы приносят пользу вашим командам, на портале ITPro Today рассказывает Кристофер Тоцци, технологический аналитик Fixate.IO.

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

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

Что такое платформа самообслуживания разработчиков?

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

Например, если разработчикам необходимо запустить кластер Kubernetes для тестирования создаваемого приложения, благодаря IDP они могут получить доступ к готовому кластеру и запустить его по требованию. Если же им нужно развернуть конвейер CI/CD, на котором они смогут работать над новым приложением, они могут обратиться к платформе самообслуживания, чтобы получить набор инструментов CI/CD, которые уже были настроены для них.

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

Потенциальные проблемы самообслуживания разработчиков

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

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

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

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

Но в определенный момент попытки автоматизировать взаимодействие между разработчиками и ITOps могут обернуться неудачей. Беседы между двумя группами важны для того, чтобы держать их на одной волне и гарантировать, что они знают о потребностях друг друга. Если ваши разработчики никогда не общаются с ИТ-инженерами, потому что они все делают с помощью платформы самообслуживания, которую внедрила ИТ-команда, то, скорее всего, эта платформа будет плохо согласовываться с потребностями разработчиков из-за отсутствия связи между двумя группами.

Как сделать самообслуживание разработчиков лучше

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

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

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