Google PCA: Niezawodność, odtwarzanie po awarii i ciągłość działania — 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

Niezawodność, odzyskiwanie po awarii (DR) i ciągłość działania zapewniają, że usługi nadal spełniają uzgodnione cele pomimo awarii komponentów, stref czy regionów. W Google Cloud niezawodność jest projektowana poprzez zrozumienie domen awarii (strefowych, regionalnych i globalnych), definiowanie celów odzyskiwania (RTO/RPO), wybór odpornych architektur usług (np. aktywny-aktywny) oraz rygorystyczne testowanie planów odzyskiwania. Twój projekt musi odwzorowywać krytyczność usług na jawne cele dostępności, gwarancje trwałości i zweryfikowane ścieżki odzyskiwania, równoważąc dostępność, spójność, koszty i złożoność operacyjną. Kluczowe zagadnienia obejmują izolowanie pojedynczych punktów awarii, wykorzystywanie zarządzanej replikacji tam, gdzie to możliwe, automatyzację decyzji o przełączaniu awaryjnym (failover) oraz ciągłą weryfikację, czy założenia sprawdzają się w warunkach zbliżonych do produkcyjnych.

Domeny awarii, lokalizacje i usługi wieloregionalne

Strefy dostępności i regiony:
- Strefy to niezależne domeny awarii w obrębie jednego regionu. Awarie strefowe to najczęstsze zdarzenia na dużą skalę, na które projektujesz rozwiązania.
- Regiony to zbiory stref połączone łączami o niskim opóźnieniu. Awarie regionalne są rzadsze, ale muszą być brane pod uwagę w przypadku systemów o wysokiej krytyczności.
- Wzorce projektowe:
  - Wewnątrz regionu: Umieść bezstanowe zasoby obliczeniowe w co najmniej dwóch strefach za pomocą regionalnych zarządzanych grup instancji (MIG).
  - Między regionami: Replikuj stan i przełączaj ruch w trybie awaryjnym dla krytycznych usług, które nie mogą tolerować utraty regionu.
Usługi wieloregionalne i globalne:
- Globalne płaszczyzny sterowania: Sieci VPC, Cloud DNS, globalne zewnętrzne równoważenie obciążenia HTTP(S) i Cloud IAM to usługi o zasięgu globalnym, używane do zmniejszenia powiązań między regionami.
- Umiejscowienie płaszczyzny danych ma znaczenie:
  - Cloud Storage: wybieraj zasobniki (buckets) regionalne, dwuregionalne lub wieloregionalne, dostosowane do wzorców dostępu i potrzeb DR.
  - BigQuery: zbiory danych znajdują się w regionie lub w lokalizacji wieloregionalnej; opcja wieloregionalna poprawia dostępność powierzchni analitycznej, ale należy wziąć pod uwagę rezydencję danych i ruch wychodzący (egress) przy zewnętrznych złączeniach.
  - Spanner: konfiguracja instancji (regionalna lub wieloregionalna) definiuje topologię replik i zachowanie spójności.
Analiza domen awarii:
- Odwzoruj każdy komponent na jego zasięg rażenia (blast radius). Przykłady:
  - Strefowy: pojedyncza maszyna wirtualna, strefowa pula węzłów GKE, strefowy dysk SSD PD.
  - Regionalny: główna instancja i replika Cloud SQL HA mają zasięg regionalny; niektóre zdarzenia konserwacyjne mogą wpłynąć na cały region.
  - Globalny: błędnie skonfigurowany IAM lub Cloud DNS wpływa na wszystkie regiony.
- Zidentyfikuj skorelowane awarie, takie jak współdzielone zależności (np. jedna brama NAT, jedna instancja Memorystore) lub ryzyko wywołane przez człowieka (współdzielone konto serwisowe, pojedynczy stan Terraform).
- Traktuj limity (quotas) jako domeny awarii; autoscaler, który osiąga regionalny limit, jest funkcjonalnie niedostępny.

Kompromisy:

Replikacja między strefami skraca czas przestoju, ale zwiększa ruch między strefami i koszty.
Projekty międzyregionalne zmniejszają RTO, ale zwiększają opóźnienia, złożoność i wydatki.
Globalne równoważenie obciążenia anycast upraszcza przełączanie awaryjne, ale maskuje niesprawne backendy tylko wtedy, gdy kontrole stanu (health checks) są precyzyjne.

Cele, mapowanie zależności i walidacja DR

