Золотые пути (Golden Paths) стали одним из ключевых строительных блоков платформ-инженерии. Они позволяют осуществлять самообслуживание набором стандартных рабочих процессов с помощью автоматизации и шаблонов, без необходимости вмешательства человека.

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

2025 DORA State of AI-assisted Software Development report обнаружила, что 90% организаций уже используют по крайней мере одну внутреннюю платформу, и когда качество платформы высокое, влияние внедрения ИИ на производительность организации становится сильным и положительным.

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

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

Пять строительных блоков: модули IaC, определения конвейеров, защитные механизмы политик, документация и точка входа в портал
Четыре фазы внедрения: понять текущее состояние, создать шаблоны и защитные механизмы, провести пилотное тестирование с итерациями и спланировать второй день (day 2).
Предоставляйте агентам тот же путь, что и людям, через API или MCP-сервер, с типизированными входными данными, ограниченными удостоверениями и согласованиями для продакшна.
Сначала измеряйте уровень принятия (adoption). Метрики доставки имеют значение только тогда, когда люди начинают использовать этот путь.

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

Безальтернативный (opinionated) означает, что платформа-команда уже сделала разумные, безопасные и стандартные выборы за пользователей.
Задокументированный означает, что разработчик (или, все чаще, агент) может найти подходящий путь и четкие инструкции по его использованию.
Поддерживаемый означает, что платформенная команда владеет им и занимается его обслуживанием.
Самообслуживание означает, что потребители могут использовать золотые пути по своему усмотрению, без других зависимостей.

Куда вписываются золотые пути в платформ-инженерии?

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

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

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

В чем разница между золотыми путями и защитными механизмами (гард-рейлами)?

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

Золотой путь представляет собой набор компонентов, принадлежащих платформенной команде и предоставляемых остальной организации:

Стандартизированные шаблоны и модули: в случае инфраструктуры это модули Terraform или OpenTofu (либо компоненты Pulumi, или конструкции CDK), включающие ваши конфигурации по умолчанию. Хороший модуль предоставляет необходимые входные данные и скрывает все остальное.
Определения CI/CD-пайплайнов: каждый путь требует стандартного способа тестирования и применения изменений. Для инфраструктурных путей это включает пайплайны IaC; для прикладных путей — сборку, тестирование и деплой. Переиспользуемые определения конвейеров обеспечивают их единообразие между командами.
Защитные механизмы политик и комплаенса: политика как код (Policy as code) проверяет изменения до того, как они попадут в продакшн. Open Policy Agent, Checkov и сервисные управляющие политики AWS являются популярными выборами, часто используемыми в комбинации.
Документация: каждый путь нуждается в четкой документации по поддерживаемым и неподдерживаемым сценариям использования, использованию, входам, выходам и владельцам. Теперь документация должна обслуживать как людей, так и агентов, поэтому ее следует соответствующим образом скорректировать. Markdown-версии документов, файл llms.txt в корне сайта документации для предоставления агентам индекса и файл AGENTS.md в каждом репозитории шаблонов — все это необходимо для использования агентами.
Портал платформы — это место, где пользователи находят эти компоненты и работают с ними. Большинство команд предоставляют золотые пути через каталог сервисов: список элементов, которые можно запросить, каждый из которых подкреплен шаблоном. Хороший портал платформы также предоставляет функции управления и отслеживания того, кто, что создал и из какой версии пути.

Как спроектировать и внедрить золотой путь

Проектирование и внедрение золотого пути состоит из четырех этапов:

Этап 1: Понять текущее состояние

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

Этап 2: Создание шаблонов и защитных механизмов

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

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

Этап 3: Запуск и итерации

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

Этап 4: Планирование операций второго дня (day 2)

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

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

Обнаружение дрейфа (Drift detection): запускайте запланированные проверки против стеков, созданных на основе пути, и получайте оповещения, когда текущее состояние отличается от кода. Регрессии и дрейф могут возникать по разным причинам.
Устаревание: Определите, как долго вы поддерживаете старые версии, и объявите даты и графики прекращения поддержки (end-of-life).
Вывод из эксплуатации: Каждый способ создания ресурсов должен предусматривать возможность их удаления, включая резервные копии и другие манифесты. Недолговечные окружения, полезные для экспериментов и тестирования, должны автоматически истекать по времени.

«Золотые пути» для ИИ-агентов и ИИ-нагрузок

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

Агенты как пользователи платформы

