Google PCA: Operacje, obserwowalność i automatyzacja platformy — 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

Operacje, obserwowalność i automatyzacja platformy w Google Cloud zapewniają, że usługi są diagnostyczne, łatwe w utrzymaniu i stale ulepszane, przy jednoczesnej kontroli bezpieczeństwa i kosztów. Spójny projekt obejmuje logowanie, metryki, śledzenie, audytowalność, runbooki, reagowanie na incydenty, zarządzanie limitami i pojemnością oraz automatyzację. Celem jest generowanie użytecznych sygnałów o niskim poziomie szumu, powiązanych z celami poziomu usług (SLO), w połączeniu z deterministyczną automatyzacją, która redukuje pracę odtwórczą i dryf konfiguracji.

Logowanie i audytowalność

Cloud Logging centralizuje logi z usług Google Cloud, GKE i maszyn wirtualnych. Preferuj logi strukturalne (JSON) ze spójnymi kluczami dla request_id, user_id, service, version, latency_ms i severity; dane strukturalne umożliwiają precyzyjne zapytania, tworzenie metryk opartych na logach i ocenę polityk. Na maszynach wirtualnych i węzłach GKE zainstaluj Ops Agent (preferowany) lub starszego agenta logowania, aby zbierać logi systemowe i aplikacyjne; upewnij się, że parsery emitują format JSON dla Twoich frameworków.

• Zasobniki logów i retencja: Używaj regionalnych zasobników logów w celu zapewnienia rezydencji danych i stosowania CMEK. Domyślne zasobniki to _Default i _Required; ten drugi przechowuje logi audytowe Admin Activity, System Event i Policy Denied ze stałą, długoterminową retencją. Twórz dedykowane zasobniki dla każdej klasy danych (np. aplikacyjne, bezpieczeństwa, analityczne) z dopasowaną retencją i CMEK. Dłuższa retencja ułatwia analizę śledczą, ale zwiększa koszty; eksportuj dane w celu długoterminowej archiwizacji, gdy retencja w Cloud Logging nie jest wymagana.

• Ujścia logów i eksporty: Kieruj logi za pomocą Log Router poprzez ujścia do BigQuery (analityka), Pub/Sub (SIEM lub potoki danych) i Cloud Storage (archiwizacja). Używaj partycjonowanych tabel BigQuery, aby zarządzać wolumenem danych i kosztami. Zawsze nadawaj kontu serwisowemu ujścia dostęp do zapisu z najniższymi uprawnieniami do miejsca docelowego, aby uniknąć cichych awarii. Unikaj pętli routingu, nie importując ponownie wyeksportowanych logów z powrotem do Cloud Logging.

• Zapytania i metryki oparte na logach: Używaj Logs Explorer z filtrami na polach logName, resource.type, severity, labels i jsonPayload. Twórz metryki oparte na logach (typu licznik lub dystrybucja) dla wskaźników SLI dotyczących współczynnika błędów i histogramów opóźnień, wspierając system alertów. Kontroluj kardynalność poprzez normalizację pól o dużej zmienności.

• Cloud Audit Logs: Logi Admin Activity (zapisy w płaszczyźnie kontrolnej), Data Access (odczyty/zapisy danych użytkownika), System Event i Policy Denied zapewniają obserwowalność administracyjną. Logi Data Access mają duży wolumen i są domyślnie wyłączone dla wielu usług; włączaj je tylko tam, gdzie jest to konieczne, i kieruj do zasobnika z odpowiednią retencją i CMEK. Logi Policy Denied pomagają wcześnie wykrywać naruszenia uprawnień i polityk organizacji. Zapewnij rozdzielenie odpowiedzialności: zespoły ds. bezpieczeństwa zazwyczaj są właścicielami logów audytowych i mają do nich dostęp, podczas gdy inne zespoły mają ograniczony wgląd.

