Prod Doğrulama, Release Stratejileri ve Uçtan Uca Yapay Zeka İş Akışı

Kazanimlar:

• Riski azaltan release stratejilerini (blue-green, canary, feature flag) ve prod doğrulama disiplinini (sağlık kontrolü, smoke test, altın sinyal izleme) kavrayabilme
• Bir deploy öncesi net rollback planı hazırlama ve deploy sonrası kritik iş yollarını doğrulama alışkanlığını uygulayabilme
• Modül boyunca öğrenilen tüm parçaları uçtan uca bir yapay zeka destekli iş akışında birleştirip her adımda 'YZ üretir, insan doğrular ve kefil olur' ilkesini uygulayabilme

Bütün bu modül tek bir ana doğru akıyordu: kodun ve altyapının güvenle prod'a (production — gerçek müşterilerin kullandığı canlı ortam) ulaşması. Şimdi zincirin en kritik ve en gerilimli halkasındayız: bir değişikliği canlıya almak ve orada gerçekten çalıştığını doğrulamak. Burada bir hata soyut değildir — müşteriyi, geliri ve itibarı doğrudan vurur. Bu yüzden olgun ekipler prod'a "umarak" değil, kontrollü release stratejileri ve sistematik doğrulama ile çıkar.

Bu son ünitede iki şeyi birleştiriyoruz: (1) riski azaltan yayın yöntemleri (canary, blue-green, feature flag) ve prod doğrulama disiplini; (2) modül boyunca öğrendiğimiz her parçanın — CI/CD, IaC, konteyner, izleme, incident, maliyet, script, güvenlik — YZ destekli uçtan uca tek bir iş akışında nasıl birleştiği. En baştaki sözü son kez tekrarlayalım: YZ her adımda taslak üretir ve hızlandırır; ama "bunu canlıya alıyorum" düğmesine basan, sonucuna kefil olan siz kalırsınız.

Riski azaltan release stratejileri

Bir değişikliği tüm kullanıcılara aynı anda vermek en riskli yoldur. Olgun yöntemler:

• Blue-Green Deployment: İki özdeş ortam tutulur — "mavi" (canlı) ve "yeşil" (yeni sürüm). Yeni sürüm yeşilde hazırlanıp test edilir, sonra trafik bir anda yeşile çevrilir. Sorun çıkarsa trafik anında maviye geri döner. Hızlı geri alma (rollback) en büyük avantajıdır.
• Canary Deployment: Yeni sürüm önce kullanıcıların küçük bir yüzdesine (örneğin %5) verilir; metrikler iyiyse kademeli olarak %100'e çıkarılır. Bir sorun tüm kullanıcıyı değil, küçük bir dilimi etkiler.
• Feature Flag (özellik bayrağı): Yeni özellik koda girer ama bir bayrakla kapalı durur; istendiğinde belirli kullanıcılara açılır. Deploy ile "yayınlama" (release) birbirinden ayrılır; sorun olursa kod geri alınmadan bayrak kapatılır.

İpucu: En hızlı güvenlik ağı, her deploy'dan önce geri alma yolunu (rollback) hazır tutmaktır. "Bir şeyler ters giderse 60 saniyede eski sürüme nasıl dönerim?" sorusunun net bir cevabı yoksa, o deploy'u yapmaya hazır değilsinizdir.

Prod doğrulama: deploy bittiği yerde iş bitmez

Bir deploy'un "yeşil" görünmesi çalıştığı anlamına gelmez. Sistematik doğrulama:

1. Sağlık kontrolleri (health checks): Servis ayağa kalktı mı, /healthz yanıt veriyor mu?
2. Duman testleri (smoke tests): En kritik birkaç kullanıcı yolu (giriş, ödeme, arama) gerçekten çalışıyor mu? Otomatik ve hızlı.
3. Altın sinyalleri izle: Deploy sonrası hata oranı, gecikme, trafik normal mi? (6. ünitedeki dört sinyal.)
4. Kademeli genişlet: Canary yüzdesini artırırken her adımda metriklere bak.
5. Gözlem penceresi: Deploy'dan sonra bir süre (örneğin 30 dk) yakın izle; sinsi sorunlar hemen görünmez.

