Google PCNE: Obserwowalność sieci, niezawodność i rozwiązywanie problemów — Przewodnik do nauki

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

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

Przegląd

Obserwowalność sieci w Google Cloud to zdyscyplinowane gromadzenie, korelowanie i analizowanie sygnałów sieciowych, które opisują osiągalność, wydajność i poprawność działania w obrębie sieci VPC, systemów równoważenia obciążenia, połączeń hybrydowych i usług. Niezawodność wynika z projektowania pod kątem wykrywania awarii i bezpiecznego usuwania ich skutków: instrumentacja telemetrii pierwszej klasy, walidacja płaszczyzny sterowania przed dotknięciem płaszczyzny danych, szczegółowa analiza dowodów w postaci pakietów tylko w razie konieczności oraz automatyzacja wycofywania zmian. Ta sekcja wyjaśnia, jak używać narzędzi i wzorców Google Cloud do wykrywania, diagnozowania i zapobiegania problemom, minimalizując jednocześnie ryzyko podczas wprowadzania zmian.

Flow Logs, Logging, Monitoring, Metryki i SLO

VPC Flow Logs dostarczają próbkowaną, zagregowaną telemetrię na poziomie karty sieciowej (NIC) maszyny wirtualnej, po ewaluacji przez zaporę sieciową VPC. Nie są to pełne zrzuty pakietów i nie zastępują logowania reguł zapory sieciowej w celu uzyskania jednoznacznych dowodów na zezwolenie/odmowę. Kluczowe ustawienia:

• Próbkowanie: 0.0–1.0. Wyższe próbkowanie poprawia dokładność kosztem objętości logów i potencjalnych kosztów.
• Interwał agregacji: 5s–30m. Krótsze interwały skracają czas do wykrycia, ale zwiększają liczbę wpisów.
• Metadane: dołączanie lub wykluczanie metadanych instancji i VPC. Dołączaj dla bogatszej analityki, wykluczaj, aby ograniczyć wrażliwe atrybuty.

Typowe włączenie na podsieci:

• gcloud compute networks subnets update SUBNET –region=REGION –enable-flow-logs –logging-flow-sampling=0.5 –logging-aggregation-interval=interval-5-min –logging-metadata=INCLUDE_ALL_METADATA

Eksportuj za pomocą ujść logów (log sinks) w celu trwałej analizy i udostępniania między projektami:

• BigQuery do analityki SQL i długoterminowej analizy trendów.
• Pub/Sub do potoków działających w czasie zbliżonym do rzeczywistego, kierowanych do SIEM/IDS.
• Cloud Storage do archiwizacji.
• Przykład ujścia do BigQuery:
  • gcloud logging sinks create flowlogs-to-bq bigquery.googleapis.com/projects/PROJECT/datasets/DATASET –log-filter=‘resource.type=“gce_subnetwork”’

Logowanie reguł zapory sieciowej uzupełnia flow logs, rejestrując decyzje o zezwoleniu/odmowie oraz dopasowane reguły. Aby obserwować zablokowany ruch, dodaj regułę odmawiającą wszystkiego (deny-all) z włączonym logowaniem pod koniec zestawu reguł:

• gcloud compute firewall-rules create deny-all –network=VPC –priority=65500 –direction=INGRESS –action=DENY –rules=all –enable-logging

Cloud Logging umożliwia ustrukturyzowane zapytania, korelację z logami żądań, logami sprawdzania poprawności (health-check), logami NAT i logami systemów równoważenia obciążenia. Twórz metryki oparte na logach dla sygnałów takich jak:

• Nagłe wzrosty liczby odrzuconych połączeń do tagów backendu (możliwa błędna konfiguracja list dozwolonych).
• Duża liczba retransmisji SYN do portu (możliwe nasycenie lub blackholing).
• Zdarzenia NAT „no available ports” (wyczerpanie zasobów Cloud NAT).

Cloud Monitoring agreguje metryki i dostarcza pulpity nawigacyjne (dashboardy), alerty oraz SLO:

