Google PCA: Migrasyon, Modernizasyon ve Hibrit Bulut Stratejisi — Ç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ış

Başarılı bir geçiş, modernizasyon ve hibrit bulut stratejisi; kullanılabilirlik, veri bütünlüğü, gecikme, güvenlik ve maliyet risklerini yönetirken platform seçimlerini iş hedefleriyle uyumlu hale getirir. Bu yol, veri merkezi riskini azaltmak için hızlı rehost (yeniden barındırma) ile bulutun avantajlarından yararlanmak için hedeflenmiş refactor (yeniden düzenleme) arasında bir denge kurar. İyileştirmeleri sürdürmek için işletim modeli de teknolojiyle birlikte gelişmelidir. Bu bölüm; değerlendirme ve dalga planlaması, karar çerçeveleri, geçiş mekanikleri, hibrit entegrasyon, modernizasyon kalıpları, ilke ve çoklu bulut konuları ve geçiş sonrası optimizasyon için hata modları ve ödünleşimlere vurgu yaparak pragmatik bir plan sunar.

Değerlendirme, Hazırlık ve Dalga Planlaması

• Keşif ve bağımlılık analizi

  • İş yüklerini, sürümleri, işletim sistemi çekirdeklerini, depolamayı, IAM’i ve veri sınıflandırmalarını envanterleyin. web→API→DB akışları, paylaşılan hizmetler (LDAP/AD, DNS, NTP), toplu iş hatları (batch pipelines) ve harici API’ler arasındaki bağımlılıkları haritalandırın.
  • Gizli bağımlılıkları ve uzun kuyruklu gecikmeyi (long-tail latency) ortaya çıkarmak için geçiş öncesi ortamlarda uygulama profilleme ve dağıtık izleme (distributed tracing) kullanın. VPC Akış Günlüklerini ve uygulama seviyesinde enstrümantasyonu (Cloud Logging, Cloud Monitoring, Cloud Trace) etkinleştirin.
  • Durum sınırlarını ve veri ağırlığını (data gravity) belirleyin: boyut, erişim desenleri (Okuma/Yazma oranı), tutarlılık beklentileri ve replikasyon topolojisi.

• Hazırlık ve beceriler

  • Bulut temelleri, IaC, CI/CD, SRE, güvenlik, ağ ve veritabanı becerilerini değerlendirin. Rol tabanlı bir eğitim ve sertifikasyon yol haritası tanımlayın ve beceri geliştirme ve gölge nöbetler (shadow on-calls) için zaman ayırın.
  • İlk dalgadan önce bir landing zone (projeler, klasörler, Shared VPC, kuruluş ilkeleri, denetim havuzları, CMEK stratejisi) oluşturun.

• Geçiş dalgası planlaması

  • Uygulamaları yakınlıklarına ve etki alanlarına (blast radius) göre dalgalar halinde gruplandırın: paylaşılan veriler, senkron bağımlılıklar ve değişiklik pencereleri. Yüksek riskli bağımlılıkları aynı dalgaya çekin veya onları iyi tanımlanmış API sözleşmeleriyle taklit edin (stub).
  • Dalga başına SLO’lar, RTO/RPO, geri alma (rollback) kriterleri ve doğrulama kapıları (validation gates) tanımlayın (şema kontrolleri, sentetik kullanıcı yolculukları, performans eşikleri).
  • Runbook’ları ve değişiklik yönetimini hazırlayın: devreye alma (cutover) adımları, kontrol noktaları, geri alma ve onay için kanıt toplama.

• Uyumluluk, lisanslama ve performans temel çizgisi oluşturma

  • Compute Engine ve yönetilen hizmetlerde işletim sistemi ve ara katman yazılımı (middleware) desteğini doğrulayın. Ticari lisanslama koşullarını, BYOL (Kendi Lisansını Getir) kısıtlamalarını, çekirdek modülü gereksinimlerini ve donanım eğilimlerini (hardware affinities) kontrol edin.
  • Hedef kaynakları boyutlandırmak ve faydaları doğrulamak için tepe ve 95. yüzdelik dilim değerleriyle CPU, bellek, IOPS, iş hacmi (throughput) ve gecikme temel çizgilerini yakalayın.

• Veri yönetişimi

  • PII/PCI verilerini sınıflandırın. Cloud DLP kullanarak içeri alım (ingest) sırasında kimliksizleştirme veya tokenizasyon planlayın. İlk üretim günlüğü depolanmadan önce denetim, saklama ve dışa aktarma ilkelerini tanımlayın.

