Google PCA: Operasyonlar, Gözlemlenebilirlik ve Platform Otomasyonu — Ç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ış

Google Cloud’da Operasyonlar, Gözlemlenebilirlik ve Platform Otomasyonu, güvenlik ve maliyet kontrol altında tutulurken hizmetlerin teşhis edilebilir, sürdürülebilir ve sürekli olarak iyileştirilmesini sağlar. Bütünsel bir tasarım; günlük kaydı, metrikler, izleme (tracing), denetlenebilirlik, runbook’lar, olay müdahalesi, kota ve kapasite yönetimi ve otomasyonu kapsar. Amaç, hizmet seviyesi hedeflerine bağlı, eyleme geçirilebilir, gürültüsü az sinyaller ile angaryayı ve yapılandırma sapmasını azaltan deterministik otomasyonu birleştirmektir.

Günlük Kaydı ve Denetlenebilirlik

Cloud Logging, Google Cloud hizmetlerinden, GKE’den ve VM’lerden gelen günlükleri merkezileştirir. request_id, user_id, service, version, latency_ms ve severity için tutarlı anahtarlara sahip yapılandırılmış günlükleri (JSON) tercih edin; yapılandırılmış veriler hassas sorgulara, günlük tabanlı metriklere ve ilke değerlendirmesine olanak tanır. VM’lerde ve GKE düğümlerinde, sistem ve uygulama günlüklerini toplamak için Ops Agent’ı (tercih edilen) veya eski logging agent’ı kurun; ayrıştırıcıların (parser) kendi framework’leriniz için JSON çıktısı verdiğinden emin olun.

Günlük demetleri (log bucket) ve saklama süresi: Veri yerleşimi ve CMEK için bölgesel olarak konumlandırılmış günlük demetleri kullanın. Varsayılan demetler _Default ve _Required‘ı içerir; ikincisi, Yönetici Etkinliği, Sistem Olayı ve Politika Reddedildi denetim günlüklerini sabit uzun vadeli saklama süresiyle depolar. Her veri sınıfı (ör. uygulama, güvenlik, analitik) için özel saklama süresi ve CMEK ile ayrılmış demetler oluşturun. Daha uzun saklama süresi adli bilişim (forensics) incelemelerini iyileştirir ancak maliyeti artırır; Logging’de saklama gerekmediğinde uzun süreli arşivleme için dışa aktarın.
Günlük havuzları (sink) ve dışa aktarımlar: Log Router ile havuzları kullanarak BigQuery (analitik), Pub/Sub (SIEM veya işlem hatları) ve Cloud Storage’a (arşivleme) yönlendirin. Hacmi ve maliyeti yönetmek için bölümlenmiş BigQuery tabloları kullanın. Sessiz hatalardan kaçınmak için havuz hizmet hesabına (sink service account) hedefe yönelik her zaman en az ayrıcalıklı yazma erişimi verin. Dışa aktarılan günlükleri tekrar Logging’e almayarak yönlendirme döngülerinden kaçının.
Sorgular ve günlük tabanlı metrikler: logName, resource.type, severity, labels ve jsonPayload alanlarına filtreler uygulayarak Logs Explorer’ı kullanın. Hata oranı SLI’ları ve gecikme histogramları için günlük tabanlı metrikler (sayıcı veya dağılım) türeterek uyarı sistemini destekleyin. Yüksek varyanslı alanları normalleştirerek kardinaliteyi kontrol edin.
Cloud Denetim Günlükleri: Yönetici Etkinliği (kontrol düzlemi yazma işlemleri), Veri Erişimi (kullanıcı verilerinin okunması/yazılması), Sistem Olayı ve Politika Reddedildi günlükleri idari gözlemlenebilirlik sağlar. Veri Erişimi günlükleri yüksek hacimlidir ve birçok hizmet için varsayılan olarak devre dışıdır; yalnızca gerektiğinde etkinleştirin ve uygun saklama süresi ve CMEK ile bir demete yönlendirin. Politika Reddedildi günlükleri, izin ve kuruluş ilkesi ihlallerini erken tespit etmeye yardımcı olur. Gözetim ayrılığını sağlayın: güvenlik ekipleri genellikle denetim günlüklerine sahip olur ve erişirken, diğer ekipler için kısıtlı görünümler bulunur.
Hata modları ve ödünleşimler:
- Fazla geniş kapsamlı havuzlar BigQuery’de maliyetleri patlatır; hassas bir şekilde filtreleyin ve bölümlerin süresini dolacak şekilde ayarlayın.
- Yüksek kardinaliteli JSON alanları (ör. tam URL’ler) sorgu performansını düşürür; verileri temizleyin ve normalleştirilmiş etiketler çıkarın.
- Yetersiz saklama süresi soruşturmaları zorlaştırır; GCS veya BigQuery’ye dışa aktarmak bu durumu hafifletir.
- Eksik agent veya yanlış yapılandırılmış ayrıştırıcılar sessiz günlük kaybına neden olur; agent’ın sağlık durumu (heartbeat) ve veri alım (ingest) hataları için uyarı ayarlayın.