RTO i RPO:
- Recovery Time Objective (RTO): docelowy czas na przywrócenie usługi. Determinuje głębokość automatyzacji, postawę zasobów zapasowych (standby) i szczegółowość instrukcji operacyjnych (runbook).
- Recovery Point Objective (RPO): akceptowalne okno utraty danych. Determinuje wybór replikacji i częstotliwość tworzenia kopii zapasowych.
Krytyczność usług i kategoryzacja:
- Zdefiniuj poziomy (np. Poziom 0: wpływ na bezpieczeństwo/finanse; Poziom 1: przychody; Poziom 2: narzędzia wewnętrzne) z docelowymi SLO, RTO/RPO i częstotliwością testowania.
- Powiąż wydatki i złożoność z poziomem; nie każda usługa wymaga konfiguracji międzyregionalnej.
Mapowanie zależności:
- Zrób inwentaryzację zależności nadrzędnych i podrzędnych: tożsamość (Cloud IAM, SAML IdP), sekrety (Secret Manager, KMS), sieć (DNS, Cloud Interconnect/VPN), pamięć masowa i bazy danych, obserwowalność, CI/CD oraz API firm trzecich.
- Udokumentuj region, strefę i SLA dla każdej zależności; zdefiniuj mechanizmy kompensacyjne dla słabszych ogniw.
Plany odzyskiwania:
- Twórz instrukcje operacyjne (runbooks) i automatyzację do przełączania awaryjnego (failover)/powrotu po awarii (failback), przywracania danych i promowania konfiguracji (DNS, backendy load balancera, zapora sieciowa).
- Przygotuj z wyprzedzeniem uprawnienia i konta serwisowe; przygotuj definicje infrastruktury, aby wyeliminować ręczne etapy zatwierdzania.
- Utrzymuj dostęp awaryjny (break-glass) z możliwością audytowalnego podniesienia uprawnień.
Testowanie odzyskiwania:
- Planuj rutynowe przełączenia awaryjne dla systemów stanowych (np. Cloud SQL HA), aby zweryfikować proces promowania repliki i renegocjacji połączeń.
- Przeprowadzaj dni testowe (game days), które symulują awarię strefy lub regionu; uwzględnij dostawców nadrzędnych oraz awarie IAM/KMS.
- Używaj wstrzykiwania błędów (fault injection) do walidacji wyłączników bezpieczeństwa (circuit breakers), limitów czasu (timeouts) i ponownych prób; weryfikuj, czy autoskalowanie i mechanizmy przeciwciśnienia (backpressure) działają zgodnie z zamierzeniami.
- Ciągle mierz RTO/RPO podczas testów; dostosowuj architekturę, gdy cele nie są osiągane.

Odporne wzorce dla zasobów obliczeniowych, baz danych i pamięci masowej

Samonaprawiające się zasoby obliczeniowe z regionalnymi grupami MIG i równoważeniem obciążenia:
- Używaj regionalnych grup MIG do dystrybucji instancji pomiędzy strefami z wykorzystaniem autoskalowania i automatycznego naprawiania.
- Użyj globalnego zewnętrznego load balancera HTTP(S) jako front-endu oraz kontroli stanu usługi backendowej (health check) odzwierciedlającej rzeczywistą gotowość (np. /healthz sprawdzający zależności).
- Zezwalaj na kontrole stanu w zaporach sieciowych, aby uniknąć ciągłego restartowania maszyn wirtualnych:

    gcloud compute firewall-rules create allow-lb-health-checks \
      --network=prod-vpc --action=ALLOW --direction=INGRESS \
      --rules=tcp:80,tcp:443 \
      --source-ranges=130.211.0.0/22,35.191.0.0/16 \
      --target-tags=web-backend
    ```

  - Unikaj stanu lokalnego; eksternalizuj sesje do Memorystore lub baz danych; używaj opróżniania połączeń (connection draining) na backendach, aby zachować przetwarzane żądania podczas skalowania w dół.
  - Typowe przyczyny awarii: niedopasowane kontrole stanu (sprawdzające zbyt wiele lub zbyt mało), brakujące reguły zapory sieciowej oraz bootstrapping zależny od niedziałających usług podrzędnych.
- Odporność Cloud SQL:
  - Wysoka dostępność: instancja podstawowa i zapasowa (standby) w oddzielnych strefach z synchroniczną replikacją dysku i automatycznym przełączaniem awaryjnym (failover); wybierz okno konserwacyjne i testuj przełączenia awaryjne.
  - Repliki do odczytu: dodaj repliki do odczytu w tym samym regionie lub w innym regionie, aby odciążyć operacje odczytu i zmniejszyć RTO w przypadku zdarzeń regionalnych; promuj repliki podczas odtwarzania po awarii (DR).
  - Kopie zapasowe i PITR:
    - Włącz automatyczne codzienne kopie zapasowe i odzyskiwanie do punktu w czasie (PITR) za pomocą logów binarnych/transakcyjnych z retencją wystarczającą do spełnienia wymogów zgodności i RPO.
    - Weryfikuj odtwarzanie kopii zapasowych w środowisku nieprodukcyjnym oraz przećwicz procedury promowania replik i aktualizacji parametrów połączenia (connection string) w aplikacji.
  - Sieć: preferuj prywatny adres IP dla środowiska produkcyjnego; upewnij się, że testy przełączania awaryjnego weryfikują zachowanie DNS i puli połączeń.
  - Wskazówka operacyjna: okresowo wykonuj kontrolowane przełączenie awaryjne, aby zweryfikować, czy pule połączeń aplikacji ponownie nawiązują połączenie bez błędów.

gcloud sql instances failover prod-sql
```