• Metryki do obserwacji: wskaźnik błędów 5xx load balancera, opóźnienie backendu, bajty/pakiety na karcie sieciowej instancji, porty przydzielone/używane/nadmiarowe w Cloud NAT, status sesji BGP w Cloud Router, utracone pakiety w tunelu VPN, wykorzystanie łącza Interconnect, utrata pakietów i opóźnienie.
• Dashboardy: buduj dashboardy per usługa i per połączenie, używając współdzielonych szablonów między projektami dla zapewnienia spójności operacyjnej.
• Alerty: preferuj alerty objawowe (wskaźnik błędów, opóźnienie, liczniki utraconych pakietów) z szybką informacją zwrotną oraz alerty przyczynowe (niestabilność BGP, zerwanie łącza) z powiadamianiem, gdy prawdopodobny jest wpływ na użytkownika.
• SLO: definiuj SLO zorientowane na użytkownika (np. globalny wskaźnik sukcesu i opóźnienie HTTP) oraz alerty o tempie zużycia budżetu błędu (burn-rate), aby identyfikować szybkie i wolne zużycie. Używaj logów żądań jako licznika/mianownika poprzez metryki oparte na logach w celu precyzyjnej oceny SLO.

Kompromisy i tryby awarii:

• Niskie próbkowanie lub długa agregacja ukrywa mikroimpulsy i krótkotrwałe awarie.
• Flow logs nie dają wglądu w pakiety odrzucone przed zaporą sieciową; polegaj na logowaniu reguł zapory, aby uzyskać dowody na odrzucenie.
• Nadmierne logowanie bez filtrowania zwiększa koszty i może spowolnić dochodzenia; eksportuj i partycjonuj dane w inteligentny sposób.

Network Intelligence Center i zaawansowana diagnostyka

Network Intelligence Center (NIC) zapewnia proaktywną i ustrukturyzowaną diagnostykę:

Connectivity Tests:

• Weryfikuje osiągalność na płaszczyźnie sterowania poprzez trasy, reguły zapory sieciowej (w tym polityki hierarchiczne), konta usług/tagi, systemy równoważenia obciążenia, Cloud NAT i połączenia hybrydowe.
• Diagnostyka tras oblicza wybrany następny skok (next hop) i zgłasza błędy konfiguracji, takie jak brakujące trasy lub ścieżki asymetryczne.
• Używaj przed i po każdej zmianie w sieci, aby wykryć niezamierzony zasięg wpływu. Narzędzie modeluje płaszczyznę sterowania i nie gwarantuje jakości płaszczyzny danych; łącz je z dowodami w postaci pakietów/metryk.

Performance Dashboard:

• Zarządzany przez Google widok utraty pakietów i opóźnień między regionami oraz do internetowych punktów obserwacyjnych. Przydatny do wykrywania zdarzeń makro (przeciążenie regionalne lub na całej ścieżce) w odróżnieniu od problemów lokalnych dla usługi.

Network Topology:

• Wizualizuje połączenia międzyprojektowe, między-VPC i hybrydowe oraz wolumeny ruchu (wykorzystując logi), aby zidentyfikować gorące punkty (hot spots), nieoczekiwane ścieżki peeringu i zachowania przechodnie, których mogłeś nie zamierzać.

Firewall Insights:

• Wykrywa przesłonięte reguły, niewykorzystane reguły zezwalające, zbyt liberalne źródła oraz reguły bez docelowych tagów/kont usług. Rekomenduje bardziej restrykcyjne reguły w celu zmniejszenia powierzchni ataku bez przerywania znanych przepływów.

Network Analyzer:

• Statyczne i dynamiczne sprawdzanie konfiguracji w różnych projektach w celu wykrycia warunków takich jak:
  • Sprawdzanie poprawności (health checks) blokowane przez zaporę (pamiętaj, aby zezwolić na zakresy źródłowych adresów IP Google dla health-checków).
  • Backendy load balancera w niewłaściwych regionach lub z brakującymi nazwanymi portami.
  • Podsieci z wyłączonym Private Google Access blokujące dostęp do API dla instancji bez

Packet Mirroring, Load Balancery i Telemetria Hybrydowa

Packet Mirroring:

• Dubluje ruch z maszyn wirtualnych do kolektora (urządzenia lub zarządzanego systemu IDS) w celu głębokiej inspekcji. Zakres można określić według podsieci, tagów sieciowych lub kont usług; należy go ograniczyć do wymaganych protokołów, aby kontrolować koszty.
• Narzuty i kompromisy: ruch wychodzący z dublowanych pakietów generuje koszty; nadmierne dublowanie może obciążać kolektory; nie należy bezkrytycznie dublować ruchu w środowisku produkcyjnym. W przypadku incydentów należy używać sesji o ograniczonym czasie trwania i wąskim zakresie.
• Integracja z IDS:
  • Cloud IDS zapewnia zarządzane wykrywanie zagrożeń poza pasmem (out-of-band), wykorzystując Packet Mirroring. Jest to preferowane rozwiązanie ze względu na szybką aktywację i mniejsze wymagania konserwacyjne.
  • Urządzenia IDS innych firm pozostają realną opcją, gdy wymagane są specyficzne sygnatury lub ekosystemy dostawców.

