Определите инфраструктуру, необходимую после прототипа

Начните со сгенерированной системы

Рассмотрим вымышленную платформу прототипирования. Она создаёт веб-контейнер, управляемую базу PostgreSQL и общедоступный URL. Рабочий процесс правильно выполняется с примерами записей. Это полезный результат: люди могут оценить функцию до финансирования более масштабной реализации.

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

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

Задайте семь вопросов о production

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

AWS Well-Architected рассматривает эксплуатацию, безопасность, надёжность, производительность, стоимость и устойчивое развитие вместе. Это напоминает, что работающее развёртывание — лишь одна часть оценки архитектуры. Прочитать документ.

Определите границы между средами

Определите ресурсы разработки, тестирования и production. Укажите, какие учётные записи могут пересекать эти границы. Не копируйте записи production в удобную preview-среду без одобренного порядка обращения с данными.

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

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

Проверьте распределение ответственности

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

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

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

Свяжите инфраструктуру с системой поставки

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

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