Veri göçü - tehlikeli mi yoksa zorunlu mu?

Şirketimin yazılım geliştirme departmanı, özellikle göçmenler için veri göçlerinin potansiyel olarak tehlikeli olduğu düşünülüyor.

Arka plan, müşterilerimizin düşük kalitede çok miktarda veri kullanmasıdır . Bunun nedenleri sadece kısmen yazılım kalitemizle ilgilidir, ancak verilerin geçmişi ile ilgilidir: Birçoğu önceki sistemlerden taşınmış , bazı hatalar (çoğunlukla iş) veri kayıtlarındaki tutarsızlıklara veya kazaların yanlış sonuçlanmasına neden olmuştur. müşteri tarafında (yazılımımızın yanlışlıkla izin verdiği).

Yöneticilerimin en önemli karşı argümanları, hatalı verilerin daha da kötü verilere dönüşebileceği , verilerin sıkıntısı müşteride bazı yöneticileri uyandırabilir ve müşterinin tarafındaki bazı işlemler artık sistemimize adapte olmuş oldukları için çalışmayabilir.

Şahsen, veri taşıma işlemlerini yazılım geliştirmenin ayrılmaz bir parçası olarak görüyorum ve veri taşıma işleminde yeniden yapılanmanın kodlamanın ne olduğu verileri görebiliyor. Veri geçişinin, gelişen bir yazılım oluşturmak için gerekli olduğunu düşünüyorum . Onsuz, biraz kötü bir veri yapısının etrafında işleyen acı verici bir yazılım oluşturmak zorunda kalacağız.

Sana soruyorum:

• Veri geliştirmeyle ilgili düşünceleriniz, özellikle gerçek hayattaki durumlar için ve sadece bir geliştiricinin bakış açısından değil?
• Yöneticilerimin görüşlerine karşı herhangi bir tartışmanız var mı?
• Şirketiniz veri göçleri ve bunlardan kaynaklanan zorluklarla nasıl başa çıkıyor?
• Bu konulara ait başka ilginç düşünceleriniz var mı?

Veri göçleri ekmek ve tereyağımdır ve veri temizliği gerçekten de çok önemli bir konudur. Kullandığımız bir strateji, müşterilerimizin verilerinin% 100'ünü taşıyor göçmenlik öncesi temizlik araçlarının asimptotik veridir.

1. Bu, onlarca veri sağlığı kontrolünün geliştirilmesi anlamına gelir (çoğunlukla sql sorguları).

2. Temizleme araçlarını müşteriyle değiştirmek (onun verileri olduğundan, düzeltme araçlarını tasarlıyoruz, bunları doğrulıyor ve yürütüyor).

3. Aleti yinelemeler üzerinde düzeltmek ve en kısa zamanda KPI destekli ölçülebilir kaliteye ulaşmak.

4. Geçiş gerçekleştikten sonra veri tutarlılığını kontrol etme. Bu D / Day'te GO / NOGO kararını vermeye yardımcı olur.

Sonunda bir veri göçü, 3 ila 5 yıl sonra gerçekleşmesi gereken son derece faydalı bir uygulamadır.

1. Platformun iş destekleme kabiliyetinin arttırılmasını sağlar.

2. Veritabanını düzenlemeyi sağlar.

3. BT platformunu yeni nesil iş araçları için hazırlar (ESB / EAI, Portallar, Öz Bakım platformları, raporlama ve veri madenciliği, siz adlandırın).

4. Yıllar boyunca biriken platformlar arasındaki DIY veri akışlarını "acil gereksinimleri" yerine getirmek için hızlı ve kirli "geçici" bir şekilde yeniden düzenler.

5. Her şeyden önce, platformlarını daha iyi tanıyan ve 'yapabilecekleri' tutumlarını destekleyen BT üretim ekibine güç veriyor. Bu tür faydaların ölçülmesi zordur, ancak birçok müşteriyi tanıdığınızda, bu durum belirginleşir. Göçten kaçan şirketler takip eden kademede kalırken, cesur olanlar paketi yönetiyor.

Evinizin bodrumunun kereste ile karıştırıldığı zamanki gibi biraz. Bir sabah, herşeyi çıkarmanız ve yalnızca ihtiyacınız olan şeyleri geri koymanız ve gerisini atmanız gerekir. Ondan sonra bodrumunuzu tekrar kullanabilirsiniz ;-)