Logi load balancera i dane z kontroli stanu:

• Logi żądań load balancera HTTP(S) zawierają metodę, URL, backend, kod odpowiedzi, opóźnienie oraz adresy IP klienta za pośrednictwem nagłówka X-Forwarded-For. Należy ich używać do analizy ścieżki klienta, ponieważ traceroute zatrzymuje się na Google Front Ends (GFEs).
• Włącz logowanie w usługach backendowych i skonfiguruj próbkowanie (sampling), aby zrównoważyć koszty i widoczność. Włącz logowanie kontroli stanu, aby widzieć wyniki sond i przyczyny awarii.
• Ograniczanie dostępu klienta: egzekwuj na backendach, tagując instancje i tworząc reguły zapory sieciowej, które zezwalają tylko na zatwierdzone zakresy IP klientów oraz adresy IP kontroli stanu Google. W celu mitygacji zagrożeń L7 i stopniowego wdrażania, użyj reguł Cloud Armor w trybie podglądu (preview mode) przed ich wdrożeniem.

Telemetria VPN i Interconnect:

• Metryki Cloud VPN (HA VPN): bajty, odrzucone pakiety (drops), błędy szyfrowania, czas działania tunelu (uptime) i stan sesji BGP. Ustaw alerty na odrzucanie pakietów, częste zdarzenia DPD i niestabilność sesji BGP (flaps).
• Skalowanie przepustowości: dodaj tunele do różnych adresów IP peerów i rozłóż ruch; monitoruj zapas przepustowości (headroom). Jeśli potrzebujesz konfiguracji active/standby między Cloud Routers, preferuj użycie atrybutu MED po stronie on-premise, aby wpłynąć na wybór ścieżki.
• Metryki Interconnect: wykorzystanie na łączu, błędy CRC i dostępność; obserwuj utrzymujące się wykorzystanie na poziomie >60–70% oraz nagłe wzrosty błędów. Utrzymuj zapasową przepustowość i zdywersyfikowane obwody. Badaj wzrosty opóźnień wraz z retransmisjami i wskaźnikami kolejkowania.
• Sygnały nasycenia na brzegu sieci: rosnąca liczba retransmisji TCP, zwiększone opóźnienie 99. percentyla bez zmian w kodzie, zdarzenia przepełnienia portów NAT oraz alerty o zajętości kolejek to wczesne ostrzeżenia o zbliżających się problemach.

Metodologia rozwiązywania problemów, obsługa incydentów i proaktywna niezawodność

Ustrukturyzowane rozwiązywanie problemów od DNS do aplikacji:

1. Zidentyfikuj ścieżkę użytkownika, która zawodzi, oraz okno czasowe; przypisz problem do regionu i ścieżki (publiczna przez LB, prywatna przez VPC lub hybrydowa).
2. DNS:

• Zweryfikuj rozwiązywanie nazw za pomocą logów Cloud DNS, wyniku polecenia dig i zachowania polityk. Sprawdź konflikty typu split-horizon i upewnij się, że polityki przekazywania (forwarding policies) są aktywne.
• Potwierdź wartości TTL i ostatnie zmiany; nieaktualne pamięci podręczne mogą imitować awarie.

3. Load balancer i warstwa brzegowa:

• Przejrzyj logi żądań i kontroli stanu. Skoreluj skoki błędów 5xx ze stanem backendu i zdarzeniami wdrożeniowymi. W przypadku L7 ufaj logom żądań bardziej niż wynikom traceroute.
• Zweryfikuj listy dozwolonych klientów (allowlists) i adresy IP kontroli stanu Google w regułach zapory sieciowej, gdy dostęp jest ograniczony.

4. Routing i zapora sieciowa:

• Użyj Connectivity Tests do deterministycznej oceny płaszczyzny sterowania. Sprawdź obowiązujące trasy (effective routes) i hierarchiczne polityki zapory sieciowej. Szukaj routingu asymetrycznego i przesłoniętych reguł.
• W przypadku odrzuconych pakietów polegaj na logowaniu reguł zapory sieciowej; rozważ dodanie logowanej reguły deny-all blisko końca stosu priorytetów podczas dochodzenia.

5. Ruch wychodzący do API Google:

• Jeśli instancje nie mają zewnętrznych adresów IP, potwierdź działanie Private Google Access i/lub Cloud NAT. Brak któregokolwiek z nich skutkuje sporadycznymi błędami i mylącymi timeoutami.

6. Połączenie hybrydowe:

