Google PCA: DevOps, inżynieria dostarczania i infrastruktura jako kod — Przewodnik do nauki

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

Część Google Professional Cloud Architect — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Google, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

DevOps, Delivery Engineering i infrastruktura jako kod (IaC) w Google Cloud koncentrują się na ciągłym dostarczaniu niezawodnych zmian z silną śledzalnością, automatyzacją i bezpieczeństwem. Architektury powinny być zoptymalizowane pod kątem krótkich cykli informacji zwrotnej, powtarzalnych wdrożeń, niezmiennej infrastruktury i mechanizmów zabezpieczających (guardrails), które skalują się wraz z organizacją. W Google Cloud zazwyczaj łączy się to z najlepszymi praktykami kontroli wersji; CI z Cloud Build; zarządzaniem artefaktami za pomocą Artifact Registry; CD z Cloud Deploy; Kubernetes z GKE przy użyciu manifestów, Helm lub Kustomize; GitOps do kontroli dryfu konfiguracji; oraz IaC z Terraform lub szablonami wdrożeń Google Cloud. Doskonałość operacyjna wymaga progresywnego dostarczania (blue-green, canary, podział ruchu i flagi funkcji), kontroli łańcucha dostaw oprogramowania (skanowanie, pochodzenie, podpisywanie), bramek testowych i wdrożeniowych oraz ładu (governance), który równoważy szybkość, bezpieczeństwo, audytowalność i odpowiedzialność (ownership).

CI/CD, kontrola wersji i orkiestracja wydań

Zasady CI/CD
- Utrzymuj gałąź master/main w stanie gotowym do wydania; praktykuj trunk-based development z krótkotrwałymi gałęziami funkcyjnymi (feature branches).
- Automatyzuj budowanie, testowanie, skanowanie i pakowanie przy każdej zmianie; wymagaj przeglądu kodu (code review) z obowiązkowymi zatwierdzeniami i sprawdzaniem statusu.
- Zachowaj pełną śledzalność od commita → przez build → skrót (digest) artefaktu → aż po wydanie na środowisku; umieszczaj sumy kontrolne SHA commitów i metadane builda w obrazach i adnotacjach wdrożenia.
- Tryby awarii: długo żyjące gałęzie, ręczne przekazywanie zadań, niestabilne testy (flaky tests), nieodtwarzalne buildy i brak niezmienności artefaktów prowadzą do późnych niespodzianek i wycofywania zmian (rollback).
Kontrola wersji, gałęzie, pull requesty, przegląd kodu i śledzalność
- Używaj chronionych gałęzi, wymaganych przeglądów (reviews) i podpisywania commitów. Oznaczaj wydania tagami i utrzymuj changelog generowany z commitów po scaleniu (merge commits).
- Stosuj pliki CODEOWNERS i metadane odpowiedzialności za usługę (service ownership), aby wymusić nadzór domenowy.
- Łącz commity z zadaniami (issues) i wdrożeniami; eksportuj logi i metadane CI/CD do Cloud Logging i BigQuery w celu audytu i zbierania metryk DORA.
Cloud Build
- Wyzwalacze (Triggers): uruchamiane przez zdarzenia Git (gałąź, tag, PR), wywołania ręczne lub Pub/Sub. Parametryzuj za pomocą podstawień (substitutions) dla wersji, środowiska i flag funkcji, aby zachować zgodność z zasadą DRY (Don’t Repeat Yourself).
- Kroki budowania (Build steps): uruchamiaj oficjalne buildery lub zdefiniowane przez siebie kontenery; używaj kroków równoległych, gdy są niezależne, aby zmniejszyć opóźnienia; używaj pamięci podręcznej (cache) dla zależności językowych, aby przyspieszyć budowanie.
- Artefakty: wysyłaj obrazy do Artifact Registry z niezmiennymi tagami i skrótami (digest); przechowuj SBOM i logi budowania; publikuj raporty z testów jako artefakty budowania.
- Bezpieczne tożsamości budowania: uruchamiaj Cloud Build z dedykowanym kontem serwisowym z najmniejszymi uprawnieniami (least privilege) i, w miarę możliwości, z Workload Identity Federation per repozytorium. Dla sieci prywatnych lub aby uniknąć ruchu wychodzącego (egress), używaj pul prywatnych (Private Pools). Ograniczaj klucze kont serwisowych; preferuj tokeny o krótkim czasie życia.
- Przykład (skrócony):
  - cloudbuild.yaml:
    - steps:
      - name: gcr.io/cloud-builders/docker args: [build, -t, $REGION-docker.pkg.dev/$PROJECT/app/web:$COMMIT_SHA, .]
      - name: gcr.io/cloud-builders/docker args: [push, $REGION-docker.pkg.dev/$PROJECT/app/web:$COMMIT_SHA]
    - substitutions:
      - _ENV=staging