Konfiguracja i odporność Spanner:
- Instancje regionalne zapewniają niskie opóźnienia oraz silnie spójne odczyty/zapisy w obrębie regionu, używając protokołu Paxos pomiędzy strefami.
- Instancje wieloregionalne replikują dane pomiędzy regionami z synchronicznymi zapisami kworum (silna spójność globalna) i opcjonalnymi replikami tylko do odczytu; wybierz region wiodący (leader region) blisko źródeł zapisu.
- Kompromisy: konfiguracja wieloregionalna poprawia RTO/RPO i dostępność odczytu, ale zwiększa opóźnienie zapisu i koszt. Używaj jej dla globalnie rozproszonych obciążeń z dużą liczbą zapisów, wymagających silnej spójności; w przeciwnym razie rozważ regionalny Spanner lub Cloud SQL z replikami.
Wzorce trwałości i odzyskiwania danych w Cloud Storage:
- Strategia lokalizacji: regionalna dla bliskości zasobów obliczeniowych, podwójny region (dual-region) dla konfiguracji active-active w dwóch regionach, wieloregionowa (multi-region) dla szerokiej dostępności dla użytkowników globalnych.
- Wersjonowanie: włącz wersjonowanie obiektów, aby umożliwić odzyskiwanie po usunięciu lub uszkodzeniu; połącz z regułami cyklu życia (lifecycle rules) w celu zarządzania kosztami.
- Retencja: stosuj zasady przechowywania na poziomie zasobnika (bucket) i, jeśli to wymagane, blokady retencji (retention locks) w celu zapewnienia zgodności; używaj blokad opartych na zdarzeniach (event-based holds) do zarządzania dokumentacją.
- Wzorce tworzenia kopii zapasowych: zasobniki w innym projekcie z oddzielnym administratorem ograniczają ryzyko przypadkowego usunięcia i eskalacji uprawnień. W przypadku baz danych eksportuj logiczne kopie zapasowe do Cloud Storage w oddzielnym projekcie.
- Przykładowa reguła cyklu życia usuwająca wersje starsze niż 90 dni:

    {
      "rule": [
        {
          "action": { "type": "Delete" },
          "condition": { "age": 90, "isLive": false }
        }
      ]
    }
    ```

    Zastosuj za pomocą:

gsutil lifecycle set lifecycle.json gs://prod-backups
```

Odzyskiwanie: utrzymuj katalogi krytycznych obiektów i testuj ich odtwarzanie; w przypadku dużych zbiorów danych, odtwarzaj je do tymczasowych zasobników, aby uniknąć kolizji nazw i zweryfikować integralność.

Zarządzanie ruchem, strategie wieloośrodkowe i ciągła odporność

