Eski sistemin verisi yeni sisteme nasıl taşınır? Eşleme, prova, mutabakat ve geçiş günü

Yeni bir sisteme geçen projelerde en çok hafife alınan ve en çok geciken kalem veri taşımadır, çünkü dışarıdan bakınca bir kopyalama işi gibi görünür. Gerçekte yapılan iş dört başlıkta toplanır: neyin taşınacağına karar vermek, her alanı tek tek eşlemek, gerçek veriyle defalarca prova yapmak ve taşıdıktan sonra sayı sayarak doğrulamak. Asıl risk de verinin kaybolması değil. Kayıp fark edilir, çünkü birileri aradığını bulamaz. Tehlikeli olan verinin sessizce yanlış gelmesidir: kırpılmış bir açıklama alanı, yanlış eşlenmiş bir sipariş durumu, ondalık hanesi kayan bir bakiye. Bunlar canlıya geçişte değil, aylar sonra bir müşteri şikâyetiyle ortaya çıkar.

Her şeyi taşımak zorunda değilsiniz

Veriyi üç kutuya ayırarak başlayın. Ana veri: müşteri, ürün, tedarikçi, hesap planı, fiyat listeleri. Açık işlemler: bekleyen siparişler, ödenmemiş faturalar, güncel stok, açık servis kayıtları. Kapanmış geçmiş: üç yıl önce teslim edilmiş siparişler, kapanmış dönemler, arşiv yazışmaları. İlk iki kutu yeni sisteme girer. Üçüncüsü çoğu projede girmemeli.

Kapanmış geçmişi taşıma kararı, proje süresini sessizce ikiye katlayan tipik karardır. Beş yıllık sipariş geçmişini yeni şemaya oturtmaya çalışırken o şemanın hiç tanımadığı eski iş kurallarıyla uğraşırsınız: artık kullanılmayan indirim tipleri, kaldırılmış depolar, birleşmiş şirket kodları. Daha ucuz alternatif genelde şu: eski veritabanını salt okunur bir arşiv olarak dondurun, üzerine tek bir arama ekranı koyun, yeni sisteme yalnızca bakiye devirlerini ve özet toplamları açın.

Saklama yükümlülüğü bu kararı etkiler ama taşımayı zorunlu kılmaz. Türk Ticaret Kanunu'nun 82. maddesi ticari defter ve belgeler için on yıllık saklama süresi öngörür, Vergi Usul Kanunu'nun 253. maddesi ise ilgili yılı takip eden takvim yılından başlayarak beş yıllık bir süre belirler. Yükümlülük verinin erişilebilir ve okunabilir kalmasını ister, yeni uygulamanın canlı tablolarında durmasını değil.

Taşımadan önce veriyi ölçün

Profilleme, taşıma projesinin en ucuz ve en çok atlanan adımıdır. Her tablo için birkaç sayı çıkarın: kayıt sayısı, zorunlu olacak alanlardaki boş oranı, mükerrer kayıt sayısı, format dışı değer sayısı, öksüz kayıt sayısı. Bir günlük iş, projenin gerçek boyutunu ortaya çıkarır.

Pratikte çıkan tablo hep benzer görünür. Aynı müşteri dört farklı yazımla dört kez kayıtlı. Vergi numarası alanında tire, boşluk ve nokta karışık. Doğum tarihi alanında yüzlerce 1900-01-01. Silinmiş ürüne bağlı sipariş satırları. Para birimi alanı boş bırakılmış birkaç yüz kayıt, hepsi bir dönem tek para birimi kullanıldığı için. Yeni sistem bu alanları zorunlu tuttuğu anda bunların her biri bir karar bekler.