Dikkat: YZ bir smoke test veya doğrulama listesi üretebilir ama hangi kullanıcı yollarının "kritik" olduğunu sizin işiniz belirler. YZ genel bir liste verir; sizin ödeme akışınızın, sizin en çok gelir getiren yolunuzun mutlaka test edilmesi gerektiğini yalnızca siz bilirsiniz.

Release stratejileri karşılaştırması

Strateji

Ana avantaj

Maliyet/karmaşıklık

En uygun

Blue-Green

Anında rollback

İki ortam = 2x kaynak

Hızlı geri alma kritikse

Canary

Etkiyi küçük dilime sınırlar

Trafik yönetimi gerekir

Büyük kullanıcı tabanı

Feature Flag

Deploy'u release'ten ayırır

Bayrak yönetimi borcu

Kademeli/hedefli açılış

Rolling update

Basit, kaynak dostu

Yavaş rollback

Basit servisler

Uçtan uca YZ destekli iş akışı

Şimdi tüm modülü tek bir akışta birleştirelim. Diyelim yeni bir mikroservis yayınlıyorsunuz. YZ her adımda taslak üretir; siz her adımda doğrularsınız:

1. Kod & konteyner (Ünite 4): YZ optimize, güvenli bir Dockerfile üretir; siz secret'sızlığı ve boyutu doğrularsınız.
2. CI/CD (Ünite 2): YZ test-build-deploy pipeline'ı yazar; siz izinleri daraltır, secret referanslarını denetlersiniz.
3. Altyapı (Ünite 3): YZ Terraform ile gerekli kaynakları tanımlar; siz plan çıktısını okur, beklenmedik silme aramazsınız.
4. Orkestrasyon (Ünite 5): YZ Kubernetes manifestlerini üretir; siz kaynak limiti, prob ve RBAC'i doğrularsınız.
5. Güvenlik (Ünite 10): YZ tarama çıktılarını önceliklendirir; siz sömürülebilir olanları önce kaparsınız.
6. İzleme (Ünite 6): YZ alarm kuralları ve pano üretir; siz eşikleri geçmiş verinizle sınarsınız.
7. Release & doğrulama (bu ünite): YZ smoke test ve rollback planı taslağı verir; siz canary'yi başlatır, metrikleri izler, düğmeye basarsınız.
8. Olay olursa (Ünite 7): YZ hipotez ve postmortem taslağı üretir; siz doğrular ve dersleri çıkarırsınız.
9. Maliyet (Ünite 8): YZ yeni kaynakların israfını izler; siz right-sizing kararlarını verirsiniz.

Her adımda ortak kural sabittir: YZ üretir ve hızlandırır, insan doğrular ve kefil olur. İşte modülün özü budur.

Üç mini vaka

Vaka 1 — canary bir felaketi %5'e hapsetti. Bir ekip yeni sürümü canary ile %5 kullanıcıya verdi. YZ'nin ürettiği pano, bu dilimde hata oranının %8'e fırladığını hemen gösterdi. Ekip %100'e çıkarmadan geri aldı; sorun kullanıcıların yalnızca %5'ini, o da birkaç dakika etkiledi. Big-bang deploy olsaydı tüm müşteri etkilenirdi.

Vaka 2 — smoke test eksik yolu yakaladı. YZ bir smoke test seti önerdi ama içinde "ödeme" akışı yoktu. Mühendis, en kritik gelir yolunun ödeme olduğunu bilerek onu ekledi. Deploy sonrası smoke test tam da ödeme adımında kırıldı — üçüncü parti bir anahtar süresi dolmuştu. Doğrulama, sessiz bir gelir kaybını dakikalar içinde yakaladı.