Yaygın hata modları: devreye alma sonrası zincirleme zaman aşımlarına neden olan bilinmeyen senkron bağımlılıklar; bağlantıyı engelleyen çakışan IP aralıkları; lisans uyumluluğu açıkları; veri mutasyonlarının geri alınamadığı durumlarda geri alma paritesinin (rollback parity) olmaması.

Geçiş Desenleri, Veri Hareketi ve Devreye Alma

• Karar çerçevesi (6R)

  • Rehost (Yeniden Barındırma): Compute Engine’e olduğu gibi taşıma. Buluta en hızlı geçiş süresi, minimum değişiklik. Risk: teknik borcu ve verimsiz boyutlandırmayı beraberinde getirir.
  • Replatform (Yeniden Platformlama): Yönetilen hizmetleri (ör. Cloud SQL, Cloud Load Balancing) benimsemek için küçük değişiklikler yapma. Düşük kod değişikliği ile daha hızlı operasyonel faydalar.
  • Refactor (Yeniden Düzenleme): GKE/Cloud Run için bileşenlerine ayırma veya konteynerleştirme; olay tabanlı desenleri benimseme. Teslimat riskiyle birlikte en yüksek uzun vadeli fayda.
  • Retire (Emekliye Ayırma): Kullanılmayan sistemleri, kullanım ve bağımlılıklarının olmadığı kanıtlandıktan sonra kaldırma.
  • Retain (Muhafaza Etme): Mevzuata veya gecikme süresine ilişkin nedenlerle şirket içinde tutma; hibrit aracılığıyla entegre etme.
  • Relocate (Yeniden Konumlandırma): vSphere iş yüklerini Google Cloud VMware Engine’e taşıma; araçları korur ve değişikliği en aza indirir.

• İşlem ve veritabanı geçiş araçları

  • Migrate to Virtual Machines, diskleri ve ağ yapılandırmasını korurken Compute Engine’e yeniden barındırmayı (rehost) hızlandırır. Misafir işletim sistemi desteğini ve çekirdek sürücülerini doğrulayın.
  • Database Migration Service, düşük kesinti süresiyle Cloud SQL’e homojen çevrimiçi replikasyon (ör. MySQL, PostgreSQL) sağlar. Binlog/replikasyon ayarlarının doğru olduğundan ve gecikme süresinin neredeyse gerçek zamanlı senkronizasyonu desteklediğinden emin olun.
  • İş yüküne uygun veritabanlarını seçme:
    • Yönetilen ilişkisel ihtiyaçlar için Cloud SQL; otomatik depolama artışını etkinleştirin ve çekirdek başına %75’e yakın CPU kullanımını izleyin; replikasyon gecikmesini takip edin ve eşiklere yaklaşılıyorsa parçalayın (shard) veya dikey ölçeklendirin.
    • Düşük gecikmeli, yüksek verimli zaman serisi verisi alımı (ör. sensör verileri) için Bigtable.
    • Küresel ölçek ve güçlü tutarlılık için Spanner; platforma bağımlılık (lock-in) ve taşınabilirlik arasındaki dengeyi anlayın.
  • Veri hareketi
    • Devam eden veya zamanlanmış transferler için Storage Transfer Service; paralelleştirme yapar ve yeniden denemeye duyarlıdır.
    • Ağ süresini ve riskini azaltmak için toplu tek seferlik yüklemeler (onlarca ila yüzlerce TB) için Transfer Appliance.
    • Küçük ve orta ölçekli veri setleri için gsutil ve paralel bileşik yüklemeler (parallel composite uploads).

• Çevrimiçi ve çevrimdışı geçiş

  • Çevrimiçi: Kısa bir devreye alma süresi ile sürekli replikasyon. Artıları: minimum kesinti süresi; Eksileri: kararlı gecikme süresi ve bant genişliği gerektirir; çift yazma (dual-write) durumundan dikkatli bir şekilde kaçınma.
  • Çevrimdışı: Anlık görüntü (snapshot) ve toplu içe aktarma. Artıları: basit ve öngörülebilir; Eksileri: kesinti süresi kopyalama süresine eşittir.