ИИ-агенты — это новый класс пользователей платформы. ИИ-ассистенты для написания кода, такие как Claude Code, Cursor, Kiro и OpenAI Codex, пишут код Terraform и открывают пул-реквесты. Агенты SRE читают логи, исследуют работающие системы и все чаще предлагают исправления и предпринимают действия.

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

Компоненты платформы, требующие доработки

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

Интерфейсы: Для каждого пути помимо пользовательского интерфейса необходимы API и сервер MCP. Протокол Model Context Protocol стал стандартным способом предоставления действий платформы агентам. Многие порталы и платформы IaC теперь поставляют собственный MCP-сервер. Например, ознакомьтесь с Spacelift MCP.

Типизированные входные данные и структурированный вывод: Входным данным нужны схемы с разрешенными значениями, чтобы агенты могли их прочитать и структурировать свою работу. Вывод (статус, ошибки, отказы политик) должен быть структурированным, чтобы агент мог реагировать на него.
Идентификация: Агентам нужны собственные учетные записи с кратковременными ограниченными полномочиями. Каждое действие сопоставляется с конкретным агентом, и вы можете при необходимости отозвать доступ агента.
Контекст: Документация, написанная для поисковой выдачи, плюс файлы репозитория (например, AGENTS.md или файлы навыков), которые сообщают агенту, какие пути существуют и когда какой из них использовать.

Средства защиты для агентов

Мы установили, что средства защиты (guardrails) являются важным уровнем безопасности для платформ. Для ИИ и агентских рабочих процессов они становятся еще важнее, учитывая масштабное влияние, которое эти инструменты оказывают на системы и платформы:

Области действия (скоупы) для каждой учетной записи агента: Ограничьте среды и действия, к которым имеет доступ каждый агент.
Шлюзы утверждения: Требуйте одобрения человека для критических операций, изменяющих состояние, или операций развертывания в рабочей среде.
Ограничения частоты и бюджета: Применяйте ограничения частоты запросов и бюджета для каждой учетной записи, чтобы избежать ситуаций, когда агенты выходят из-под контроля или зацикливаются.
Журналы аудита: Записывайте все действия агентов.

Запускайте агентов с доступом только для чтения. Переходите к ограниченной записи в непроизводственных средах, а затем к изменениям в продакшене после получения одобрения. Автономность зарабатывается для каждого рабочего процесса на основе того, как агент справляется с задачами. Мы более подробно рассмотрели этот путь внедрения в статье AI in Platform Engineering: When Agents Join Your Platform, а полный набор средств контроля — в статье Guardrails for AI-Generated Infrastructure.

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

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

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

Общей тенденцией также является внедрение специфических метрик для агентов. Вот несколько идей:

Частота ошибок и отката: Как часто инициированные агентами изменения завершаются сбоем или отменяются по сравнению с изменениями, внесенными людьми на том же пути.
Стоимость одного запуска агента: Затраты на токены и вычисления на одно изменение.

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

Spacelift — это платформа оркестрации инфраструктуры для OpenTofu, Terraform, Pulumi, CloudFormation, Ansible и Kubernetes. Ее строительные блоки тесно связаны с описанными выше компонентами «золотых путей».

Сопоставление строительных блоков

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

Модули IaC: Реестр модулей содержит версионированные модули Terraform и OpenTofu с тестами, которые запускаются для каждой новой версии.
Стеки: Стек — это единица развертывания в Spacelift: исходный код, состояние, конфигурация и учетные данные, с которыми он запускается. Каждый ресурс, созданный через «золотой путь», оказывается в стеке.
Пространства (Spaces): Пространства служат границей доступа. Они объединяют стеки, политики, контексты и облачные интеграции. Правила доступа в пространстве определяют, кто может читать или изменять то, что находится внутри него. Дочерние пространства могут наследоваться от родительских, поэтому платформа-команда может определять общие политики.
Учетные данные: Облачные интеграции для основных провайдеров облачных услуг генерируют кратковременные учетные данные для каждого запуска, поэтому в стеках нет статических ключей. Контексты содержат общую конфигурацию (переменные среды, файлы, хуки) и привязываются к стекам.
Политики и средства защиты: Политики написаны на языке Rego и выполняются в Open Policy Agent. Политики планов (plan policies) проверяют предлагаемые изменения; политики утверждения (approval policies) требуют проверок перед применением запуска; политики отправки и триггеров контролируют запуск; политики входа контролируют доступ. Будучи привязанными через пространства или метки, они применяются к каждому стеку.
Чертежи (Blueprints): Чертежи — это формы, определяемые в YAML, которые создают настроенный стек на основе пользовательских вводов. Полученный стек существует независимо и может редактироваться.
Шаблоны: Шаблоны добавляют управление жизненным циклом. Каждая опубликованная версия привязана к коммиту, а созданные из шаблона стеки неизменяемы: они меняются только тогда, когда развертывание переходит на новую версию шаблона или меняются его входные данные. Это связанная модель из раздела о версионировании, которая делает обновление в нескольких развертываниях практически осуществимым.
Обнаружение дрейфа (Drift detection): Запланированное обнаружение дрейфа выполняет предлагаемые планы по расписанию cron и может выполнять автоматическую сверку.