Vaka 3 — hazır rollback 90 saniyede kurtardı. Blue-green kuran bir ekip, yeni sürümü yeşile aldı; 2 dakika sonra gecikme iki katına çıktı. Önceden hazırladıkları rollback ile trafiği 90 saniyede maviye çevirdiler. Kök nedeni (yeni sürümdeki yavaş bir sorgu) baskı altında değil, sonra sakince buldular. Hazır geri alma yolu, kesintiyi neredeyse görünmez kıldı.

Dört kopyalanabilir şablon

1) Release stratejisi seçimi:

Şu servisi prod'a alacağım: [SERVİS/BAĞLAM: kullanıcı sayısı,kesinti toleransı, altyapı]. Blue-green, canary ve feature flagarasında hangisini önerirsin? Her birinin bu bağlamdaki avantaj,maliyet ve rollback hızını karşılaştır. Bir öneri ver ama sonkararı benim vereceğimi belirt.

2) Smoke test / doğrulama listesi:

[SERVİS] için deploy sonrası çalıştıracağım bir smoke test vedoğrulama listesi taslağı üret: sağlık kontrolü, en kritik kullanıcıyolları, hangi metrikleri kaç dakika izlemeliyim? En kritik işyollarını benim işaretleyeceğimi varsay ve o alanı boş bırak.

3) Rollback planı:

[DEPLOY YÖNTEMİ] kullanıyorum. Bana net bir geri alma (rollback)planı yaz: hangi komut/adımla eski sürüme dönerim, ne kadar sürer,rollback'in kendi riskleri neler (ör. veritabanı göçü geri alınamaz),rollback'ten önce neyi kontrol etmeliyim?

4) Uçtan uca release kontrol listesi:

Yeni bir [SERVİS] prod'a çıkışı için uçtan uca bir hazırlık kontrollistesi üret: kod/imaj güvenliği, pipeline, altyapı planı, izlemeve alarm, güvenlik taraması, release stratejisi, rollback vedoğrulama. Her maddeyi "hazır mıyım?" sorusuna çevir.

Zayıf prompt / Güçlü prompt

Zayıf: "Bunu prod'a nasıl alırım?"

Sonuç: bağlam yok; YZ genel geçer deploy adımları sıralar, sizin risk toleransınıza, kullanıcı ölçeğinize ve rollback ihtiyacınıza değinmez.

Güçlü: "10 milyon kullanıcılı bir ödeme servisini prod'a alacağım, kesinti toleransım çok düşük. Canary mi blue-green mi önerirsin, neden? Deploy sonrası hangi kritik yolları smoke test etmeliyim, hangi metrikleri kaç dakika izlemeliyim ve 60 saniyelik bir rollback planı nasıl olmalı? Son kararı ben vereceğim."

Fark: ikinci istem ölçeği, toleransı ve rollback beklentisini verir; strateji + doğrulama + geri alma ister ve kararı insanda bırakır.

Sık yapılan hatalar

• Rollback planı olmadan deploy etmek. Geri dönüş yolu yoksa her deploy kumar.
• Big-bang deploy. Tüm kullanıcıya aynı anda vermek, riski en yükseğe çıkarır.
• "Yeşil = çalışıyor" varsaymak. Sağlık kontrolü geçen servis, kritik yolda kırık olabilir.
• Kritik iş yollarını YZ'ye bıraktığını sanmak. Ödeme gibi yolları siz işaretlemelisiniz.
• Deploy sonrası izlememek. Sinsi sorunlar ilk dakikada görünmez; gözlem penceresi şart.
• Veritabanı göçünü geri alınabilir sanmak. Bazı değişiklikler rollback ile geri gelmez; ayrı planlanır.

Özetle