• Devreye alma planlaması, geri alma ve kesinti süresi kontrolü

  • Devreye almadan günler önce DNS TTL’lerini düşürün, gerekli olmayan değişiklikleri dondurun ve bir bakım penceresi planlayın.
  • Doğrulama adımlarını yürütün: şema denkliği, sağlama toplamları (checksum) veya satır sayıları, uygulama duman testleri (smoke test), kanarya trafiği (canary traffic) ve performans sondaları.
  • Geri alma (Rollback): Geriye dönük uyumlu şema değişiklikleri, özellik bayrakları (feature flags) ve doğruluk kaynağı (source-of-truth) verilerinin korunmasını sağlayın. Kararlılık kanıtlanana kadar geri döndürülemez yazmalardan kaçının.
  • Minimum kesinti süresiyle örnek VM disk genişletme:
    • Konsol veya CLI’da diski yeniden boyutlandırın:

undefined

- Linux ext4 üzerinde:

undefined

• GKE’de minimum etkiyle sıralı uygulama güncellemeleri (rolling update):

undefined

Yaygın hata modları: Cloud VPN üzerinden paket kaybının veritabanı replikasyonunu kesintiye uğratması (Dedicated Interconnect veya Partner Interconnect kullanın), devreye alma sırasında çift yazma (dual-write) tutarsızlığı, eksik sağlık kontrollerinin (health check) sıralı güncellemeleri durdurması.

Hibrit Kimlik, Bağlanabilirlik ve Şirket İçi Entegrasyon

• Kimlik

  • Doğruluk kaynağı (source of truth) olarak Active Directory’yi koruyun. Hesap ve grup senkronizasyonu için Google Cloud Directory Sync kullanın ve kullanıcıların Google Cloud’a erişimi için SAML SSO yapılandırın.
  • Roller aracılığıyla en az ayrıcalık (least-privilege) ilkesine uygun IAM yetkileri verin, iş yükleri için hizmet hesapları (service account) kullanın ve uzun ömürlü anahtarlar yerine Workload Identity Federation’ı tercih edin.

• Hibrit bağlanabilirlik ve yönlendirme

  • Başlangıçtaki düşük verim gerektiren ihtiyaçlar ve testler için Cloud VPN kullanın; sürekli bant genişliği, daha düşük gecikme süresi ve öngörülebilir replikasyon performansı için Dedicated Interconnect’e geçin. Dayanıklılık için yedekli VLAN ekleri ve HA VPN veya çift interconnect bağlantıları dağıtın.
  • Uçtan uca erişilebilirliği korumak için Google Cloud IP aralıklarının şirket içi CIDR’larla çakışmadığından emin olun.

  • Güvenlik duvarı kuralları ve etiketlerle katmanlı erişimi zorunlu kılın. Sadece web→API erişimine izin verme örneği:

undefined

• Genel ağa çıkış (public egress) olmadan hizmetten hizmete iletişim için Private Service Connect ve özel Google erişimini kullanın; uygun yerlerde VPC Service Controls ile segmentasyon yapın.

• Hibrit DNS: Hem şirket içi hem de bulut adlarını çözümlemek için yönlendirme (forwarding) ve gelen/giden (inbound/outbound) politikalarıyla Cloud DNS kullanın.

• Şirket içi entegrasyon ve gecikme süresi

  • Durumu (state) işlem gücüne (compute) yakın tutun veya tam tersi; eğer şirket içi veritabanı yetkili (authoritative) kalmalıysa, özel erişim için Cloud VPN/Interconnect ile App Engine flexible veya Compute Engine kullanmayı düşünün.
  • Senkron yolları ayırmak (decouple) ve gecikme süresi dalgalanmalarını (jitter) absorbe etmek için önbellekler (cache) ve kuyruklar (queue) kullanın; sadece ortalamaları değil, p95/p99 gecikme sürelerini ölçün.

Yaygın hata modları: çakışan CIDR’ların rotaları engellemesi, yetersiz BGP oturum yedekliliği, genel DNS veya ağ çıkış (egress) sızıntılarının özel hizmetleri açığa çıkarması ve yüksek gecikmeli bağlantılar üzerinde beklenmedik şekilde yoğun iletişim kuran (chatty) protokollerin sorun yaşaması.

Modernizasyon, İşletim Modeli ve Optimizasyon

