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:
- Sistem trafik alıyor mu? (smoke)
- SLO’lar normale yakın mı? (gözlem)
- 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.