Prod'a çıkmak zincirin en kritik halkasıdır ve "umarak" değil, kontrollü stratejilerle yapılır: blue-green anında geri alma, canary etkiyi küçük dilime sınırlama, feature flag deploy'u release'ten ayırma sağlar. Deploy bittiğinde iş bitmez; sağlık kontrolleri, smoke testler ve altın sinyal izleme ile sistematik doğrulama şarttır. YZ, tüm modül boyunca — Dockerfile'dan pipeline'a, Terraform'dan alarm kuralına, postmortem'den maliyet analizine — her adımda taslak üretip hızlandırır. Ama her adımda doğrulayan, canlıya alma düğmesine basan ve sonuca kefil olan yetkin insan kalır. Uçtan uca YZ destekli DevOps'un altın kuralı budur.

Uygulama görevi

Yayınlayacağınız (gerçek veya kurgusal) bir servis seçin. (1) "Release stratejisi seçimi" şablonuyla bağlamınıza uygun bir strateji belirleyin ve nedenini yazın. (2) "Smoke test / doğrulama listesi" şablonuyla bir doğrulama listesi ürettirin ve en kritik iş yollarını kendiniz ekleyin. (3) "Rollback planı" şablonuyla 60 saniyelik bir geri alma planı hazırlayın ve içinde geri alınamaz bir adım olup olmadığını kontrol edin.

Kontrol listesi

• [ ] Bağlamıma uygun bir release stratejisi (canary/blue-green/flag) seçtim.
• [ ] Deploy öncesi net ve hızlı bir rollback planım hazır.
• [ ] Smoke testlerime en kritik iş yollarını (ör. ödeme) kendim ekledim.
• [ ] Deploy sonrası altın sinyalleri bir gözlem penceresi boyunca izliyorum.
• [ ] Geri alınamaz adımları (veritabanı göçü vb.) ayrıca planladım.
• [ ] Her adımda YZ taslağını doğruladım; canlıya alma kararını ben verdim.

Modul Sinavi

1. DevOps ve bulutta yapay zeka için en doğru konumlandırma aşağıdakilerden hangisidir?

• A) Yapay zeka bir asistan ve karar destek aracıdır; prod'a etki eden kritik kararların sorumluluğu insandadır ✔
• B) Yapay zeka prod deploy'larını ve secret rotasyonunu insan onayı olmadan kesinleştirebilir
• C) Yapay zeka yalnızca dokümantasyon yazmakta işe yarar, altyapıyla ilgisi yoktur
• D) Yapay zeka her zaman mühendisten daha güvenilir komut ürettiği için denetim gereksizdir

Aciklama: Yapay zeka pipeline, yapılandırma, betik ve log gibi metin ağırlıklı işlerde hız kazandıran bir asistan ve karar destek aracıdır. Canlı ortama (prod) yayın, secret yönetimi ve son uygulama gibi kesinti, para ve güvenlik etkileyen kararların sorumluluğu ise yetkin mühendiste kalır.

2. Yapay zekanın ürettiği bir DevOps komutu veya yapılandırmasını uygulamadan önceki doğrulama disiplini için en doğru ifade hangisidir?

• A) Çıktı akıcı ve kendinden emin görünüyorsa doğrudan prod'da çalıştırılabilir
• B) Yalnızca sözdizimi hatası yoksa çıktı güvenlidir, başka kontrol gerekmez
• C) Çıktıyı kaynağa bağla, kuru çalıştır (plan/dry-run) ve kendi sistem bağlamınla süz; sonra uygula ✔
• D) İlk denemeyi doğrudan prod'da yapıp sonucu izlemek en hızlı doğrulamadır

Aciklama: Üç adımlı doğrulama esastır: çıktıyı kaynağa bağlamak (komut/bayrak resmi dokümanda gerçekten var mı), kuru çalıştırmak (plan/--dry-run ile ne olacağını görmek) ve sistem süzgecinden geçirmek (kendi mimari ve güvenlik bağlamına uyuyor mu). Akıcılık doğruluk anlamına gelmez.

