Platform engineering для разработки с ИИ

Создайте для прототипов путь в production

Люди могут исследовать идеи с разными ИИ-инструментами, а организация — предоставить общий путь в production. Команда платформы делает этот путь понятным, поддерживаемым и воспроизводимым.

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

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

Развивайте платформу как продукт для её пользователей

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

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

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

Учитывайте агентов среди пользователей платформы

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

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

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

Определите поддерживаемый процесс и его ограничения

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

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

Поддерживайте сервисы после создания

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

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

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

Свяжите платформу с software factory

Platform engineering определяет поддерживаемые возможности и границы эксплуатации. Software factory связывает требования, планирование, реализацию, подтверждающие материалы и поставку. Эти подходы могут дополнять друг друга, если software factory планирует работу с учётом реальной платформы.

Включите постоянную эксплуатацию в оценку. Проверьте, кто ищет новые уязвимости, развёртывает исправления, реагирует на инциденты и поддерживает подтверждения соответствия требованиям. Для этих возможностей нужны согласованный объём работ и владельцы. Сам термин «software factory» их не гарантирует.

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

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