Bir diğer temel husus, günümüzde, müşterilerin beklentilerinin her zaman harekete geçmesidir, "müşteriler her zaman daha fazla talep ediyor". Böylece, belirli bir şirketin rakiplerinin, pazar paylarını arttırma niyetinde olan bu yeni trendlere bakma konusunda her zaman önemli bir bölümü olacaktır. Bunu yapacakları şey, trendleri takip etmek veya hatta trendleri yönlendirmek için tekliflerini uyarlamaktır ve bu da işin sürekli olarak yeniden yapılandırılmasını gerektirir. Eğer BT platformunuz çok katıysa, kendi tarafınızdaki pazar trendlerini takip etmek ya da ondan önce kendi nihayetinde kendi pazar payınızı korumak için kendi yeteneğiniz üzerinde bir sürüklenme olacaktır. Başka bir deyişle, hareketli bir pazarda atalet, ilgisizlik için bir reçetedir.

Buna karşılık, daha yeni bir sisteme veri göçü daha modern ve çok yönlü bir verimlilik aracı oluşturacak ve çalışanların daha yeni teknolojilerden yararlanmalarını sağlayacak ve bu da şirketin iç inovasyon sürecinin desteklenmesine ve hatta yönlendirilmesine katkıda bulunacaktır. böylece nispi pazar payını güvence altına almak veya arttırmak.

Yukarıdaki düşünceler aslında "Veri Taşıma - tehlikeli ya da zorunlu" başlığı altında sorulan sorunun yalnızca yarısına cevap vermektedir. Evet Veri Taşıma olan esansiyel fakat bunlar da tehlikeli? Bu hesapta, BT’deki birçok şey o zaman tehlikelidir. Tanım olarak, risklerin yüksek olduğu her şey tehlikelidir; Özellikle konuyu ciddiye almazsanız. Ancak bu aslında BT'deki en yaygın modeldir . Ciddiye verileri-merkezleri veya yüksek kullanılabilirlik veya felaket toleransı almamak olduğunu tehlikeli.
Bu, bugünün şirketlerinin bugünün Bilgi Teknolojileri manzarasının bu sütunlarından vazgeçmeleri gerektiği anlamına mı geliyor? Kesinlikle değil!

Şaka yapmak için, "Profesyoneller tarafından yapılan bir uçağı kullanmazsanız, uçmanın tehlikeli olduğunu" iddia edebilirsiniz. Veri Migrasyonları için aynıdır. Profesyoneller tarafından yürütüldüğünde ve yürütüldüğünde, iyi tasarlanmış ve iyi işletilen bir uçakta uçmaktan daha tehlikeli değildir. Yatırım getirisi, karasal ulaşım araçlarına kıyasla aynı orandadır.
Profesyonellere emanet edildiğinde, çoğu göç iyi kontrol edilen başarılara sahiptir ve başarısızlık + terk oranı son derece düşüktür.

Yöneticilerinize kendilerine “Çoğu şirket Data Migration projelerini başarılı bir şekilde uygularken , şirketimizi bir başarısızlıkla sonuçlanacak kadar farklı kılan ne olabilir?”

Alain, başarılı bir veri taşıma projesi için veri temizlemenin önemi ve veri taşıma işleminin gerisinde yatan mantık açısından büyük cevap verdi. Yöneticinizin yalnızca özel endişelerini hedeflemek istiyorum.

Benim düşünceme göre, veri taşıma yapıp yapmama sorusu değil, ne zaman yapılacağı ile ilgili. Yöneticiniz, verilerinizin artık yalnızca sizin olmadığını ve son müşterilerin prosedürlerini bunun etrafında oluşturduğunu söyleyen kesinlikle geçerli bir noktaya sahiptir. Ancak bu durum gelecekte değişmeyecek . Er ya da geç kötü veri kalitesi işinizi yavaşlatan kaçınılmaz bir faktör haline gelecek ve siz de göç etmek zorunda kalacaksınız. Bunu baskı altında ve sıkı teslim tarihleriyle yapmak, yetersiz kararlara yol açabilir. Ayrıca, şu an sahip olacağınız ve bundan 2-3 yıl sonra sahip olacağınız uzmanlığı düşünün. Ya verilerinizi anlayan insanlar şirketten ayrılacaksa? Sahip olduğunuz belgelerin yeterli olduğundan emin misiniz?

