Самообслуживание — это возможность для разработчиков быстрее и качественнее внедрять инновации и одновременно снижать риски для бизнеса. О том, что нужно — и чего не нужно — делать при создании внутренней платформы разработки (internal development platform, IDP), на портале The New Stack рассказывает Дерек Эшмор, директор по трансформации приложений компании Asperitas.

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

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

Наиболее очевидным решением для обеспечения самообслуживания разработчиков может показаться развертывание IDP. Все большее число IDP — например, Open Source-продукты Backstage и Atlassian Compass — помогают предприятиям сделать разнообразные технические решения доступными для команд по требованию.

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

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

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

Прежде чем перейти к рассмотрению проблем, давайте разберемся, что такое самообслуживание разработчиков и какие преимущества оно дает как разработчикам, так и компаниям.

Упрощенно, самообслуживание разработчиков — это модель, при которой инженеры-программисты могут создавать сервисы и среды, необходимые им для продуктивной работы, без необходимости просить или ждать, пока ИТ-отдел установит и настроит эти решения. Как правило, для этого разработчики используют корпоративную платформу самообслуживания, предоставляющую различные готовые, официально поддерживаемые решения — например, сервис, позволяющий быстро и легко развернуть кластер Kubernetes или создать конвейер CI/CD с помощью утвержденных инструментов.

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

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

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

Разработчикам, не обладающим глубоким пониманием Kubernetes, также не придется тратить много времени на создание среды. Аналогичная логика применима и к сетевым инженерам, сисадминам и любым другим специалистам, чьи знания высоко востребованы на рынке.

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

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

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

1. Платформы, не соответствующие задачам разработчиков

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

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

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

2. Поддержание качества

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

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

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

3. Поддержка платформы

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

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

4. Вопросы стоимости

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

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

5. Отсутствие вовлеченности

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

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

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

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

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