Cloud Deploy
- Wydania (Releases) i cele (targets): modeluj potok dostarczania z promocją pomiędzy celami (np. dev → staging → prod). Wydanie zawiera niezmienne odwołanie do artefaktu i konfigurację wdrożenia.
- Zatwierdzenia i promocja: wymagaj ręcznych lub zautomatyzowanych zatwierdzeń z kontrolą opartą na rolach. Promocja powinna być szybką akcją o niskim ryzyku, ponieważ artefakt i manifesty pozostają niezmienione.
- Wdrożenie canary i rollback: zdefiniuj strategie stopniowego udostępniania, sprawdzania kondycji (health checks) i automatycznego wycofywania zmian w przypadku błędów SLO. Rejestruj każdą promocję, osobę zatwierdzającą i wynik weryfikacji na potrzeby audytu.
- Tryby awarii: zmienne artefakty między środowiskami, ręczne użycie kubectl na produkcji lub pominięcie weryfikacji przed wdrożeniem powodują dryf konfiguracji i nieśledzalne awarie.

Infrastruktura jako kod i zarządzanie konfiguracją

Terraform
- Moduły: hermetyzują wzorce wielokrotnego użytku (np. VPC, klastry GKE, konta usług, powiązania IAM). Wersjonuj i przypinaj wydania modułów; publikuj wewnętrzne rejestry modułów.
- Zdalny stan (remote state): przechowuj w Cloud Storage z włączonym wersjonowaniem, polityką retencji i CMEK; włącz blokowanie (locking); ograniczaj dostęp za pomocą IAM i jednolitego dostępu na poziomie bucketa; twórz kopie zapasowe stanu.
- Plany i sprawdzanie polityk: uruchamiaj terraform fmt/validate/plan w CI; wymagaj ręcznej weryfikacji planu; wymuszaj politykę jako kod (OPA/Conftest, Sentinel lub Policy Controller), aby blokować naruszenia (np. publiczne buckety, zbyt szerokie powiązania IAM).
- Promocja między środowiskami: używaj oddzielnych workspace’ów lub oddzielnych stanów/backendów dla każdego środowiska; promuj zmiany za pomocą tych samych wersji modułów i zmiennych; nigdy nie edytuj zasobów chmurowych ręcznie. Wrażliwe dane wejściowe powinny pochodzić z Secret Manager lub automatyzacji, nigdy nie być zapisane na stałe w kodzie.
- Scenariusze awarii: wyciek sekretów do pliku stanu, współbieżne zmiany bez blokowania, dryf spowodowany zmianami poza kodem (out-of-band) oraz ukryte zależności, które psują operacje destroy/replace.
Szablony wdrożeń Google Cloud i konfiguracja deklaratywna
- Używaj narzędzi deklaratywnych (Terraform, Google Cloud Deployment Manager lub Kubernetes Configuration as Code) do definiowania pożądanego stanu, zamiast skryptów z imperatywnymi krokami.
- Preferuj niezmienną infrastrukturę (immutable infrastructure): wymieniaj szablony instancji i aktualizuj grupy MIG przez rolling update; wdrażaj nowe Deploymenty GKE zamiast łatać pody w miejscu. Niezmienne wzorce upraszczają rollback i audyt.
- Deployment Manager obsługuje szablony Jinja/Python dla zasobów Google Cloud, ale jest ograniczony do Google Cloud; Terraform oferuje szerszy ekosystem i narzędzia do polityk. Wybór powinien być oparty na standardach organizacyjnych i umiejętnościach zespołu.
Manifesty Kubernetes, Helm, Kustomize i GitOps
- Manifesty: utrzymuj bazowe szablony z nakładkami dla poszczególnych środowisk; parametryzuj tylko to, co powinno się różnić między środowiskami (np. liczba replik, limity, endpointy).
- Helm: pakuj, twórz szablony i wersjonuj usługi za pomocą chartów; blokuj zależności; przypinaj skróty (digest) obrazów. Scenariusz awarii: nadmierne użycie szablonów zaciemnia intencje i komplikuje weryfikację.
- Kustomize: zarządzaj nakładkami (baza + patche dla środowisk); prostsze niż Helm, gdy wystarczający jest czysty Kubernetes.
- GitOps: kontroler (np. Config Sync, Argo CD, Flux) ciągle uzgadnia stan klastrów z pożądanym stanem w Git; każda zmiana to PR z weryfikacją i ścieżką audytową. Automatycznie wykrywaj i koryguj dryf.