• Zbadaj metryki Cloud Router oraz VPN/Interconnect. Sesja BGP jest aktywna (up), ale trasy nie są zainstalowane, co może odzwierciedlać preferencje atrybutów; zweryfikuj MED/local-pref i numery ASN. Obserwuj utraty pakietów i problemy z MTU ścieżki.

7. Dowody na poziomie pakietów:

• Jeśli płaszczyzna sterowania wygląda poprawnie, ale objawy nadal występują, użyj Packet Mirroring w wąskim zakresie, aby zebrać dane PCAP w pobliżu problematycznej maszyny wirtualnej lub warstwy; sprawdź czasy SYN/SYN-ACK, retransmisje oraz bity MSS/DF pod kątem czarnych dziur MTU (MTU blackholes).

Obsługa incydentów:

• Bezpieczeństwo zmian: wdrażaj zmiany etapami, ograniczając ich zakres do tagów/kont serwisowych, stosując niższy priorytet i wyłączone reguły; włącz logowanie i testuj za pomocą wdrożeń kanarkowych (canaries). Użyj trybu podglądu (preview) w Cloud Armor dla zmian w politykach L7.
• Wycofanie zmian (Rollback): predefiniuj zmiany odwrotne, przechowuj poprzednie konfiguracje w systemie kontroli wersji i w stosownych przypadkach używaj krótkożyciowych flag funkcji (feature flags) na brzegu aplikacji.
• Analiza poincydentalna: stwórz oś czasu na podstawie logów i metryk, sklasyfikuj czynniki przyczyniające się do problemu (np. zbyt liberalna reguła przesłonięta przez regułę deny, wyczerpanie zasobów NAT), odnotuj luki w wykrywaniu i dodaj zabezpieczenia: alerty, kontrole NIC i wzmocnienie polityk.

Planowanie pojemności i proaktywna niezawodność:

• Śledź docelowe wartości zapasu (headroom): 30–50% na łączach VPN/Interconnect, wykorzystanie portów NAT poniżej 60% w trybie ciągłym, użycie CPU i QPS backendów LB znacznie poniżej progów autoskalowania.
• Twórz metryki oparte na logach dla kluczowych ryzyk: skoki liczby odrzuceń (deny spikes), przepełnienie NAT, liczba niestabilności (flap) sesji BGP, wskaźniki błędów 5xx i błędy połączeń backendów LB. Używaj alertów o tempie zużycia (burn-rate) w wielu oknach czasowych, aby wychwytywać zarówno szybkie, jak i powolne incydenty.
• Monitorowanie syntetyczne: używaj Uptime Checks z wielu regionów dla publicznych punktów końcowych oraz prywatnych sond z testowych maszyn wirtualnych dla usług wewnętrznych.
• Ulepszenia prewencyjne: doprecyzuj reguły zapory sieciowej za pomocą Firewall Insights, rozwiązuj problemy wykryte przez Network Analyzer, skracaj okres agregacji Flow Log podczas szczytowego obciążenia i eksportuj logi do BigQuery w celu cyklicznego wykrywania anomalii.

Praktyczny scenariusz problemu

Firma Contoso Games obsługuje globalne API do gier w regionach us-east1 i europe-west1, zrównoważone za pomocą load balancera HTTP(S), z połączeniem HA VPN do lokalnego centrum danych. Użytkownicy w Europie zgłaszają sporadyczne timeouty i wyższe opóźnienia po niedawnej zmianie w zaporze sieciowej. Instancje nie mają zewnętrznych adresów IP i muszą uzyskiwać dostęp do API Google prywatnie.

Podejście:

1. Ustalenie okna czasowego i wpływu na SLO

• Uzasadnienie: Precyzyjne określenie okna czasowego ogranicza zapytania do odpowiednich logów i dostosowuje dochodzenie do wskaźników SLO mających wpływ na użytkownika. Alert o tempie zużycia (burn-rate) potwierdza szybkie wyczerpywanie budżetu błędu SLO w regionie europe-west1.

2. Weryfikacja płaszczyzny sterowania za pomocą Connectivity Tests

• Uzasadnienie: Utwórz test od frontendu zewnętrznego load balancera HTTP(S) do usługi backendowej w europe-west1 oraz od problematycznych maszyn wirtualnych do wirtualnego adresu IP (VIP) Private Google Access. Test sygnalizuje, że hierarchiczna polityka zapory sieciowej blokuje kontrole stanu do niektórych backendów oraz brak Private Google Access dla jednej z podsieci.

3. Potwierdzenie stanu warstwy brzegowej i backendu za pomocą logów

