Когда инженерные метаданные неточны, разработчикам и менеджерам становится невозможным принимать решения, основанные на истине, пишет на портале The New Stack Дженна Данной, возглавляющая отдел контент-маркетинга платформы для внутренних порталов разработчиков (IDP) Port.
Согласно отчету Port «2025 State of Internal Developer Portals», половина инженеров не очень доверяет данным, на которые они больше всего полагаются в своей центральной системе учета. Это представляет собой серьезную проблему для разработчиков и инженерных команд в целом, поскольку центральные системы учета являются важнейшими инструментами для современной разработки ПО.
Когда инженерные метаданные неточны, доверять им становится невозможно. Это означает, что инженеры могут быть менее готовы полагаться на данные, к которым они имеют доступ — даже если их можно проверить — из-за предыдущих проблем с данными, повторяющихся неудач с изменениями или общего ощущения, что они могут «обжечься» на неточной статистике. Без точных данных команды становятся уязвимыми перед конкурентами и снижением качества создаваемого ПО.
Каждая центральная система учета, например Confluence, база данных управления конфигурациями (CMDB) или Jira, содержит ключевые сведения об эффективности разработчиков, пропускной способности команды, стабильности системы, программной инфраструктуре и связях команды с каждой частью ПО в зависимости от владельца. Недостаток доверия к этим данным может вызвать проблемы у разработчиков и менеджеров при принятии решений по кодированию, обработке инцидентов, откате неудачных развертываний и определении приоритетности задач в зависимости от их ценности для бизнеса. Если они не доверяют (или не могут доверять) этим данным, они часто принимают решения на основе неполной или неточной информации.
Проблемы с устаревшими методами сбора данных
Отсутствие достоверных данных усугубляет проблемы, с которыми вы сталкиваетесь в рамках конвейера разработки ПО и в области инженерной культуры. Если ваша команда не может получить доступ к точным метаданным о вашей организации в реальном или близком к реальному времени, вам будет сложно устранять инциденты, повышать эффективность работы разработчиков и управлять затратами.
Однако, несмотря на ограничения традиционных методов, многие организации продолжают в той или иной мере полагаться на них: 25% организаций продолжают использовать CMDB, а 17% — электронные таблицы, говорится в отчете.
Обычно организации не переходят на новые методы отслеживания метаданных программных активов по одной из следующих причин:
- они потратили годы на настройку и расширение своих методов в соответствии со своими специфическими потребностями;
- они не хотят переходить на современные альтернативы, которые могут нарушить рабочие процессы;
- при наличии серьезных проблем и неэффективности рабочего процесса внедрение нового инструмента может оказаться слишком большой когнитивной нагрузкой, чтобы брать ее на себя без доказанной наперед пользы.
Все это обычные причины, которые вы можете услышать, пытаясь внедрить новые инструменты или сформировать новую инженерную культуру. В результате лишь немногие организации имеют действительно актуальные данные. Только 6% опрошенных инженеров сообщили, что ежедневно вручную обновляют метаданные программных активов в таких системах, как электронные таблицы, Confluence, Jira или CMDB, а 53% организаций обновляют свои репозитории метаданных не чаще одного раза в неделю.
Более того, большинство распространенных репозиториев метаданных обеспечивают ограниченную совместимость с дополнительными системами, что приводит к трудностям в получении полной картины конвейера. Чтобы восполнить пробелы, инженеры в итоге используют несколько репозиториев, что открывает путь к дальнейшим неточностям и устаревшей информации.
Эти инструменты также не могут, как правило, измерить истинную отдачу от ваших инвестиций без значительной работы по интеграции или сбора данных вручную в нескольких инженерных системах, особенно в условиях, когда генеративный искусственный интеллект (GenAI) продолжает усиливать влияние на разработку ПО.
Ликвидация разрыва между разработчиком и менеджером
Существует расхождение между доверием к этим репозиториям разработчиков и их руководителей. Если данным, к которым они могут получить доступ в унаследованных репозиториях метаданных, доверяют 56% руководителей инженерных подразделений, то среди разработчиков таковых только 46%.
Хотя возможно, что более высокое доверие руководителей к этим репозиториям обусловлено менее глубоким знакомством с их системами, такой разрыв в степени доверия указывает на то, что инженеры и менеджеры могут работать с совершенно разных позиций понимания. Это может приводить к разрыву и дальнейшему недопониманию целей и приоритетов проекта, расхождениям в восприятии срочности решения тех или иных вопросов и т. д.
Например, руководитель конкретной команды инженеров может захотеть понять, как за квартал изменился показатель отказов вследствие изменений в этой команде. Если он увидит, что он увеличился, то, используя всего одну или две системы для выяснения причин, он может сделать вывод, что количество отказов увеличилось по негативным причинам, например из-за того, что команда не пишет код по спецификации или испытывает трудности и спешит развернуть его вовремя.
Но когда разработчики проводят расследование, они могут использовать разные системы для поиска данных и получить другие результаты, например, увидеть, что сбои в развертываниях связаны с периодом повышенного количества или неожиданных срабатываний ложноположительных предупреждений. С их точки зрения, эта проблема могла быть вызвана временным сбоем в среде, который был устранен, а значит, имевший место всплеск частоты отказов не является поводом для беспокойства в будущем.
Тем временем разработчики и инженеры, скорее всего, уже посетили бесчисленное количество совещаний, чтобы обсудить данные, согласовать их точность, представить их руководству, предложить и реализовать решения, что отнимает время от разработки и вызывает всеобщее разочарование.
Подобные сценарии показывают не только то, почему точная информация необходима для современной разработки ПО, но и то, почему важно, чтобы каждый сотрудник инженерной организации понимал и имел доступ к единому, унифицированному, всеобъемлющему репозиторию метаданных.
Почему IDP набирают популярность?
Согласно нашему исследованию, инженерные команды хотят уйти от этих неурядиц в коммуникациях и сборе данных. Более половины (53%) опрошенных организаций внедрили IDP, чтобы решить эти проблемы с точностью и ясностью данных, а почти четверть (23%) — специально для того, чтобы он служил репозиторием метаданных.
Внутренние порталы разработчиков обеспечивают широкий обзор конвейера разработки и встроенный контроль доступа на основе ролей (RBAC), что дает любому сотруднику организации доступ к данным и возможность обновления в режиме реального времени. Они снижают потребность в дополнительной документации, а также позволяют командам работать вместе с одной и той же отправной точки по всем вопросам, объединяя команды против проблем, а не друг против друга.
IDP также обеспечивают масштабируемость и значительно сокращают объем рутинного ручного обслуживания, которое ранее требовалось для объединения всех систем, используемых в процессе разработки ПО, в единый интерфейс. Это означает, что разработчики могут потратить больше времени на кодирование, а не на ручную проверку каждого внешнего сервиса, сравнение текущих и старых данных на предмет обновлений и последующее обновление системы записей для каждого внесенного изменения.
