Ucuz görünen migration bazen en pahalı projedir
Bir veritabanını taşırken ilk hesap genellikle hedef cluster maliyetiyle yapılır. Yeni ortam şu kadar CPU, şu kadar RAM, şu kadar depolama. Bu hesap gereklidir ama yeterli değildir. Göç projesinin gerçek maliyeti çoğu zaman görünmeyen işlerde saklıdır.
Doğrulama sorguları hazırlanacak, uygulama bağlantı dizeleri değişecek, CI/CD ortamları güncellenecek, raporlar test edilecek, müşteri iletişimi yapılacak, rollback kararı yazılacak. Bunların hiçbiri tek başına zor olmayabilir; ama hepsi birlikte takvimi ve riski belirler.
- Altyapı maliyeti göç maliyetinin yalnızca bir kısmıdır.
- Kesinti penceresi iş kaybı ve müşteri güveni açısından ayrıca değerlendirilmelidir.
- Doğrulama yapılmayan göç tamamlanmış sayılmaz.
- Geri dönüş planı olmayan geçiş, umutla yapılan yayına alma gibidir.
Maliyet kalemlerini teknik ve iş maliyeti diye ayırın
Göç maliyetini anlaşılır yapmak için iki tablo kullanın. Teknik tabloda kaynak, depolama, ağ, yedek, CDC, geçici ortam ve geri yükleme hedefleri durur. İş tablosunda kesinti süresi, ekip zamanı, destek yükü, müşteri iletişimi ve risk azaltma işleri yer alır.
Bu ayrım finans ekibinin de teknik ekibin de aynı resmi görmesini sağlar. Aksi halde teknik ekip “çok zor değil” derken iş tarafı müşteri etkisini, finans ise çift çalışan altyapı dönemini kaçırabilir.
Göç maliyeti hesap iskeleti
Teknik maliyet kaynak cluster çalışma süresi hedef cluster çalışma süresi CDC/replication geçiş dönemi yedek ve snapshot saklama test/geri yükleme hedefleri ağ/veri transferi İş maliyeti planlama ve ekip zamanı downtime veya salt okunur pencere müşteri iletişimi doğrulama ve QA rollback hazırlığı olay riski ve destek yükü
Doğrulama maliyetini kısmayın
Migration sırasında en tehlikeli cümlelerden biri “satır sayısı tuttu, tamamdır” cümlesidir. Satır sayısı başlangıç için iyidir ama tek başına doğrulama değildir. Kritik tablolar, toplamlar, son yazılan kayıtlar, referans bütünlüğü, indeksler, sequence değerleri ve uygulama sorguları da kontrol edilmelidir.
Doğrulama maliyeti bazen migration süresinin önemli kısmını alır. Bu kötü değil; çünkü hatayı cutoverdan önce bulmak, müşteriden gelen ticket ile bulmaktan çok daha ucuzdur.
Pratik doğrulama paketi
SELECT 'orders' AS table_name, count(*) FROM orders; SELECT status, count(*), sum(total_amount) FROM orders GROUP BY status ORDER BY status; SELECT id, created_at, updated_at FROM orders ORDER BY updated_at DESC LIMIT 20;
TürkDB migration-runner neyi azaltır, neyi azaltmaz?
TürkDB migration-runner fikri snapshot, CDC, hedef cluster hazırlığı ve cutover adımlarını daha düzenli hale getirmeyi hedefler. Bu hedefin gerçek rahatlık sağlayıp sağlamadığı pilot migration ile ölçülmelidir.
Yine de migration-runner ürün kararını sizin yerinize vermez. Hangi saat uygun, ne kadar lag kabul edilebilir, hangi müşteri bilgilendirilecek, hangi doğrulama başarılı sayılacak, ne olursa rollback yapılacak? Bunlar iş ve ürün bağlamıyla belirlenir.
Migration planı karar kaydı
Hedef: kaynak: hedef: cutover penceresi: kabul edilen maksimum lag: salt okunur süre: doğrulama sorguları: rollback eşiği: müşteri iletişim sahibi: final karar sahibi:
Göçten sonra eski sistemi hemen silmeyin
Cutover başarılı olduktan sonra eski sistemi hemen kapatmak cazip olabilir. Fakat kısa bir gözlem penceresi, beklenmeyen rapor farklarını veya uygulama kenar durumlarını yakalamak için değerlidir. Bu pencerenin maliyeti baştan hesaba katılmalıdır.
Eski sistemin ne zaman salt okunur kalacağı, ne zaman yedek alınacağı, ne zaman silineceği ve kimlik bilgisiların ne zaman kapatılacağı migration planının parçası olmalıdır. Böylece “taşıdık ama iki sistem de açık kaldı” borcu oluşmaz.