Belki şimdi göç yapmak gerekli değildir, ancak yöneticinizin en azından tam olarak ne zaman göç olacağı konusunda bir vizyona sahip olması gerekir.

Bir sigorta şirketi için çalışıyordum ve çekirdek sistem için veri göçüne katıldım. Toplamda 4 kez vardı. Yani, burada benim yorumlarım:

Benim durumumda, veri göçü bir zorunluluktur, çünkü düzenlemeyle verileri en az 10 yıl boyunca tutmalıyız ve uzun vadede ikili sistemi desteklemeyi göze alamayız. Diğer bir sebep ise, kullanıcılar yeni uygulama ile çalışmalarına devam edebilmelerini beklemektir. Çalıştıkları öğeyi bulamazlarsa, uygulamanız kötüdür ve veriler doğru olmadığında daha da kötüleşir.

Veri göçü korkunç bir canavar ve gerçektir, bu yüzden bununla yüzleşin. Risklidir ancak daha erken ve dikkatli bir şekilde ele alınarak en aza indirilebilir. Bir rehber olarak, veri geçişinde göz önünde bulundurulması gereken dört büyük süreç vardır:

1. Veri haritalama. Master'ın (ve kombinasyonlarının) yeni sisteme haritaları
2. Veriler temizlendi. Verilerdeki istisna haritaları, yani, yeni sistemde kombinasyonu geçersiz sayılan veriler. Mümkünse, eşleştirilmesi mümkün olmayan verileri dışlamak ve potansiyel olarak yeni sistemi bozmak ve geçici çözüm hazırlamak için işle uğraşın
3. Gerçek veri taşıma Veri göçünü gerçekleştirmek için birçok strateji vardır. Örneğin: büyük patlama, artımlı
4. Rapor birleştirilmesi. Her iki sistemin de paralel çalışması durumunda, doğru ve tutarlı raporun nasıl üretileceği

Dikkatli plan ile olay, bok olur! Özel bir görev gücü, göçle ilgili sorunların üstesinden gelmeye hazır olmalıdır.

1) Veri geliştirmeyle ilgili düşünceleriniz, özellikle gerçek yaşam durumları için ve sadece geliştiricinin bakış açısından değil nelerdir?

Göç, sistem geliştirmenin önemli bir parçasıdır. Eski sistemleri kısmen veya tamamen değiştirirseniz, göç, yönetimin ister istemese de yaşamın bir gerçeğidir. Mevcut veriler kötüyse, yeni sisteminize kötü bir şekilde yansıtacaktır. Bu nedenle, iyi bir göç stratejisine sahip olmak çok önemlidir.

2) Yöneticilerimin görüşlerine karşı herhangi bir tartışmanız var mı?

Evet, göç risklidir, ancak aynı zamanda yaşamın bir gerçeğidir. Ve mümkün olduğunca erken onunla başa çıkmak.

3) Şirketiniz veri göçleri ve bunlardan kaynaklanan zorluklarla nasıl başa çıkıyor?

Şirketim - artan başarı ile müşterileri aktif olarak göç sürecine dahil etti. Mevcut verileri projenin en başındaki adımlarında elimizden geldiğince inceliyoruz ve taşımayı başlamadan önce müşteriyi veri kalitesini iyileştirmeye teşvik ediyoruz. Bazen gerçekten talep ediyoruz.

4: Bu konulara ait diğer ilginç düşünceler

Tavsiyem geçiş sürecini iki adımda bölmektir: Dönüşüm ve Veri temizleme. Dönüşüm oldukça yalındır - eski sistem nesnelerini yeni sisteme eşleme meselesi. Öte yandan, veri temizliği çok zor bir şey olabilir (yukarıda belirtildiği gibi). Müşteriyi mümkün olduğunca dahil edin ve sürece mümkün olduğunca erken başlayın. Kötü verilerin yeni sisteminize (bazen nedensiz olarak) kötü yansıtacağını unutmayın. Yeni bir sistem çalışmadığında, bir müşteri nadiren eski sistemde gayet iyi görünen veriyi suçlar.