Strategie wieloośrodkowe:
- Active-active: obsługa ruchu z wielu regionów jednocześnie; wymaga symetrycznej replikacji danych i zapisów bezkonfliktowych. Najlepsze RTO/RPO; najwyższy koszt i złożoność.
- Active-passive: gorący ośrodek główny (primary) i gotowy ośrodek zapasowy (secondary); dane replikowane w sposób ciągły, ruch przełączany w przypadku awarii. Dobra równowaga między kosztem a RTO.
- Warm standby: przeskalowany w dół ośrodek zapasowy z wstępnie zsynchronizowanymi danymi; wymaga przeskalowania w górę podczas przełączania awaryjnego (failover); umiarkowane RTO i koszt.
- Pilot light: minimalna replikacja krytycznych danych i definicje infrastruktury; większość komponentów jest udostępniana podczas przełączania awaryjnego; długie RTO, niski koszt stały.
- Cold standby: tylko okresowe kopie zapasowe; odtwarzanie w przypadku awarii; najdłuższe RTO, najniższy koszt.
Przełączanie awaryjne (failover) za pomocą DNS i zarządzania ruchem:
- Preferuj routing oparty na kontroli kondycji (health checks) na warstwie 7 przy użyciu globalnego zewnętrznego load balancera HTTP(S). Wykonuje on kontrole kondycji dla każdego backendu i przenosi ruch z dala od niezdrowych stref lub regionów bez zmian w DNS.
- Używaj rekordów DNS z niskim TTL tylko jako zgrubnego mechanizmu przełączania awaryjnego lub do przełączania między rozłącznymi adresami VIP load balancerów; pamiętaj, że buforowanie DNS oznacza, że przełączenie awaryjne nie jest natychmiastowe.
- Dla usług prywatnych używaj Internal HTTP(S) Load Balancing z regionalnymi wzorcami przełączania awaryjnego oraz prywatnego DNS, który w razie potrzeby możesz aktualizować programowo.
Wzorce łagodnej degradacji (graceful degradation):
- Implementuj flagi funkcji (feature flags) do wyłączania niekrytycznych funkcjonalności pod obciążeniem.
- Używaj wyłączników awaryjnych (circuit breakers), limitów czasu (timeouts), ponowień z losowym opóźnieniem (jitter) i grodzi (bulkheads) do lokalizowania awarii.
- Zapewnij tryb tylko do odczytu, gdy ścieżki zapisu są uszkodzone; kolejkowanie zapisów do późniejszego uzgodnienia.
- Ograniczaj liczbę żądań od klientów (rate-limiting) i stosuj mechanizm przeciwciśnienia (backpressure), aby zapobiegać awariom kaskadowym.
Testowanie chaosu (chaos testing) i ciągłe doskonalenie:
- Wstrzykiwanie błędów (fault injection) na warstwie sieciowej (opóźnienia, utrata pakietów) i aplikacyjnej weryfikuje, czy mechanizmy odpornościowe uruchamiają się zgodnie z projektem.
- Dni testowe (Game days) wdrażają procedury odzyskiwania w zespołach; obejmują one powiadamianie, wykonywanie scenariuszy odzyskiwania (runbooks) i analizy poawaryjne (postmortems) z konkretnymi działaniami naprawczymi.
- Śledź budżety błędów i wskaźniki SLO; dostosowuj pojemność, strategie ponowień i konfiguracje replikacji w miarę napływu danych.
Kompromisy między dostępnością, spójnością, kosztem i złożonością:
- Dostępność a spójność: silna spójność globalna (np. Spanner multi-regional) może zwiększać opóźnienia zapisu; spójność ostateczna (eventual consistency, np. repliki asynchroniczne) może poprawić opóźnienia, ale wiąże się z ryzykiem nieaktualnych odczytów.
- Koszt a RTO/RPO: przechowywanie danych w dwóch regionach i bazy danych wieloregionalne zwiększają wydatki, ale minimalizują utratę danych i przestoje.
- Złożoność a niezawodność: każdy mechanizm przełączania awaryjnego, strumień replikacji i reguła routingu muszą być obsługiwane i testowane; utrzymuj projekty tak proste, jak to konieczne do osiągnięcia celów.

Praktyczny scenariusz problemowy

Acme Tickets, szybko rozwijająca się firma zajmująca się sprzedażą biletów online, musi zapewnić ciągłość działania podczas awarii regionalnych dla swojego API zakupowego i katalogu wydarzeń, utrzymując jednocześnie rygorystyczne RTO/RPO (RTO ≤ 5 minut, RPO ≤ 1 minuta). Stos technologiczny obejmuje bezstanowe mikroserwisy, relacyjną bazę danych zamówień, potok analityczny oraz statyczne zasoby multimedialne.

Zdefiniuj poziomy usług (service tiers), wskaźniki SLO i cele odzyskiwania (recovery objectives)

Uzasadnienie: Sklasyfikuj API zakupowe i bazę danych zamówień jako Tier 0 (RTO 5 min, RPO 1 min), katalog jako Tier 1 (RTO 15 min, RPO 5 min), a analitykę jako Tier 2 (best effort). To dostosowuje koszt i złożoność do wpływu na biznes.

Wybierz rozmieszczenie regionalne i strategię wieloośrodkową

Uzasadnienie: Wdróż architekturę active-active w regionach us-central1 i us-east1 dla usług bezstanowych, aby zminimalizować RTO; użyj architektury active-passive dla bazy danych zamówień, aby zrównoważyć opóźnienia zapisu i koszt.

