Atulpriya Sharma, будучи послом CNCF и организатором Platform Engineering TCG, считает, что главный вопрос платформенной инженерии заключается не в том, создала ли организация платформу, а в том, как разработчики фактически взаимодействуют с её возможностями. Организации, у которых ещё нет официальной платформы, обычно полагаются на разрозненные скрипты и индивидуальные знания, тогда как другие могут иметь портал разработчиков, интерфейс CLI и готовые рабочие процессы, но по-прежнему обрабатывать запросы вручную. В обоих случаях проблема заключается в зрелости интерфейса, через который команды используют возможности платформы.
Материал опирается на модель зрелости платформенной инженерии CNCF, которая независимо оценивает пять аспектов: инвестиции, внедрение, интерфейсы, процессы и измерения. Каждый аспект имеет четыре уровня: временный, операционный, масштабируемый и оптимизирующий. Согласно модели, организация не переходит на следующий уровень как единое целое: она может продвигаться в одном аспекте, оставаясь на отстающем уровне в другом. Анализ сосредоточен на интерфейсах, то есть на шаблонах, интерфейсах CLI, порталах и API, которыми пользуются разработчики.
Четыре этапа развития интерфейса платформы
На первом уровне организация полагается на специализированные процедуры: ручные запросы, процессы, различающиеся между командами, и знания, передаваемые от одного человека к другому. Отсутствие официального названия платформы не означает её фактического отсутствия: повторяющиеся сообщения конкретному инженеру с просьбой настроить базу данных представляют собой текущий интерфейс платформы, пусть и неуправляемый.
Второй уровень называется стандартизированными инструментами. Здесь появляются «золотые пути» или проторённые маршруты, а также документация, шаблоны и согласованные интерфейсы для предоставления возможностей и их мониторинга. Обычно результаты выглядят положительно: повышается внедрение, ускоряется адаптация новых сотрудников и улучшаются показатели. Однако запросы, выходящие за пределы ожидаемого маршрута, по-прежнему требуют вмешательства платформенной команды, поэтому интерфейс становится единообразным, но не самодостаточным.
На третьем уровне появляются решения самообслуживания, позволяющие разработчику выполнять большинство стандартных запросов без обращения к платформенной команде. Этот уровень оценивает скорее поведение команд, чем одни только показатели: сокращается число заявок на стандартное предоставление ресурсов, новые инженеры начинают напрямую пользоваться платформой, а работа платформенной команды переходит от выполнения отдельных запросов к улучшению среды, которая ими управляет. Согласно приведённым автором примерам, организации сообщали о сокращении запросов на исключения на 40–60% после добавления вариантов настройки для самообслуживания.
На четвёртом уровне, уровне интегрированных сервисов, возможности платформы становятся прозрачной частью повседневных рабочих инструментов. При создании нового сервиса мониторинг, журналирование и безопасность могут интегрироваться автоматически, а политики безопасности применяют свои правила через платформу, вместо того чтобы заставлять разработчика вручную согласовывать их. Платформа становится почти незаметной, а её успех измеряется тем, насколько редко разработчикам приходится задумываться об инфраструктуре.
Почему организации останавливаются на втором уровне?
Анализ выделяет четыре повторяющиеся проблемы. Первая — проблема очередей: «золотые пути» покрывают распространённые случаи, но нестандартные случаи могут составлять 30% работы в крупных организациях. Автор приводит пример розничной организации, использовавшей «золотой путь» для развертывания Kubernetes через Helm charts и ArgoCD. За шесть месяцев внедрение достигло 85%, однако накопилось 40 исключений, и команда стала тратить 60% времени на конфигурации, выходящие за пределы маршрута.
Вторая проблема — разрыв в экспертизе: платформенные команды могут создавать универсальные возможности, которые не вполне соответствуют потребностям специализированных команд, побуждая их разрабатывать собственные альтернативы. Третья — ловушка сопровождения: каждая новая возможность означает дополнительную поверхность для обновления, тестирования и исправлений при обнаружении уязвимости или обновлении Kubernetes. Автор упоминает случай, когда накопились устаревшие интерфейсы Helm charts, зависимости от облачного провайдера и сетевые допущения, в результате чего их обновление стало рискованным.
Четвёртая проблема — жёсткость. «Золотой путь» отражает допущения, которые были верны при его проектировании, но со временем они могут превратиться в ограничения по мере изменения технологий, процессов и потребностей команд. Тогда множатся исключения и теневые инфраструктуры, а платформенная команда превращается в фабрику индивидуальных решений вместо улучшения базового интерфейса.
Что меняется на практике?
Для перехода с первого уровня на второй автор предлагает сначала назвать и описать то, что уже существует, а не создавать новый портал: выявить запросы, которые возникают чаще всего, требуют больше всего времени и лучше всего поддаются стандартизации, а затем выбрать один «золотой путь» и действительно улучшить его, прежде чем расширять каталог.
При переходе со второго уровня на третий необходимо прекратить использовать платформенную команду как обязательное человеческое звено. Для этого «золотые пути» должны стать настраиваемыми, с проверенными вариантами и ограничениями, задаваемыми политиками, а не жёстко заданными значениями, при этом следует предусмотреть выходы для обоснованных нестандартных случаев. Анализ также рекомендует измерять запросы до их автоматизации: в примере из медиасектора трёхмесячная регистрация запросов показала, что 20% типов запросов составляют 80% объёма. Сначала для этих шаблонов создали самообслуживание, и за шесть месяцев накопившаяся очередь сократилась на 60%.
Кроме того, следует рассматривать интерфейс как продукт, а не сосредотачиваться только на серверных возможностях. Обнаруживаемость, правила проверки, контракты и способы обработки непредвиденных запросов — всё это является частью продукта. При приближении к четвёртому уровню автоматизация переходит от действий, которые разработчик выбирает сам, к интеллектуальным допущениям, реализуемым политиками внутри Git, среды разработки и систем CI/CD, при этом владение возможностями распределяется между командами безопасности, баз данных и мониторинга в рамках чётких контрактов.
Интерпретация certi.news
Фактическое изменение, на которое обращает внимание статья, заключается в переходе критерия успеха платформы разработчиков от количества запущенных инструментов и маршрутов к степени автономии, которую получают пользователи, а затем — к уровню интеграции этих возможностей в рабочий процесс. Это важно для платформенных команд, поскольку они могут внешне повысить внедрение, одновременно перенося бремя выполнения в очередь исключений и задач сопровождения.
Однако приведённые здесь примеры и цифры автор представляет как наблюдения, сделанные в ходе взаимодействия с организациями, а не как независимое количественное исследование, доказывающее применимость тех же соотношений к каждой организации. Кроме того, достижение четвёртого уровня предполагает зрелость контрактов, политик и распределения ответственности — то, чего не обеспечит само по себе приобретение портала или добавление агента искусственного интеллекта. В заключении ставится важный открытый вопрос: интерфейс самообслуживания, разработанный для людей-разработчиков, не обязательно является интерфейсом, пригодным для использования агентами искусственного интеллекта, которые взаимодействуют с API с частотой и по шаблонам, не похожим на человеческие рабочие процессы. Поэтому зрелость машиночитаемых интерфейсов может стать следующим этапом, который платформенным командам предстоит измерять.