Stopniowe dostarczanie, łańcuch dostaw, testowanie i weryfikacja

Flagi funkcyjne (feature flags) i zarządzanie ruchem
- Flagi funkcyjne oddzielają wdrożenie od wydania; używaj ich do stopniowego udostępniania, testów A/B i jako wyłączniki awaryjne. Upewnij się, że stany flag są wersjonowane i audytowalne; usuwaj nieużywane flagi.
- Dzielenie ruchu (traffic splitting): w Cloud Run używaj routingu procentowego między rewizjami; w GKE używaj service mesh lub kontrolerów ingress, które wspierają routing ważony. Dla API pod jedną nazwą hosta/TLS, utrzymuj oddzielne usługi backendowe dla każdej ścieżki za HTTP(S) Load Balancerem; routing oparty na ścieżce czysto izoluje starą i nową wersję, zachowując jeden adres URL i certyfikat.
- Blue-green: utrzymuj dwa gotowe do produkcji stosy; przełączaj ruch atomowo za pomocą load balancera, selektorów usług lub ruchu między rewizjami Cloud Run. Umożliwia natychmiastowy rollback, ale podwaja koszt w stanie ustalonym.
- Wdrożenie kanarkowe (canary) i stopniowe: stopniowo zwiększaj ruch z małej części, mierząc złote sygnały (golden signals) i biznesowe KPI; automatyzuj rollback w przypadku regresji.
Kontrole łańcucha dostaw oprogramowania
- Skanowanie obrazów: włącz skanowanie podatności w Artifact Analysis; przerywaj buildy w przypadku krytycznych podatności lub znanych złych obrazów bazowych; utrzymuj regularny cykl łatania.
- Pochodzenie i podpisywanie (provenance and signing): generuj w Cloud Build dane o pochodzeniu kompilacji zgodne z SLSA; podpisuj artefakty za pomocą Cosign; wymuszaj polityki Binary Authorization wymagające atestacji przed wdrożeniem.
- Zarządzanie zależnościami: przypinaj wersje i skróty (digest), utrzymuj SBOM, przechowuj lokalnie (vendor) krytyczne zależności i weryfikuj sumy kontrolne. Scenariusze awarii obejmują dryf zależności przechodnich i skompromitowane rejestry.
Piramida testów, bramki wdrożeniowe i weryfikacja po wdrożeniu
- Piramida: kładź nacisk na szybkie testy jednostkowe; dodaj testy integracyjne i kontraktowe; uruchamiaj ukierunkowane testy end-to-end. Utrzymuj dane testowe realistyczne i zanonimizowane (użyj Cloud DLP do usuwania danych PII).
- Bramki wdrożeniowe (deployment gates): wymuszaj progi dla wskaźnika zdawalności testów, statusu podatności, zgodności z politykami i weryfikacji kodu przed promocją; wymagaj ręcznej akceptacji dla środowiska produkcyjnego, gdy ryzyko jest podwyższone.
- Weryfikacja po wdrożeniu: uruchamiaj testy typu smoke test, testy syntetyczne i analizę kanarkową przy użyciu Cloud Monitoring, Error Reporting i Trace. Jeśli wskaźniki KPI ulegną pogorszeniu, uruchom automatyczny rollback i otwórz incydent z przechwyconym kontekstem.
- Diagnostyka operacyjna: wdrażaj agenta Cloud Logging tam, gdzie jest to potrzebne, i instrumentuj usługi dla Trace i Debugger. Utrzymuj runbooki do bezpiecznego usuwania problemów (np. zmiana rozmiaru dysku trwałego online i uruchomienie resize2fs z minimalnym przestojem).

Zarządzanie, bezpieczeństwo, audytowalność i odpowiedzialność

