Değişim Sonrası Doğrulama Ritmi: Smoke, SLO ve Rollback

Kurumsal platformlarda en pahalı cümle şudur: “Deploy bitti.”
Çünkü çoğu incident, deploy’un yapılmasından değil; deploy sonrası doğrulamanın “kişisel refleks” olarak kalmasından doğar. Doğrulama ritmi yoksa şu olur:

• değişiklik gerçek kullanıcı trafiğine değdiğinde sürpriz çıkar,
• hata sinyali geç görülür,
• rollback kararı tartışmaya dönüşür.

Bu yazıda değişim sonrası doğrulamayı, ekiplerin gerçekten uygulayabileceği kadar sade bir ritme bağlayan bir çerçeve paylaşıyorum.

Amaç: “Yayın”ı tanımla

Yayın, sadece artefact’ın üretime çıkması değildir. Yayın, şu üç sorunun cevabıdır:

1. Sistem trafik alıyor mu? (smoke)
2. SLO’lar normale yakın mı? (gözlem)
3. Bozulursa geri dönüş kararımız net mi? (rollback)

3 katmanlı doğrulama ritmi

Katman 1 — 2–5 dakikalık smoke checks

Hedef: en temel kırılmaları hızlı yakalamak.

• kritik endpoint’ler 200/ok mu?
• auth/SSO akışı çalışıyor mu?
• temel bağımlılıklar (DB, cache, queue) sağlıklı mı?
• trafik LB üzerinden doğru node’lara dağılıyor mu?

Smoke, “derin analiz” değil; “bariz kırık var mı?” kontrolüdür.

Katman 2 — 15–30 dakikalık SLO gözlemi

Hedef: kullanıcı etkisini ölçmek.

• error rate (5xx / app error)
• p95/p99 latency
• saturation (CPU, mem, conntrack, DB pool)
• kritik queue/backlog metrikleri

Bu katmanda kritik olan şey baseline: “normal” değerleri bilmiyorsan, karar tartışmaya döner.

Katman 3 — 24 saatlik stabilite penceresi (hafif)

Hedef: “yavaş bozulan” sorunları yakalamak.

• memory leak / fd leak
• cache davranışı (stampede, eviction)
• trafik paterni değişince ortaya çıkan bug

Bu aşama için tam zamanlı nöbet gerekmiyor; ama dashboard ve alarm eşiği doğru olmalı.

Rollback kriterini baştan yaz

Rollback kararı incident anında verilirse, ekip psikolojisi ve iletişim baskısı karar kalitesini düşürür. Basit bir kural seti:

• 10 dakika içinde SLO belirgin bozuluyorsa → rollback
• kritik akış çalışmıyorsa → rollback
• veri tutarlılığı riski varsa → “ileri düzeltme” yerine rollback

Sahada çalışan küçük otomasyonlar

Doğrulamayı kişiden bağımsız kılmak için küçük ama etkili pratikler:

• deploy sonrası otomatik smoke job (CI/CD veya runbook script)
• canary dashboard link’i (tek tık)
• “rollback komutu”nun dokümante olması (tek komut olmasa bile net adımlar)
• change ticket’a otomatik metrik snapshot ekleme (önce/sonra değil; sadece kanıt)

İletişim: tek paragraf format

Değişiklik sonrası kanıt odaklı tek paragraf iyi çalışır:

• Değişiklik: ne çıktı?
• Doğrulama: hangi smoke check + hangi metrik penceresi?
• Sonuç: SLO normal mi, risk var mı?
• Plan: izleme süresi ve rollback kriteri

Sonuç

Değişim sonrası doğrulama bir “iyi niyet” değil, operasyonel bir disiplindir. Smoke + SLO + rollback kriteri üçlüsünü ritme bağladığında; MTTR düşer, tartışma azalır ve yayın kültürü hızlanırken güven de artar. Üretimde hedef; sadece yeni özellik çıkarmak değil, çıktıktan sonra gerçekten çalıştığını kanıtlamaktır.