Temizliği, mümkün olan yerde kaynak sistemde yapın. Taşıma betiğinin içine yazılan her temizlik kuralı sonraki her provada yeniden çalışır ve kaynak sistemde veri girmeye devam eden ekip aynı hatayı üretmeye devam eder. Her temizlik kararının bir de sahibi olmalı. "Şu 1.200 mükerrer müşteri kaydından hangisi kalacak" sorusunun cevabı kodda değil, o müşterilerle çalışan ekipte.

Eşleme tablosu projenin asıl sözleşmesidir

Alan eşlemesi bir doküman işidir ve tek bir tabloda yaşar: kaynak tablo ve alan, hedef alan, dönüşüm kuralı, alan boşsa ne yazılacağı, kararı kimin verdiği. Geliştirici bu tabloyu doldurmaz, doldurulmuş halini uygular. İş birimi okumadan onaylanan eşleme, sonradan "biz bunu böyle kullanmıyorduk" toplantısına dönüşür.

Zor vakalar hep aynı yerlerden çıkar. Tek alanın ikiye bölünmesi (tek bir ad soyad alanından ad ve soyad üretmek, ortada üç kelime varsa ne olacağı dahil). Durum kodu uyuşmazlığı: eski sistemde on bir sipariş durumu varken yenisinde altı tane olması ve aradaki beşinin nereye düşeceği. Ondalık hassasiyeti, para birimi ve kur alanları. Karakter kodlaması, özellikle latin5 tablolardan gelen Türkçe karakterler. Bir de alan uzunluğu: eski açıklama alanı 500 karakterken yenisi 255 ise, veritabanı ayarına göre fazlası hata vermeden kırpılabilir. Sessiz kırpma en sinsi hata tipidir, çünkü mutabakatta satır sayısı tutar.

Eski kimlikleri atmayın

Taşınan her kayıt için eski kimlik ile yeni kimliği eşleyen bir tablo tutun ve bu tabloyu projeden sonra da saklayın. Dört yerde işinize yarar: mutabakat sırasında farkı bulmak için, müşteri "148322 numaralı siparişim" dediğinde destek ekibi için, hâlâ eski kimlikle veri gönderen entegrasyonlar için, ve taşımayı yeniden çalıştırmak gerektiğinde.

Bununla bağlantılı ikinci kural: taşıma betiği tekrar çalıştırılabilir olmalı. Hedef tabloda eski kimlik alanına tekil indeks koyun ve yükleme mantığını "varsa güncelle, yoksa ekle" biçiminde yazın. Betik yarıda kalacak. Ağ kopacak, disk dolacak, bir tabloda beklenmedik bir değer çıkacak. Yarıda kalan bir yükleme, tekrar çalıştığında kayıtları ikizlemiyorsa geçiş gecesi çok daha sakin geçer.

Prova yapılmamış geçiş planı plan değildir

Provayı tam üretim kopyasıyla yapın, örneklem veriyle değil. Küçük bir örneklem, hem süreyi hem de veri kalitesi sürprizlerini gizler. Her provada üç şeyi ölçün: toplam süre, düşen kayıt sayısı, hangi tabloda ne hata verdiği. Bu üç sayı prova prova düşmüyorsa henüz hazır değilsiniz.

Süre tek başına planı değiştirebilir. Yükleme 26 saat sürüyorsa ve elinizdeki pencere cumartesi gecesi sekiz saatse, bunu üç ay önce öğrenmek istersiniz. Öğrendiğinizde seçenekleriniz de vardır: indeksleri yükleme sonrası oluşturmak, tabloları paralel yüklemek, geçmiş veriyi kapsam dışına almak, ya da stratejiyi değiştirmek. Geçiş gecesinin 02.00'sinde bu seçeneklerin hiçbiri yoktur.

Prova ortamına alınan üretim kopyasında kişisel veriler maskelenmeli, gerçek API anahtarları ve ödeme sağlayıcı bilgileri temizlenmelidir. Test ortamının üretim verisiyle beslenmesi doğru bir tercihtir; maskelenmemiş olarak beslenmesi ise geliştirme ekibindeki herkese müşteri verisini açmak anlamına gelir.