Geçirmeyi planladığınız veriler şu anda hatalıysa, geçiş yapıp yapmamanız düzeltilmelidir. Kötü veri = işe yaramaz veri.

Göçler riskli, bu doğru. Ancak her büyük BT projesi de öyle. Riski azaltmanın yolları var ve bunların kesinlikle bir göç sırasında önceden planlanması gerekiyor.

İlk olarak, şimdi olduğu gibi sisteme geri dönmek için her zaman bir yolunuz olmalıdır. İkinci geçiş, yalnızca geçiş için ayarlanan test sunucularında yapılmalıdır. Önce sınama kabiliyeti olmadan göç yapmak aptalca. Üçüncüsü, geçiş için tüm kodlar kaynak kontrolünde olmalıdır.

Dördüncüsü, taşıma işlemine başlamadan önce gereksinimler ve test planları gerekir. Eski sistemde 1.293.687 kayıt bulunduysa, yenisinde aynı olduğunu veya nereye gittiklerini (belki de bir istisna tablosuna) bildiğinizi bilmeniz gerekir. Denormalize bir şema normalleştiriyorsanız, başlamadan önce kaç kayıt yapmanız gerektiğini hesaplamanız ve sonra bunu kontrol etmeniz gerekir. Bir sistemden diğerine eşlemelerin ne olduğunu belirten dokümantasyon gerekir. Bu, QA çalışanlarınızın verilerin doğru yere gittiğini kontrol etmesine yardımcı olacaktır.

