Google PCD: Obserwowalność, debugowanie i operacje Site Reliability — Przewodnik do nauki

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

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

Przegląd

Obserwowalność, debugowanie i operacje SRE (site reliability engineering) w Google Cloud koncentrują się na uczynieniu systemów mierzalnymi, diagnozowalnymi i odpornymi. Solidna obserwowalność wymaga spójnego logowania i metryk, śledzenia rozproszonego (distributed tracing), alertów umożliwiających podjęcie działań oraz zdyscyplinowanego reagowania na incydenty. Niezawodność wymaga jasności co do wskaźników (SLI) i celów (SLO) poziomu usług, rygorystycznego sygnalizowania stanu systemu oraz pętli sprzężenia zwrotnego, która przekształca wnioski z produkcji w ulepszenia inżynierskie. Ta sekcja opisuje, jak budować te zdolności od początku do końca w Google Cloud oraz jak analizować kompromisy i typowe tryby awarii.

Podstawy logowania i monitorowania

Cloud Logging

Emituj logi strukturalne. Preferuj format JSON ze stabilnymi nazwami pól, aby zapytania i metryki oparte na logach pozostały solidne między wydaniami. Uwzględnij poziom ważności (severity), nazwę usługi, wersję, lokalizację oraz identyfikator żądania lub kontekst śledzenia w celu korelacji.
Koreluj logi ze śladami (traces), ustawiając pola:
- logging.googleapis.com/trace: projects/PROJECT_ID/traces/TRACE_ID
- logging.googleapis.com/spanId: SPAN_ID
- logging.googleapis.com/trace_sampled: true
Buckety i retencja. Bucket _Default zazwyczaj ma 30-dniową retencję (konfigurowalną). Bucket _Required zawiera określone logi audytowe z dłuższą, stałą retencją. Twórz regionalne buckety, aby kontrolować rezydencję danych i ustawiać niestandardową retencję dla każdego bucketa.
Ujścia (sinks). Kieruj logi do BigQuery w celu analizy, do Pub/Sub dla konsumentów strumieniowych lub do Storage w celu archiwizacji. Używaj zagregowanych ujść na poziomie folderu lub organizacji, aby przechwytywać logi z podrzędnych projektów.
Zapytania. Używaj języka zapytań Logging do filtrowania według resource.type, etykiet, jsonPayload, httpRequest lub textPayload.

Przykłady:

Wpis logu strukturalnego (w skrócie):

undefined

Aktualizacja retencji:

undefined

Utworzenie ujścia do BigQuery dla logów błędów:

undefined

Odczytanie ostatnich błędów 5xx dla Cloud Run:

undefined

Cloud Monitoring

Metryki. Używaj metryk Google Cloud, metryk niestandardowych i metryk opartych na logach. Preferuj etykiety o niskiej kardynalności; eksplozja kardynalności etykiet powoduje problemy z kosztami i opóźnieniami zapytań.
Pulpity nawigacyjne. Twórz dedykowane pulpity dla każdej usługi i zależności (baza danych, cache, kolejki). Wizualizuj sygnały RED (requests, errors, duration) i USE (utilization, saturation, errors).
Polityki alertów. Wyzwalaj alerty na podstawie progów, braku metryki, wskaźników, tempa wypalania SLO lub niepowodzeń kontroli dostępności. Konfiguruj kanały powiadomień (e-mail, SMS, PagerDuty, Pub/Sub, webhooks). Tłumacz niestabilne alerty (flapping) za pomocą okien czasowych i funkcji wyrównujących (aligners).
Kontrole dostępności (uptime checks). Sonduj z wielu regionów; używaj prywatnych kontroli dostępności dla wewnętrznych punktów końcowych lub uruchamiaj testy syntetyczne wewnątrz VPC.

Metryki oparte na logach