"Taşındı" demeden önce sayın

Mutabakat dört katmanlıdır. Tablo bazında satır sayıları. Parasal ve sayısal kolonların toplamları: toplam alacak bakiyesi, SKU bazında stok adedi, dönem bazında fatura tutarı toplamı. Anahtar alanlarda sağlama değeri karşılaştırması. Ve rastgele seçilmiş elli kaydın uçtan uca gözle kontrolü, tercihen o veriyi günlük kullanan kişi tarafından.

Bu iş için hazır araçlar da var. AWS Database Migration Service, taşıma görevinin içinde doğrulama çalıştırır: kaynaktaki her satırı hedefteki karşılığıyla karşılaştırır, satır sayısı ve sağlama değeri üzerinden kontrol eder, sürekli değişiklik yakalama kullanıyorsanız tam yükleme bittikten sonra gelen değişiklikleri de doğrulamaya dahil eder. Geçişten önce beklenen durum, çoğaltma gecikmesinin sıfıra inmesidir. Araç kullanmıyorsanız aynı kontrolleri elle yazın, çünkü kontrollerin varlığı araçtan önemli.

Mutabakat raporunu geliştirme ekibi değil, finans ve operasyon imzalasın. Kimse log dosyasındaki "migration completed successfully" satırına güvenmek zorunda değil. Rakamları kendi bildiği raporla karşılaştıran bir muhasebeci, en iyi test aracınızdır. Raporlarda tutarsızlık bu geçişten sonra da devam ederse, sorunun taşımada değil metrik tanımında olabileceğini raporlar neden tutmuyor yazısında ele almıştık.

Tek seferde mi, kademeli mi

Tek seferde geçiş (big bang) en basit olanıdır: veri girişi durur, yükleme yapılır, kontroller geçer, yeni sistem açılır. Test etmesi kolay, anlatması kolay. Karşılığında geri dönüş penceresi dar ve geçiş gecesindeki baskı yüksektir. Veri hacmi yönetilebilir ve planlı kesinti mümkünse doğru seçimdir.

Kademeli geçiş modül modül ya da şube ve şirket bazında ilerler, iki sistem bir süre birlikte yaşar. Riski böler, operasyon yükünü ikiye katlar ve bir soruyu zorunlu kılar: bir kaydın sahibi şu anda hangi sistem? Bu sorunun cevabı her veri tipi için yazılı değilse kademeli geçiş, çift kayıt üreten bir makineye dönüşür. İki sistem arasında geçici bir senkronizasyon köprüsü kuracaksanız, entegrasyonlarda veri senkronizasyonunun nerede bozulduğunu baştan okumakta fayda var.

Üçüncü seçenek değişiklik yakalama (CDC) ile ilerlemek: önce tam yükleme, ardından kaynaktaki değişiklikleri sürekli aktarma, gecikme sıfıra indiğinde geçiş. Kesintiyi dakikalara indirir, karşılığında kaynak veritabanından destek ve ek altyapı ister. Dördüncüsü paralel çalıştırma: iki sistem bir dönem birlikte çalışır ve çıktılar karşılaştırılır. En güvenli ve en pahalı olanı budur; ay sonu kapanışı gibi geri alınamaz süreçlerde bir dönem paralel koşmak makul bir sigortadır. Seçimi iki soru belirler: kaç saat kesintiye dayanabilirsiniz, ve ekibiniz bir süre çift veri girişini kaldırabilir mi?

Geçiş günü bir senaryo, bir saat ve bir isim ister

Geçiş planı dakika dakika yazılır: veri girişinin donduğu saat, son yedeğin alındığı an, yükleme adımları ve tahmini süreleri, kontrol noktaları, her adımdan kimin sorumlu olduğu. Kontrol noktalarında devam etme kararını verecek tek bir kişinin adı da yazılı olmalı. Kalabalık bir odada kimsenin durdurma yetkisi yoksa, kötü giden bir geçiş sabaha kadar sürer.