Szybkość i bezpieczeństwo
- Rozwój oparty na gałęzi głównej (trunk-based development) z krótko żyjącymi PR-ami i obowiązkowymi przeglądami (review) utrzymuje płynność pracy (flow) bez poświęcania jakości.
- Samoobsługowe potoki (pipelines) z szablonami dla popularnych stosów technologicznych (GKE + Helm, Cloud Run, Dataflow) przyspieszają pracę zespołów i redukują ryzyko związane z niestandardowymi rozwiązaniami.
Dostęp, tożsamość i zatwierdzenia
- Używaj dedykowanych kont serwisowych (service accounts) dla każdego etapu potoku, stosując zasadę najmniejszych uprawnień (least privilege) i Workload Identity Federation; unikaj statycznych kluczy.
- Rozdzielaj obowiązki: deweloperzy tworzą oprogramowanie; menedżerowie wydań (release managers) zatwierdzają wdrożenia na produkcję; operatorzy środowiska uruchomieniowego (runtime operators) odpowiadają za konfigurację i budżety w czasie działania aplikacji.
Audytowalność i zgodność z regulacjami (compliance)
- Eksportuj logi Cloud Build, Cloud Deploy i Cloud Audit Logs do BigQuery. Używaj widoków na zbiorach danych (dataset views) i IAM do udostępniania audytorom danych audytowych o ograniczonym zakresie. Przechowuj metryki długoterminowo, eksportując je do Cloud Storage lub BigQuery zgodnie z polityką.
- Zapisuj skróty (digests) artefaktów w metadanych wdrożenia. Utrzymuj kompleksowe SBOM i dane o pochodzeniu (provenance) dla każdego wydania.
Odpowiedzialność i wskaźniki SLO
- Każda usługa ma swojego właściciela, dyżury (on-call), wskaźniki SLO i budżety błędów (error budgets), które warunkują wydania. Powiąż polityki wdrożeń ze zgodnością z SLO, aby unikać wdrażania zmian, gdy budżet błędów jest wyczerpany.
Częste kompromisy i pułapki
- Koszt wdrożenia blue-green a szybkość wycofywania zmian (rollback); pewność uzyskana dzięki wdrożeniu canary a czas do pełnego wdrożenia.
- Spójność dzięki GitOps a elastyczność operacyjna; zezwalaj na kontrolowane procedury awaryjne (break-glass) z logowaniem i późniejszymi PR-ami naprawczymi.
- Nadmierne używanie szablonów zmniejsza czytelność; utrzymuj konfigurację jawną i minimalną.
- Centralna polityka zapobiega błędnym konfiguracjom, ale musi być wdrażana iteracyjnie, aby niepotrzebnie nie blokować pracy zespołów.

Praktyczny scenariusz problemowy

Firma: Borealis Fintech

Wyzwanie: Borealis uruchamia nowe API do płatności na GKE, jednocześnie utrzymując wersje v1 i v2 pod tą samą nazwą hosta i certyfikatem TLS. Wymagają pełnej śledzalności (end-to-end), progresywnego dostarczania z wykorzystaniem wdrożeń canary i flag funkcyjnych (feature flags), silnych kontroli łańcucha dostaw oprogramowania (supply-chain) oraz audytowanych promocji zmian między środowiskami dev, staging i prod. Chcą również używać GitOps do konfiguracji klastrów i Terraform do zarządzania zasobami platformy.

Podejście:

Ustanowienie kontroli wersji i strategii branchowania
- Stwórz monorepo z katalogami dla poszczególnych usług oraz osobne repozytorium na infrastrukturę (infra repo). Wymuś ochronę gałęzi main, obowiązkowe przeglądy PR-ów, plik CODEOWNERS i podpisane commity. Uzasadnienie: przepływ pracy oparty na gałęzi głównej (trunk-based) z jasno określoną odpowiedzialnością i historią gotową do audytu.
Budowanie artefaktów za pomocą Cloud Build i Artifact Registry
- Zdefiniuj plik cloudbuild.yaml do budowania i wysyłania obrazów tagowanych za pomocą $COMMIT_SHA oraz opatrzonych adnotacjami z SBOM i danymi o pochodzeniu (provenance). Użyj dedykowanego konta serwisowego Cloud Build z zasadą najmniejszych uprawnień oraz puli prywatnej (Private Pool). Uzasadnienie: powtarzalne, izolowane buildy ze śledzonymi skrótami (digests).
- Przykład:
  - gcloud artifacts repositories create app –repository-format=docker –location=us
Implementacja kontroli łańcucha dostaw oprogramowania
- Włącz skanowanie podatności w Artifact Registry. Generuj dane o pochodzeniu (provenance) i podpisuj obrazy za pomocą Cosign w krokach po zakończeniu budowania (post-build) w Cloud Build. Skonfiguruj Binary Authorization, aby wymagał podpisów i pozytywnego wyniku skanowania przed wdrożeniem na GKE. Uzasadnienie: blokowanie niezaufanych lub podatnych na zagrożenia artefaktów w momencie egzekwowania polityki.
Modelowanie dostarczania za pomocą Cloud Deploy
- Zdefiniuj potok dostarczania (delivery pipeline) ze środowiskami docelowymi (targets) dev, staging, prod oraz strategią canary dla środowiska prod. Wymagaj ręcznego zatwierdzenia dla środowiska prod przez osoby z odpowiednimi rolami. Uzasadnienie: niezmienne promowanie wersji i audytowalne zatwierdzenia.
- clouddeploy.yaml (fragment):
  - strategy:
    - canary:
      - canaryDeployment:
        percentages: [5, 25, 50, 100]
