Когда ваша платформенная команда строит шоссе, которым никто не пользуется

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

Но команды приложений этим не пользуются.

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

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

Почему команды бросают внутренние платформы

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

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

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

Относитесь к платформе как к продукту

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

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

Это не требует формального процесса управления продуктом. Это может начаться с простых привычек:

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

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

Поддерживайте платформу в актуальном состоянии

Обновление платформы — это не просто обновление версий инструментов. Это поддержание путей деплоя в соответствии с тем, как команды на самом деле работают.

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

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

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

Цена запущенной платформы

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

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

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

Короткий чеклист для платформенных команд

Если вы отвечаете за платформу, вот несколько вещей, которые стоит регулярно проверять:

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

Эти вопросы не об инструментах. Они о том, полезна ли ваша платформа тем, кто от нее зависит.

Настоящая мера платформы

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

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