3. Bir hata veya deploy sorununu yapay zekaya sorarken içinde gerçek bir veritabanı parolası olan .env dosyasıyla ilgili doğru yaklaşım nedir?

• A) Gerçek secret'ları <PLACEHOLDER> ile maskele; yalnızca maskelenmiş hata ve bağlamı paylaş ✔
• B) Tüm .env dosyasını olduğu gibi yapıştırmak sorunu daha hızlı çözer
• C) Secret'lar zaten base64 olduğu için düz yapıştırmak güvenlidir
• D) Parolayı yapıştırmak sakıncasızdır çünkü yapay zeka onu asla saklamaz

Aciklama: Hiçbir gerçek secret yapay zeka istemine yapıştırılmaz. Parola, token gibi değerler <PLACEHOLDER> ile maskelenir; yalnızca hata mesajı ve gerekli bağlam paylaşılır. Secret zaten sızmışsa derhal iptal edilip yenilenmelidir (rotate).

4. Bir CI/CD pipeline'ında secret'ların (parola, token) doğru yönetimi aşağıdakilerden hangisidir?

• A) Platformun secret deposunda tutulur ve referansla (örn. ${{ secrets.X }}) çağrılır, düz metin yazılmaz ✔
• B) Kolaylık için pipeline YAML'ına düz metin olarak yazılır
• C) Her job'un başında echo ile log'a basılarak doğrulanır
• D) En geniş izinle (write-all) tanımlanırsa güvenlik artar

Aciklama: Secret'lar YAML'a düz metin yazılmaz; platformun secret deposunda tutulup ${{ secrets.X }} gibi referanslarla çağrılır. Ayrıca en az yetki ilkesiyle token izinleri daraltılır ve secret log'a basılmaz.

5. Terraform ile altyapı yönetiminde, bir değişikliği canlıya uygulamadan önce yapılması gereken en kritik adım nedir?

• A) Doğrudan 'terraform apply' çalıştırmak; plan zaman kaybıdır
• B) State dosyasını halka açık bir depoya yedeklemek
• C) 'terraform plan' çalıştırıp çıktıdaki destroy/replace satırlarını denetlemek, sonra uygulamak ✔
• D) Provider sürümünü kaldırıp en yeni sürümün otomatik gelmesini sağlamak

Aciklama: 'terraform apply' öncesinde mutlaka 'terraform plan' çalıştırılır. Plan, ne ekleneceğini, ne değişeceğini ve özellikle ne silineceğini (destroy) hiçbir şey uygulamadan gösterir. Beklenmedik bir destroy veya replace satırı görülürse apply yapılmamalıdır.

6. Bir Terraform plan çıktısında üretim veritabanı için '-/+ replace' satırı görülürse ne anlama gelir ve ne yapılmalıdır?

• A) Kaynak sadece yerinde güncellenecek, hiçbir risk yok
• B) Kaynak silinip yeniden oluşturulacak; veri kaybı riski var, beklenmiyorsa apply durdurulmalı ✔
• C) Yeni bir kaynak ekleniyor, mevcut veritabanı etkilenmez
• D) Bu yalnızca bir uyarıdır, güvenle yok sayılabilir

Aciklama: '-/+ replace', kaynağın silinip yeniden oluşturulacağı anlamına gelir; bir veritabanı için bu veri kaybı demektir. Beklenmiyorsa apply durdurulmalı, değişiklik güvenli bir yönteme çevrilmeli veya değiştirilemez alana dokunulmamalıdır.

7. Bir Dockerfile'ın güvenliği ve boyutu açısından üretime hazır olması için aşağıdakilerden hangisi doğrudur?

