Müşteri Kubernetes değil sonuç satın alır
Bölgesel bulut veya hosting sağlayıcısı için yönetilen veritabanı fikri çekicidir: müşterinin zaten sunucusu, sitesi veya uygulaması sizdedir; veritabanını da sizden almak ister. Ama müşterinin aldığı şey “PostgreSQL podu” değildir. Bağlantı bilgisini alıp uygulamasına koymak, gerektiğinde geri yükleme istemek, faturayı anlamak ve destek alabilmek ister.
Bu yüzden ürünleşme katmanı teknik kurulum kadar önemlidir. Arka tarafta Kubernetes, operatör ve storage olabilir; müşteri tarafında ise paket adı, bölge, SLA, yedek politikası, bağlantı modeli ve net fatura görünür olmalıdır.
- Motor seçimi ürünün yalnızca bir parçasıdır; paket ve destek deneyimi de üründür.
- Müşteri cluster yaşam döngüsünü panel, API, CLI veya Terraform ile yönetebilmelidir.
- Fatura, son cluster durumundan değil ölçülmüş kullanım kayıtlarından üretilmelidir.
- Geri yükleme, yedek ve destek aksiyonları ürünün parçası olarak izlenmelidir.
Paketleri makine boyutu kadar iş yükü diliyle anlatın
Sadece CPU ve RAM yazan paketler teknik ekip için anlamlı olabilir ama her müşteri için yeterli değildir. “Küçük web uygulaması”, “yüksek trafikli OLTP”, “analitik pano” gibi kullanım dili karar vermeyi kolaylaştırır. Yine de bu anlatımın altında ölçülebilir makine-paketi olmalıdır.
TürkDB tarafındaki makine-paketi ve ölçümleme yaklaşımı burada işe yarar. Paketler pazarlama adı taşıyabilir; faturalama ise node-hour, depolama, yedek ve PITR arşiv gibi ölçülebilir kayıtlara dayanır.
Paketleme karar matrisi
Starter DB -> küçük web uygulaması, düşük trafik, temel yedek Business DB -> düzenli trafik, pooler, daha uzun yedek saklama süresi Analytics DB -> ClickHouse, yüksek okuma, pano ve event pipeline Dedicated DB -> büyük müşteri, ayrı tenant/cluster, özel bakım penceresi
Ölçümleme yoksa fatura tartışmaya dönüşür
Yönetilen veritabanı hizmetinde fatura kalemi anlaşılır olmalıdır. İşlem kaynağı, live depolama, yedek depolama, PITR archive ve geri yükleme işlemleri aynı sepete atılırsa müşteri “neye para ödüyorum?” diye sorar. Daha kötüsü, siz de hangi müşterinin size maliyet yarattığını göremezsiniz.
Ölçüm kayıtları fatura kadar iç maliyet için de değerlidir. Başarısız provisioning müşteriye fatura edilmemeli, ama iç maliyet olarak görünmelidir. Geri yükleme hedefi belirli bir değerlendirme penceresinde ücretsiz olabilir; bu da açık bir kayıtla izlenmelidir.
Fatura kalemlerini ayırma
cluster_compute_node_hour -> aktif node süresi cluster_live_storage_gb_hour -> provisioned volume yedek_storage_gb_day -> tamamlanmış yedek objesi pitr_archive_gb_day -> WAL/binlog/oplog arşivi geri yükleme_operation -> geri yükleme işi kaydı credit -> destek, promosyon veya outage düzeltmesi
Satış vaadi destek ritmiyle kapanır
Yönetilen veritabanı satıyorsanız müşterinin beklediği şey yalnızca “servis açık” değildir. Bağlantı sorunu olduğunda kime yazacağını, geri yükleme gerektiğinde ne kadar sürede döneceğini, bakım olduğunda nasıl haberdar edileceğini bilmek ister.
TürkDB’nin CLI, denetim, olay ve yedek yüzeyleri bu destek ritmini standartlaştırmaya yardım eder. Sağlayıcı tarafında önemli karar, hangi pakette hangi destek seviyesi ve hangi geri yükleme hedefi verileceğini açıkça yazmaktır.
Sağlayıcı için örnek cluster açılışı
turkdb cluster create --name customer-acme-business-pg \ --engine postgresql \ --version 16 \ --region tr-ist-1 \ --tier business-2 \ --yedek-retention 14d \ --tag customer=acme \ --tag plan=business-db turkdb backup list customer-acme-business-pg turkdb cluster events customer-acme-business-pg --limit 20