Co wiemy?
Fikcyjny scenariusz edukacyjny
Zespół tworzy automatyczne testy dla agentów kodujących. Na każde zadanie lub pull request potrzebuje odrębnej bazy zgodnej z PostgreSQL, pozwalającej uruchomić migracje i testy integracyjne. Bazy mają żyć krótko, a dane są wyłącznie syntetyczne; do środowiska nie wolno kopiować danych produkcyjnych. W zespole istnieje centralna platforma z mechanizmami IAM, limitami kosztów i rejestrem zasobów.
Rozważane są trzy warianty: współdzielony staging, zarządzany PostgreSQL tworzony dla każdego zadania oraz AlloyDB Express tworzony dla każdego zadania. Dostawca ogłosił AlloyDB Express 4 listopada 2026 roku jako usługę Preview. Deklarowane czasy tworzenia to około dwóch sekund dla public DNS i około 20 sekund dla Private Service Connect; wznowienie po uśpieniu też może wymagać około 20 sekund. W Preview występują ograniczenia, w tym 20 GB danych, brak CMEK, brak SLA i kopii zapasowych.
Zespół nie wie jeszcze, czy pomiary we własnej sieci i pipeline potwierdzą korzyści. Architekt musi wybrać wariant do ograniczonego PoC oraz określić granice autonomii agenta. To nie jest opis rzeczywistego wdrożenia ani rekomendacja korzystania z Preview dla danych wrażliwych.
Jaką decyzję architektoniczną podejmiesz dla krótkotrwałego PoC i jakie warunki nałożysz na autonomię agenta? Uzasadnij wybór w kontekście izolacji, bezpieczeństwa, kosztów i możliwości wyjścia z Preview.
Za co mentor ocenia odpowiedź?
Wynik jest wskazówką do nauki, nie oceną zawodowych kompetencji.
- Izolacja i cykl życia
- Granice uprawnień agenta
- Preview, pomiary i droga wyjścia
Zobacz pytania naprowadzające
- Czy szybkość utworzenia bazy oznacza, że agent powinien mieć szeroką rolę administracyjną?
- Co dzieje się z bazą po zamknięciu pull requesta lub przerwaniu wykonania zadania?
- Jakie ograniczenia Preview mogłyby wykluczyć tę usługę w innym typie danych lub zastosowaniu?
- Które metryki potwierdzą, że nowy wariant jest lepszy od zarządzanego PostgreSQL?