Откройте путь для ИИ-агентов

Агенты обращаются к Spacelift через три интерфейса: два вне пользовательского интерфейса и один внутри него.

Сервер Spacelift MCP: Spacelift размещает MCP-сервер для каждой учетной записи. Он предоставляет инструменты для обнаружения схемы GraphQL API, выполнения запросов только для чтения, проверки схем провайдеров, выполнения мутаций и управления ресурсами.
Intent: Spacelift Intent подготавливает инфраструктуру на основе естественного языка через MCP-клиент, такой как Claude Code, Cursor, ChatGPT или VS Code. Intent вызывает операции провайдера Terraform напрямую под управлением Spacelift. Политики Intent проверяют каждую операцию записи до ее выполнения. Intent лучше подходит для исследований и работы в песочницах, чем для долгосрочных производственных ресурсов.
Infra Assistant: Infra Assistant — это чат-панель в пользовательском интерфейсе Spacelift. В режиме Ask (Вопрос) она работает только для чтения: объясняет стеки и неудачные запуск или ищет информацию в документации. В режиме Build (Сборка) она может создавать ресурсы и управлять ими в ходе диалога, руководствуясь теми же политиками Intent.

Вместе эти инструменты предоставляют «золотым путям» (Golden Paths) интерфейсы для агентов, подкрепленные теми же политиками.

Демонстрационный золотой путь: Сервису требуется база данных Postgres на AWS

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

Чтобы повторить эти действия, создайте бесплатную пробную учетную запись Spacelift, подключите Spacelift MCP к вашему любимому инструменту для агентов и попросите его настроить пример золотого пути из этого блога, а также подключить вас к Spacelift! Также ознакомьтесь с репозиторием демо-кода, чтобы изучить все файлы подробно. Давайте приступим:

Шаг 1: Публикация модуля

Платформенная команда публикует модуль rds-postgres в реестре модулей Spacelift. Его интерфейс прост: четыре параметра выбирает разработчик, а два предоставляет платформа.

variables.tf

Внутри модуля настройки платформенной команды фиксированы:

main.tf

Для продакшена настраивается Multi-AZ, 30-дневное резервное копирование, защита от удаления и финальный снимок при удалении. В средах dev и staging используются более дешевые конфигурации. Учетные данные сохраняются в Secrets Manager, а хранилище шифруется. Модуль создает собственную группу подсетей БД и группу безопасности, которая разрешает трафик Postgres только изнутри VPC.

Выходные данные (outputs) предоставляют сервисной команде все необходимое для подключения:

outputs.tf

Файл .spacelift/config.yml в каталоге модуля задает module_version: 1.0.0. Spacelift публикует эту версию в приватный реестр аккаунта, где на нее ссылаются стеки как на spacelift.io/<account>/rds-postgres/aws.

Шаг 2: Обертывание в шаблон

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

Затем платформенная команда определяет шаблон Spacelift вокруг этого:

postgres.yaml

Блок maps направляет запросы в каждое окружение. Развертывания dev и staging попадают в непродакшн-пространство, а продакшн — в собственное пространство. На пространства и облачные интеграции ссылаются по их сгенерированным ID.

Контексты aws-network-<env> предоставляют AWS_REGION, TF_VAR_vpc_id и TF_VAR_subnet_ids. Шаблоны входных данных отклоняют неверное имя сервиса в форме до запуска каких-либо процессов. При установке autodeploy: true план, прошедший проверки политик, применяется без ручного подтверждения; продакшн по-прежнему ждет проверяющего (см. шаг 3). Каждое развертывание проходит ночную проверку на дрейф конфигурации (drift check).

Публикация этого как версии 1.0 фиксирует ее на текущем коммите; когда платформенная команда увеличивает версию Postgres или изменяет значение по умолчанию, она публикует версию 1.1, и каждое развертывание переходит на нее тогда, когда это решают его владельцы (или сама платформенная команда).

Шаг 3: Подключение защитных барьеров (guardrails)