Örnek: özel saklama süresine sahip bölgesel bir günlük demeti oluşturun ve filtrelenmiş bir denetim havuzunu dışa aktarın.

undefined

İzleme, Takip ve Uygulama Teşhisi

Cloud Monitoring, sistem ve uygulama metriklerini toplar; gösterge panellerini, uyarıları, çalışma süresi denetimlerini, bildirim kanallarını ve hizmet seviyesi hedeflerini destekler.

Metrikler ve gösterge panelleri: Google hizmetleri için yerleşik metrikleri kullanın ve Cloud Monitoring API veya OpenTelemetry aracılığıyla özel metrikler oluşturun. Dört altın sinyali vurgulayın: gecikme, trafik, hatalar, doygunluk. Etiketleri akıllıca uygulayın; sınırsız etiket değerlerinden kaçının. Çoklu proje görünümlerini birleştirmek için Metrik Kapsamı’nı (Metrics Scope) kullanın. Gerektiğinde etkileyici sorgular için MQL kullanın.
Uyarı ve bildirim kanalları: Hızlı tespiti ve gürültü azaltmayı dengelemek için SLO’lar için çok pencereli, çoklu yanma oranlı uyarılar uygulayın. Bildirim kanallarını (e-posta, SMS, Pub/Sub, webhook’lar, üçüncü taraf olay araçları) tanımlayın ve uyarı dokümantasyonuna runbook bağlantıları ve bağlam ekleyin. Uyarı fırtınalarını önlemek için bildirim oranı sınırlarını ve olayların otomatik kapanmasını kullanın.
Çalışma süresi denetimleri: Kritik uç noktaları birden çok bölgeden TLS doğrulaması, DNS ve içerik eşleştirmesi ile yoklayın. Çalışma süresi denetimlerini uyarı ve hizmet SLO’larına bağlayın. Çalışma süresi denetimlerinin dahili bağımlılıkları doğrulamadığını unutmayın; sentetik işlemler ve dahili sağlık kontrolleri ile tamamlayın.
SLO’lar ve SLI’lar: Kullanılabilirlik, gecikme ve doğruluk için SLI’lar tanımlayın. Cloud Monitoring Hizmet İzleme’de (Service Monitoring) SLO’ları yapılandırın ve hata bütçelerini takip edin. Müşteri etkisine uyum sağlamak için ham hatalara değil, bütçe yanmasına göre uyarı ayarlayın. Kalan hata bütçesine uymak için sürüm kapıları (release gates) veya aşamalı teslimat kullanın.
Cloud Trace, Error Reporting, Profiler: Span’leri istek ve bağımlılık üst verileriyle notlandırmak için OpenTelemetry ile hizmetler arasında dağıtık izleme kullanın. Maliyeti kontrol altında tutarken kritik akışların kapsandığından emin olmak için örneklemeyi hizmet ve yol başına dinamik olarak ayarlayın. Error Reporting, günlüklerden gelen istisnaları (exception) otomatik olarak birleştirir, yığın izine (stack trace) göre tekilleştirir ve bildirimleri tetikler. Profiler, üretim ortamında düşük ek yük ile sürekli CPU, yığın (heap) ve duvar saati (wall-time) profilleri sağlar; bunu sıcak yolları (hot path) ortadan kaldırmak ve maliyeti düşürmek için kullanın.
Hata modları ve ödünleşimler:
- Aşırı metrik kardinalitesi maliyeti artırır ve sorguları yavaşlatır; yayınlamadan (emit) önce toplayın (aggregate).
- Düşük izleme örneklemesi kuyruk gecikmesi sorunlarını gizler; yavaş yollar için daha yüksek bir oranda örnekleme yapın.
- Yanlış hizalanmış (ör. çok katı) SLO’lar uyarı yorgunluğu yaratır; gerçek trafik verileriyle yineleyin.
- Dahili bağımlılıklar başarısız olurken çalışma süresi denetimleri başarılı olabilir; bağımlılığa duyarlı SLO’lar kullanın.

Platform Operasyonları, Runbook’lar ve Olay Yönetimi