Zaimplementuj regionalne grupy MIG i globalny load balancing HTTP(S)

Uzasadnienie: Dwie regionalne grupy MIG (jedna na region), rozłożone na co najmniej dwie strefy każda. Pojedynczy globalny adres VIP anycast kieruje ruch przez usługi backendowe z kontrolą kondycji, automatycznie wykluczając regiony, które przestały odpowiadać.

Eksternalizuj stan i skonfiguruj samonaprawę (self-healing)

Uzasadnienie: Przechowuj sesje w Memorystore z replikami do odczytu w innym regionie dla katalogu i utrzymuj usługi jako bezstanowe, aby autoleczenie MIG i aktualizacje stopniowe (rolling updates) były bezpieczne. Kontrole kondycji wskazują na /healthz, który weryfikuje krytyczne usługi podrzędne (downstreams).

Udostępnij Cloud SQL for PostgreSQL z wysoką dostępnością (HA) i repliką do odczytu w innym regionie

Uzasadnienie: Użyj HA w regionie głównym dla odporności na poziomie strefy i włącz PITR (Point-In-Time Recovery) z wystarczającym okresem przechowywania. Utwórz replikę do odczytu w regionie zapasowym oraz przetestowany scenariusz (runbook) do jej promocji w przypadku awarii regionalnej, spełniając RPO ≤ 1 minuta przy minimalnej utracie zapisów.

Zaplanuj rutynowe testy przełączania awaryjnego bazy danych

Uzasadnienie: Przeprowadzaj comiesięczne kontrolowane przełączenia awaryjne, aby zweryfikować zachowanie aplikacji podczas ponownego łączenia i promocję repliki. Rozwiązuje to częsty problem, w którym repliki nigdy nie są promowane podczas rzeczywistych incydentów.

Umieść statyczne multimedia w zasobniku (bucket) Cloud Storage typu dual-region z włączonym wersjonowaniem i przechowywaniem

Uzasadnienie: Typ dual-region zapewnia dostępność obiektów w dwóch regionach; wersjonowanie chroni przed przypadkowym nadpisaniem/usunięciem. Zastosuj reguły cyklu życia (lifecycle rules), aby wygaszać stare wersje i kontrolować koszty.

Zabezpiecz kontrole kondycji i ruch wychodzący (egress) za pomocą zapory sieciowej i limitów (quotas)

Uzasadnienie: Utwórz jawne reguły zapory sieciowej dla kontroli kondycji load balancera i monitoruj regionalne limity instancji, aby zapobiec zablokowaniu autoskalera podczas przełączania awaryjnego.

Zaimplementuj DNS jako zgrubny mechanizm kontroli z niskim TTL

Uzasadnienie: Chociaż globalny load balancer obsługuje routing oparty na kondycji, utrzymuj rekord A z niskim TTL wskazujący na zapasowy adres VIP na potrzeby awaryjnego, ręcznego przełączenia, mając na uwadze ograniczenia buforowania DNS.

Zautomatyzuj scenariusze odzyskiwania po awarii (DR runbooks) i weryfikuj je podczas dni testowych (game days)

Uzasadnienie: Użyj Cloud Scheduler do wyzwalania syntetycznego ruchu i wskaźników SLO w Cloud Monitoring, aby potwierdzić zachowanie podczas kwartalnych dni testowych z wstrzykniętymi błędami (np. blokowanie ruchu międzyregionalnego, zamykanie węzłów). Zbieraj metryki RTO/RPO i udoskonalaj procedury.

Zabezpiecz i oddziel kopie zapasowe

Uzasadnienie: Eksportuj codzienne logiczne kopie zapasowe bazy danych zamówień do zasobnika Cloud Storage w osobnym projekcie z blokadami przechowywania (retention locks); okresowo odtwarzaj je na instancji przejściowej (staging), aby zweryfikować integralność i czas odtworzenia.

Zaimplementuj łagodną degradację

Uzasadnienie: Jeśli baza danych zamówień ulegnie degradacji, przełącz katalog w tryb tylko do odczytu, kolejkowanie zapisów do późniejszego uzgodnienia i odrzuć niekrytyczne funkcje. Zapobiega to awariom kaskadowym i utrzymuje częściową funkcjonalność usługi.

Ta architektura zapewnia zautomatyzowane regionalne przełączanie awaryjne dla usług bezstanowych, kontrolowane i przetestowane przełączanie awaryjne dla komponentów stanowych oraz zweryfikowane procesy odzyskiwania, które spełniają cele ciągłości biznesowej Acme Tickets.

← Bezpieczeństwo · Wszystkie domeny · Migracja →

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