Açılış süreci hatası ilk güven kırığıdır
Yeni müşteri ilk kez giriş yaptığında uygulama hata veriyorsa teknik borç daha ilk günden müşteri deneyimine dönüşür. Çoğu ekip bu hatayı “migration unutulmuş” diye açıklar ama kök neden genelde daha geniştir: açılış süreci süreci kod kadar ciddiye alınmamıştır.
Tenant açılışı bir iş akışıdır. Veritabanı hazır mı, migration tamam mı, bağlantı gizli değeri doğru mu, yedek penceresi açık mı, müşteri hangi bölgede, hangi paketle başladı? Bunların her biri aynı açılış süreci kaydında izlenebilmelidir.
- Tenant kimliği ve veritabanı kimliği aynı sözlükle adlandırılmalı.
- Migration ve seed data adımları açılışın parçası olmalı.
- Bağlantı dizesi uygulamaya güvenli gizli değer akışıyla verilmeli.
- Yedekleme/PITR ve denetim daha sonra değil, ilk gün açık olmalı.
Tenant açılışını iki parçaya ayırın
İyi açılış süreci akışı önce altyapıyı hazırlar, sonra uygulama tenant kaydını aktifleştirir. Tersini yaparsanız uygulama tenantı görür ama veritabanı hazır olmadığı için ilk isteklerde hata üretir.
Bu ayrım basit görünür ama olayları azaltır. Önce cluster/database, kullanıcı, izin listesi, migration ve yedek hazır olur. Sonra tenant uygulamada aktif hale gelir ve müşteri daveti gönderilir.
Açılış süreci sırası
1. Tenant kaydı pending durumunda oluşturulur 2. Veritabanı veya database provision edilir 3. Migration çalıştırılır 4. Seed data ve başlangıç ayarları yüklenir 5. Yedekleme/PITR ve izin listesi doğrulanır 6. Uygulama gizli değerleri güncellenir 7. Sağlık kontrolü başarılıysa tenant active yapılır 8. Müşteri daveti gönderilir
Terraform ile açılış süreci tekrar edilebilir olur
SaaS ürünlerde tenant sayısı arttıkça manuel panel tıklamaları sürdürülebilir olmaz. Terraform veya benzer IaC yaklaşımı, tenant veritabanını ürün açılış süreci sürecinin bir parçası haline getirir.
Bu, her müşteriyi ayrı cluster yapmak zorundasınız anlamına gelmez. Ama yaptığınız seçim kodda görünür olur: hangi tenant hangi tierda, hangi regionda, hangi yedek politikasıyla çalışıyor?
Terraform ile tenant veritabanı fikri
resource "turkdb_cluster" "tenant_acme" {
name = "tenant-acme-prod"
engine = "postgresql"
version = "16"
region = "tr-ist-1"
tier = "standard-2"
yedek_retention = "14d"
pooler_enabled = true
tags = {
tenant = "acme"
environment = "canlı ortam"
}
}
resource "turkdb_ip_izin listesi" "tenant_acme_office" {
cluster_id = turkdb_cluster.tenant_acme.id
cidr = "203.0.113.42/32"
description = "Acme ofis"
}Gerçek provider alanları sürüme göre değişebilir; önemli olan tenant açılışının izlenebilir ve tekrar edilebilir hale gelmesidir.
Migration başarısını sadece exit code ile ölçmeyin
Migration komutu 0 ile bitti diye tenant gerçekten hazır olmayabilir. Uygulamanın beklediği tablo, indeks, extension, başlangıç kullanıcısı ve tenant ayarı doğrulanmalıdır. Özellikle multi-tenant sistemlerde yanlış tenant_id ile seed data yazmak sessiz ama pahalı bir hatadır.
Açılış süreci sonrası basit doğrulama
SELECT current_database(); SELECT count(*) FROM schema_migrations; SELECT id, status FROM tenants WHERE slug = 'acme'; SELECT count(*) FROM users WHERE tenant_id = 'acme' AND role = 'owner';
Rollback planı davetten önce hazır olmalı
Tenant açılışı yarım kalırsa müşteri daveti gönderilmemeli veya tenant pending durumda kalmalıdır. Yarım açılmış veritabanı, yarım yazılmış gizli değer ve aktif görünen tenant birleştiğinde destek ekibi gereksiz baskı altında kalır.
TürkDB tarafında cluster olayları, yedek ve denetim kayıtları açılış süreci sorununu sonradan anlamayı kolaylaştırma hedefinin parçasıdır. Ama en doğru çözüm, müşteri aktif edilmeden önce sağlık kontrolü kapısı koymaktır.
TürkDB açılış süreci health kontrolü
turkdb cluster get tenant-acme-prod turkdb cluster events tenant-acme-prod --limit 20 turkdb backup list tenant-acme-prod turkdb connect tenant-acme-prod --no-tunnel