Canlıya çıkış, bağlanabildik demek değildir
Yeni bir uygulama canlı ortama çıkarken veritabanı çoğu zaman son dakikada kontrol edilir: host doğru mu, parola çalışıyor mu, migration geçti mi? Bunlar gereklidir ama canlı sistem için yeterli değildir.
Canlı ortam veritabanı, kullanıcı trafiği geldiğinde sadece sorgu çalıştırmaz; hata, büyüme, güvenlik, yedek, bakım ve olay sorumluluğu da taşır. Bu yüzden canlıya çıkış kontrolü kanıta dayalı olmalıdır.
- Bağlantı çalışmalı ama gereksiz IP aralıkları açık olmamalı.
- Yedekleme açık olmalı ama geri yükleme edildiği de kanıtlanmalı.
- Uygulama kullanıcısı admin olmamalı.
- Alarm ve müdahale rehberi olmadan canlıya çıkış eksik sayılmalı.
- Rollback kararı release sırasında icat edilmemeli.
Güvenlik ve erişim ilk kapıdır
Canlı ortamda bağlantı bilgisinin doğru olması kadar erişimin dar olması da önemlidir. TLS zorunluluğu, IP izin listesi, servis bazlı kullanıcı ve kimlik bilgisi rotasyonu planı canlıya çıkmadan önce netleşmelidir.
En sık yapılan hata, ilk çıkış rahat olsun diye geniş yetkili kullanıcıyla başlamaktır. Bu kısa vadede işleri hızlandırır ama sonradan daraltması daha zor bir güvenlik borcu üretir.
Canlıya çıkış erişim kontrolü
Kontrol et: Uygulama kullanıcısı admin değil TLS zorunlu IP izin listesi sadece gerekli kaynakları içeriyor CI/CD gizli değerleri canlı ortam için ayrı destek erişimi acil erişim akışına bağlı kimlik bilgisi rotasyonu için plan var
Yedek değil, geri yükleme kanıtı isteyin
“Yedek alıyoruz” cümlesi kulağa güvenli gelir ama üretim için yeterli değildir. Geri yükleme denenmediyse yedek sadece umut kaydıdır. Canlıya çıkış öncesi en az bir geri yükleme hedefi açılmalı, uygulamanın temel okuma/yazma akışı bu hedefte doğrulanmalıdır.
PITR kullanılıyorsa hedef zaman seçimi, RPO beklentisi ve geri yükleme sonrası açık veri silme talepleri gibi konular da kontrol edilmelidir.
TürkDB canlıya çıkış hazırlığı kontrolü
turkdb cluster get prod-db turkdb cluster allowlist list prod-db turkdb backup list prod-db turkdb cluster pitr status prod-db turkdb audit list --cluster prod-db --limit 50 turkdb billing usage --cluster prod-db
Monitoring ve müdahale rehberi ekip diline çevrilmeli
Metriklerin var olması yetmez; ekip hangi alarmda ne yapacağını bilmelidir. CPU yüksekliği, disk doluluğu, bağlantı limiti, replication lag, yedek başarısızlığı ve yavaş sorgu alarmı için ilk bakılacak yerler yazılı olmalıdır.
Müdahale Rehberi kısa ve uygulanabilir olmalıdır. Olay anında kimse uzun mimari doküman okumaz. İyi müdahale rehberi, ilk 15 dakikada etkiyi, kapsamı, veri güvenliğini ve iletişim ritmini kurar.
Canlıya çıkış müdahale rehberi iskeleti
Alarm: İlk kontrol: Kullanıcı etkisi: Veri kaybı riski: Rollback eşiği: İletişim kanalı: Karar sahibi: Sonradan yazılacak postmortem alanı:
Canlıya çıkış kararını tek kişi taşımamalı
Canlıya çıkış kararı tek bir mühendisin omzunda kalırsa risk büyür. Ürün, geliştirme, operasyon ve destek tarafı aynı kısa kontrol listesini görmeli; eksik bir madde varsa bunun bilinçli kabul mü yoksa engel mi olduğu yazılmalıdır.
TürkDB bu kararı kolaylaştıracak sinyalleri üretmeyi hedefleyebilir; fakat “bu riskle canlıya çıkarız” cümlesi iş kararıdır. En sağlıklı çıkış, teknik kanıt ve iş beklentisinin aynı sayfada buluştuğu çıkıştır.