Политика плана проверяет каждый ресурс aws_db_instance, который создается, обновляется или заменяется в рамках запуска:

rds-guardrails.plan.rego

Политика располагается в родительском пространстве golden-paths с меткой autoattach:*, поэтому она автоматически применяется к каждому стеку в этом пространстве и его дочерних пространствах.

В продакшн-окружениях также действует политика утверждения в том же пространстве с меткой autoattach:env/prod, поэтому она применяется только к стекам, помеченным шаблоном как env/prod:

prod-review.approval.rego

Теперь продакшн-запуск ожидает одного подтверждения и останавливается в случае любого отклонения. Стеки разработки (dev) и тестирования (staging) не имеют этой метки, поэтому их запуски применяются сразу после успешного прохождения политики плана.

Шаг 4: Развертывание (руками человека или агента)

Разработчик открывает список шаблонов в Spacelift, выбирает «Postgres for services», заполняет поля checkout, staging, small и payments и запускает развертывание. Spacelift создает стек checkout-postgres-staging в непродакшн-пространстве, подключает контекст staging и интеграцию с AWS, выполняет план, оценивает rds-guardrails и производит применение (apply).

Через несколько минут выходные данные стека содержат все необходимое для работы сервиса:

Тот же разработчик может вместо этого ввести следующее в Claude Code с подключенным сервером Spacelift MCP:

Сервису checkout требуется небольшая база данных Postgres в среде staging. Владелец — команда payments. Используйте наш золотой путь.

Агент использует инструменты обнаружения (discover) и запроса (query) сервера MCP для поиска шаблонов с меткой golden-path/postgres и чтения их схемы входных данных. Затем он вызывает операцию изменения (mutate) для создания развертывания с теми же четырьмя параметрами, которые человек ввел бы в форму, и опрашивает статус запуска до его завершения. Запрос на продакшн-окружение затем попадает под действие политики утверждения, и требуется одобрение человека.

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

Золотой путь — это продукт, а не шаблон. Ему необходимы владелец, версия, журнал изменений (changelog) и дата прекращения поддержки (deprecation date), иначе вы получите каталог, которому никто не доверяет, и очередь запросов, которая никогда не уменьшается. Компонент с агентом меняется гораздо меньше, чем кажется. Если ваши пути уже документированы, имеют версии и проверяются политиками, обслуживание агента в основном сводится к их предоставлению через API или MCP-сервер вместо формы.

Запустите бесплатную пробную версию, подключите сервер Spacelift MCP к вашему агенту кодинга и позвольте ему создать путь вместе с вами.

Часто задаваемые вопросы

В чем разница между золотым путем и проложенной дорогой (paved road)? Понятия «проложенная дорога» и «золотой путь» обычно используются как взаимозаменяемые для описания рекомендуемого и поддерживаемого маршрута для типичной инженерной задачи. Netflix популяризировал термин «проложенная дорога», в то время как Spotify ввел понятие «золотой путь», и сегодня большинство специалистов считают их синонимами.

В чем разница между золотым путем и проложенной дорогой?

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

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

В чем разница между золотым путем и каталогом сервисов?

Золотой путь (Golden Path) — это стандартизированный, поддерживаемый рабочий процесс, который помогает разработчикам выполнять такие задачи, как создание сервиса, в то время как каталог сервисов — это реестр, в котором отслеживаются существующие сервисы, их владельцы, зависимости и метаданные. Один показывает, как создавать, другой — что уже существует.

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

Кто отвечает за Золотые пути в организации?

Команда платформенной инженерии отвечает за Золотые пути и относится к ним как к внутренним продуктам, обеспечивая их версионирование, документацию и поддержку. Группы безопасности, надежности (SRE) и комплаенса обычно участвуют в разработке политик и защитных механизмов, которые внедряются в этот путь.

Каковы примеры Золотых путей?Типичные примеры включают создание шаблона нового микросервиса с уже настроенными CI/CD, Dockerfile, чартом Helm и дашбордами, подготовку управляемой базы данных, запуск эфемерной среды предварительного просмотра, а также развертывание без状态ного API с автоматически зарегистрированными в каталоге средствами наблюдаемости, сканирования безопасности и метаданными владельцев.

Каковы примеры Золотых путей?

Типичные примеры включают создание шаблона нового микросервиса с уже настроенными CI/CD, Dockerfile, чартом Helm и дашбордами, подготовку управляемой базы данных, запуск эфемерной среды предварительного просмотра, а также развертывание без状态ного API с автоматически зарегистрированными в каталоге средствами наблюдаемости, сканирования безопасности и метаданными владельцев.