Örnek sorular
Ci Cd PipelinesZorluk 3
GitOps kurulumunda, bir ortamın istenen durumu bir Git repository'sinde deklaratif olarak tanımlanır ve otomatik bir controller, canlı ortamı sürekli olarak orada commit edilenle eşleşecek şekilde reconcile eder. Ortama doğrudan deploy komutları çalıştıran bir pipeline'a kıyasla, GitOps'un getirdiği temel yapısal fark nedir?
- aGit, istenen durum için tek doğru kaynak hâline gelir ve reconciliation yalnızca deploy anında değil sürekli olarak çekilip uygulanır.✓
- bGitOps herhangi bir pipeline ihtiyacını tamamen ortadan kaldırır, çünkü uygulama kodunu tek başına Git build edip test edebilir.
- cGitOps, tüm ortamların aralarında hiçbir ayrım olmadan tek bir Git repository'sini paylaşmasını zorunlu kılar.
- dGitOps, otomatik reconciliation tasarım gereği devre dışı olduğundan deploy'ların yalnızca manuel tetiklenebileceği anlamına gelir.
Açıklama:GitOps'taki belirleyici değişim, Git'in deklare edilen istenen durumu tutması ve bir controller'ın canlı ortamı buna doğru sürekli çekip reconcile etmesidir; bu, yalnızca pipeline bir deploy komutu çalıştırdığında olan tek seferlik bir push'tan farklıdır. Bu ayrıca tek seferlik bir apply değil, sürekli drift düzeltmesi de sağlar. b yanlıştır — GitOps yine de build/test için bir pipeline'a ihtiyaç duyar, değiştirdiği şey deploy reconciliation'ının nasıl olduğudur, pipeline'ın var olup olmadığı değil. c gereksiz bir kısıtlama uydurur; ortamlar genelde repo, branch veya dizin ile yine ayrılabilir. d, GitOps'a ters düşer; GitOps özellikle reconciliation'ı devre dışı bırakmak yerine otomatikleştirir.
Ci Cd PipelinesZorluk 3
İki ekip de pipeline'larının "testler geçtikten sonra otomatik olarak production'a deploy ettiğini" söylüyor. A ekibinde deploy adımı çalışmadan önce birinin manuel onay butonuna tıklaması gerekiyor. B ekibinde ise hiçbir manuel kapı yok — geçen bir pipeline doğrudan production'a deploy ediyor. Sırasıyla A ve B ekibinin pratiğini en doğru etiketleyen terim çifti hangisidir?
- aA ekibi continuous integration uygular; B ekibi continuous delivery uygular.
- bA ekibi continuous delivery uygular; B ekibi continuous deployment uygular.✓
- cA ekibi continuous deployment uygular; B ekibi continuous delivery uygular.
- dA ve B ekibi ikisi de aynı continuous deployment'ı uygular, çünkü ikisi de otomatik deploy ediyor.
Açıklama:Continuous delivery, her doğrulanmış değişikliği release'e hazır tutar ama nihai production release kararını bir insana bırakır (A ekibinin manuel kapısı). Continuous deployment ise bu kapıyı tamamen kaldırır, böylece pipeline'ı geçen her değişiklik otomatik olarak canlıya çıkar (B ekibi). a şıkkı iki ekibi de gerçekte oldukları aşamadan daha geriye etiketler. c iki tanımı yer değiştirir. d, iki pratiği ayıran manuel onay farkını yok sayarak yanlış biçimde herhangi bir ayrım olmadığını iddia eder.
Ci Cd PipelinesZorluk 3
Bir soruşturma sırasında bir mühendis, üç hafta önce çalışan bir job'un pipeline log'larında bir database şifresinin düz metin olarak yazdırıldığını fark ediyor; çünkü bir script, kaldırılmadan önce debug amacıyla echo $DB_PASSWORD kullanmış. Log'lar hâlâ saklanıyor ve pipeline'a okuma erişimi olan herkes tarafından görüntülenebiliyor. En uygun acil tepki nedir?
- aBaşka bir şey yapmamak, çünkü şifreyi yazdıran debug satırı script'ten zaten kaldırılmış.
- bSaklanan eski log'larda şifreyi geriye dönük olarak maskelemesi için pipeline'ın log masking özelliğine güvenmek.
- cDebug satırını kaldırmaya ek olarak, ifşa olan credential'ı rotate etmek ve ele geçirilmiş kabul etmek.✓
- dKullanılmayan eski bir log'un okunması pek olası olmadığı için bir sonraki planlı credential rotation döngüsünü beklemek.
Açıklama:Bir secret, okuma erişimi olan herkesin görebileceği log'lara yazdırıldıktan sonra, buna neden olan debug satırı sonradan kaldırılmış olsa bile ele geçirilmiş kabul edilmelidir — rotate etmek gerçek ifşa penceresini kapatır. a yalnızca gelecekteki ifşayı önler, saklanan log'larda zaten görünür olan credential hakkında hiçbir şey yapmaz. b yaygın bir yanılgıdır: masking tipik olarak ileriye dönük yazdırma anında uygulanır, zaten depolanmış log içeriğine geriye dönük değil. d, bilinen ve zaten ifşa olmuş bir secret'ın düzeltilmesini gereksiz yere geciktirir.
Ci Cd PipelinesZorluk 3
Bir monorepo birkaç bağımsız servis içeriyor. Şu anda, bir değişiklik yalnızca bir servisin dizinine dokunsa bile her push tüm servisler için tam pipeline'ı çalıştırıyor. Bu, her çalışmayı gerekenden çok daha uzun sürdürüyor. Bunu en iyi çözecek pipeline tasarım değişikliği hangisidir?
- aMonorepo'yu servis başına ayrı bir repository'ye bölmek, çünkü path bazlı filtreleme başka türlü mümkün değildir.
- bDoğrudan dokunulmamış servisler için test stage'ini kaldırmak, ama build ve deploy stage'lerini yine de çalıştırmak.
- cPipeline'ı değişen path'leri tespit edecek ve yalnızca dizini değişen servisler için job çalıştıracak şekilde yapılandırmak.✓
- dTüm servisler için tam pipeline aynı anda bitsin diye paralel runner makine sayısını artırmak.
Açıklama:Path bazlı tetikleme (dizin/dosyalarda değişiklik tespiti), bir monorepo pipeline'ının yalnızca gerçekten değişenle ilgili job'ları çalıştırmasını sağlar, test kapsamını azaltmadan çalışma süresini kısaltır. a gereksiz derecede sert bir yapısal değişikliktir; çoğu CI/CD aracı tek bir monorepo içinde path filtrelerini destekler. b güvensizdir — dokunulmamış görünen bir servisi hâlâ deploy ederken testlerini atlamak, bayat doğrulamaya dayanarak deploy etme riski taşır. d, gereksiz işten kaçınmak yerine soruna sadece daha fazla donanım atar ve boşa harcanan hesaplamayı azaltmaz.
Ci Cd PipelinesZorluk 3
Belirli bir integration test, ilgisiz pull request'lerde aralıklı olarak, kabaca beş çalışmadan birinde, hatalarla tutarlı biçimde ilişkilendirilebilecek bir kod değişikliği olmadan başarısız oluyor. Geliştiriciler daha fazla araştırma yapmadan pipeline her başarısız olduğunda rutin olarak yeniden çalıştırmaya başladı. Bu örüntünün ele alınmadan bırakılmasının temel uzun vadeli riski nedir?
- aEkip pipeline hatalarına giderek güvenini kaybeder ve bir gün gerçek bir regresyonu da refleks olarak yeniden çalıştırıp geçebilir.✓
- bPipeline aracı sonunda aynı job'u iki kez çalıştırmayı reddedecek ve daha fazla yeniden çalıştırmayı kalıcı olarak engelleyecektir.
- cFlaky test otomatik olarak her branch'te zorunlu bir check'e yükseltilecek ve tüm gelecekteki merge'leri engelleyecektir.
- dTekrarlanan yeniden çalıştırmalar yüzünden build caching sessizce bozulacak ve bundan böyle geçersiz artifact'ler üretecektir.
Açıklama:İnsanların alışkanlıkla düzeltmek veya karantinaya almak yerine yeniden çalıştırıp geçtiği bilinen bir flaky test, pipeline'a bir sinyal olarak duyulan güveni aşındırır — gerçek tehlike, gerçek bir regresyonun bir gün 'muhtemelen sadece flaky test' diye görmezden gelinip araştırılmak yerine yeniden çalıştırılıp geçilebilecek olmasıdır. b, c ve d şıklarının hepsi pipeline araçlarının gerçekte sergilemediği mekanik arızalar uydurur; buradaki gerçek risk aracın kendisinin teknik bir arızası değil, insan/süreç kaynaklı (aşınan güven) bir risktir.
Cloud Architecture ScalingZorluk 3
Bir ekip, gün içinde trafiği değişen ama taban yükü yıl boyunca öngörülebilir ve istikrarlı olan bir servis işletiyor. En maliyet-etkin altyapı stratejisi hangisidir?
- aTüm kapasiteyi tamamen on-demand çalıştırmak, çünkü reserved kapasiteye taahhüt vermek değişken bir iş yükü için gereken esnekliği her zaman azaltır
- bGünlük tepe yükü karşılayacak tüm kapasiteyi reserve etmek, çünkü reserved fiyatlandırma autoscaling'i düşünme ihtiyacını tamamen ortadan kaldırır
- cÖngörülebilir taban yükü reserved kapasiteyle karşılamak, değişken/tepe trafiği ise autoscaling ile eklenen on-demand instance'larla karşılamak✓
- dKurulumu basit tutmak için autoscaling'i tamamen devre dışı bırakıp her zaman tepe yüke göre boyutlandırılmış sabit sayıda büyük on-demand instance çalıştırmak
Açıklama:Bilinen, istikrarlı taban yük için reserved kapasite ile öngörülemeyen tepe için on-demand (genelde autoscale edilen) kapasiteyi birleştirmek, istikrarlı kullanım için indirimi yakalarken değişken kısım için esnekliği korur. b, günün çoğunda gerçekleşmeyen tepe yükü karşılamak için reserved kapasiteye aşırı taahhüt verir ve para kaybettirir. d ise autoscaling'i tamamen terk eder ve 7/24 tepe seviyesinde maliyet öder; anlatılan en pahalı seçenektir.