Google PCA: Güvenilirlik, Felaket Kurtarma ve İş Sürekliliği — Çalışma kılavuzu

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

Şunun bir parçası: Google Professional Cloud Architect — Çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: Google sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

Genel Bakış

Güvenilirlik, felaket kurtarma (DR) ve iş sürekliliği; hizmetlerin bileşen, zone veya bölge arızalarına rağmen üzerinde anlaşılan hedefleri karşılamaya devam etmesini sağlar. Google Cloud’da güvenilirlik; hata etki alanlarını (zonal, bölgesel ve küresel) anlayarak, kurtarma hedeflerini (RTO/RPO) tanımlayarak, dayanıklı hizmet mimarilerini (ör. aktif-aktif) seçerek ve kurtarma planlarını titizlikle test ederek tasarlanır. Tasarımınız, hizmet kritiklik düzeyini; kullanılabilirlik, tutarlılık, maliyet ve operasyonel karmaşıklığı dengeleyerek, açık kullanılabilirlik hedefleri, dayanıklılık garantileri ve doğrulanmış kurtarma yollarıyla eşleştirmelidir. Ana temalar arasında tekil hata noktalarını (single points of failure) izole etmek, mümkün olan yerlerde yönetilen replikasyonu kullanmak, yük devretme (failover) kararlarını otomatikleştirmek ve varsayımların üretim benzeri koşullarda geçerli olduğunu sürekli olarak doğrulamak yer alır.

Hata Etki Alanları, Konumlar ve Çok Bölgeli Hizmetler

Kullanılabilirlik zone’ları ve bölgeleri:
- Zone’lar, bir bölge içindeki bağımsız hata etki alanlarıdır. Zonal arızalar, tasarım yaparken dikkate almanız gereken en yaygın büyük ölçekli olaylardır.
- Bölgeler, düşük gecikmeli bağlantılara sahip zone koleksiyonlarıdır. Bölgesel arızalar daha nadirdir ancak yüksek kritiklikteki sistemler için dikkate alınmalıdır.
- Tasarım desenleri:
  - Bölge içi: Durumsuz (stateless) işlem gücünü, bölgesel yönetilen örnek grupları (regional managed instance groups - MIG’ler) aracılığıyla en az iki zone’a yayın.
  - Bölgeler arası: Bölgesel kayıpları tolere edemeyen kritik hizmetler için durumu (state) çoğaltın ve trafiği başka bir bölgeye yönlendirin (failover).
Çok bölgeli ve küresel hizmetler:
- Küresel kontrol düzlemleri: VPC ağları, Cloud DNS, küresel harici HTTP(S) yük dengeleme ve Cloud IAM, bölgesel bağımlılığı azaltmak için kullanılan küresel kapsamlı hizmetlerdir.
- Veri düzlemi (data-plane) yerleşimi önemlidir:
  - Cloud Storage: erişim desenlerine ve DR ihtiyaçlarına uygun olarak bölgesel, çift bölgeli veya çok bölgeli bucket’lar seçin.
  - BigQuery: veri setleri bir bölgede veya çoklu bölgede bulunur; çoklu bölge, analiz yüzeyinin kullanılabilirliğini artırır ancak harici birleştirmeler (join) için veri yerleşimi (data residency) ve dışa aktarım (egress) maliyetlerini göz önünde bulundurun.
  - Spanner: örnek yapılandırması (bölgesel veya çok bölgeli), replika topolojisini ve tutarlılık davranışını tanımlar.
Hata etki alanı analizi:
- Her bileşeni kendi etki yarıçapıyla (blast radius) eşleştirin. Örnekler:
  - Zonal: tek bir VM, zonal GKE düğüm havuzu, zonal SSD PD.
  - Bölgesel: Cloud SQL HA birincil+yedek sunucuları bölgeseldir; bazı bakım etkinlikleri bir bölgeyi etkileyebilir.
  - Küresel: yanlış yapılandırılmış bir IAM veya Cloud DNS tüm bölgeleri etkiler.
