Çok müşteri yönetimi sadece daha çok veritabanı değildir
Ajanslarda ilk yıllarda işler basit ilerler: birkaç müşteri, birkaç veritabanı, bağlantı bilgileri bir password manager içinde. Sonra müşteri sayısı artar, ekip büyür, destek talepleri çoğalır ve aynı düzen yavaş yavaş kırılganlaşır.
Asıl mesele kaç veritabanı olduğu değil, her müşterinin operasyonel sınırının net olup olmadığıdır. Kim erişebilir, hangi IP’den erişebilir, yedeği nerede, geri yükleme ne kadar sürer, maliyeti kime ait, destek sırasında ne yapıldı? Bu sorulara standart cevap yoksa ölçek büyüdükçe güven azalır.
- Müşteri verisi teknik olarak da operasyonel olarak da ayrılmalı.
- Destek erişimi kalıcı kullanıcılarla değil, süreli ve izli süreçlerle yürümeli.
- Yedekleme ve geri yükleme standardı müşteriye göre unutulmamalı, platform davranışı olmalı.
- Kaynak kullanımı müşteri bazında okunamıyorsa faturalama ve kapasite kararı bulanıklaşır.
İzolasyon kararını müşteri riski belirler
Her müşteri için ayrı fiziksel dünya kurmak bazen gereksiz maliyet üretir; her müşteriyi aynı veritabanına koymak da güven ve operasyon riski oluşturabilir. Doğru karar, müşterinin veri hassasiyeti, trafik profili, sözleşme beklentisi ve destek modeline göre verilir.
Küçük ve düşük riskli müşteriler aynı motor üzerinde ayrı database veya schema ile yönetilebilir. Büyük, regülasyon hassasiyeti olan veya performansı bağımsız tutulması gereken müşteriler için ayrı cluster daha sağlıklı olabilir.
Basit izolasyon karar matrisi
Küçük müşteri, düşük trafik -> ayrı database/schema, sınırlı kullanıcı Orta müşteri, düzenli trafik -> ayrı database + ayrı role + yedek etiketi Büyük müşteri, SLA/sözleşme var -> ayrı cluster + ayrı izin listesi + ayrı bakım penceresi Hassas veri veya regülasyon -> ayrı tenant/cluster + denetim + destek erişim onayı
TürkDB ile müşteri açılışını ritüele dönüştürün
Çok müşterili işlerde en değerli şeylerden biri tekrar edilebilir açılış akışıdır. Yeni müşteri geldiğinde “hangi porttu, TLS gerekiyordu mu, yedekleme açık mıydı?” gibi sorular sorulmamalı. Bunlar bir checklist ve mümkünse otomasyon olmalıdır.
TürkDB CLI veya Terraform kullanımı burada anlamlıdır. Çünkü her müşteri için bağlantı, izin listesi, yedek ve kaynak sınıfı aynı dille tarif edilir. Bu, hem hata payını azaltır hem de ekipte bilgi tek kişiye bağlı kalmaz.
Yeni müşteri cluster açılışı
turkdb cluster create --name acme-prod-pg \ --engine postgresql \ --version 16 \ --tier standard-2 \ --region tr-ist-1 \ --yedek-retention 14d \ --pooler enabled \ --tag customer=acme \ --tag environment=canlı ortam turkdb cluster allowlist add acme-prod-pg 203.0.113.42 --desc "Acme ofis" turkdb connect acme-prod-pg --no-tunnel turkdb backup create acme-prod-pg
Buradaki amaç tek komut ezberi değil, açılış standardıdır. Müşteri adı, ortam, yedek ve bağlantı politikası ilk günden görünür olur.
Destek erişimi kalıcı kapı olmamalı
Ajans ekiplerinde “bir bakalım” diye verilen erişimler zamanla unutulur. Bir müşteri sorunu çözülür ama destek kullanıcısı kalır, eski IP izin listesite durur, denetim bakılmadığı için kimin ne yaptığı belirsizleşir.
Bunu çözmenin yolu destek ekibini veritabanından tamamen uzaklaştırmak değildir. Yol, destek erişimini süreli, gerekçeli ve kayıtlı hale getirmektir. Böylece ekip hızlı hareket ederken müşteri güveni de zedelenmez.
Destek erişimi sonrası kapanış kontrolü
turkdb cluster events acme-prod-pg --limit 50 turkdb audit list --cluster acme-prod-pg --actor [email protected] turkdb cluster allowlist list acme-prod-pg turkdb cluster allowlist remove acme-prod-pg 198.51.100.17
Müşteri bazlı maliyet konuşulabilir olmalı
Ajanslarda veritabanı maliyeti çoğu zaman genel gider gibi başlar. Bir süre sonra bazı müşteriler beklenenden çok daha fazla kaynak kullanır, ama bunun faturalamaya mı, optimizasyona mı, paket değişikliğine mi dönüşeceği netleşmez.
Müşteri bazlı etiket, cluster ve kaynak görünürlüğü burada ticari faydaya dönüşür. Hangi müşteri daha fazla depolama büyütüyor, hangisinin yedek maliyeti artıyor, hangisi ayrı cluster gerektiriyor? Bu sorular teknik olduğu kadar ticari sorulardır.