• Eski sistem modernizasyon kalıpları

  • Strangler fig (Boğucu İncir): Monolitin önüne bir API cephesi (facade) yerleştirin ve alan adlarını (domain) artımlı olarak yeni servislere yönlendirin.
  • Konteynerleştirme: Temel imajları standartlaştırın (uyumlu olduğunda Alpine gibi slim imajları tercih edin), bağımlılık kurulumunu önbelleğe almak için Dockerfile katmanlarını kaynak kodunu kopyalamadan önce sıralayarak derleme süresini azaltın ve staging ortamında otomatik testler içeren bir CI/CD ardışık düzeni benimseyin.
  • Yönetilen veri: Operasyonel veri depolarını yönetilen veritabanlarına taşıyın; her alan adı (domain) için özel seçim yapın: Transactional (işlemsel) iş yükleri için Cloud SQL, zaman serisi (time-series) için Bigtable, global olarak tutarlı (globally consistent) iş yükleri için Spanner.

• Uygulama uyumluluğu, tutarlılığı ve performans doğrulaması

  • İşletim sistemi ve ara katman (middleware) desteğini, thread ve bağlantı limitlerini ve dosya sistemi semantiğini onaylayın. Lisans taşınabilirliğini ve kullanım ölçümünü doğrulayın.
  • Veri tutarlılığı gereksinimlerini tanımlayın (kendi yazdığını okuma (read-your-write), monotonik okumalar (monotonic reads), nihai ve güçlü tutarlılık (eventual vs strong)). Bunları hedef veritabanları ve erişim kalıplarıyla uyumlu hale getirin.
  • Yük testleri ve sentetik kullanıcı yolculukları ile performansı doğrulayın; geçiş sonrası SLO bütçelerinin ulaşılabilir olduğundan emin olun.

• Gözlemlenebilirlik ve uyumluluk

  • Mikroservisler arasındaki gecikmeyi (latency) yerelleştirmek için uygulamaları Cloud Logging, Monitoring ve Trace ile enstrümante edin.
  • Denetim günlüklerini (audit logs) ve IAM ilke değişikliklerini BigQuery’ye aktarın ve denetçilerle veri kümeleri üzerinde görünümler (views) ve IAM aracılığıyla paylaşın. Çok yıllık saklama gereksinimlerini karşılamak için uzun vadeli metrikleri Cloud Storage’a aktarın.

• İşletim modeli ve sahiplik

  • SRE uygulamalarını benimseyin: SLO’lar, hata bütçeleri (error budgets), olay müdahalesi (incident response) ve suçlayıcı olmayan postmortem’ler. Servis sahipliğini, runbook’ları ve nöbet (on-call) rotasyonlarını tanımlayın.
  • Altyapıyı tutarlı bir şekilde sağlamak için IaC (ör. Terraform) kullanın. Deployment Manager’ın Google’a özgü olduğunu ve çoklu bulut kaynak otomasyonunu sınırlayabileceğini ve birçok mühendis tarafından bilinmediğini unutmayın.
  • Projeler ve ortamlar arasında Organization Policy, IAM Conditions, Config Sync ve Policy Controller (OPA Gatekeeper) ile ilke tutarlılığını otomatikleştirin.

• Çoklu bulut stratejisi ve teknolojiye bağımlılık (lock-in) değiş tokuşları

  • Kubernetes, 12 faktörlü uygulama (12-factor app) pratikleri, OpenAPI ile tanımlanmış sözleşmeler (contracts) ve veri çıkışı (egress) soyutlamaları ile taşınabilirliği artırın. Taşınabilirliği operasyonel yük ve performansla dengeleyin; yönetilen servisler iş yükünü (toil) azaltır ancak geçiş maliyetini artırabilir.

• Maliyet ve performans optimizasyonu; hizmetten çıkarma

  • Durumsuz (stateless) Compute Engine’i yönetilen örnek grupları (managed instance groups) ve otomatik ölçeklendirme (autoscaling) ile ölçeklendirin; sıfıra kadar ölçeklenmeden (scale-to-zero) yararlanan anlık (bursty) veya MVP iş yükleri için sunucusuz (Cloud Functions veya Cloud Run) çözümleri seçin.
  • VM’leri doğru boyutlandırın (rightsize), GKE’de otomatik ölçeklendirmeyi etkinleştirin, taahhütlü kullanım indirimleri (committed use discounts) uygulayın ve kullanılmayan yapıları (artifacts) hizmetten çıkarın. Fayda gerçekleşmesini KPI’lar (kullanılabilirlik, gecikme, hizmet başına maliyet) aracılığıyla takip edin.
  • Bir bekleme süresi (cooling period) ve bağımlılık onayından sonra şirket içi (on-prem) sistemleri hizmetten çıkarın. Verileri saklama ilkesine göre arşivleyin veya silin ve CMDB’yi güncelleyin.