- Paylaşılan bağımlılıklar (ör. tek bir NAT ağ geçidi, tek bir Memorystore örneği) veya insan kaynaklı riskler (paylaşılan hizmet hesabı, tek bir Terraform state dosyası) gibi birbiriyle ilişkili arızaları belirleyin.
- Kotaları da birer hata etki alanı olarak düşünün; bölgesel kota sınırına ulaşan bir otomatik ölçekleyici (autoscaler) işlevsel olarak devre dışı kalmış demektir.

Artıları ve eksileri (Trade-offs):

Zone’lar arası replikasyon kesinti süresini azaltır ancak zone’lar arası trafik ve maliyet ekler.
Bölgeler arası tasarımlar RTO’yu düşürür ancak gecikmeyi, karmaşıklığı ve harcamayı artırır.
Küresel anycast yük dengeleme, yük devretmeyi basitleştirir ancak yalnızca sağlık kontrolleri (health check) hassas ise sağlıksız arka uçları (backend) maskeler.

Hedefler, Bağımlılık Haritalaması ve DR Doğrulaması

RTO ve RPO:
- Kurtarma Süresi Hedefi (RTO): hizmeti geri yüklemek için hedeflenen süre. Otomasyon derinliğini, beklemedeki sistemlerin (standby) duruşunu ve operasyonel kılavuzların (runbook) ayrıntı düzeyini belirler.
- Kurtarma Noktası Hedefi (RPO): kabul edilebilir veri kaybı penceresi. Replikasyon ve yedekleme sıklığı seçimini belirler.
Hizmet kritikliği ve katmanlandırma:
- Hedef SLO’lar, RTO/RPO ve test sıklığı ile katmanlar (ör. Katman 0: güvenlik/finansal etki; Katman 1: gelir; Katman 2: dahili araçlar) tanımlayın.
- Harcamayı ve karmaşıklığı katmana bağlayın; her hizmetin bölgeler arası olmasına gerek yoktur.
Bağımlılık haritalaması:
- Yukarı ve aşağı yönlü bağımlılıkların envanterini çıkarın: kimlik (Cloud IAM, SAML IdP), gizli anahtarlar (Secret Manager, KMS), ağ (DNS, Cloud Interconnect/VPN), depolama ve veritabanları, gözlemlenebilirlik, CI/CD ve üçüncü taraf API’ler.
- Her bağımlılık için bölgeyi, zone’u ve SLA’yı belgeleyin; zayıf halkalar için telafi edici kontroller tanımlayın.
Kurtarma planları:
- Yük devretme/geri dönme (failover/failback), veri geri yükleme ve yapılandırma yükseltme (DNS, yük dengeleyici arka uçları, güvenlik duvarı) için operasyonel kılavuzlar (runbook) ve otomasyon oluşturun.
- İzinleri ve hizmet hesaplarını önceden hazırlayın; manuel onay süreçlerini ortadan kaldırmak için altyapı tanımlarını hazırda bekletin.
- Denetlenebilir yetki yükseltme ile acil durum erişimini (break-glass access) sürdürün.
Kurtarma testi:
- Durum bilgisi olan (stateful) sistemler (ör. Cloud SQL HA) için, birincil sunucuya yükseltmeyi (promotion) ve bağlantının yeniden kurulmasını doğrulamak amacıyla rutin yük devretme (failover) testleri planlayın.
- Zonal veya bölgesel kesintileri simüle eden tatbikatlar (game days) düzenleyin; bu tatbikatlara yukarı yönlü sağlayıcıları ve IAM/KMS arızalarını da dahil edin.
- Devre kesicileri (circuit breaker), zaman aşımlarını ve yeniden denemeleri doğrulamak için hata enjeksiyonu (fault injection) kullanın; otomatik ölçeklendirmenin ve geri basıncın (backpressure) amaçlandığı gibi çalıştığını doğrulayın.
- Testler sırasında RTO/RPO’yu sürekli olarak ölçün; hedefler karşılanmadığında mimariyi ayarlayın.

Dayanıklı İşlem, Veritabanı ve Depolama Desenleri