Geçerli hatalı verilerin nasıl işleneceğini belirlemeniz gerekir. Ne temizlenebilir, 'Bilinmeyen' yazan zorunlu bir alanda neye ihtiyaç duyulabilir? İstisna tablosuna ne atılmalı, bir grup kullanıcı tarafından elle müdahale edilmesi gerekenler (bu iki insanın gerçekten ya da kaç kişi olduğuna karar vermek. Bu uygulamada örneğin aynı isimde iki doktor var mı ve eğer iki kaydın ne zaman seçileceğini seçmek için bir veriyse, vb.

Başarılı bir göçün anahtarı planlamadır. Planlamanın (test senaryolarının ve ünite testlerinin yazılmasını içeren) genellikle fiili gelişmeden daha fazla zaman aldığını buldum.

Başarılı bir veri taşıma işleminin bir sonraki anahtarı KG. Bu, QA ekibine lansmandan bir gün önce atılacak bir proje değil. QA bir sorun olduğunu söylediğinde başlatılacak bir proje değil.

Başarılı bir geçişin diğer bir anahtarı, verilerin çoğunluğunu dağıtmak ve orjinal sistem çalışırken hala test etmektir. Çok fazla kayıt taşıyorsanız, bu zaman alabilir ve yeni değişiklikler olacaktır. Bu nedenle işleminiz, taşıma başladıktan sonra veri değişikliklerini de yapabilmelidir. Örneğin, SQL Server, bu konuda yardımcı olabilecek Change Data Capture adlı bir şeye sahiptir. Orjinal sistemin bir yedeğini alabilir ve aynı zamanda değişiklik verilerini yakalamayı açabilirsiniz. Ardından, yedeklemeyi taşıma sunucunuza yeniden döndürebilir, taşıma işlemini sınayabilir, yüklenen verilerin çoğunluğunu alabilirsiniz ve ardından yalnızca değişen kayıtları yüklemeniz gerekir. Kesin kayıtları geçirdiğinizde, geçiş tamamlanıncaya kadar kaynak sistemi kapatın. Bu, kayıtların çoğunu vaktinden önce geçirmenin bir nedenidir, bu yüzden başvuru en az süredir. Geçiş zamanınızı iyi seçin, maaş bordrosunu işleme koymaları veya W2'leri göndermeleri gereken günü kapatmayın. Ve düşük kullanım saatlerinde yapın. Birden fazla müşteriniz varsa, önce bir kişiyi geçirmeyi ve diğerlerini yapmadan önce hepsinin iyi olduğundan emin olmayı düşünebilirsiniz. Bir sorun varsa, bir müşterinin verilerini 10000'den geri almak çok daha kolaydır. Ama yaparsanız bunu dikkatlice planlayın. Bir sorun varsa 10000'den fazla veri. Ama yaparsanız bunu dikkatlice planlayın. Bir sorun varsa 10000'den fazla veri. Ama yaparsanız bunu dikkatlice planlayın.

Geçiş yeni bir kullanıcı arayüzü içeriyorsa, lütfen gerçek kullanıcıları geçiş testi kapsamında kullanmalarını sağlayın. Daha sonra diğer kullanıcıları eğitmeden önce eğitin (ama gitmeden bir haftadan daha az bir süre önce unuturlar). Sınamaya dahil olan kullanıcıların eğitimi tasarlamalarına yardımcı olmasını sağlayın, hangi soruları olduğunu ve insanların hangi sırayla bilmeleri gerektiğini bilirler. Girdilerini alın, bir alan gerekli yapın, çünkü kullanıcılar kayıtlara girdiklerinde genellikle bu veriye sahip olmadıklarında yardımcı olmayacağını düşünüyorsanız. Verileri tam olarak alamadıkları için yeni gerekli alana önemsiz bırakacaklar.

Mevcut verilerde neyin yanlış olduğuna bakın, gelecekte bunun kötüleşmesini önlemek için yabancı anahtarlar, kısıtlamalar, tetikleyiciler, uygulamadaki iş kuralları, varsayılan değerler vb. Ekleyebilir misiniz? Kötü verileri temizlediğinizde, aynı zamanda bu kötü verilerin gelecekte girmesini önlemek için bir yol oluşturmanız gerekir. Kötü verilerin neden alaşımlandığını analiz edin ve deliklerin iç dizaynını düzeltin.

Veri göçü bir zorunluluktur. Veri geçişi olmadan sıklıkla ilerleyemezsiniz. Çalıştığım birçok sistem gerekli geçmişe sadece önceki sistemlerden ulaşılabilirdi. Göç bunu yapmanın tek pratik yöntemidir. Veri kalitesi genellikle bir konudur. Genellikle, bu önceki sistemde ele alınmalıdır. Bu, kalitenin geri kazanılması için verilerde değişiklik yapılmasını gerektirebilir.

Çalıştığım diğer sistemler, diğer sistemlerden gelen verilere dayanıyordu. Bu farklı ama önemli bir konudur. Bazı durumlarda veriler tamamen değiştirilebilir. Yeni verilerde yer alan değişiklikler mevcut kümeyle birleştirilerek diğer durumlar daha iyi ele alınabilir. Bu tür göçler, gelen yayın için geçerlilik kontrollerini içermelidir.

Mevcut verileri doğrulama ve temizleme yeteneği bir sistemin önemli bir özelliği olabilir. Bu göçten bağımsızdır. Sistemin kontrolü dışındaki verileri değiştirmek için genellikle mekanizmalar vardır. Bu, verilerin geçersiz olmasına neden olabilir. Diğer veri sorunları, uygulamadaki hatalardan kaynaklanmaktadır. Doğrulama rutinlerinin periyodik olarak çalıştırılması, sorunun tanımlanmasına yardımcı olabilir ve verilerin geçiş zamanı gelmeden önce temizlenmesini sağlar. Verilerin erken temizlendiği belirtildiği gibi, geçişi kolaylaştırabilir.

Bazı validasyonlar zamana duyarlıdır ve değiştirilmemiş verilere uygulanmamalıdır. Bu, kodların emekli edildiği kodlanmış değerlerle ortaktır. Doğrulama hatalarını tetiklemeden kayıttaki diğer alanları değiştirmek mümkün olmalıdır. Bu, güncelleme doğrulama işlemini hangi alanların doğrulamadan önce değiştiğini tespit etmesi gerektiği için daha karmaşık hale getirebilir. Alanlar arası doğrulama da daha karmaşık olabilir. Bazı kayıtları salt okunur olarak ele alma yeteneği bu durumda doğrulamadan kaçınılabileceği için yardımcı olabilir.

Üzerinde çalıştığım bir sistemde, yeni sistem müşteri tarafından kısmen reddedildi. Yeni veri giriş modüllerinin kullanılmasına izin vermediler. Ancak toplu işlemin yeni sistemden yapılmasını istediler. Çözüm, toplu işlemden önceki verileri her gece geçirmek oldu.

Bu gerekli bir kötülük. Her iki ucunda da bulundum ve bunlar sorunu birleştiren diğer sorunlardan bazıları.

1. Özellikle girişimde, komada yeni bir sisteme girdiklerinde, eski sistemin yaptığı her şeyi yapmasını istiyorlar. Prosedürlerini gözden geçirmiyorlar. O kadar bunaldılar ki, her şeyi aynı şekilde yapmaya devam etmek istiyorlar. Bu onlar için güvenlidir.
2. Yeni sistemi öğrenmek veya uzmanlığa sahip insanları işe almak için zaman ayırmazlar.
3. Yeni sistemi 1 numaraya oturtmak veya işlerinin yeni bir yönünü ele almak için özelleştirmek istiyorlar. Yeni Sistem X Özelleştirmeleri X Dönüştürülmüş Veri = Bileşik Komplikasyonlar
4. Test için yeterli zaman yok.
5. Müşteriler paralel koşmaktan / iki kez bir şeyler yapmaktan nefret eder. Kullanıcıları suçlayamazsınız, çünkü diğer görevlerinin tümü tam anlamıyla sürdürüldüğü için buna vakti tanınmamıştır.

Yöneticileriniz veri dönüştürmeyerek satış kaybını haklı çıkarabilirlerse, onlara daha fazla güç kazandırın. Müşterilerinize tüm veri dönüşümlerinin başarısız olduğunu söylemek işe yaramayacak çünkü başkası onlara her zaman bunu yapacağını söyleyecektir (Genellikle rekabetiniz.).

Veri geliştirmeyle ilgili düşünceleriniz, özellikle gerçek hayattaki durumlar için ve sadece bir geliştiricinin bakış açısından değil?

Yazılımın düzenli olarak yükseltilmesi gerekir. Geçişin kaydedildiğinden emin olmak için yedekleme ve test işlemlerine ihtiyacınız var.

Yöneticilerimin görüşlerine karşı herhangi bir tartışmanız var mı?

riskli olduğu doğru. ancak teknikleri daha az riskli hale getirmek için uyarlayabilirsiniz.

Şirketiniz veri göçleri ve bunlardan kaynaklanan zorluklarla nasıl başa çıkıyor?

günlük yedekleme, artan yedekleme, üretime her dağıtımdan önce yedeklememiz vardır. bu en azından kötü bir şey olursa geri almanıza izin verir.

test ortamımız, otomatik testlerimiz ve günlük kurulum sunucumuz var. ayrıca ana işlemlerin ve fonksiyonların düzgün çalıştığından emin olmak için bir duman testi prosedürü. Oluşturmayı test etmek için geliştiricileri, KG ve kullanıcıları içerir (veriler taşınır).

veri geçişi, yükseltme ve geri alma sürümlerini sağlayan raylar üzerinde ruby ​​kullanıyoruz. bu hayatımızı kolaylaştırıyor.

capistrano'yu kod güncelleme ve veri taşıma işlemlerini yürütmek için kullanıyoruz. göçü otomatik ve basit tutmak, üretim sisteminin çalışmasını sağlamak için anahtar şeylerden biridir.

Bu konulara ait başka ilginç düşünceleriniz var mı?

Bana veri taşıma ile ilgili diğer bir endişe kod yükseltme ve veri taşıma işlemlerinin tutarlılığıdır. Benim durumumda, yine, bununla başa çıkmak için otomatik yollar kullanıyoruz. ve her zaman geri alma için hazır.

Veri geçişini manuel olarak yürütmek, veritabanını bilinmeyen duruma döndürebilir. ve veri geçişi versiyonunu farklı sunucu ortamları arasında karşılaştırmak zordur.

Umarım yardımcı olur.

Eski miras sistemlerinden veri taşımak için zamanımızı boşa harcamıyoruz, çünkü zaman ve yatırım ve risk çok fazla. Biz sadece daha yeni sistemler ile ilerliyoruz ve gerektiğinde entegre oluyoruz.

Her işletmenin desteklemesi gereken bir eski miras sistemi vardır ve bu sadece normal bir iş yapmanın maliyetidir.

Yöneticilerinizin gerçekleştirmeyi umdukları ödül, göçün maliyeti göz önüne alındığında daha yüksek olsaydı.