Pratik Problem Senaryosu

Acme Weather Networks, gerçek zamanlı sensör platformunu ve eski bir J2EE yönetici arayüzünü şirket içi (on-prem) bir veri merkezinden Google Cloud’a taşımalıdır. Sistem, saniyede 10 okuma gönderen 50.000 sensörden veri alıyor ve beş yıllık geçmiş veriyi (75 TB) saklıyor. Geçiş sırasında şirket içi ERP ve Active Directory’ye özel erişimi sürdürmeli, şirket içi bir MySQL veritabanı için kesinti süresini en aza indirmeli ve VPN üzerinden gözlemlenen aralıklı replikasyon hatalarını ortadan kaldırmalıdır.

1. Güvenli bir başlangıç bölgesi (landing zone) oluşturun

   • Kuruluş (org), klasörler (folders) ve prod/nonprod projeleri oluşturun. Hibrit bağlantı aracılığıyla şirket içi erişilebilirliği sağlamak için çakışmayan IP aralıklarına sahip bir Shared VPC kurun. Kuruluş ilkelerini (org policies) ve en az ayrıcalıkla (least-privilege) erişimle BigQuery’ye merkezi denetim günlüğü aktarımlarını uygulayın.
   • Gerekçe: İş yükleri gelmeden önce yönlendirme çakışmalarını önlemek ve temel yönetişimi zorunlu kılmak.

2. Hibrit kimlik uygulayın

   • AD kimliklerini ve gruplarını yansıtmak için Google Cloud Directory Sync’i yapılandırın ve SAML SSO’yu kurun. Platform ve iş yükleri için hizmet hesapları (service accounts) ve IAM özel rollerini (custom roles) kullanın.
   • Gerekçe: Kurumsal kimliği doğruluk kaynağı (source of truth) olarak korur ve en az ayrıcalıklı erişim kontrolünü sağlar.

3. Bağlantıyı sağlayın ve performans için plan yapın

   • Geliştirme/test için HA Cloud VPN ile başlayın. Üretim veritabanı replikasyonu ve istikrarlı sensör alımı için, çift VLAN eklentisi (VLAN attachments) ve BGP oturumları ile Dedicated Interconnect sağlayın.
   • Gerekçe: Interconnect, VPN’e göre daha düşük gecikme ve daha az paket kaybı sağlayarak MySQL replikasyonunu ve akış halindeki veri alımını (streaming ingestion) stabilize eder.

4. Geçmiş verileri verimli bir şekilde taşıyın

   • Transfer Appliance sipariş edin, 75 TB’lık veri setini şirket içinde yükleyin, gönderin ve Cloud Storage’a yeniden yükleyin (rehydrate). Gerekirse devam eden artımlı güncellemeler için Storage Transfer Service’i kullanın. Bigtable veya BigQuery depolamasından önce Kişisel Tanımlanabilir Bilgileri (PII) kimliksizleştirmek için destek günlükleri üzerinde Cloud DLP çalıştırın.
   • Gerekçe: Çevrimdışı toplu transfer, devreye alma (cutover) penceresi riskini azaltır ve devrelerin doygunluğa ulaşmasını önler.

5. J2EE yönetici arayüzünü yeniden barındırın (rehost)

   • J2EE VM’ini Compute Engine’e lift-and-shift yapmak için Migrate to Virtual Machines kullanın. Örnekleri (instances) bir HTTP(S) yük dengeleyicinin (load balancer) arkasındaki bir yönetilen örnek grubuna (managed instance group) yerleştirin. Yalnızca web→API→DB akışlarını zorunlu kılmak için etiketlere (tags) göre güvenlik duvarı kuralları uygulayın. Örnek:

undefined

• Gerekçe: Bilinen bir çalışma zamanı (runtime) ile riski hızla azaltırken en az ayrıcalıklı ağ yollarını zorunlu kılmak.

6. MySQL’i minimum kesintiyle Cloud SQL’e taşıyın

   • Kaynakta performansı temel alın (baseline) ve ikili günlük kaydını (binary logging) etkinleştirin. Cloud SQL’e sürekli replikasyon kurmak için Database Migration Service’i kullanın. Otomatik depolama artışını etkinleştirin ve CPU %75’e yaklaştığında ve replikasyon gecikmesi (replication lag) 60 saniyenin altına düştüğünde uyarılar (alerts) oluşturun.
   • Gerekçe: Çevrimiçi geçiş, düşük kesinti süresi sağlar; yönetilen SQL, iş yükünü (toil) azaltır ve operasyonel SLO’ları zorunlu kılar.

