Bilgi Bankası
GenelMaliyet ve kaynak 18 dk 14.06.2026

Yönetilen veritabanı pilotunda hangi kanıtları istemelisiniz?

Yönetilen veritabanı kararını özellik listesiyle değil, pilotta görülen kanıtla vermek daha sağlıklıdır. Bir servis “yedek var” diyebilir; asıl soru o yedek’ın geri dönüp dönmediği, kimin eriştiği, maliyetin nasıl oluştuğu ve olay anında hangi kanıtın kaldığıdır.

Bu yazı sana şu durumda yardımcı olur
  • yönetilen veritabanı sağlayıcısı değerlendiriyorsunuz
  • satış sunumu iyi ama hangi kanıtı istemeniz gerektiği belirsiz
  • yedek, failover ve güvenlik başlıkları özellik listesi gibi anlatılıyor
  • pilot başarı kriteri yazılmadığı için karar kişisel izlenime kalıyor
  • maliyet, geri yükleme ve destek sınırları sözlü kalıyor
Yazıyı bitirince

Yönetilen veritabanı pilotunu küçük ama ciddi bir doğrulama çalışmasına çevirebileceksiniz: hangi iş yükü seçilecek, hangi metrikler ölçülecek, hangi riskler kabul edilecek, hangi vaatler üretime taşınmayacak daha netleşecek.

TürkDB açısından ürünleşme notu

Bu bölüm, TürkDB’nin ilgili problemi hangi ürün ilkeleri ve kontrol noktalarıyla ele alacağını anlatır. Kapsam, gerçek iş yükü ve ihtiyaçla birlikte netleşir.

TürkDB için doğru yaklaşım, değeri özellik listesiyle değil üretilen kanıtla göstermektir. Bu yazı TürkDB için de bir disiplin notudur: geri yükleme, erişim, denetim, ölçümleme ve operasyon sınırları ölçülebilir hale gelmeden büyük vaatlere dönüşmemelidir.

Pilot, satış demosunun teknik adı değildir

Yönetilen veritabanı pilotu çoğu zaman yanlış başlar. Sağlayıcı bir panel gösterir, birkaç cluster açılır, bağlantı bilgisi alınır ve herkes “çalışıyor gibi” hisseder. Bu kötü bir başlangıç değildir ama karar vermek için yeterli değildir.

İyi pilot, küçük kapsamlı ama ciddi bir üretim provasıdır. Her şeyi test etmeye çalışmaz; ama en kritik riskleri kanıtlamaya çalışır. Yedek gerçekten geri dönüyor mu? Failover olduğunda uygulama nasıl davranıyor? Erişim kimde kalıyor? Fatura hangi ölçümden çıkıyor? Destek nerede başlıyor, nerede bitiyor?

  • Pilotun amacı ürünü beğenmek değil, riski ölçmektir.
  • Başarı kriteri yazılı değilse pilot sonunda herkes farklı şeyi başarılı sayar.
  • En iyi pilot, gerçek ama sınırlı bir iş yükü seçer.
  • Kanıt üretmeyen demo, satın alma kararını güvenli hale getirmez.

Önce hangi iş yükü ile deneyeceğinizi seçin

Pilot için en kritik karar, hangi veritabanı iş yükünün seçileceğidir. Tamamen oyuncak veriyle yapılan deneme bazı arayüz sorunlarını gösterir ama operasyon riskini göstermez. Doğrudan en kritik canlı ortam veritabanıyla başlamak da gereksiz risklidir.

Orta yol daha sağlıklıdır: üretime benzeyen, veri hacmi ve sorgu deseni gerçekçi olan ama müşteri etkisi kontrol edilebilir bir iş yükü seçin. Örneğin test ortamı geri yükleme hedefi, düşük riskli internal servis, analitik kopya veya salt okunur raporlama verisi iyi aday olabilir.

Pilot iş yükü seçim notu