• Tryby awarii i kompromisy:

  • Zbyt szeroko zdefiniowane ujścia gwałtownie zwiększają koszty w BigQuery; filtruj precyzyjnie i wygaszaj partycje.
  • Pola JSON o wysokiej kardynalności (np. pełne adresy URL) pogarszają wydajność zapytań; oczyszczaj dane i wyodrębniaj znormalizowane etykiety.
  • Niewystarczająca retencja utrudnia dochodzenia; eksporty do GCS lub BigQuery łagodzą ten problem.
  • Brakujący agent lub błędne konfiguracje parserów powodują cichą utratę logów; alertuj o braku sygnału życia agenta (heartbeat) i błędach pozyskiwania.

Przykład: utwórz regionalny zasobnik logów z niestandardową retencją i wyeksportuj filtrowane ujście audytowe.

• gcloud logging buckets create app-logs –location=us-central1 –retention-days=30
• gcloud logging sinks create bq-audit-sink bigquery.googleapis.com/projects/PROJECT/datasets/audit –log-filter=“logName:cloudaudit.googleapis.com AND protoPayload.serviceName:*” –use-partitioned-tables

Monitorowanie, śledzenie i diagnostyka aplikacji

Cloud Monitoring zbiera metryki systemowe i aplikacyjne, obsługuje pulpity nawigacyjne, alerty, testy dostępności, kanały powiadomień i cele poziomu usług.

• Metryki i pulpity nawigacyjne: Korzystaj z wbudowanych metryk dla usług Google i twórz niestandardowe metryki za pomocą Cloud Monitoring API lub OpenTelemetry. Kładź nacisk na cztery złote sygnały: opóźnienie, ruch, błędy, nasycenie. Stosuj etykiety rozważnie; unikaj nieograniczonych wartości etykiet. Używaj Metrics Scope do agregowania widoków z wielu projektów. Używaj MQL do tworzenia zaawansowanych zapytań, gdy jest to potrzebne.

• Alerty i kanały powiadomień: Implementuj alerty typu multi-window i multi-burn-rate dla SLO, aby zrównoważyć szybkość wykrywania z redukcją szumu. Zdefiniuj kanały powiadomień (e-mail, SMS, Pub/Sub, webhooks, narzędzia do zarządzania incydentami firm trzecich) i umieszczaj linki do runbooków oraz kontekst w dokumentacji alertu. Używaj limitów częstotliwości powiadomień i automatycznego zamykania incydentów, aby zapobiegać burzom alertów.

• Testy dostępności (uptime checks): Sondowanie krytycznych punktów końcowych z wielu regionów z weryfikacją TLS, DNS i dopasowaniem treści. Powiąż testy dostępności z alertami i celami SLO usług. Pamiętaj, że testy dostępności nie weryfikują wewnętrznych zależności; uzupełnij je o transakcje syntetyczne i wewnętrzne testy kondycji.

• SLO i SLI: Zdefiniuj wskaźniki SLI dla dostępności, opóźnień i poprawności. Skonfiguruj SLO w Cloud Monitoring Service Monitoring i śledź budżety błędów. Alertuj o zużyciu budżetu, a nie o surowych błędach, aby dostosować się do wpływu na klienta. Używaj bramek wydań (release gates) lub wdrożeń progresywnych, aby nie przekroczyć pozostałego budżetu błędów.

• Cloud Trace, Error Reporting, Profiler: Używaj śledzenia rozproszonego między usługami za pomocą OpenTelemetry, aby adnotować spany metadanymi żądania i zależności. Dostosowuj próbkowanie dynamicznie dla każdej usługi i ścieżki, aby zapewnić pokrycie krytycznych przepływów przy jednoczesnej kontroli kosztów. Error Reporting automatycznie agreguje wyjątki z logów, deduplikuje je na podstawie śladu stosu (stack trace) i wyzwala powiadomienia. Profiler dostarcza ciągłe profilowanie CPU, sterty (heap) i czasu zegarowego (wall-time) w środowisku produkcyjnym z niskim narzutem; używaj go do eliminowania gorących ścieżek (hot paths) i redukcji kosztów.