• A) Kolaylık için secret'ı ENV ile imaja gömmek ve root olarak çalıştırmak
• B) Her zaman ':latest' etiketi kullanıp temel imajı olabildiğince büyük tutmak
• C) Tek aşamalı build ve tüm derleme araçlarını son imajda bırakmak
• D) Secret'ı gömmemek, yetkisiz USER ile çalışmak, küçük ve sürümü sabit temel imaj ve çok aşamalı build kullanmak ✔

Aciklama: Üretime hazır bir imaj: secret'ı gömmez (runtime'da enjekte eder), root yerine yetkisiz bir USER ile çalışır, küçük ve sürümü sabit bir temel imaj (slim/alpine, :latest değil) kullanır ve çok aşamalı build ile küçültülür. Ayrıca yayından önce zafiyet taramasından geçirilir.

8. Kubernetes'te bir Deployment'a kaynak limiti (limits) tanımlanmamasının en önemli riski nedir?

• A) Pod hiç başlamaz, çünkü limit zorunlu bir alandır
• B) Sadece izleme panosunda bir uyarı çıkar, çalışma etkilenmez
• C) Kubernetes otomatik olarak güvenli varsayılan limitler uygular, risk yoktur
• D) Pod sınırsız büyüyüp düğümün kaynağını tüketerek komşu servisleri de çökertebilir ✔

Aciklama: Kaynak limiti olmayan bir Pod, örneğin bir bellek sızıntısıyla sınırsızca büyüyüp üzerinde çalıştığı düğümün (node) tüm kaynağını tüketebilir ve komşu servisleri de çökertebilir. Bu yüzden requests/limits tanımlamak sağlamlığın temelidir.

9. İzleme ve alarm kurulumunda 'alarm yorgunluğu' (alert fatigue) nasıl önlenir?

• A) Olabildiğince çok metriğe alarm kurup her dalgalanmada uyarı üretmek
• B) Tüm alarmları en yüksek önem düzeyine ayarlamak
• C) Alarmlara süre (for) koymadan anlık değerlerle tetiklemek
• D) Alarmları eyleme dönük ve doğru aciliyette tutmak, eşikleri geçmiş veriyle sınamak, gereksizleri birleştirmek ✔

Aciklama: Her alarm eyleme dönük (actionable) ve doğru aciliyette olmalıdır; eylem gerektirmeyen bilgiler panoda gösterilir, kimseyi uyandırmaz. Alarm eşikleri sistemin geçmiş verisiyle sınanır ve gereksiz/tekrar eden alarmlar birleştirilir. Böylece gerçek alarm gürültüde kaybolmaz.

10. Bir üretim olayı (incident) sırasında en doğru öncelik sıralaması nedir?

• A) Önce tam kök nedeni bulmak, azaltmayı ancak neden netleşince yapmak
• B) Önce postmortem raporunu yazmak, sonra servise dokunmak
• C) Önce azaltmak (servisi ayağa kaldır/geri al), kök neden analizini sonraya bırakmak ✔
• D) Önce olayın sorumlusunu bulup raporlamak

Aciklama: Altın kural 'önce azalt, sonra soruştur'dur. Amaç önce hizmeti ayağa kaldırmak veya bilinen-iyi sürüme geri almaktır (mitigate); kök neden analizi baskı azaldıktan sonra sakince yapılır. Tam kök nedeni bulmayı beklemek toparlanma süresini (MTTR) büyütür.

11. Suçsuz (blameless) postmortem kültürünün temel amacı nedir?

• A) Hatayı yapan kişiyi belirleyip sorumluluğu ona yüklemek
• B) Sistem ve süreçlere odaklanıp öğrenmeyi teşvik etmek; suçlama yerine tekrarı önleyen dersler çıkarmak ✔
• C) Olayı hiç raporlamayıp unutulmasını sağlamak
• D) Yalnızca teknik detayı yazıp eyleme dönük madde eklememek