Bölgesel MIG’ler ve yük dengeleme ile kendi kendini onaran işlem gücü:
- Otomatik ölçeklendirme ve kendi kendini onarma özellikleriyle örnekleri (instance) bölgeler (zone) arasında dağıtmak için bölgesel MIG’ler kullanın.
- Gerçek hazır olma durumuna göre ayarlanmış bir arka uç hizmeti sağlık denetimi (örneğin, /healthz bağımlılıkları kontrol eder) ile küresel bir harici HTTP(S) yük dengeleyiciyi ön uç olarak kullanın.
- Sürekli VM geri dönüşümünü önlemek için güvenlik duvarlarından sağlık denetimlerine izin verin:

    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
    ```

  - Yerel durumdan (local state) kaçının; oturumları (session) Memorystore veya veritabanları gibi harici bir yere taşıyın; küçülme (scale-in) sırasında devam eden istekleri korumak için arka uçlarda bağlantı boşaltmayı (connection draining) kullanın.
  - Yaygın hata modları: yanlış hizalanmış sağlık denetimleri (çok fazla veya çok az kontrol etme), eksik güvenlik duvarı kuralları ve sağlıksız alt sistemlere (downstream) bağlı olan başlangıç (bootstrapping) süreçleri.
- Cloud SQL dayanıklılığı:
  - Yüksek erişilebilirlik: senkron disk replikasyonu ve otomatik yük devretme (failover) ile ayrı bölgelerde (zone) birincil (primary) ve yedek (standby) sunucular; bir bakım aralığı seçin ve yük devretmeleri test edin.
  - Okuma replikaları (Read replica): okuma işlemlerinin yükünü azaltmak ve bölgesel olaylar için RTO'yu düşürmek amacıyla aynı bölgeye veya bölgeler arasına okuma replikaları ekleyin; DR (Felaket Kurtarma) sırasında replikaları terfi ettirin (promote).
  - Yedeklemeler ve PITR:
    - Uyumluluk ve RPO için yeterli saklama süresine sahip ikili/işlem günlükleri (binary/transaction logs) aracılığıyla otomatik günlük yedeklemeleri ve belirli bir zamana geri dönmeyi (point-in-time recovery - PITR) etkinleştirin.
    - Geri yüklemeleri üretim dışı ortamlarda doğrulayın ve terfi prosedürleri ile uygulama bağlantı dizisi (connection string) güncellemelerinin provasını yapın.
  - Ağ: üretim için özel IP'yi (private IP) tercih edin; yük devretme testlerinin DNS/bağlantı havuzu (connection pooling) davranışını doğruladığından emin olun.
  - Operasyonel ipucu: uygulama havuzlarının (application pool) temiz bir şekilde yeniden bağlandığını doğrulamak için periyodik olarak kontrollü bir yük devretme gerçekleştirin.

gcloud sql instances failover prod-sql
```