• Tryby awarii i kompromisy:

  • Nadmierna kardynalność metryk zwiększa koszty i spowalnia zapytania; agreguj dane przed ich wysłaniem.
  • Niskie próbkowanie śledzenia ukrywa problemy z opóźnieniami w ogonie rozkładu (tail latency); dla wolnych ścieżek stosuj wyższą częstotliwość próbkowania.
  • Niedopasowane SLO (np. zbyt restrykcyjne) generują zmęczenie alertami; iteruj na podstawie danych z rzeczywistego ruchu.
  • Testy dostępności mogą przechodzić pomyślnie, podczas gdy wewnętrzne zależności zawodzą; używaj SLO uwzględniających zależności.

Operacje na platformie, runbooki i zarządzanie incydentami

Rygor operacyjny skraca średni czas wykrywania, łagodzenia skutków i wyciągania wniosków.

• Runbooki i eskalacja: Każdy alert musi być powiązany z deterministycznym runbookiem zawierającym warunki wstępne, kroki diagnostyczne, procedurę wycofywania zmian (rollback) i szablony komunikacji. Zdefiniuj jasne harmonogramy dyżurów (on-call) i polityki eskalacji. Przechowuj runbooki w systemie kontroli wersji i testuj je.

• Zarządzanie incydentami i analizy post-mortem: Używaj ustandaryzowanych poziomów ważności (severities), ról (incident commander, communications, ops, SME) i kanałów komunikacji. Preferuj chat ops i strony statusowe do masowej komunikacji. Pisz analizy post-mortem bez obwiniania (blameless), które zawierają oś czasu, czynniki sprzyjające, luki w wykrywaniu, wpływ na klienta oraz konkretne działania naprawcze przypisane do właścicieli i terminów.

• Zarządzanie limitami (quota) i sygnały o pojemności: Monitoruj metryki Service Usage i limity serviceruntime za pomocą alertów dotyczących wskaźnika wykorzystania. Proaktywnie wnioskuj o zwiększenie limitów i dostosuj limity autoskalowania do przyznanych limitów (quotas). Wykorzystuj sygnały o pojemności, takie jak CPU, memory, deskryptory plików, pule połączeń i głębokość kolejki. Dla GKE, dostrajaj HPA/VPA i cluster autoscaler; dla GCE MIGs, ustawiaj odpowiednio okresy cool-down i skalowanie predykcyjne (predictive autoscaling).

• Kondycja usług i rozwiązywanie problemów: Łącz funkcje live tail w Logs Explorer, metryki oparte na logach, dashboardy i Trace, aby skrócić MTTD. Włącz VPC Flow Logs i Firewall Rules Logging do diagnostyki sieci; używaj konsoli szeregowej VM w przypadku problemów z uruchamianiem. Zachowaj przechwytywanie pakietów i śledzenie jądra (kernel tracing) jako procedury awaryjne (break-glass) w runbookach.

• Tryby awarii:

  • Wyczerpanie limitu (quota) wygląda jak awaria; ustaw alert na 80% wykorzystania i ograniczaj liczbę żądań od systemów nadrzędnych (rate-limit upstream).
  • Autoskalowanie bez wstępnego przygotowania (prewarming) powoduje zimne starty (cold starts); używaj minimalnej liczby replik dla krytycznych ścieżek.
  • Brak testów syntetycznych maskuje awarie widoczne dla klienta; zaimplementuj transakcje canary.

Automatyzacja, inwentaryzacja zasobów, polityki i dryf

Automatyzuj powtarzalne zadania, stosując zasadę najmniejszych uprawnień i idempotentność.

• Narzędzia: Używaj Cloud Shell do bezpiecznej, efemerycznej administracji z trwałym katalogiem $HOME; umieszczaj pomocnicze pliki binarne w ~/bin, aby zapewnić ich trwałość w PATH. Automatyzuj za pomocą gcloud, REST API i bibliotek klienckich. Używaj kont usług i workload identity, aby wyeliminować długoterminowe klucze.

• Harmonogramy i orkiestratory: Używaj Cloud Scheduler do wyzwalania zadań HTTP i Pub/Sub zgodnie z harmonogramami cron. Używaj Workflows do orkiestracji automatyzacji obejmującej wiele usług, z ponowieniami, wykładniczym backoffem, kompensacją i limitami czasowymi. Zapewnij idempotentność i dodawaj identyfikatory korelacji do logów.