Geri dönüşün de bir tarifi olmalı ve en önemlisi, dönüşü olmayan noktanın saati yazılı olmalı. O saatten sonra "eski sisteme dönelim" demek, yeni sisteme girilmiş yeni kayıtları da geri almak anlamına gelir ve genelde mümkün değildir. Bu yüzden geri dönüş kararı gecenin ilerleyen saatlerinde değil, önceden belirlenmiş kontrol noktasında verilir. Kesintiyi kısaltan dağıtım teknikleri için sıfır kesintili yayına alma yazısındaki yaklaşımlar geçiş gecesine de uyarlanabilir.

Veri taşındı, geçiş başarılı demek değil

TSB, nisan 2018'de 5,2 milyon müşterisinin verisini yeni bankacılık platformuna taşıdı. Düzenleyicilerin tespiti dikkat çekicidir: veri taşıması başarıyla tamamlandı, platform hemen ardından teknik olarak çöktü. Şube, telefon, internet ve mobil bankacılıkta yaşanan kesintinin etkileri aralık ayına kadar sürdü. FCA ve PRA aralık 2022'de bankaya toplam 48,65 milyon sterlin ceza kesti (FCA 29,75 milyon, PRA 18,9 milyon) ve banka zarar gören müşterilere 32,7 milyon sterlin tazminat ödedi.

Buradan çıkan ders teknik değil, kapsamla ilgili. "Veri taşındı" ile "geçiş başarılı" aynı cümle değildir. Alıcı sistemin gerçek yükü kaldırıp kaldırmadığı, entegrasyonların yeni hacimle çalışıp çalışmadığı, destek ekibinin ilk haftaki çağrı yoğunluğuna hazır olup olmadığı da taşıma projesinin parçasıdır. Yük testi ve kapasite provası, veri doğrulaması kadar plana girmeli.

Canlıya çıkış bitiş değil

Mutabakatı ilk ay her gün, sonra haftalık tekrarlayın. Taşınamayan kayıtlar için bir istisna kuyruğu açın ve o kuyruğa bakan bir kişi belirleyin. "Sonra bakarız" listesi, altı ay sonra kimsenin açmadığı bir Excel dosyasına dönüşür ve içindeki kayıtlar genelde en karmaşık müşterilere ait olur.

Eski sistemin veri modelini bilen kişiyi en az bir çeyrek daha erişilebilir tutun. Sözleşmesi biten danışman gittiğinde "bu alan neden hep 3 yazıyor" sorusunun cevabı da gider. Bu riskin uç örneği Birmingham Belediyesi'nin Oracle programıdır: 19 milyon sterlin bütçeyle başlayan proje, banka mutabakat süreci bozulduğu için belediyeyi uzun süre denetlenebilir hesap üretemez hale getirdi ve basına yansıyan son tahminlerde toplam maliyet 144 milyon sterline çıktı. Orada da sorun tek bir teknik hata değil, canlıya çıktıktan sonra mutabakatın onarılamamasıydı.

Bu haftaya sığan ilk adım

En kritik üç tabloyu seçin, çoğu şirkette bunlar müşteri, ürün ve açık siparişlerdir. Her biri için tek sayfalık bir profil çıkarın: kayıt sayısı, yeni sistemde zorunlu olacak alanlardaki boş oranı, mükerrer kayıt sayısı, format dışı değer sayısı, öksüz kayıt sayısı.

Sonra aynı üç tablo için eşleme tablosunun ilk sürümünü yazın ve iş birimiyle tek bir toplantıda satır satır geçin. O toplantıda kaç kez "bu alan aslında şu anlama geliyor" cümlesini duyduğunuzu sayın. O sayı, projenin gerçek büyüklüğü hakkında herhangi bir tahmin toplantısından daha doğru fikir verir.