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

Рынок внутренних платформ разработки расширяется на фоне практической потребности бизнеса в ускорении разработки и упрощении внутренних процессов. Компании стремятся сократить time-to-market, уменьшить зависимость от дефицитных DevOps-специалистов и выстроить контролируемый внутренний контур с учетом требований безопасности и комплаенса — на это указывает генеральный директор HDTech Владимир Вощук.

Повышенный интерес к внутренним платформам разработки обусловлен не только стремлением к автоматизации, но и усложнением самой разработки и инфраструктуры. Как отмечает руководитель продукта GitFlic «Группы Астра» Кирилл Довгаль, IDP прежде всего решает задачу интеграции разрозненных инструментов и процессов в единую среду, формируя общий стандарт разработки и повышая управляемость жизненного цикла ПО.

Сложности, с которыми сталкиваются создатели IDP, можно объединить в несколько категорий:

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

Рассмотрим каждую из них немного детальнее.

Упорядочивание в IDP — как найти баланс между единообразием и гибкостью

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

Однако в ходе создания платформы неизбежно приходится учитывать интересы всех задействованных отделов:

• самих разработчиков;
• команды DevOps;
• специалистов по информационной безопасности;
• тех, кто отвечает за приобретение лицензий и прочее IT-обеспечение.

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

На практике это противоречие усугубляется тем, что IDP одновременно служит и средством стандартизации, и способом упрощения работы со сложными современными стеками. Директор по техническому развитию платформы «Сфера» (Т1) Александр Степчков отмечает, что платформа становится «единым центром управления», позволяющим работать с микросервисной архитектурой и разнородными инструментами без ручной координации между командами.

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

Ещё одна сложность, связанная с настройкой самой IDP, — это поиск равновесия между строгими правилами и свободой действий. Здесь возможны два крайних варианта:

1. Недостаточно чёткие регламенты и слабый контроль процессов со стороны платформы. В таком случае ожидаемый эффект в виде ускорения разработки и сокращения ошибок не будет достигнут.
2. Чрезмерно жёсткие ограничения. Все процессы настолько зарегламентированы, что разработчикам остаётся свобода лишь в нескольких фрагментах кода. В результате специалисты начнут массово обходить платформу, например, используя собственный API с интеграцией через OAuth.

Однако излишняя строгость регламентов нередко приводит к противоположному результату. «Платформа обязана обеспечивать максимально простой и надежный способ решения задач, но не должна становиться авторитарной системой», — подчеркивает Александр Степчков.

А вот что говорит Владимир Вощук: «Заказчику важна не функциональность в количественном выражении, а понятная польза в повседневной деятельности».

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

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

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

IDP и столкновение технологий

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

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

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

Время и затраты: что сокращается, а что увеличивается

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

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

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

Почему команду «лихорадит» при переходе на IDP и как с этим справиться

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

Во многом это связано с тем, что дело не ограничивается технологиями. «Переход на IDP — это не техническая, а культурная трансформация», — подчеркивает Александр Степчков.

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

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

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

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

Ключевой принцип IDP — равновесие

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

На практике компании всё чаще выбирают итеративный подход — внедряют платформу поэтапно, адаптируя её к реальным процессам и постепенно объединяя инструменты в единую экосистему. Такой метод, отмечает руководитель продукта GitFlic «Группы Астра» Кирилл Довгаль, помогает снизить сопротивление команд и ускорить получение практической отдачи от IDP.