• Przykłady rutynowej automatyzacji:

  • Codzienny eksport zasobów do GCS i BigQuery w celu tworzenia raportów inwentaryzacyjnych i raportów dryfu.
  • Zautomatyzowane obliczanie wskaźnika zużycia budżetu błędu (burn rate) SLO i publikowanie go na pulpicie nawigacyjnym.
  • Okresowa ocena zgodności z politykami organizacji i wykrywanie anomalii w IAM.

• Inwentaryzacja zasobów i ocena polityk: Cloud Asset Inventory dostarcza migawki zasobów, powiązań IAM i polityk organizacji w danym punkcie czasowym oraz strumienie zmian w czasie rzeczywistym. Eksportuj dane do BigQuery w celu analizy historycznej i wykrywania dryfu; subskrybuj Pub/Sub, aby niemal w czasie rzeczywistym analizować naruszenia polityk. Używaj Policy Analyzer i Recommender do wykrywania zbyt szerokich i nieużywanych uprawnień IAM. Wymuszaj ograniczenia za pomocą Organization Policy i waliduj konfiguracje przed wdrożeniem, stosując politykę jako kod (policy-as-code).

• Dryf konfiguracji: Zapobiegaj dryfowi za pomocą deklaratywnego IaC (infrastruktura jako kod) i ciągłej walidacji. Po wykryciu dryfu automatycznie uzgadniaj stan lub poddawaj zasoby kwarantannie. Oznaczaj zasoby informacją o pochodzeniu (np. deployment_id), aby odróżnić zasoby zarządzane od tworzonych ad hoc.

• Architektura obserwowalności pod kątem bezpieczeństwa, niezawodności i kosztów:

  • Bezpieczeństwo: Przekierowuj logi audytowe do zasobników chronionych przez CMEK z ograniczonym dostępem; eksportuj je do dedykowanego projektu bezpieczeństwa. Integruj z SIEM za pośrednictwem Pub/Sub.
  • Niezawodność: Twórz pulpity nawigacyjne i alerty na podstawie SLI i śladów (traces); ćwicz automatyzację obsługi incydentów za pomocą Workflows.
  • Koszt: Kontroluj kardynalność metryk, dostosowuj retencję logów dla każdego zasobnika, partycjonuj eksporty do BigQuery i używaj Profiler do optymalizacji gorących ścieżek (hot paths).

Przykład: zaplanuj codzienny eksport zasobów i wykonaj workflow.

• gcloud asset export –content-type=resource –output-path=gs://ORG-SEC-BUCKET/daily/resources-$(date +%F).json
• gcloud scheduler jobs create http run-asset-scan –schedule=“0 3 * * *” –uri=“WORKFLOW_EXECUTIONS_API_ENDPOINT” –http-method=POST –oauth-service-account-email=scheduler-sa@PROJECT.iam.gserviceaccount.com

Praktyczny scenariusz problemowy

Firma Contoso Commerce uruchamia wieloregionalną platformę do obsługi płatności opartą na GKE. Wymagania: audytowalna administracja, alerty oparte na SLO z minimalnym szumem, śledzenie żądań end-to-end, zautomatyzowana nocna inwentaryzacja zgodności i ścisła kontrola kosztów.

Podejście:

1. Stworzenie fundamentów pod logowanie i audyt

• Utwórz regionalne zasobniki logów z CMEK dla logów aplikacji, bezpieczeństwa i analityki; ustaw retencję na 30 dni dla logów aplikacji i ponad 400 dni dla logów bezpieczeństwa, zgodnie z wymaganiami. Przekieruj logi Admin Activity, System Event i Policy Denied do zasobnika bezpieczeństwa; włącz logi Data Access tylko dla usług płatniczych.
• Uzasadnienie: Segregacja według wrażliwości danych zmniejsza promień rażenia (blast radius) i koszty; CMEK spełnia wymagania zgodności; ograniczenie logów Data Access zapobiega nagłym wzrostom wolumenu.

2. Wdrożenie ustrukturyzowanego logowania i zbierania logów aplikacji