Operasyonel titizlik; tespit etme, etki azaltma ve öğrenme için geçen ortalama süreyi azaltır.

Runbook’lar ve eskalasyon: Her uyarı; ön koşulları, teşhis adımlarını, geri alma (rollback) prosedürlerini ve iletişim şablonlarını içeren deterministik bir runbook’a bağlanmalıdır. Net nöbet (on-call) rotasyonları ve eskalasyon politikaları tanımlayın. Runbook’ları sürüm kontrolünde saklayın ve test edin.
Olay yönetimi ve postmortem’ler: Standartlaştırılmış ciddiyet seviyeleri, roller (olay komutanı, iletişim, operasyon, SME) ve kanallar kullanın. Genel duyurular için chat ops ve durum sayfalarını tercih edin. Zaman çizelgesini, katkıda bulunan faktörleri, tespit açıklarını, müşteri etkisini ve sahiplere/tarihlere bağlanmış somut takip eylemlerini belgeleyen, suçlayıcı olmayan postmortem’ler yazın.
Kota yönetimi ve kapasite sinyalleri: Kullanım oranına ilişkin uyarılarla Service Usage ve serviceruntime kota metriklerini izleyin. Proaktif olarak kota artışı talep edin ve otomatik ölçeklendirme (autoscaling) limitlerini kotalarla uyumlu hale getirin. CPU, bellek, dosya tanımlayıcıları (file descriptors), bağlantı havuzları (connection pools) ve kuyruk derinliği (queue depth) gibi kapasite sinyallerini kullanın. GKE için HPA/VPA ve cluster autoscaler’ı ayarlayın; GCE MIG’ler için ise uygun yerlerde bekleme süreleri (cool-downs) ve tahmine dayalı otomatik ölçeklendirme (predictive autoscaling) ayarlayın.
Servis sağlığı ve sorun giderme: MTTD’yi azaltmak için Logs Explorer live tail, log tabanlı metrikler, gösterge panoları (dashboard’lar) ve Trace’i bir arada kullanın. Ağ sorunlarını önceliklendirmek (triage) için VPC Flow Logs ve Firewall Rules Logging’i etkinleştirin; önyükleme (boot) hataları için VM seri konsolunu kullanın. Paket yakalama (packet capture) ve çekirdek izlemeyi (kernel tracing) runbook’larda acil durum (“break-glass”) prosedürleri olarak bulundurun.
Hata modları:
- Kota tükenmesi kesinti gibi görünür; yüzde 80 kullanıma ulaşıldığında uyarı ayarlayın ve yukarı akışta (upstream) hız sınırlaması (rate-limit) uygulayın.
- Önceden hazırlık (prewarming) olmadan otomatik ölçeklendirme soğuk başlatmalara (cold starts) neden olur; kritik yollar için minimum replika kullanın.
- Sentetik kontrollerin eksikliği, müşteri tarafından görülebilen hataları maskeler; kanarya (canary) işlemleri uygulayın.

Otomasyon, Kaynak Envanteri, İlke ve Sapma

Tekrarlanabilir görevleri en az ayrıcalık ilkesi ve idempotency ile otomatikleştirin.