Aciklama: Blameless postmortem 'kim yaptı' değil 'hangi sistem ve süreç bu hataya izin verdi' sorusuna odaklanır. İnsanlar cezalandırılmayacağını bilirse hatayı açıkça paylaşır; gizlenen hata tekrarlanır. Rapor bir suçlama tutanağı değil, eyleme dönük maddelerle dolu bir öğrenme belgesidir.

12. Bulut maliyet optimizasyonunda (FinOps), taahhütlü indirimlere (Reserved/Savings Plan) geçmeden önce yapılması gereken en mantıklı adım nedir?

• A) Önce mümkün olan en uzun taahhüdü almak, israfı sonra düşünmek
• B) Önce israfı temizlemek (atıl kapatma, right-sizing), sonra kararlı kullanımı taahhüde bağlamak ✔
• C) Tüm kaynakları hemen Spot kapasiteye taşımak
• D) Fatura verisini hiç incelemeden en pahalı kalemi silmek

Aciklama: Önce israf temizlenmelidir (atıl kaynakları kapatmak, aşırı boyutlu kaynakları küçültmek). Aksi halde israf edilen kullanımı indirimli fiyata 1-3 yıl kilitlemiş olursunuz. Right-sizing ve atıl temizliği taahhüt gerektirmez ve risksize yakındır.

13. Yapay zekanın önerdiği bir betikte 'rm -rf "$DIR"/' satırı varsa en önemli güvenlik önlemi nedir?

• A) Betiği okumadan doğrudan prod'da çalıştırmak, hız kazandırır
• B) set -euo pipefail ve boş değişken kontrolü ekleyip önce dry-run ile denemek ✔
• C) Değişken adını kısaltmak yeterlidir
• D) rm yerine rm -rf --force kullanmak sorunu çözer

Aciklama: $DIR boşsa bu ifade kök dizini silmeye çalışabilir. 'set -u' ile tanımsız değişkende durmak ve silmeden önce değişkenin boş olmadığını kontrol etmek (örn. [ -n "$DIR" ] || exit 1) felaketi önler. Ayrıca yıkıcı işlemler önce dry-run ile denenmelidir.

14. Bir bulut erişim anahtarı yanlışlıkla halka açık bir depoya sızarsa ilk yapılması gereken nedir?

• A) Anahtarı derhal iptal edip yenilemek (rotate); silmek tek başına yetmez ✔
• B) Sadece dosyayı depodan silmek yeterlidir, anahtar güvendedir
• C) Kimse görmemiştir diye hiçbir şey yapmamak
• D) Depoyu gizli (private) yapmak, anahtarı döndürmeye gerek bırakmaz

Aciklama: Sızan secret derhal iptal edilip yenilenmelidir (rotate). Sadece dosyayı silmek yetmez çünkü secret Git geçmişinde kalır ve halka açık depolar saniyeler içinde botlarca taranır. İptal/döndürmeden sonra etki değerlendirilir ve tekrarı önlemek için secret tarayıcı eklenir.

15. Prod'a yeni bir sürüm yayınlarken riski en aza indiren yaklaşım aşağıdakilerden hangisidir?

• A) Yeni sürümü tüm kullanıcılara aynı anda vermek (big-bang) ve rollback planı hazırlamamak
• B) Deploy 'yeşil' göründüğü an işi bitmiş saymak, ek doğrulama yapmamak
• C) Canary/blue-green/feature flag gibi kontrollü strateji, hazır rollback planı ve deploy sonrası smoke test + metrik izleme kullanmak ✔
• D) Kritik iş yollarının testini tamamen yapay zekaya bırakıp kendisi hiç belirlememek

Aciklama: Kontrollü release stratejileri (canary ile küçük bir yüzdeye başlamak, blue-green ile anında geri alabilmek, feature flag ile deploy'u release'ten ayırmak) riski sınırlar. Ayrıca deploy öncesi net bir rollback planı ve deploy sonrası smoke test ile altın sinyal izleme şarttır; 'yeşil görünmek' çalıştığı anlamına gelmez.