Spanner yapılandırması ve dayanıklılığı:
- Bölgesel örnekler (Regional instance), bölgeler (zone) arasında Paxos kullanarak bir bölge içinde düşük gecikmeli, güçlü tutarlılığa (strongly consistent) sahip okuma/yazma işlemleri sağlar.
- Çok bölgeli örnekler (Multi-regional instance), senkron yeterli çoğunlukla yazma (synchronous quorum writes) (güçlü küresel tutarlılık) ve isteğe bağlı salt okunur replikalar ile bölgeler arasında replikasyon yapar; yazma işlemlerini yapanlara yakın bir lider bölge (leader region) seçin.
- Artıları ve eksileri: çok bölgeli yapı, RTO/RPO’yu ve okuma erişilebilirliğini iyileştirir ancak yazma gecikmesini ve maliyeti artırır. Güçlü tutarlılığa ihtiyaç duyan, küresel olarak dağıtılmış, yazma yoğun iş yükleri için kullanın; aksi takdirde bölgesel Spanner veya replikalı Cloud SQL’i değerlendirin.
Cloud Storage dayanıklılığı ve kurtarma desenleri:
- Konum stratejisi: işlem gücüne yakınlık (compute-locality) için bölgesel (regional), iki bölge arasında aktif-aktif için çift bölgeli (dual-region), küresel kullanıcılara geniş erişilebilirlik için çok bölgeli (multi-region).
- Sürüm oluşturma (Versioning): silinme veya bozulma durumunda kurtarma yapmak için nesne sürüm oluşturmayı etkinleştirin; maliyetleri yönetmek için yaşam döngüsü kurallarıyla (lifecycle rules) birleştirin.
- Saklama (Retention): bucket düzeyinde saklama politikaları (retention policies) ve gerekirse uyumluluk için saklama kilitleri (retention locks) uygulayın; kayıt yönetimi için olaya dayalı bekletmeleri (event-based holds) kullanın.
- Yedekleme desenleri: projeler arası, ayrı yöneticiye sahip bucket’lar, yanlışlıkla silmeyi ve ayrıcalık yükseltmeyi (privilege escalation) azaltır. Veritabanları için, mantıksal yedekleri (logical backups) farklı bir projedeki Cloud Storage’a dışa aktarın.
- 90 günden eski sürümleri silmek için örnek yaşam döngüsü kuralı:

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

    Uygulamak için:

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

Kurtarma: kritik nesnelerin kataloglarını tutun ve geri yüklemeleri test edin; büyük veri setleri için, isim çakışmalarını önlemek ve bütünlüğü doğrulamak amacıyla geri yüklemeleri geçici bucket’lara aşamalı olarak yapın.

Trafik Yönetimi, Çoklu Saha Stratejileri ve Sürekli Dayanıklılık

Çoklu saha stratejileri:
- Aktif-aktif: trafiğe aynı anda birden fazla bölgeden hizmet verilir; simetrik veri replikasyonu ve çakışmasız yazma işlemleri gerektirir. En iyi RTO/RPO; en yüksek maliyet ve karmaşıklık.
- Aktif-pasif: sıcak bir birincil ve hazır bir ikincil bölge bulunur; veriler sürekli olarak çoğaltılır, arıza durumunda trafik yönlendirilir. Maliyet ve RTO arasında iyi bir denge sunar.
- Ilık yedek: önceden senkronize edilmiş verilere sahip, küçültülmüş bir ikincil bölge; yük devretme sırasında ölçek büyütme gerektirir; orta düzeyde RTO ve maliyet.
- Pilot ışığı: minimum düzeyde kritik veri replikasyonu ve altyapı tanımları; bileşenlerin çoğu yük devretme sırasında sağlanır; uzun RTO, düşük sabit maliyet.
- Soğuk yedek: yalnızca periyodik yedeklemeler; arıza durumunda yeniden oluşturma; en uzun RTO, en düşük maliyet.
DNS ve trafik yönetimi yük devretme:
- Genel harici HTTP(S) yük dengeleyici ile Katman 7’de sağlık durumuna dayalı yönlendirmeyi tercih edin. Bu, arka uç başına sağlık kontrolleri yapar ve DNS değişikliği olmadan trafiği sağlıksız bölgelerden veya coğrafyalardan uzaklaştırır.
- Düşük TTL’li DNS kayıtlarını yalnızca kaba bir yük devretme kontrolü olarak veya birbirinden bağımsız yük dengeleyici VIP’leri arasında geçiş yapmak için kullanın; DNS önbelleklemenin, yük devretmenin anlık olmadığı anlamına geldiğini unutmayın.
- Özel hizmetler için, bölgesel yük devretme kalıpları ile birlikte Internal HTTP(S) Load Balancing ve gerektiğinde programatik olarak güncelleyebileceğiniz özel DNS kullanın.
Zarif indirgeme kalıpları:
- Stres altında kritik olmayan işlevleri devre dışı bırakmak için özellik bayrakları (feature flags) uygulayın.
- Arızaları yerelleştirmek için devre kesiciler (circuit breakers), zaman aşımları (timeouts), jitter ile yeniden denemeler ve bulkhead’ler kullanın.
- Yazma yolları bozulduğunda salt okunur mod sağlayın; yazma işlemlerini daha sonra mutabakat için bir kuyruğa alın.
- Zincirleme arızaları önlemek için istemcilere hız sınırı (rate-limit) uygulayın ve geri basınç (backpressure) uygulayın.
Kaos testi ve sürekli iyileştirme:
- Ağ (gecikme, paket kaybı) ve uygulama katmanlarında hata enjeksiyonu (fault injection), dayanıklılık kontrollerinin tasarlandığı gibi tetiklendiğini doğrular.
- Oyun günleri (game days), ekipler arasında kurtarma süreçlerini operasyonelleştirir; çağrı gönderme, runbook çalıştırma ve somut düzeltici eylemlerle postmortem’leri içerir.
- Hata bütçelerini (error budgets) ve SLO’ları takip edin; verilerin gerektirdiği şekilde kapasiteyi, yeniden deneme stratejilerini ve replikasyon yapılandırmalarını ayarlayın.
Kullanılabilirlik, tutarlılık, maliyet ve karmaşıklık arasındaki ödünleşimler:
- Kullanılabilirlik ve tutarlılık: güçlü küresel tutarlılık (ör. Spanner çoklu bölge) yazma gecikmesini artırabilir; nihai tutarlılık (ör. asenkron replikalar) gecikmeyi iyileştirebilir ancak güncel olmayan okuma riski taşır.
- Maliyet ve RTO/RPO: çift bölgeli depolama ve çok bölgeli veritabanları harcamayı artırır ancak veri kaybını ve kesinti süresini en aza indirir.
- Karmaşıklık ve güvenilirlik: her yük devretme mekanizması, replikasyon akışı ve yönlendirme kuralı işletilmeli ve test edilmelidir; hedeflere ulaşmak için tasarımları gerektiği kadar basit tutun.

Pratik Problem Senaryosu

Hızla büyüyen bir çevrimiçi biletleme şirketi olan Acme Tickets, satın alma API’si ve etkinlik kataloğu için bölgesel kesintiler sırasında sürekli operasyonları sağlamalı ve sıkı RTO/RPO hedeflerini (RTO ≤ 5 dakika, RPO ≤ 1 dakika) korumalıdır. Sistem yığını, durum bilgisi olmayan (stateless) mikro hizmetler, ilişkisel bir sipariş veritabanı, bir analiz işlem hattı ve statik medya varlıklarını içerir.

Hizmet katmanlarını, SLO’ları ve kurtarma hedeflerini tanımlayın

Gerekçe: Satın alma API’sini ve sipariş DB’sini Katman 0 (RTO 5dk, RPO 1dk), kataloğu Katman 1 (RTO 15dk, RPO 5dk) ve analitiği Katman 2 (en iyi çaba) olarak sınıflandırın. Bu, maliyet ve karmaşıklığı iş etkisine göre hizalar.

Bölgesel yerleşimi ve çoklu saha stratejisini seçin

Gerekçe: RTO’yu en aza indirmek için durum bilgisi olmayan hizmetler için us-central1 ve us-east1 arasında aktif-aktif dağıtım yapın; yazma gecikmesi ve maliyeti dengelemek için sipariş veritabanı için aktif-pasif kullanın.

Bölgesel MIG’leri ve genel HTTP(S) yük dengelemeyi uygulayın

Gerekçe: Her biri en az iki zone’a yayılmış iki bölgesel MIG (her bölge için bir tane). Tek bir genel anycast VIP, trafiği sağlık kontrolü yapılan arka uç hizmetleri aracılığıyla yönlendirir ve sağlıksız bölgeleri otomatik olarak devre dışı bırakır.

Durumu dışsallaştırın ve kendi kendini iyileştirmeyi yapılandırın

Gerekçe: Oturumları katalog için bölgeler arası okuma replikaları ile Memorystore’da saklayın ve hizmetleri durum bilgisi olmayan (stateless) tutun, böylece MIG otomatik iyileştirme ve aşamalı güncellemeler güvenli olur. Sağlık kontrolleri, kritik alt sistemleri doğrulayan /healthz adresini işaret eder.

HA ve bölgeler arası okuma replikası ile Cloud SQL for PostgreSQL’ü sağlayın

Gerekçe: Bölgesel dayanıklılık için birincil bölgede HA kullanın ve yeterli saklama süresiyle PITR’yi etkinleştirin. İkincil bölgede bölgeler arası bir okuma replikası oluşturun ve bölgesel bir arıza durumunda bu replikayı birincil yapmak için test edilmiş bir runbook hazırlayın. Bu, RPO ≤ 1 dakika hedefini minimum yazma kaybıyla karşılar.

Rutin veritabanı yük devretme testleri planlayın

Gerekçe: Uygulamanın yeniden bağlanma davranışını ve replika yükseltme sürecini doğrulamak için aylık kontrollü yük devretmeler gerçekleştirin. Bu, gerçek olaylar sırasında replikaların hiçbir zaman yükseltilmediği yaygın bir arıza modunu ele alır.

Statik medyayı sürüm oluşturma ve saklama ile çift bölgeli bir Cloud Storage bucket’ına yerleştirin

Gerekçe: Çift bölge, nesne kullanılabilirliğini iki bölgede garanti eder; sürüm oluşturma, kazara üzerine yazmalara/silmelere karşı koruma sağlar. Eski sürümleri sonlandırmak ve maliyeti kontrol etmek için yaşam döngüsü kuralları uygulayın.

Sağlık kontrollerini ve çıkış trafiğini güvenlik duvarı ve kotalarla koruyun

Gerekçe: Yük dengeleyici sağlık kontrolleri için açık güvenlik duvarı kuralları oluşturun ve yük devretme sırasında otomatik ölçekleyicinin durmasını önlemek için bölgesel örnek kotalarını izleyin.

DNS’i düşük TTL ile kaba bir kontrol olarak uygulayın

Gerekçe: Genel yük dengeleyici sağlık durumuna dayalı yönlendirmeyi yönetirken, acil durum manuel geçişleri için yedek bir VIP’ye işaret eden düşük TTL’li bir A kaydı bulundurun ve DNS önbellek sınırlamalarını anlayın.

Felaket Kurtarma (DR) runbook’larını otomatikleştirin ve oyun günleri aracılığıyla doğrulayın

Gerekçe: Üç aylık oyun günleri sırasında sentetik trafik tetiklemek için Cloud Scheduler’ı ve davranışı doğrulamak için Cloud Monitoring SLO’larını kullanın. Bu oyun günlerinde enjekte edilmiş hatalar (ör. bölgeler arası trafiği engelleme, node’ları sonlandırma) bulunsun. RTO/RPO metriklerini yakalayın ve prosedürleri iyileştirin.

Yedekleri güvence altına alın ve ayırın

Gerekçe: Sipariş DB’sinin günlük mantıksal yedeklerini, saklama kilitleri (retention locks) ile ayrı bir projedeki bir Cloud Storage bucket’ına dışa aktarın; bütünlüğü ve zamanlamayı doğrulamak için periyodik olarak bir hazırlık (staging) örneğine geri yükleyin.

Zarif indirgeme uygulayın

Gerekçe: Sipariş DB’si bozulursa, kataloğu salt okunur moda geçirin, yazma işlemlerini daha sonra mutabakat için kuyruğa alın ve kritik olmayan özellikleri devre dışı bırakın. Bu, zincirleme arızaları önler ve kısmi hizmeti sürdürür.

Bu mimari, durum bilgisi olmayan hizmetler için otomatik bölgesel yük devretme, durum bilgisi olan bileşenler için kontrollü ve test edilmiş yük devretme ve Acme Tickets’ın iş sürekliliği hedeflerini karşılayan doğrulanmış kurtarma süreçleri sunar.

← Güvenlik · Tüm alanlar · Migrasyon →

Bu soruları çözün → · ExamRoll.io’da süreli pratik →