Araçlar: Kalıcı $HOME ile güvenli, geçici yönetici erişimi için Cloud Shell kullanın; PATH kalıcılığı için yardımcı ikili dosyaları ~/bin içine yerleştirin. gcloud, REST API’leri ve istemci kütüphaneleri ile otomasyon sağlayın. Uzun ömürlü anahtarları ortadan kaldırmak için hizmet hesaplarını ve workload identity’yi kullanın.
Zamanlayıcılar ve orkestratörler: HTTP ve Pub/Sub işlerini cron zamanlamalarına göre tetiklemek için Cloud Scheduler kullanın. Yeniden denemeler, geri çekilme (backoff), telafi ve zaman aşımları ile çoklu hizmet otomasyonunu düzenlemek için Workflows kullanın. Idempotency’yi sağlayın ve loglara korelasyon kimlikleri ekleyin.
Rutin otomasyon örnekleri:
- Envanter ve sapma raporları için GCS ve BigQuery’ye günlük varlık dışa aktarımı.
- Bir gösterge panosunda yayınlanan otomatikleştirilmiş SLO tükenme oranı (burn-rate) hesaplaması.
- Kuruluş ilkelerine ve IAM anormalliklerine karşı periyodik ilke değerlendirmesi.
Kaynak envanteri ve ilke değerlendirmesi: Cloud Asset Inventory, kaynakların, IAM bağlamalarının ve kuruluş ilkelerinin belirli bir anlık ve gerçek zamanlı değişiklik akışlarını sağlar. Geçmişe yönelik analiz ve sapma tespiti için BigQuery’ye dışa aktarın; neredeyse gerçek zamanlı ilke ihlali triyajı için Pub/Sub’a abone olun. Gereğinden geniş kapsamlı IAM ve kullanılmayan izinleri tespit etmek için Policy Analyzer ve Recommender kullanın. Organization Policy ile kısıtlamaları zorunlu kılın ve dağıtım öncesi yapılandırmaları kod olarak ilke (policy-as-code) ile doğrulayın.
Yapılandırma sapması: Bildirimsel IaC ve sürekli doğrulama ile sapmayı önleyin. Tespit edildiğinde, ya otomatik olarak uzlaştırın ya da kaynakları karantinaya alın. Yönetilen ve anlık (ad hoc) kaynakları ayırt etmek için kaynakları kaynak (köken) bilgisiyle (ör. deployment_id) etiketleyin.
Güvenlik, güvenilirlik ve maliyet için gözlemlenebilirlik mimarisi:
- Güvenlik: Denetim loglarını CMEK ile korunan, erişimi kısıtlanmış bucket’lara yönlendirin; özel bir güvenlik projesine dışa aktarın. Pub/Sub aracılığıyla SIEM entegrasyonu yapın.
- Güvenilirlik: Gösterge panolarını ve uyarıları SLI’lardan ve trace’lerden (izlerden) oluşturun; Workflows ile olay otomasyonunun provasını yapın.
- Maliyet: Metrik kardinalitesini kontrol edin, her bucket için log saklama süresini ayarlayın, BigQuery dışa aktarımlarını bölümleyin ve yoğun kullanılan yolları (hot path) optimize etmek için Profiler kullanın.

Örnek: günlük bir varlık dışa aktarımını zamanlayın ve bir workflow çalıştırın.

undefined

Pratik Problem Senaryosu

Contoso Commerce, çok bölgeli, GKE tabanlı bir ödeme platformu başlatıyor. Gereksinimler: denetlenebilir yönetim, minimum gürültüye sahip SLO odaklı uyarılar, uçtan uca istek takibi (tracing), otomatikleştirilmiş gecelik uyumluluk envanteri ve güçlü maliyet kontrolleri.

Yaklaşım:

Loglama ve denetim temellerini oluşturun

Uygulama, güvenlik ve analitik logları için CMEK ile bölgesel log bucket’ları oluşturun; uygulama için 30 gün, güvenlik için ise gereksinimlere göre 400+ gün olarak ayarlayın. Admin Activity, System Event ve Policy Denied loglarını güvenlik bucket’ına yönlendirin; Data Access loglarını yalnızca ödeme hizmetleri için etkinleştirin.
Gerekçe: Hassasiyete göre ayrım yapmak, etki alanını (blast radius) ve maliyeti azaltır; CMEK uyumluluğu sağlar; Data Access’in kapsamını daraltmak hacimdeki ani artışları önler.

Yapılandırılmış uygulama loglaması ve toplamayı uygulayın

Uygulama loglarını, PII (Kişisel Tanımlayıcı Bilgiler) için temizlenmiş korelasyon kimlikleri (trace_id, span_id) ve kullanıcı/oturum etiketleri ile yapılandırılmış JSON olarak göndermek için GKE node’larına Ops Agent ve sidecar/daemonset toplayıcıları dağıtın.
Gerekçe: Yapılandırılmış loglar, hassas sorgular, log tabanlı metrikler ve trace’ler (izler) ile birleştirme imkanı sağlar; korelasyon kimlikleri dağıtık teşhisi destekler.

Dağıtık takip (tracing), hata toplama ve profil oluşturmayı dağıtın

Mikroservisleri, Cloud Trace’e veri gönderen OpenTelemetry SDK’ları ile enstrümante edin; ödeme ve sepet yolları için daha yüksek örnekleme oranı ayarlayın. Tüm çalışma zamanları için Error Reporting’i ve CPU/bellek açısından kritik hizmetler için Profiler’ı etkinleştirin.
Gerekçe: Trace’ler gecikmeyi servis atlamasına (hop) göre yerelleştirir; Error Reporting, triyaj sürecini hızlandırmak için yığın izlerini (stack trace) gruplandırır; Profiler, işlem maliyetini ve kuyruk gecikmesini (tail latency) azaltır.

SLI/SLO’ları tanımlayın ve uyarı ile gösterge panolarını yapılandırın