• Uzasadnienie: Przefiltruj logi żądań load balancera dla europe-west1 z warunkiem response_code >= 500, aby wyizolować błędy backendu. Logi kontroli stanu pokazują niepowodzenia sond pochodzących ze znanych źródłowych adresów IP kontroli stanu Google. Dowodzi to niestabilności backendu (flapping) spowodowanej przez zaporę sieciową, a nie regresji w aplikacji.

4. Przywrócenie prawidłowego działania i zapewnienie bezpieczeństwa poprzez zmiany o ograniczonym zakresie

• Uzasadnienie: Dodaj regułę zezwalającą (allow), skierowaną na tagi backendu, która dopuszcza ruch z zakresów źródłowych adresów IP kontroli stanu. Włącz logowanie dla tej reguły. Ponieważ dostęp jest ograniczony do znanych klientów, zweryfikuj, czy reguła zapory sieciowej na liście dozwolonych (allowlist) zawiera tylko określone zakresy IP klientów oraz zakresy kontroli stanu. Początkowo pozostaw nową regułę wyłączoną, a następnie włącz ją podczas wdrożenia kanarkowego (canary) przy niskim ruchu, aby ograniczyć promień rażenia (blast radius).

5. Ponowne ustanowienie prywatnego ruchu wychodzącego do API Google

• Uzasadnienie: Włącz Private Google Access w problematycznej podsieci, aby instancje bez zewnętrznych adresów IP mogły docierać do usług Google bez zawracania ruchu (hairpinning) przez VPN lub zapory sieciowe firm trzecich. Zmniejsza to opóźnienia i eliminuje wąskie gardło.

6. Sprawdzenie nasycenia połączenia hybrydowego i MTU

• Uzasadnienie: Przejrzyj metryki HA VPN pod kątem utraty pakietów i wykorzystania. Jeden z tuneli wykazuje podwyższoną liczbę utraconych pakietów. Zwiększ przepustowość, dodając drugi tunel do innego adresu IP urządzenia peer w lokalnym centrum danych i rozłóż ruch. Zweryfikuj efektywne MTU i MSS clamp, aby zapobiec czarnym dziurom PMTU (PMTU blackholes) na ścieżce VPN.

7. Użycie trybu podglądu Cloud Armor dla podejrzanych, nadużywających zasobów klientów

• Uzasadnienie: Z logów żądań wynika, że niewielki zbiór adresów IP klientów gwałtownie zwiększa ruch tuż przed awariami sond. Dodaj regułę blokującą (deny) w Cloud Armor w trybie podglądu (preview), aby zweryfikować, czy blokowanie zmniejszyłoby obciążenie backendu przed jej wdrożeniem, unikając przypadkowego wpływu na użytkowników.

8. Użycie Packet Mirroring w wąskim zakresie w celu potwierdzenia zachowania płaszczyzny danych

• Uzasadnienie: Przekieruj ruch z jednej niestabilnej maszyny wirtualnej backendu do Cloud IDS na 15 minut. Dane PCAP pokazują wyczerpanie backlogu SYN podczas gwałtownych wzrostów ruchu od nadużywających zasobów adresów IP, co potwierdza użyteczność polityki Cloud Armor i potrzebę ograniczenia liczby żądań (rate limiting).

9. Zamknięcie incydentu i wzmocnienie zabezpieczeń

• Uzasadnienie: Po włączeniu reguły zezwalającej na kontrole stanu, potwierdzeniu działania Private Google Access, przeskalowaniu przepustowości VPN i wdrożeniu zweryfikowanej reguły Cloud Armor, wskaźniki błędów wracają do normy. Dodaj dashboardy monitorujące wskaźnik powodzenia kontroli stanu, wykorzystanie portów NAT, utraty pakietów VPN oraz liczbę błędów 5xx dla każdego regionu. Utwórz alerty oparte na logach dotyczące odrzuceń przez zaporę sieciową dla tagów backendu oraz alerty o tempie zużycia budżetu błędu SLO (burn-rate). Zarejestruj incydent, jego główne przyczyny (zmiana w hierarchicznej zaporze sieciowej; nadużywający ruch; nasycenie VPN) i dodaj kontrole Network Analyzer oraz Firewall Insights do listy kontrolnej przed wprowadzeniem zmian.

Ta sekwencja demonstruje bezpieczny, oparty na dowodach proces pracy: potwierdź stan płaszczyzny sterowania, obserwuj płaszczyznę danych, zastosuj minimalne, odwracalne zmiany, a następnie zinstytucjonalizuj wnioski poprzez alerty i zautomatyzowane kontrole.

← GKE · Wszystkie domeny · Automatyzacja sieci →

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

Przeglądaj Google →