7. Kontrollü devreye alma (cutover) gerçekleştirin

   • 48 saat önceden DNS TTL’lerini düşürün, şema değişikliklerini dondurun ve bir bakım penceresi planlayın. Şirket içinde yazma işlemlerini durdurun, DMS gecikmesinin sıfır olduğundan emin olun, sağlama toplamlarını (checksums) ve uygulama duman testlerini (smoke tests) çalıştırın ve ardından istemcileri Cloud SQL’e yönlendirin. Doğrulama başarısız olursa yazma işlemlerinin tekrar şirket içine yönlendirilebileceği bir geri alma (rollback) planı bulundurun.
   • Gerekçe: Belirleyici adımlar RTO’yu sınırlar ve veri tutarlılığını korur.

8. Gerçek zamanlı telemetri için veri alımı (ingestion) oluşturun

   • Pub/Sub aracılığıyla veri alın, Dataflow ile işleyin ve düşük gecikmeli yazma ve okumalar için zaman serisi verilerini Bigtable’da saklayın. ERP entegrasyonunu Interconnect üzerinden özel (private) tutun.
   • Gerekçe: Bigtable, yüksek verimli (high-throughput) zaman serisi profiliyle eşleşir ve Pub/Sub, anlık yoğunluk yaşayan üreticileri (producers) tüketicilerden (consumers) ayırır.

9. Servisleri konteynerleştirin ve CI/CD’yi tanıtın

   • GKE için durumsuz (stateless) servisleri konteynerleştirin. Slim temel imajlar kullanarak ve katmanları bağımlılık kurulumu kaynak kodunu kopyalamadan önce gelecek şekilde sıralayarak Dockerfile’ları optimize edin. Staging ortamında otomatik testler ve canary dağıtımları (canary rollouts) ile bir CI/CD ardışık düzeni uygulayın. Minimum kesintiyle güncelleyin:

undefined

• Gerekçe: Büyük bir yeniden yazım (big-bang rewrite) olmadan dağıtım hızını, güvenilirliğini ve ölçeklenebilirliği artırır.

10. Gözlemlenebilirliği ve denetimi geliştirin

    • Mikroservisler arasındaki gecikmeyi (latency) tam olarak belirlemek için Cloud Logging, Monitoring ve Trace ile enstrümantasyon yapın. Denetim günlüklerini (audit logs) BigQuery’ye aktarın ve denetçi kapsamındaki görünümleri (views) paylaşın. Beş yıllık saklama süresini karşılamak için uzun vadeli metrikleri Cloud Storage’a aktarın.
    • Gerekçe: Tam doğrulukta telemetri, SLO’ları ve uyumluluğu destekler.

11. Optimize edin ve hizmetten çıkarın

    • MIG’lerde ve GKE’de otomatik ölçeklendirmeyi etkinleştirin, örnekleri doğru boyutlandırın (rightsize), taahhütlü kullanım indirimleri (committed use discounts) uygulayın ve 7/24 çalışmayan iş yüklerini sıfıra kadar ölçeklenmesi için sunucusuz (örneğin, yardımcı görevler için Cloud Functions) platformlarda zamanlayın. Stabilite ve bir bekleme süresinden (cooling period) sonra, şirket içi sistemleri hizmetten çıkarın, CMDB’yi güncelleyin ve elde edilen faydaları yayınlayın.
    • Gerekçe: İkili çalıştırma (dual-run) masraflarını ortadan kaldırırken maliyet ve operasyonel verimlilikleri yakalamak.

12. Operasyonel hale getirin ve eğitin

    • Runbook’ları, RACI’yi, nöbet (on-call) rotasyonlarını ve SLO/hata bütçelerini (error budgets) son haline getirin. Beceri eksikliklerini kapatmak için hedefe yönelik eğitim ve sertifikasyon planları sunun. IaC için Terraform’u tercih edin; Deployment Manager’ın Google’a özgü olduğunu ve Google dışı kaynakları ele alamayabileceğini unutmayın.
    • Gerekçe: Olgun bir işletim modeli, geçiş olayının ötesinde güvenilirliği ve hızı sürdürür.

← Güvenilirlik · Tüm alanlar · Operasyonlar →

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

Google'a göz atın →