SLI’ları tanımlayın: p90 ve p99 ödeme gecikmesi, ödeme API’sinin kullanılabilirliği ve ödeme başarı oranı. SLO’ları belirleyin (ör. yüzde 99,9 kullanılabilirlik, 800 ms altında p99 gecikmesi). Runbook bağlantıları ve PagerDuty kanalı ile tükenme oranı (burn-rate) uyarıları (1 saatte yüzde 2 ve 6 saatte yüzde 1) yapılandırın; altın sinyalleri (golden signals) ve hata payı (error budget) eğilimlerini gösteren panolar oluşturun.
Gerekçe: Hata payı uyarıları, müşteri etkisine bağlanır ve gürültüyü azaltır; gösterge panoları operasyonel durumsal farkındalık sağlar.

Harici ve dahili sağlık kontrolleri ekleyin

Ödeme uç noktaları için içerik doğrulaması ile çok bölgeli çalışma süresi kontrolleri (uptime checks) yapılandırın; sepetten ödemeye akışı için sentetik işlem kontrolleri ekleyin. GCLB ve GKE hazır olma (readiness) problarını entegre edin.
Gerekçe: Çalışma süresi kontrolleri, müşteriye dönük kullanılabilirliği doğrular; sentetik akışlar, bağımlılık kırılmalarını tespit eder.

Envanter, ilke izleme ve sapma tespitini otomatikleştirin

Cloud Asset Inventory dışa aktarımlarını GCS ve BigQuery’ye almak için bir Güvenlik projesi oluşturun; IAM ve kuruluş ilkesi değişiklikleri için gerçek zamanlı Pub/Sub akışlarını etkinleştirin. İstenilen durum manifestolarını mevcut varlıklarla karşılaştırmak için her gece Workflows çalıştırın; bilet açın veya düşük riskli sapmaları otomatik olarak uzlaştırın.
Gerekçe: Merkezi envanter denetimleri destekler; sürekli ilke değerlendirmesi ayrıcalıkların zamanla artmasını (privilege creep) önler; otomasyon sapmayı engeller.

Kotaları ve kapasiteyi yönetin

İşlem, yük dengeleyici ve API kotalarını yüzde 70 ve 85 kullanımda uyarılarla izleyin. Hedef yük için önceden daha yüksek kotalar talep edin; GKE cluster autoscaler ve HPA limitlerini kotalarla uyumlu hale getirin. Başlatılması yavaş olan MIG tabanlı hizmetler için tahmine dayalı otomatik ölçeklendirmeyi etkinleştirin.
Gerekçe: Kota tavanları kesinti gibi görünebilir; proaktif ayarlamalar ve uyumlu otomatik ölçeklendirme, yoğun zamanlarda kısıtlamayı (throttling) önler.

Gözlemlenebilirlikte maliyeti optimize edin

Log saklama süresini bucket bazında sınırlayın, Log Router filtreleri aracılığıyla üretimdeki ayrıntılı hata ayıklama (debug) loglarını hariç tutun ve yalnızca gerekli alanları bölüm son kullanma tarihi ile BigQuery’ye aktarın. Metrik etiket kardinalitesini kısıtlayın; yoğun kullanılan servislerin boyutunu küçültmek için Profiler bulgularını kullanın.
Gerekçe: Gözlemlenebilirlik uygun maliyetli olmalıdır; hedeflenmiş saklama ve dışa aktarma, kontrolsüz harcamaları önler.

Runbook’ler ve olay müdahale pratiği hazırlayın

Her uyarı ilkesi için teşhis sorguları, trace filtreleri, geri alma (rollback) komutları ve iletişim planlarını içeren, sürüm kontrolü yapılmış runbook’ler yazın. Yükseltme (escalation) ve otomasyon süreçlerini doğrulamak için game day’ler düzenleyin.
Gerekçe: Belirlenmiş, pratik edilmiş müdahaleler MTTR’ı (Ortalama Onarım Süresi) azaltır ve güvenilirliği artırır.

Doğrulayın ve yineleyin

Uyarı gürültüsünü sürekli olarak gözden geçirin, eşikleri ayarlayın ve gerçek trafiğe göre SLO’ları iyileştirin. Postmortem (olay sonrası analiz) eylem maddelerini sahipleri ve son teslim tarihleriyle tamamlanana kadar takip edin.
Gerekçe: Gözlemlenebilirlik ve operasyonlar, ölçülen geri bildirimlerle iyileşir, bu da angaryayı azaltır ve zamanla hizmet kalitesini artırır.

← Migrasyon · Tüm alanlar · DevOps →

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