pilot-is-yuku-secimi.md
Aday iş yükü:
Veri hacmi:
Motor:
Okuma/yazma oranı:
Kritik sorgular:
Müşteri etkisi:
Geri dönüş planı:
Pilot dışında bırakılan riskler:
Karar sahibi:

Yedek kanıtı almadan güvenmeyin

Yedek var demek kolaydır. Bir cron işi, obje deposu, snapshot veya operatör çıktısı size “yedek alındı” diyebilir. Ama satın alma kararında görmek istediğiniz şey yedeğin varlığı değil, geri dönüşün kanıtıdır.

Pilot sırasında en az bir geri yükleme hedefi açılmalı ve bu hedefte temel doğrulama yapılmalıdır. Uygulama bağlanabiliyor mu, kritik tablolar duruyor mu, son kayıtlar beklenen zamanda mı, hassas verinin geri yükleme hedefinde nasıl korunacağı belli mi? Bu soruların cevabı yoksa yedek başlığı hâlâ eksiktir.

Geri yükleme kanıt paketi

restore-evidence-checklist.txt
Geri yükleme tarihi ve hedef zamanı:
Geri yükleme hedefi:
Doğrulanan tablolar:
Kritik satır/toplam kontrolleri:
Uygulama temel doğrulama testi:
Erişim ve maskeleme kontrolü:
Geri yükleme süresi:
Kabul / ret kararı:

Failover testinde sadece veritabanına bakmayın

Failover testi yalnızca “primary değişti mi?” sorusu değildir. Uygulama bağlantıyı tekrar kurabildi mi, pooler davranışı bozuldu mu, yazma sırasında hata nasıl ele alındı, kullanıcı etkisi kaç saniye sürdü, alarm doğru kişiye gitti mi? Yönetilen veritabanı pilotunda bu sorular özellikle değerlidir.

Bazı sağlayıcılar failover davranışını her iş yükü için aynı olgunlukta sunamayabilir. Bu tek başına ayıp değildir; ayıp olan, ölçülmemiş davranışı üretim garantisi gibi anlatmaktır. Pilotun değeri bu ayrımı dürüstçe göstermesidir.

  • Failover süresi teknik metrik, kullanıcı etkisi iş metriğidir.
  • Uygulama reconnect davranışı sağlayıcının değil sizin kodunuzun da sorumluluğudur.
  • Alarm ve olay kaydı yoksa testin sonradan öğrenme değeri azalır.
  • Başarısız failover testi kötü haber değil; üretim öncesi yakalandığı için iyi haberdir.

Maliyet görünürlüğünü pilotta isteyin

Yönetilen veritabanı kararında en yanıltıcı alanlardan biri maliyettir. Aylık paket fiyatı tek başına yeterli değildir. İşlem kaynağı, live depolama, yedek depolama, PITR arşivi, geri yükleme hedefi, destek etkisi ve kredi/indirim kayıtları birbirinden ayrılmalıdır.

Pilot sırasında tam fatura çıkmasa bile ölçümleme mantığı gösterilmelidir. Hangi kaynak ölçülüyor, hangisi müşteriye yansıyor, hangisi iç maliyet olarak kalıyor, geri yükleme hedefi unutulursa ne oluyor? Bu sorular ileride fatura tartışmasını azaltır.

Pilot karar skoru

managed-database-pilot-scorecard.md
Geri yükleme kanıtı: geçer / eksik
Failover davranışı: geçer / eksik
Erişim ve denetim: geçer / eksik
Maliyet görünürlüğü: geçer / eksik
Destek sınırı: geçer / eksik
Uygulama uyumu: geçer / eksik

Üretime taşınabilecekler:
Üretimden önce kapanması gerekenler:
Satın alma kararı: devam / bekle / vazgeç
Devam etmek istersen

Sorunu motor bazında derinleştirin

Benzer belirtiler farklı motorlarda farklı nedenlere dayanır; yayınlanan tüm rehberleri ana sayfadan takip edebilirsiniz.

Tüm makaleler