• Wdróż Ops Agent na węzłach GKE oraz kolektory w formie sidecar/daemonset, aby przesyłać logi aplikacji w ustrukturyzowanym formacie JSON z identyfikatorami korelacji (trace_id, span_id) oraz etykietami użytkownika/sesji, oczyszczonymi z danych osobowych (PII).
• Uzasadnienie: Ustrukturyzowane logi umożliwiają precyzyjne zapytania, tworzenie metryk na podstawie logów i łączenie ich ze śladami (traces); identyfikatory korelacji wspierają diagnostykę rozproszoną.

3. Wdrożenie śledzenia rozproszonego, agregacji błędów i profilowania

• Zinstrumentuj mikrousługi za pomocą OpenTelemetry SDK, eksportując dane do Cloud Trace; ustaw wyższy sampling dla ścieżek związanych z finalizacją zakupu i płatnościami. Włącz Error Reporting dla wszystkich środowisk uruchomieniowych oraz Profiler dla usług krytycznych pod względem użycia procesora/pamięci.
• Uzasadnienie: Ślady (traces) pozwalają zlokalizować opóźnienia na poszczególnych etapach między usługami; Error Reporting grupuje ślady stosu, aby przyspieszyć wstępną analizę (triage); Profiler redukuje koszty obliczeniowe i opóźnienia krańcowe (tail latency).

4. Zdefiniowanie SLI/SLO oraz konfiguracja alertów i pulpitów nawigacyjnych

• Zdefiniuj SLI: opóźnienie p90 i p99 dla procesu finalizacji zakupu, dostępność API do finalizacji zakupu oraz wskaźnik pomyślnych płatności. Ustaw SLO (np. dostępność na poziomie 99,9%, opóźnienie p99 poniżej 800 ms). Skonfiguruj alerty o wskaźniku zużycia budżetu błędu (burn rate) (2% w ciągu 1 godziny i 1% w ciągu 6 godzin) z linkami do runbooków i kanałem PagerDuty; zbuduj pulpity nawigacyjne wyświetlające złote sygnały (golden signals) i trendy budżetu błędu.
• Uzasadnienie: Alerty oparte na budżecie błędu są powiązane z wpływem na klienta i redukują szum; pulpity nawigacyjne zapewniają operacyjną świadomość sytuacyjną.

5. Dodanie zewnętrznych i wewnętrznych kontroli stanu (health checks)

• Skonfiguruj wieloregionalne kontrole dostępności (uptime checks) dla punktów końcowych finalizacji zakupu z walidacją treści; dodaj syntetyczne testy transakcji dla przepływu od koszyka do płatności. Zintegruj z GCLB i sondami gotowości (readiness probes) GKE.
• Uzasadnienie: Kontrole dostępności weryfikują dostępność od strony klienta; syntetyczne przepływy wykrywają awarie zależności.

6. Automatyzacja inwentaryzacji, monitorowania polityk i wykrywania dryfu

• Utwórz projekt Bezpieczeństwa (Security), aby odbierać eksporty z Cloud Asset Inventory do GCS i BigQuery; włącz strumienie Pub/Sub w czasie rzeczywistym dla zmian w IAM i politykach organizacji. Uruchamiaj co noc Workflows, aby porównywać manifesty stanu pożądanego z bieżącymi zasobami; otwieraj zgłoszenia lub automatycznie uzgadniaj dryf o niskim ryzyku.
• Uzasadnienie: Scentralizowana inwentaryzacja wspiera audyty; ciągła ocena polityk zapobiega pełzaniu uprawnień (privilege creep); automatyzacja ogranicza dryf.

7. Zarządzanie limitami (quotas) i pojemnością

• Monitoruj limity zasobów obliczeniowych, load balancerów i API za pomocą alertów przy 70% i 85% wykorzystania. Wnioskuj z wyprzedzeniem o wyższe limity dla docelowego obciążenia; dostosuj limity autoskalera klastra GKE i HPA do limitów (quotas). Włącz predykcyjne autoskalowanie dla usług opartych

← Migracja · Wszystkie domeny · DevOps →

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

Przeglądaj Google →