Routing API v1 i v2 pod tą samą nazwą hosta
- Skonfiguruj zewnętrzny HTTP(S) Load Balancer z osobnymi usługami backendowymi (backend services) dla ścieżek /v1 i /v2, z których każda wskazuje na odpowiedni GKE NEG. Uzasadnienie: czysta izolacja oparta na ścieżkach, ten sam certyfikat i DNS, niezależna wdrażalność.
- Przykład (fragment):
  - gcloud compute url-maps add-path-matcher api-map –path-matcher-name api-pm –default-service v1-bes –path-rules="/v1/=v1-bes,/v2/=v2-bes"
Zarządzanie infrastrukturą za pomocą Terraform
- Stwórz moduły dla VPC, GKE, Artifact Registry, kont serwisowych i IAM. Przechowuj zdalny stan (remote state) w zasobniku Cloud Storage chronionym przez CMEK, z włączonym wersjonowaniem i retencją. Wymuszaj polityki OPA w procesie CI, aby zapobiegać ryzykownym zmianom. Uzasadnienie: reużywalne, podlegające przeglądom i zarządzane dostarczanie platformy.
- backend “gcs” { bucket = “borealis-tf-state” prefix = “prod” }
Konfiguracja Kubernetes za pomocą Helm/Kustomize i GitOps
- Utrzymuj bazowe manifesty dla API oraz nakładki (overlays) dla każdego środowiska przy użyciu Kustomize. Użyj Config Sync lub Argo CD do uzgadniania stanu klastrów ze stanem w repozytorium Git. Uzasadnienie: deklaratywne, audytowalne i odporne na dryf konfiguracji (drift) operacje.
Progresywne dostarczanie z wdrożeniem canary i flagami funkcyjnymi
- Użyj wdrożenia canary w Cloud Deploy dla środowiska prod oraz SDK do flag funkcyjnych (np. OpenFeature), aby kontrolować udostępnianie nowej logiki. Zacznij od 5% ruchu, automatycznie promuj wersję przy dobrych wskaźnikach SLO; automatycznie wycofuj zmiany w przypadku degradacji i używaj flagi jako wyłącznika awaryjnego (kill switch). Uzasadnienie: zmniejszenie zasięgu ewentualnej awarii (blast radius) i oddzielenie wdrożenia (deploy) od wydania (release).
Bramki jakości i weryfikacja
- Etapy potoku: testy jednostkowe → testy integracyjne na środowisku tymczasowym (ephemeral) → skanowanie kontenerów → sprawdzanie polityk → testy end-to-end na środowisku staging → wdrożenie canary na prod z automatyczną weryfikacją opartą na SLO (Cloud Monitoring, Error Reporting, Trace). Uzasadnienie: szybka informacja zwrotna na wczesnym etapie, wysokie bezpieczeństwo przed wdrożeniem na produkcję i obiektywne sprawdzanie stanu systemu po wdrożeniu.
Operacje, logowanie i audyt
- Zainstaluj agentów Cloud Logging/Monitoring na maszynach wirtualnych i włącz logi/metryki dla obciążeń w GKE. Eksportuj logi CI/CD i Audit Logs do BigQuery z widokami o ograniczonym zakresie dla audytorów. Utrzymuj runbooki (w tym procedury bezpiecznego wycofywania zmian i awaryjnego przełączania DNS lub LB). Uzasadnienie: obserwowalność umożliwiająca szybkie naprawy oraz dowody gotowe do celów zgodności z regulacjami (compliance).

Ten projekt zapewnia szybkość dzięki przepływowi pracy opartemu na gałęzi głównej (trunk-based) i zautomatyzowanym potokom; bezpieczeństwo dzięki wdrożeniom canary, flagom funkcyjnym i Binary Authorization; audytowalność dzięki niezmiennym artefaktom, zatwierdzeniom i scentralizowanym logom; oraz jasną odpowiedzialność poprzez plik CODEOWNERS i środowiska kontrolowane przez GitOps.

← Operacje · Wszystkie domeny · Koszty →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →