Google PCD: Gözlemlenebilirlik, Hata Ayıklama ve Site Güvenilirlik Operasyonları — Çalışma kılavuzu

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

Şunun bir parçası: Google Professional Cloud Developer — Ç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ış

Google Cloud’da gözlemlenebilirlik, hata ayıklama ve site güvenilirliği operasyonları, sistemleri ölçülebilir, teşhis edilebilir ve dayanıklı hale getirmeye odaklanır. Güçlü bir gözlemlenebilirlik; tutarlı günlük kaydı ve metrikler, dağıtık izleme, eyleme geçirilebilir uyarılar ve disiplinli bir olay müdahalesi gerektirir. Güvenilirlik; hizmet seviyesi göstergeleri ve hedefleri konusunda netlik, titiz sağlık sinyalleri ve üretimden elde edilen içgörüleri mühendislik iyileştirmelerine dönüştüren bir geri bildirim döngüsü talep eder. Bu bölüm, bu yeteneklerin Google Cloud’da uçtan uca nasıl oluşturulacağını ve ödünleşimler ile yaygın hata modları hakkında nasıl akıl yürütüleceğini özetlemektedir.

Günlük Kaydı ve İzleme Temelleri

Cloud Logging

Yapılandırılmış günlükler yayınlayın. Sorguların ve günlüğe dayalı metriklerin sürümler arasında sağlam kalması için kararlı alan adlarına sahip JSON’u tercih edin. Korelasyon için önem derecesi, hizmet adı, sürüm, konum ve bir istek kimliği veya izleme bağlamı ekleyin.
Alanları ayarlayarak günlükleri izlemelerle ilişkilendirin:
- logging.googleapis.com/trace: projects/PROJECT_ID/traces/TRACE_ID
- logging.googleapis.com/spanId: SPAN_ID
- logging.googleapis.com/trace_sampled: true
Bucket’lar ve saklama süresi. _Default bucket’ı genellikle 30 günlük (yapılandırılabilir) bir saklama süresine sahiptir. _Required bucket’ı, daha uzun ve sabit saklama süresine sahip belirli denetim günlüklerini içerir. Veri yerleşimini kontrol etmek için bölgesel bucket’lar oluşturun ve her bucket için özel saklama süresi belirleyin.
Sink’ler. Günlükleri analiz için BigQuery’ye, akış tüketicileri için Pub/Sub’a veya arşivleme için Storage’a yönlendirin. Alt projeleri yakalamak için klasör veya kuruluş düzeyinde toplu sink’ler kullanın.
Sorgular. resource.type, etiketler, jsonPayload, httpRequest veya textPayload’a göre filtrelemek için Logging sorgu dilini kullanın.

Örnekler:

Yapılandırılmış günlük girdisi (kısaltılmış): { “severity”: “ERROR”, “message”: “Ödeme işlemi başarısız oldu”, “service”: “payments”, “version”: “2026-09-01”, “user_id_hash”: “9c1…”, “labels”: {“tenant”:“gold”}, “logging.googleapis.com/trace”: “projects/myproj/traces/4bf92f3577b34da6a3ce929d0e0e4736”, “logging.googleapis.com/spanId”: “00f067aa0ba902b7” }
Saklama süresini güncelleme:

undefined

Hata günlükleri için bir BigQuery sink’i oluşturma:

undefined

Cloud Run için son 5xx hatalarını okuma:

undefined

Cloud Monitoring

Metrikler. Google Cloud metriklerini, özel metrikleri ve günlüğe dayalı metrikleri kullanın. Düşük kardinaliteli etiketleri tercih edin; etiket kardinalitesinin patlaması maliyet ve sorgu gecikmesi sorunlarına neden olur.
Gösterge Panelleri. Her hizmet ve her bağımlılık (veritabanı, önbellek, kuyruklar) için özel gösterge panelleri oluşturun. RED (istekler, hatalar, süre) ve USE (kullanım, doygunluk, hatalar) sinyallerini görselleştirin.
Uyarı Politikaları. Eşiklere, metrik yokluğuna, oranlara, SLO yanma oranlarına veya çalışma süresi denetimi hatalarına göre tetikleyin. Bildirim kanallarını (e-posta, SMS, PagerDuty, Pub/Sub, web kancaları) yapılandırın. Pencereleme ve hizalayıcılar aracılığıyla kararsız (flapping) uyarıları bastırın.
Çalışma Süresi Denetimleri. Birden çok bölgeden yoklama yapın; dahili uç noktalar için özel çalışma süresi denetimlerini kullanın veya VPC içinden sentetik testler çalıştırın.

Günlüğe dayalı metrikler

Sayaçlar, olayları özetler (örneğin, /api/alpha/* isteklerinin sayısı).
Dağılımlar, gecikmeyi veya yük boyutlarını yakalar.
Örnek:

undefined

Operasyonel analiz

Anlık (ad hoc) analizler için bir sink aracılığıyla BigQuery’ye yönlendirin; maliyeti kontrol etmek için şemaları ve zaman damgasına göre bölümlemeyi tasarlayın.
Uygun olan yerlerde dışa aktarma yapmadan toplama yapmak için Logging bucket’larındaki Log Analytics’i kullanın.
CPU, bellek, kuyruk derinliği, Cloud SQL bağlantıları, Spanner yüksek öncelikli CPU, Pub/Sub onaylanmamış (unacked) mesajlar ve Cloud Storage 429/5xx oranları gibi metriklerden kapasite sinyalleri oluşturun.

Yaygın tuzaklar ve ödünleşimler

Aşırı günlük kaydı, alım (ingestion) maliyetini artırır ve sinyali belirsizleştirir; örnekleme ve önem derecesi disiplinini tercih edin.
Eksik korelasyon kimlikleri, olay triyajını engeller; trace ID’lerini uçtan uca yayın.
Sık erişilen (hot) bucket’larda uzun süreli saklama maliyeti artırır; uzun vadeli ihtiyaçlar için arşive veya BigQuery’ye aktarın.

İzleme, Hatalar ve Derinlemesine Teşhis

Dağıtık izleme

İzleme bağlamı. W3C trace-context (traceparent, tracestate) tercih edin. Cloud Trace ile birlikte çalışabilirlik için x-cloud-trace-context’i desteklemeye devam edin: x-cloud-trace-context: TRACE_ID/SPAN_ID;o=1
Aktarım. İzleme başlıklarını servisler, mesaj kuyrukları ve asenkron sınırlar arasında iletin; RPC veya SQL çağrıları yaparken yeni alt span’ler yakalayın. Bağlam kaybı, servis haritalarını bozar ve “bilinmeyen servis” düğümlerini şişirir.
Örnekleme. Maliyet ve doğruluğu dengeleyin; girişte dinamik ‘head-based’ örnekleme ve nadir yavaş istekler için ’tail-based’ örnekleme kullanışlılığı artırabilir.

Cloud Trace

Gecikme histogramları, span şelaleleri ve servis haritaları sağlar. Kritik alt operasyonlar (RPC’ler, DB sorguları) için ek açıklamalar (annotations) kullanın.
p95/p99 izlemelerini kullanarak aykırı değerleri teşhis edin; fan-out, N+1 sorguları veya kilit çekişmesine (lock contention) dikkat edin.
Bir izlemeye tıklandığında loglarını ortaya çıkarması için izleme-log korelasyonunu etkinleştirin.

Error Reporting

İstisnaları servis/versiyon başına yığın imzasına (stack signature) göre otomatik olarak toplar. Servisler arası karışıklığı önlemek için servis bağlamını yapılandırın. Gürültülü bilinen hataları bastırın veya bunları daha düşük öncelikli bildirimlere yönlendirin.
İstisna mesajlarından PII’ı (Kişisel Tanımlayıcı Bilgiler) redakte edin; bunun yerine kararlı hata kodları ve korelasyon ID’leri loglayın.

Cloud Profiler

Desteklenen çalışma zamanları için düşük ek yüklü sürekli CPU/heap profili oluşturma. Regresyonları yakalamak için profilleri versiyonlar ve trafik seviyeleri arasında karşılaştırın. Örnekleme artefaktlarını kesin sayımlar olarak yorumlamaktan kaçının.

Cloud Debugger

Anlık görüntüler (Snapshots), süreci duraklatmadan bir kod konumundaki değişkenleri yakalar. Logpoints, geçici loglama ifadeleri ekler. Erişimi kısıtlayın, hassas değişkenleri redakte edin ve PII olmayan ifadelerle sınırlayın.

Kısa örnek: W3C traceparent ekleme ve bir logu ilişkilendirme

HTTP aktarımı: traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
Cloud Trace’e bağlamak için log alanı: “logging.googleapis.com/trace”: “projects/myproj/traces/4bf92f3577b34da6a3ce929d0e0e4736”

Güvenilirlik Mühendisliği, Uyarı ve Sağlık Sinyalleri

SLI’lar, SLO’lar, SLA’lar ve hata bütçeleri

SLI’lar kullanıcı memnuniyetini ölçer: kullanılabilirlik, gecikme, doğruluk. Kritik her uç nokta ve kullanıcı yolculuğu için tanımlayın.
SLO’lar hedefler belirler, örn. 30 gün boyunca isteklerin %99,9’unun 300 ms’nin altında olması.
Hata bütçeleri, izin verilebilir güvenilmezliği ölçer. Bütçeleri sürüm çıkarma, deneyler veya geçişler için harcayın; tüketim oranı çok yüksekse değişiklikleri dondurun.
SLA’lar dış taahhütlerdir; marjı korumak için SLO’yu SLA’dan daha sıkı tutun.

Kaliteli uyarı tasarımı

Mümkün olduğunda neden tabanlı uyarılar yerine SLO ve semptom tabanlı uyarıları tercih edin.
Gürültüyü azaltırken hızlı ve yavaş tüketimleri yakalamak için çoklu pencere, çoklu tüketim oranlı uyarılar (örneğin, 5 dakikada 14 kat ve 1 saatte 2 kat) kullanın.
Gözetleyiciler (watchdogs) için metrik yokluğu ekleyin (örn. uzun süren bir işin heartbeat’i).
Önem derecesine göre yönlendirin; bildirimleri hız sınırlayın (rate-limit); runbook’lara ve dashboard’lara bağlantılar sağlayın.

Sağlık kontrolleri ve problar

Hazırlık kontrolleri (Readiness checks) bağımlılıklar hazır olana kadar trafiği engeller; canlılık kontrolleri (liveness checks) kilitlenmiş süreçlerde yeniden başlatmaları tetikler; başlangıç probları (startup probes) yavaş başlayan uygulamaları erken yeniden başlatmalardan korur.
Yük dengelemeli VM’ler için, sağlık denetleyicisi kaynak aralıklarına izin verin, yoksa trafik arka uçlara (backends) asla ulaşmaz: gcloud compute firewall-rules create allow-lb
–network prod –allow tcp
–source-ranges 130.211.0.0/22,35.191.0.0/16 –direction INGRESS
Kubernetes örneği: readinessProbe: httpGet: { path: /ready, port: 8080 } periodSeconds: 5 failureThreshold: 3 livenessProbe: httpGet: { path: /healthz, port: 8080 } initialDelaySeconds: 30 periodSeconds: 10
Sentetik test. Oturum açma, ödemeler veya diğer kritik yolları doğrulamak için Cloud Scheduler + Cloud Run/Functions aracılığıyla çalışma süresi kontrolleri (uptime checks) ve özelleştirilmiş uçtan uca akışlar kullanın.
Bağımlılık izleme. Veritabanı bağlantı doygunluğunu, RPC hata oranlarını, kuyruk birikmelerini, giden trafik (egress) hatalarını ve üçüncü taraf SLI’larını takip edin. Geçici 429/5xx hataları için ’truncated exponential backoff’ ile yeniden denemeler ayarlayın ve güvenlik için ‘idempotency’ anahtarları kullanın.

Olay Müdahalesi, Güvenlik Odaklı Hata Ayıklama ve Kök Neden

Olay müdahale yaşam döngüsü

Triyaj: ciddiyeti sınıflandırın, olay komutanı atayın ve tanımlanmış kanallar aracılığıyla nöbetçi ekibe çağrı yapın.
Sınırlama: bilinen hafifletmeleri ve trafik kontrollerini (geri alma, canary, circuit breaker, rate limiter) uygulayın.
İletişim: dahili bir kriz odası (war-room) oluşturun, paydaşları düzenli olarak güncelleyin ve gerektiğinde kullanıcıya yönelik durum yayınlayın.
Çözüm ve Kurtarma: SLI’lar aracılığıyla sistem sağlığını doğrulayın; erken “sorun yok” bildirimlerinden kaçının.
Postmortem: zaman çizelgesini, tespit boşluklarını, katkıda bulunan faktörleri ve sorumlu sahipleri ile bitiş tarihleri olan eylem maddelerini suçlayıcı olmayan bir şekilde analiz edin. Kapanana kadar takip edin.

Runbook’lar

Tetikleyicileri, gerekli bağlamı, teşhis komutlarını, güvenli hafifletmeleri, geri alma adımlarını ve eskale etme yollarını içerin. Belirli hata modları için dashboard’lara, loglara ve playbook’lara bağlantı verin.

Kota ve kapasite izleme

Cloud Monitoring metrikleri aracılığıyla hizmet kotalarını izleyin. %70–80 dolulukta uyarıları otomatikleştirin ve planlanmış yük testleri veya lansmanlar için önceden artış talep edin.
İzlenecek kapasite sinyalleri: CPU, bellek, dosya tanıtıcıları (file descriptors), iş parçacığı havuzları (thread pools), veritabanı bağlantıları, otomatik ölçekleyici (autoscaler) limitleri ve istek kuyruğu derinliği.

Hassas bilgileri ifşa etmeden hata ayıklama

Gizli bilgileri ve kişisel olarak tanımlanabilir bilgileri (PII) kaynakta ayıklayın (redact); gizli bilgileri Secret Manager’da merkezileştirin. Kullanıcı tanımlayıcıları için hashing veya tokenization kullanın. Loglama ara katman yazılımında (middleware) alan düzeyinde ayıklamayı etkinleştirin.
IAM aracılığıyla loglara, izlemelere (trace) ve hata ayıklama araçlarına erişimi sınırlayın; uygun olan yerlerde CMEK ve VPC Service Controls kullanın.
Debugger’da, büyük nesne grafiklerinin toplanmasını devre dışı bırakın ve hassas çerçevelerin (frame) yakalanmasını önlemek için koşullar ekleyin.

Katmanlar arası kök neden analizi

Çalışma Zamanı (Runtime): Profiler aracılığıyla GC, iş parçacığı havuzları veya CPU’daki ani artışları, Trace’deki p99 gecikmesiyle ilişkilendirin.
Ağ (Network): Yolları doğrulamak için yük dengeleyici (load balancer) loglarını, VPC Flow Logs’u, güvenlik duvarı (firewall) loglarını ve Connectivity Tests’i inceleyin. Sistem durumu denetimi (health-check) hataları genellikle eksik güvenlik duvarı kurallarından veya yanlış portlardan kaynaklanır.
IAM: İzin reddi veya politika değişiklikleri için Cloud Audit Logs’u inceleyin; hizmet hesabı (service account) rollerini ve token kapsamlarını doğrulayın.
Veri (Data): Yoğun noktaları (hotspot) bulmak için Cloud SQL Insights, Spanner sorgu istatistikleri, Bigtable CPU ve sıcak tabletleri (hot tablets) ve Storage hata oranlarını kullanın. Geçici hatalar için backoff ile yeniden denemeler uygulayın ve tail latency’yi artıran fan-out’u azaltın.
İlişkili izleme kimlikleri (trace ID) ve log tabanlı metriklerle bir araya getirin; olay sonrası analiz sırasında çok kaynaklı birleştirmeler (join) yapmak için BigQuery’ye aktarın.

Pratik Problem Senaryosu

Fjord Retail, çoklu hizmetli bir ödeme sistemini Cloud Run, Cloud SQL, Pub/Sub ve harici bir vergi API’si kullanarak Google Cloud’a taşıyor. Kullanıcılar, ani indirim (flash sale) dönemlerinde aralıklı zaman aşımları ve ani hata oranı artışları bildiriyor ve nöbetçi ekip gürültülü, düşük sinyalli uyarılar alıyor.

Yaklaşım:

İzleme korelasyonu ile yapılandırılmış loglamayı etkinleştirin

Hizmetler arasında W3C traceparent yayılımını ekleyin ve tüm loglara logging.googleapis.com/trace’i dahil edin. Gerekçe: Uçtan uca korelasyon, mühendislerin yavaş bir kullanıcı isteğinden tam olarak yavaş olan RPC’ye veya sorguya ve onun loglarına geçiş yapmasını sağlar.

Logging bucket’ları, saklama süreleri ve dışa aktarımlar oluşturun

_Default saklama süresini 90 güne çıkarın ve AB iş yükleri için bölgesel bir bucket oluşturun. ERROR ve WARNING logları için BigQuery’ye birleştirilmiş bir sink ekleyin:

undefined

Gerekçe: Yeterli sıcak (hot) saklama süresi hata ayıklamaya yardımcı olur; BigQuery, sıcak depolama maliyetlerini artırmadan hızlı olay analizi sağlar. 3) SLI/SLO’ları ve SLO tabanlı uyarıları tanımlayın

Kullanılabilirlik SLI’ı: başarılı istekler / toplam. Gecikme SLI’ı: POST /checkout için p95 süresi.
SLO’lar: Aylık %99.9 kullanılabilirlik; ödeme işlemlerinin %95’i < 300 ms.
Çok pencereli hata payı harcama oranı (burn-rate) uyarıları ve ödeme sistemi heartbeat’i için bir metrik yokluğu uyarısı yapılandırın. Gerekçe: Belirti tabanlı uyarılar gürültüyü azaltır ve yalnızca kullanıcıyı etkileyen durumlar için çağrı yapar.

Sistem durumu denetimleri (health probe) ve sentetik kontroller ayarlayın

Cloud Run hizmetleri /ready ve /healthz yollarını sunar. /checkout için genel bir çalışma süresi denetimi (uptime check) ve VPC içinde test kimlik bilgileriyle tam bir ödeme işlemi gerçekleştiren özel bir sentetik iş ekleyin. Gerekçe: Hazır olma durumu (readiness), soğuk arka uçların (backend) trafik almasını engeller; sentetik kontroller uçtan uca sorunları ve üçüncü taraf regresyonlarını yakalar.

Cloud Trace ve Profiler’ı etkinleştirin ve backoff ile yeniden deneme yöntemini benimseyin

Uygun olan yerlere Trace/Profiler ajanlarını kurun; otomatik HTTP istemci enstrümantasyonunu ve SQL span ek açıklamalarını etkinleştirin. Vergi API’si çağrıları için idempotency anahtarlarıyla kesilmiş üstel backoff (truncated exponential backoff) uygulayın. Gerekçe: İzleme (tracing), gecikmeye neden olan faktörleri izole eder; backoff, 429/5xx amplifikasyonunu azaltır ve hata bütçelerini korur.

Kapasite ve kotaları izleyin

Cloud SQL bağlantıları, CPU, InnoDB arabellek havuzu (buffer pool), Pub/Sub onaylanmamış (unacked) mesajlar, Cloud Run eşzamanlılığı (concurrency) ve hizmet kotası kullanımı için dashboard’lar ve uyarılar ekleyin. Gerekçe: Kapasite doygunluğu, tail latency’nin yaygın bir gizli nedenidir; erken uyarılar kesintileri önler.

Gizlilik için hata ayıklamayı sıkılaştırın

Hash’lenmiş kullanıcı kimlikleri kullanın ve hata mesajlarından kişisel olarak tanımlanabilir bilgileri (PII) hariç tutun. Debugger’ı yalnızca ayıklama (redaction) kuralları ve logpoint’ler ile üretim ortamıyla sınırlayın. Gerekçe: Veri minimizasyonu ilkesine uyarken gözlemlenebilirliği sürdürün.

Bağımlılık izleyicileri ve circuit breaker’lar oluşturun

Özel metrikler aracılığıyla harici vergi API’sinin başarı oranını ve gecikmesini izleyin; hatalar bir eşiği aştığında önbelleğe alınmış vergi oranlarına geçmek için bir circuit breaker’ı devreye sokun. Gerekçe: Üçüncü taraf bağımlılıklardaki hataları izole edin ve temel ödeme sistemi kullanılabilirliğini koruyun.

Runbook’ları ve eskale etme yollarını hazırlayın

Adımları belgeleyin: SLO dashboard’larını doğrulayın, yoğun kenarlar (hot edges) için Trace hizmet haritasını kontrol edin, yavaş sorgular için Cloud SQL Insights’ı inceleyin, güvenlik duvarını ve sistem durumu denetimlerini doğrulayın ve kota payını değerlendirin. Geri alma ve canary prosedürlerini dahil edin. Gerekçe: Tutarlı ve hızlı müdahale, MTTR’yi düşürür ve anlık riskli değişikliklerden kaçınır.

Olay sonrası analiz ardışık düzeni (pipeline)

Kiracı başına hata oranlarını hesaplamak ve logları izlemeler (trace) ve Cloud SQL içgörüleriyle trace ID’ye göre ilişkilendirmek için BigQuery dışa aktarımlarını kullanın. Gerekçe: Dayanıklı, sorgulanabilir geçmiş, doğru kök neden analizleri (RCA) ve önleyici tedbirler sağlar.

Bu plan, sinyal kalitesini yükseltir, tespit ve çözüm süresini kısaltır, ani yoğunluklar sırasında kullanıcı deneyimini korur ve üretimde hata ayıklama sırasında gizliliği zorunlu kılar.

← Sürekli Teslimat · Tüm alanlar · Performans →

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