Liczniki (counters) podsumowują wystąpienia (na przykład liczba żądań do /api/alpha/*).
Dystrybucje (distributions) przechwytują opóźnienia lub rozmiary payloadu.
Przykład:

undefined

Analityka operacyjna

Do analizy ad hoc kieruj dane do BigQuery za pomocą ujścia; projektuj schematy i partycjonowanie według znacznika czasu, aby kontrolować koszty.
Używaj Log Analytics w bucketach Logging, aby agregować dane bez eksportowania, tam gdzie to możliwe.
Buduj sygnały o pojemności na podstawie metryk takich jak użycie CPU, pamięci, głębokość kolejki, połączenia Cloud SQL, użycie CPU o wysokim priorytecie w Spanner, niepotwierdzone wiadomości w Pub/Sub oraz wskaźniki błędów 429/5xx w Cloud Storage.

Częste pułapki i kompromisy

Nadmierne logowanie zwiększa koszty pozyskiwania danych i zaciemnia sygnał; preferuj próbkowanie (sampling) i dyscyplinę w zakresie poziomów ważności.
Brak identyfikatorów korelacji utrudnia analizę incydentów (triage); propaguj identyfikatory śledzenia (trace IDs) na całej ścieżce end-to-end.
Długa retencja w gorących bucketach zwiększa koszty; eksportuj dane do archiwum lub BigQuery dla potrzeb długoterminowych.

Śledzenie, błędy i zaawansowana diagnostyka

Śledzenie rozproszone

Kontekst śledzenia. Preferuj W3C trace-context (traceparent, tracestate). W celu zapewnienia interoperacyjności z Cloud Trace, kontynuuj wsparcie dla x-cloud-trace-context: x-cloud-trace-context: TRACE_ID/SPAN_ID;o=1
Propagacja. Przekazuj nagłówki śledzenia między serwisami, kolejkami komunikatów i granicami asynchronicznymi; przechwytuj nowe spany podrzędne podczas wywołań RPC lub SQL. Utrata kontekstu psuje mapy usług i powoduje powstawanie węzłów „nieznanej usługi”.
Próbkowanie (sampling). Zrównoważ koszt i wierność; dynamiczny sampling typu head-based na wejściu (ingress) oraz sampling typu tail-based dla rzadkich, wolnych zapytań mogą zwiększyć użyteczność.

Cloud Trace

Dostarcza histogramy opóźnień, kaskady spanów (waterfalls) i mapy usług. Używaj adnotacji dla krytycznych podoperacji (wywołania RPC, zapytania do bazy danych).
Diagnozuj wartości odstające za pomocą śladów p95/p99; zwracaj uwagę na wzorce fan-out, zapytania N+1 lub rywalizację o blokady.
Włącz korelację śladów z logami, aby kliknięcie w ślad ujawniało powiązane z nim logi.

Error Reporting

Automatycznie agreguje wyjątki według sygnatury stosu dla każdej usługi/wersji. Skonfiguruj kontekst usługi, aby uniknąć mieszania błędów z różnych serwisów. Wyciszaj znane, generujące szum błędy lub kieruj je do powiadomień o niższym priorytecie.
Redaguj dane osobowe (PII) z komunikatów wyjątków; zamiast tego loguj stabilne kody błędów i identyfikatory korelacji.

Cloud Profiler

Ciągłe profilowanie CPU/sterty o niskim narzucie dla wspieranych środowisk uruchomieniowych. Porównuj profile między wersjami i poziomami ruchu, aby wykrywać regresje. Unikaj interpretowania artefaktów próbkowania jako dokładnych liczb.

Cloud Debugger

Migawki (snapshots) przechwytują zmienne w danym miejscu kodu bez wstrzymywania procesu. Logpoints wstrzykują tymczasowe instrukcje logowania. Ograniczaj dostęp, redaguj wrażliwe zmienne i ograniczaj zakres do wyrażeń nie zawierających danych osobowych (non-PII).

Krótki przykład: dodanie W3C traceparent i skorelowanie logu

Propagacja przez HTTP: traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
Pole w logu do powiązania z Cloud Trace: “logging.googleapis.com/trace”: “projects/myproj/traces/4bf92f3577b34da6a3ce929d0e0e4736”

Inżynieria niezawodności, alerty i sygnały o stanie

SLI, SLO, SLA i budżety błędów

SLI mierzą zadowolenie użytkownika: dostępność, opóźnienie, poprawność. Definiuj je dla każdego krytycznego punktu końcowego i ścieżki użytkownika.
SLO określają cele, np. 99,9% zapytań poniżej 300 ms w ciągu 30 dni.
Budżety błędów kwantyfikują dopuszczalną zawodność. Wykorzystuj budżety na wydania, eksperymenty lub migracje; wstrzymaj zmiany, jeśli tempo zużycia (burn rate) jest zbyt wysokie.
SLA to zewnętrzne zobowiązania; utrzymuj SLO bardziej rygorystyczne niż SLA, aby chronić margines.

Projektowanie alertów wysokiej jakości

W miarę możliwości preferuj alerty oparte na SLO i objawach zamiast alertów opartych na przyczynach.
Używaj alertów wielookresowych o różnym tempie zużycia (np. 14x w ciągu 5 minut i 2x w ciągu 1 godziny), aby wychwytywać szybkie i wolne zużycie budżetu, jednocześnie redukując szum.
Dodaj alerty o braku metryk dla watchdogów (np. sygnał heartbeat od długo działającego zadania).
Kieruj alerty według ważności; ograniczaj liczbę powiadomień (rate-limit); udostępniaj linki do runbooków i dashboardów.

Kontrole stanu i sondy

Sondy gotowości (readiness checks) blokują ruch, dopóki zależności nie są gotowe; sondy żywotności (liveness checks) wyzwalają restarty zablokowanych procesów; sondy startowe (startup probes) chronią wolno startujące aplikacje przed przedwczesnymi restartami.
Dla maszyn wirtualnych za load balancerem, zezwól na ruch z zakresów źródłowych mechanizmu kontroli stanu, w przeciwnym razie ruch nigdy nie dotrze do backendów:

undefined

Przykład dla Kubernetes:

undefined

Testowanie syntetyczne. Używaj kontroli dostępności (uptime checks) i dedykowanych przepływów end-to-end za pomocą Cloud Scheduler + Cloud Run/Functions, aby walidować logowanie, płatności lub inne krytyczne ścieżki.
Monitorowanie zależności. Śledź nasycenie połączeń z bazą danych, wskaźniki błędów RPC, zaległości w kolejkach, błędy na wyjściu (egress) i SLI usług trzecich. Ustaw ponawianie prób z mechanizmem truncated exponential backoff dla przejściowych błędów 429/5xx, używając kluczy idempotencji dla bezpieczeństwa.

Reagowanie na incydenty, bezpieczne debugowanie i analiza przyczyn źródłowych

Cykl życia reakcji na incydenty

Wstępna klasyfikacja (triage): klasyfikuj wagę, przydziel dowodzącego incydentem (incident commander) i powiadamiaj dyżurnego (on-call) przez zdefiniowane kanały.
Ograniczenie (containment): zastosuj znane środki zaradcze i mechanizmy kontroli ruchu (wycofanie zmian, canary, circuit breaker, rate limiters).
Komunikacja: utrzymuj wewnętrzny pokój narad (war-room), regularnie aktualizuj interesariuszy i w razie potrzeby publikuj status dla użytkowników.
Rozwiązanie i przywrócenie działania: weryfikuj stan systemu za pomocą wskaźników SLI; unikaj przedwczesnego ogłaszania końca problemu.
Analiza post-mortem: przeprowadź bezstronną analizę osi czasu, luk w wykrywaniu, czynników sprzyjających oraz zadań do wykonania (action items) z przypisanymi właścicielami i terminami. Śledź postępy aż do ich zamknięcia.

Runbooki

Powinny zawierać wyzwalacze, wymagany kontekst, polecenia diagnostyczne, bezpieczne środki zaradcze, kroki wycofania zmian oraz ścieżki eskalacji. Umieszczaj linki do dashboardów, logów i playbooków dla konkretnych scenariuszy awarii.

Monitorowanie limitów (quota) i pojemności

Monitoruj limity usług (service quotas) za pomocą metryk Cloud Monitoring. Zautomatyzuj alerty przy wykorzystaniu na poziomie 70–80% i z wyprzedzeniem wnioskuj o zwiększenie limitów przed planowanymi testami obciążeniowymi lub wdrożeniami.
Sygnały dotyczące pojemności do śledzenia: CPU, pamięć, deskryptory plików, pule wątków, połączenia z bazą danych, limity autoskalera i głębokość kolejki żądań.

Debugowanie bez ujawniania informacji wrażliwych

Redaguj sekrety i dane osobowe (PII) u źródła; centralizuj sekrety w Secret Manager. Używaj haszowania lub tokenizacji dla identyfikatorów użytkowników. Włącz redakcję na poziomie pól w oprogramowaniu pośredniczącym (middleware) do logowania.
Ograniczaj dostęp do logów, śladów (traces) i narzędzi do debugowania za pomocą IAM; w odpowiednich przypadkach używaj CMEK i VPC Service Controls.
W usłudze Debugger wyłącz zbieranie dużych grafów obiektów i dodaj warunki, aby unikać przechwytywania ramek z wrażliwymi danymi.

Analiza przyczyn źródłowych (RCA) na różnych warstwach

Środowisko uruchomieniowe (runtime): koreluj skoki w GC, pulach wątków lub użyciu CPU za pomocą Profiler z opóźnieniem p99 w Trace.
Sieć: sprawdzaj logi load balancera, VPC Flow Logs, logi zapory sieciowej i Connectivity Tests, aby zweryfikować ścieżki. Błędy kontroli stanu (health check) często wynikają z brakujących reguł zapory lub błędnych portów.
IAM: przeglądaj Cloud Audit Logs pod kątem odmów uprawnień lub zmian w politykach; potwierdź role kont usługowych i zakresy tokenów.
Dane: używaj Cloud SQL Insights, statystyk zapytań Spanner, użycia CPU i gorących tabletów w Bigtable oraz wskaźników błędów Storage, aby znaleźć punkty zapalne (hotspots). Stosuj ponowienia z wykładniczym czasem oczekiwania (backoff) dla błędów przejściowych i ograniczaj rozproszenie (fan-out), które wzmacnia opóźnienie w ogonie rozkładu (tail latency).
Połącz wszystko za pomocą skorelowanych identyfikatorów śledzenia (trace ID) i metryk opartych na logach; eksportuj do BigQuery, aby wykonywać złączenia (join) z wielu źródeł podczas analizy poincydentalnej.

Praktyczny scenariusz problemu

Firma Fjord Retail migruje wielousługowy proces płatności (checkout) do Google Cloud, używając Cloud Run, Cloud SQL, Pub/Sub i zewnętrznego API do obsługi podatków. Użytkownicy zgłaszają sporadyczne przekroczenia czasu oczekiwania i skokowe wzrosty błędów podczas wyprzedaży błyskawicznych (flash sales), a zespół dyżurny (on-call) otrzymuje szumiące alerty o niskiej wartości informacyjnej.

Podejście:

Zaimplementuj ustrukturyzowane logowanie z korelacją śledzenia (trace)

Dodaj propagację nagłówka W3C traceparent między usługami i uwzględnij logging.googleapis.com/trace we wszystkich logach. Uzasadnienie: korelacja end-to-end pozwala inżynierom szybko przejść od wolnego żądania użytkownika do konkretnego wolnego wywołania RPC lub zapytania i jego logów.

Utwórz zasobniki (buckets) Logging, skonfiguruj retencję i eksporty

Zwiększ retencję dla zasobnika _Default do 90 dni i utwórz regionalny zasobnik dla obciążeń w UE. Dodaj zagregowany ujście (sink) do BigQuery dla logów o poziomie ERROR i WARNING:

undefined

Uzasadnienie: wystarczająca retencja w trybie „gorącym” (hot storage) ułatwia debugowanie; BigQuery umożliwia szybką analizę incydentów bez zawyżania kosztów przechowywania danych w trybie „gorącym”. 3) Zdefiniuj wskaźniki SLI/cele SLO i alerty oparte na SLO

SLI dostępności: pomyślne żądania / wszystkie żądania. SLI opóźnienia: czas trwania p95 dla POST /checkout.
Cele SLO: dostępność 99,9% w skali miesiąca; 95% płatności < 300 ms.
Skonfiguruj alerty oparte na tempie zużycia budżetu błędu (burn-rate) w wielu oknach czasowych oraz alert o braku metryki dla sygnału życiowego (heartbeat) procesu płatności. Uzasadnienie: alerty oparte na symptomach redukują szum i powodują powiadomienie (page) tylko w przypadku realnego wpływu na użytkownika.

Skonfiguruj sondy kondycji (health probes) i testy syntetyczne

Usługi Cloud Run udostępniają punkty końcowe /ready i /healthz. Dodaj globalny test dostępności (uptime check) dla /checkout oraz prywatne zadanie syntetyczne w VPC, które wykonuje pełny proces płatności przy użyciu danych testowych. Uzasadnienie: sonda gotowości (readiness) zapobiega kierowaniu ruchu do „zimnych” backendów; testy syntetyczne wykrywają problemy end-to-end i regresje w usługach firm trzecich.

Włącz Cloud Trace i Profiler oraz zaimplementuj ponowienia z wykładniczym czasem oczekiwania (backoff)

Zainstaluj agentów Trace/Profiler tam, gdzie to możliwe; włącz automatyczną instrumentację klienta HTTP i adnotacje spanów SQL. Zaimplementuj ucięty wykładniczy czas oczekiwania (truncated exponential backoff) z kluczami idempotencji dla wywołań API podatkowego. Uzasadnienie: śledzenie (tracing) izoluje czynniki wpływające na opóźnienia; mechanizm backoff redukuje amplifikację błędów 429/5xx i chroni budżety błędów.

Monitoruj pojemność i limity (quotas)

Dodaj dashboardy i alerty dla połączeń Cloud SQL, użycia CPU, puli buforów InnoDB, niepotwierdzonych wiadomości w Pub/Sub, współbieżności Cloud Run i wykorzystania limitów usług (service quota). Uzasadnienie: wysycenie pojemności jest częstą ukrytą przyczyną opóźnień w ogonie rozkładu (tail latency); wczesne alerty zapobiegają awariom.

Wzmocnij bezpieczeństwo debugowania pod kątem prywatności

Używaj haszowanych identyfikatorów użytkowników i wykluczaj dane osobowe (PII) z komunikatów o błędach. Ogranicz użycie Debugger w środowisku produkcyjnym tylko do logpointów i z zastosowaniem reguł redakcji. Uzasadnienie: zachowaj obserwowalność, jednocześnie przestrzegając zasady minimalizacji danych.

Zbuduj monitory zależności i mechanizmy circuit breaker

Śledź wskaźnik sukcesu i opóźnienie zewnętrznego API podatkowego za pomocą metryk niestandardowych; wyzwalaj mechanizm circuit breaker, aby przełączyć się na buforowane stawki podatkowe, gdy liczba błędów przekroczy próg. Uzasadnienie: izoluj awarie w zależnościach od firm trzecich i utrzymuj dostępność kluczowego procesu płatności.

Przygotuj runbooki i ścieżki eskalacji

Udokumentuj kroki: weryfikacja dashboardów SLO, sprawdzenie mapy usług w Trace pod kątem „gorących” krawędzi, analiza Cloud SQL Insights w poszukiwaniu wolnych zapytań, weryfikacja zapory sieciowej i kontroli stanu oraz ocena zapasu w limitach (quota). Uwzględnij procedury wycofywania zmian i canary. Uzasadnienie: spójna, szybka reakcja skraca MTTR (Mean Time To Resolve) i pozwala uniknąć ryzykownych zmian ad-hoc.

Potok analityczny do analizy poincydentalnej

Użyj eksportów do BigQuery do obliczania wskaźników błędów dla poszczególnych najemców (per-tenant) oraz do korelowania logów ze śladami (traces) i danymi z Cloud SQL Insights za pomocą trace ID. Uzasadnienie: trwała, przeszukiwalna historia umożliwia dokładne analizy przyczyn źródłowych (RCA) i wdrażanie środków zapobiegawczych.

Ten plan podnosi jakość sygnału, skraca czas wykrywania i rozwiązywania problemów, chroni doświadczenie użytkownika podczas skoków obciążenia i zapewnia prywatność podczas debugowania na produkcji.

← Ciągłe dostarczanie · Wszystkie domeny · Wydajność →

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