Migrasi data - berbahaya atau esensial?

Departemen pengembangan perangkat lunak perusahaan saya menghadapi masalah bahwa migrasi data dianggap berpotensi berbahaya, terutama bagi manajer saya.

Latar belakangnya adalah bahwa pelanggan kami menggunakan sejumlah besar data dengan kualitas buruk . Alasan untuk ini hanya sebagian terkait dengan kualitas perangkat lunak kami , tetapi lebih kepada sejarah data: Sebagian besar dari mereka telah dimigrasi dari sistem pendahulunya , beberapa bug menyebabkan (sebagian besar bisnis) inkonsistensi dalam catatan data atau ketidakhadiran secara tidak sengaja pada sisi pelanggan (yang mana perangkat lunak kami diizinkan karena kesalahan).

Argumen kontra paling penting dari manajer saya adalah bahwa data yang salah dapat berubah menjadi data yang lebih buruk , masalah data dapat membangunkan beberapa manajer di pelanggan dan beberapa proses di sisi pelanggan mungkin tidak berfungsi lagi karena proses mereka agak disesuaikan dengan sistem kami.

Secara pribadi, saya menganggap migrasi data sebagai bagian integral dari pengembangan perangkat lunak dan migrasi data dapat dilihat sebagai data apa yang dimaksud dengan refactoring terhadap kode. Saya pikir migrasi data sangat penting untuk membuat perangkat lunak yang berkembang . Tanpa itu, kita harus membuat perangkat lunak yang menyakitkan yang agak bekerja di sekitar struktur data yang buruk.

Saya bertanya:

• Apa pendapat Anda tentang migrasi data, terutama untuk kasus kehidupan nyata dan tidak hanya dari perspektif pengembang?
• Apakah Anda memiliki argumen yang menentang pendapat manajer saya?
• Bagaimana perusahaan Anda menangani migrasi data dan kesulitan yang disebabkan oleh mereka?
• Adakah pemikiran menarik lain yang termasuk dalam topik ini?

Migrasi data adalah roti dan mentega saya dan pembersihan data memang masalah yang sangat penting. Salah satu strategi yang kami gunakan melakukan migrasi 100% dari data pelanggan kami adalah pembersihan asimtotik data alat pra-migrasi.

1. Ini berarti mengembangkan puluhan pemeriksaan data-kewarasan (kebanyakan kueri sql).

2. Saling menukar alat pembersih dengan pelanggan (karena itu datanya, kami merancang utilitas penambalan, ia memvalidasinya dan mengeksekusinya).

3. Memperbaiki alat melalui iterasi dan mencapai kualitas terukur yang didukung KPI secepatnya.

4. Memeriksa konsistensi data setelah migrasi berakhir. Ini membantu untuk membuat keputusan GO / NOGO pada D-Day.

Pada akhirnya migrasi data adalah latihan yang sangat bermanfaat yang harus terjadi setelah 3 hingga 5 tahun.

1. Hal ini memungkinkan untuk meningkatkan kemampuan platform untuk mendukung bisnis.

2. Memungkinkan untuk merampingkan basis data.

3. Ini mempersiapkan platform TI untuk perangkat bisnis generasi berikutnya (ESB / EAI, Portal, platform Self-Care, pelaporan dan penggalian data, sebut saja).

4. Ini mengatur ulang aliran data DIY antara platform yang telah terakumulasi selama bertahun-tahun dengan cara "sementara" yang cepat dan kotor untuk memenuhi "persyaratan mendesak".

5. Di atas semua itu memberdayakan tim produksi TI yang datang untuk mengetahui platform mereka lebih baik dan menumbuhkan sikap 'bisa-lakukan'. Manfaat semacam ini sulit diukur tetapi ketika Anda mengenal banyak klien, pertimbangan ini menjadi jelas. Perusahaan yang menghindar dari migrasi tetap berada di tingkat berikut, perusahaan yang berani memimpin paket.

Ini sedikit seperti ketika ruang bawah tanah rumah Anda menjadi berantakan dengan kayu. Suatu pagi, Anda harus mengambil semuanya dan mengembalikan hanya barang-barang yang Anda butuhkan dan membuang sisanya. Setelah itu, Anda dapat menggunakan ruang bawah tanah lagi ;-)

Pertimbangan mendasar lainnya adalah bahwa saat ini, harapan pelanggan selalu berubah, seperti dalam "pelanggan selalu lebih menuntut". Sehingga akan selalu ada proporsi yang signifikan dari pesaing perusahaan tertentu dalam mencari tren baru ini dengan niat yang jelas untuk meningkatkan pangsa pasar mereka. Cara mereka akan melakukannya adalah dengan menyesuaikan penawaran mereka untuk tetap pada tren atau bahkan mendorong tren, dan itu memerlukan rekayasa ulang bisnis yang konstan. Jika platform IT Anda terlalu kaku, itu akan menjadi hambatan pada kemampuan Anda sendiri untuk pasangan atau mendahului tren pasar di sisi Anda sendiri dan, pada akhirnya untuk mempertahankan pangsa pasar Anda sendiri. Dengan kata lain, inersia pasar yang bergerak adalah resep untuk tidak relevan.

Sebaliknya, migrasi data ke sistem yang lebih baru akan meluncurkan alat produktivitas yang lebih modern dan lebih fleksibel, membuat yang terbaik dari teknologi yang lebih baru, lebih menarik bagi karyawan dan ini pada gilirannya, akan berkontribusi untuk mendukung atau bahkan memimpin proses inovasi internal perusahaan , dengan demikian mengamankan atau meningkatkan pangsa pasar relatifnya.

Pertimbangan di atas sebenarnya hanya menjawab setengah dari pertanyaan yang diajukan dalam judul "Migrasi Data - berbahaya atau penting". Ya Migrasi Data sangat penting, tetapi apakah itu juga berbahaya? Pada akun ini, banyak hal di IT berbahaya saat itu. Menurut definisi, apa pun di mana taruhannya tinggi adalah berbahaya; terutama jika Anda tidak menganggap serius masalah ini. Tetapi ini sebenarnya adalah pola yang paling umum dalam TI. Tidak menganggap serius pusat data atau ketersediaan tinggi atau toleransi bencana adalah berbahaya.
Apakah itu berarti bahwa perusahaan saat ini harus memilih keluar dari pilar lanskap Teknologi Informasi saat ini? Tentunya tidak!

Untuk membuat titik Anda bercanda, Anda bisa berpendapat bahwa "Terbang itu berbahaya jika Anda tidak menggunakan pesawat yang dibuat oleh para profesional". Itu sama untuk Migrasi Data. Ketika dieksekusi dan dilakukan oleh para profesional, itu tidak lebih berbahaya daripada terbang di pesawat yang dirancang dan dioperasikan dengan baik. Dan ROI dalam proporsi yang sama dibandingkan dengan alat transportasi darat.
Ketika dipercayakan kepada para profesional, sebagian besar migrasi dikendalikan dengan sukses dan tingkat kegagalan + pengabaian sangat rendah.

Manajer Anda harus dituntun untuk bertanya pada diri sendiri, "Sementara sebagian besar perusahaan berhasil melalui proyek Migrasi Data, apa yang akan membuat perusahaan kami sangat berbeda sehingga malah akan mengalami kegagalan?

Alain memberikan jawaban yang bagus dalam hal pentingnya pembersihan data untuk proyek migrasi data yang sukses dan alasan di balik melakukan migrasi data sama sekali. Saya ingin menargetkan hanya masalah khusus yang dimiliki manajer Anda.

Menurut pendapat saya itu bukan pertanyaan apakah akan melakukan migrasi data atau tidak, ini tentang kapan melakukannya. Manajer Anda memiliki poin yang benar-benar valid mengatakan bahwa data Anda bukan hanya milik Anda lagi dan pelanggan akhir sudah membangun prosedur di sekitarnya. Namun keadaan ini tidak akan berubah di masa mendatang . Cepat atau lambat, kualitas data yang buruk akan menjadi faktor yang tidak dapat dihindari untuk memperlambat bisnis Anda dan Anda akan dipaksa untuk melakukan migrasi. Melakukan ini di bawah tekanan dan dengan tenggat waktu yang ketat dapat menyebabkan keputusan yang tidak optimal. Selain itu, pikirkan keahlian yang Anda miliki sekarang dan akan miliki dalam 2-3 tahun dari sekarang. Bagaimana jika orang yang memahami data Anda akan meninggalkan perusahaan? Apakah Anda yakin dokumentasi yang Anda miliki memadai?

Mungkin melakukan migrasi sekarang tidak diperlukan tetapi manajer Anda setidaknya perlu memiliki visi kapan tepatnya migrasi akan dilakukan.

Saya bekerja di perusahaan asuransi dan terlibat dalam migrasi data untuk sistem inti. Yaa, ada total 4 kali. Jadi, inilah komentar saya:

Dalam kasus saya, migrasi data adalah suatu keharusan, karena dengan peraturan kita harus menyimpan data setidaknya selama 10 tahun, dan kita tidak mampu mendukung sistem ganda dalam jangka panjang. Alasan lainnya adalah pengguna berharap mereka dapat melanjutkan pekerjaan mereka dengan aplikasi baru. Jika mereka tidak dapat menemukan item tempat mereka bekerja, aplikasi Anda buruk, dan bahkan lebih buruk ketika data tidak benar.

Nah, migrasi data adalah binatang yang mengerikan dan itu nyata, jadi hadapilah. Ini berisiko tetapi dapat diminimalkan dengan mengatasinya lebih awal dan hati-hati. Sebagai panduan, ada empat proses besar yang harus dipertimbangkan dalam migrasi data:

1. Pemetaan data. Peta master (dan kombinasinya) ke sistem baru
2. Pembersihan data. Peta pengecualian dalam data, yaitu data yang kombinasinya dianggap tidak valid pada sistem baru. Jika mungkin, berurusan dengan bisnis untuk mengecualikan data yang tidak memiliki cara untuk dipetakan dan berpotensi merusak sistem baru, dan menyiapkan solusi
3. Migrasi data aktual. Ada banyak strategi untuk melakukan migrasi data. Misalnya: big bang, incremental
4. Laporkan konsolidasi. Jika kedua sistem berjalan secara paralel, bagaimana menghasilkan laporan yang benar dan konsisten

Acara dengan rencana hati-hati, sial terjadi! Satuan tugas khusus harus siap untuk menangani masalah yang terkait dengan migrasi.

1) Apa pendapat Anda tentang migrasi data, terutama untuk kasus kehidupan nyata dan tidak hanya dari perspektif pengembang ?:

Migrasi adalah bagian penting dari pengembangan sistem. Jika Anda sebagian atau seluruhnya menggantikan sistem lama, migrasi adalah fakta kehidupan apakah manajemen menginginkannya atau tidak. Jika data yang ada buruk, itu akan berdampak buruk pada sistem baru Anda. Karena itu, sangat penting untuk memiliki strategi migrasi yang baik.

2) Apakah Anda memiliki argumen yang bertentangan dengan pendapat manajer saya?

Ya, migrasi itu berisiko, tetapi itu juga fakta kehidupan, jadi atasi saja. Dan menanganinya sedini mungkin.

3) Bagaimana perusahaan Anda menangani migrasi data dan kesulitan yang disebabkan oleh mereka?

Perusahaan saya telah - dengan meningkatnya keberhasilan melibatkan pelanggan secara aktif dalam proses migrasi. Kami meninjau data yang ada sebaik mungkin di langkah awal proyek, dan mendorong pelanggan untuk meningkatkan kualitas data sebelum kami mulai bermigrasi. Terkadang kami benar-benar menuntutnya.

4: Pikiran menarik lainnya yang termasuk dalam topik ini

Saran saya adalah membagi proses migrasi dalam dua langkah: Konversi dan Pembersihan data. Konversi cukup mudah - masalah memetakan objek sistem lama ke sistem baru yang baru. Membersihkan data di sisi lain bisa menjadi hal yang sangat rumit (seperti yang disebutkan di atas). Libatkan pelanggan sebanyak mungkin, dan mulailah prosesnya sedini mungkin. Ingatlah bahwa data yang buruk akan berdampak buruk pada sistem baru Anda - terkadang sama sekali tanpa alasan. Ketika sistem baru tidak berfungsi, pelanggan jarang akan menyalahkan data yang tampaknya berfungsi dengan baik di sistem lama.

Jika data yang Anda rencanakan untuk dimigrasi saat ini buruk, perlu diperbaiki apakah Anda melakukan migrasi atau tidak. Data buruk = data tidak berguna.

Migrasi itu berisiko, itu benar. Tapi begitu pula setiap proyek TI besar. Ada beberapa cara untuk mengurangi risiko dan risiko tersebut harus direncanakan di muka dalam suatu migrasi.

Pertama, Anda harus selalu memiliki cara untuk kembali ke sistem seperti sekarang. Migrasi kedua harus dilakukan pada server uji yang disiapkan hanya untuk migrasi. Adalah bodoh untuk melakukan migrasi tanpa kemampuan untuk mengujinya terlebih dahulu. Ketiga, semua kode untuk migrasi harus dalam kontrol sumber.

Keempat, Anda memerlukan persyaratan dan rencana pengujian sebelum memulai migrasi. Anda perlu tahu bahwa jika Anda memiliki 1.293.687 catatan dalam sistem lama, bahwa Anda memiliki yang sama di yang baru atau Anda tahu di mana mereka pergi (ke tabel pengecualian mungkin). Jika Anda menormalkan skema denormalized, Anda perlu menghitung berapa banyak catatan Anda harus berakhir dengan sebelum Anda mulai dan kemudian memeriksanya. Anda memerlukan dokumentasi yang menentukan apa pemetaan dari satu sistem ke sistem lainnya. Ini akan membantu orang-orang QA Anda memeriksa untuk melihat bahwa data pergi ke tempat yang tepat.

Anda perlu menentukan cara menangani data buruk saat ini. Apa yang bisa dibersihkan, apa yang mungkin membutuhkan nilai di bidang yang diperlukan yang mengatakan 'Tidak Diketahui', apa yang harus dibuang ke tabel pengecualian, apa yang perlu intervensi manual oleh sekelompok pengguna (memutuskan apakah kedua orang ini benar-benar dup atau tidak apakah ada dua dokter dalam praktek itu dengan nama yang sama misalnya dan jika itu adalah dup mana data yang harus dipilih ketika dua catatan berbeda, dll.).

Kunci keberhasilan migrasi adalah perencanaan. Saya telah menemukan bahwa perencanaan (yang mencakup penulisan kasus uji dan tes unit) biasanya membutuhkan waktu lebih lama daripada pengembangan yang sebenarnya.

Kunci berikutnya untuk migrasi data yang sukses adalah QA. Ini bukan proyek untuk dilemparkan ke tim QA sehari sebelum peluncuran. Ini bukan proyek untuk diluncurkan ketika QA mengatakan ada masalah.

Kunci lain untuk migrasi yang berhasil adalah untuk menggunakan sebagian besar data dan mengujinya saat sistem asli masih berjalan. Jika Anda memindahkan banyak catatan, ini bisa memakan waktu dan perubahan baru akan terjadi. Jadi proses Anda harus dapat menarik perubahan data setelah migrasi dimulai juga. SQL Server misalnya memiliki sesuatu yang disebut Ubah Data Capture yang dapat membantu dengan ini. Anda dapat mengambil cadangan sistem asli dan mengaktifkan perubahan pengambilan data secara bersamaan. Kemudian Anda dapat mem-resot cadangan ke server migrasi Anda, menguji migrasi, mendapatkan sebagian besar data yang dimuat dan kemudian Anda hanya perlu memuat catatan yang telah berubah. Saat Anda memigrasi catatan akhir, matikan sistem sumber sampai migrasi selesai. Ini adalah salah satu alasan untuk memigrasi sebagian besar catatan sebelumnya, jadi aplikasi turun paling sedikit waktu. Pilih waktu migrasi Anda dengan baik, jangan tutup sistem penggajian pada hari mereka harus memproses penggajian atau mengirimkan W2s. Dan lakukan selama jam penggunaan rendah. Jika Anda memiliki banyak klien, Anda dapat mempertimbangkan untuk bermigrasi terlebih dahulu dan memastikan semuanya baik sebelum melakukan yang lain. Jauh lebih mudah untuk mengembalikan data satu pelanggan dari 10.000 jika ada masalah. Tetapi rencanakan ini dengan hati-hati jika Anda melakukannya. Data lebih dari 10.000 jika ada masalah. Tetapi rencanakan ini dengan hati-hati jika Anda melakukannya. Data lebih dari 10.000 jika ada masalah. Tetapi rencanakan ini dengan hati-hati jika Anda melakukannya.

Jika migrasi melibatkan antarmuka pengguna baru, harap minta pengguna yang sebenarnya untuk menggunakannya sebagai bagian dari pengujian migrasi. Kemudian latih pengguna lain sebelum ditayangkan (tetapi kurang dari seminggu sebelum ditayangkan atau mereka akan lupa). Jika pengguna terlibat dalam pengujian membantu merancang pelatihan, mereka tahu pertanyaan apa yang mereka miliki dan apa yang orang perlu ketahui dalam urutan apa. Dapatkan input mereka, buat bidang yang diperlukan karena menurut Anda seharusnya tidak akan membantu jika pengguna biasanya tidak memiliki data saat mereka memasukkan catatan. Mereka hanya akan memasukkan sampah ke dalam bidang yang baru diperlukan karena mereka tidak bisa mendapatkan data di sebaliknya.

Lihatlah apa yang salah dengan data saat ini, dapatkah Anda menambahkan kunci asing, batasan, pemicu, aturan bisnis dalam aplikasi, nilai default, dll. Untuk menghindari hal ini menjadi buruk di masa mendatang? Saat Anda membersihkan data yang buruk, Anda juga perlu menciptakan cara untuk menghindari agar data yang buruk tersebut tidak masuk di masa mendatang. Menganalisis mengapa data buruk disatukan dan memperbaiki desain lubang.

Migrasi data adalah suatu keharusan. Tanpa migrasi data, Anda seringkali tidak dapat melanjutkan. Banyak sistem saya telah bekerja dengan riwayat yang diperlukan hanya tersedia dari sistem sebelumnya. Migrasi adalah satu-satunya metode praktis untuk melakukan ini. Kualitas data sering menjadi masalah. Secara umum, ini harus ditangani dalam sistem sebelumnya. Ini mungkin memerlukan perubahan pada data untuk mendapatkan kembali kualitas.

Sistem lain yang pernah saya gunakan bergantung pada data dari sistem lain. Ini adalah masalah yang berbeda tetapi signifikan. Dalam beberapa kasus, data dapat diganti seluruhnya. Kasus-kasus lain mungkin lebih baik ditangani dengan menggabungkan perubahan yang termasuk dalam data baru ke dalam set yang ada. Jenis-jenis migrasi ini harus mencakup pemeriksaan validitas untuk umpan yang masuk.

Kemampuan untuk memvalidasi dan membersihkan data yang ada dapat menjadi fitur penting dari suatu sistem. Ini tidak tergantung pada migrasi. Sering ada mekanisme untuk mengubah data yang berada di luar kendali sistem. Ini dapat menyebabkan data menjadi tidak valid. Masalah data lainnya dihasilkan dari bug dalam aplikasi. Menjalankan rutinitas validasi secara berkala dapat membantu mengidentifikasi masalah dan memungkinkan data dibersihkan sebelum tiba waktunya untuk migrasi. Seperti telah dicatat, membersihkan data lebih awal dapat membuat migrasi lebih mudah.

Beberapa validasi peka waktu, dan tidak boleh diterapkan pada data yang belum dimodifikasi. Ini umum dengan nilai kode, di mana kode telah pensiun. Seharusnya dimungkinkan untuk mengubah bidang lain dalam catatan tanpa memicu kesalahan validasi. Ini dapat membuat validasi pembaruan lebih kompleks karena perlu mengidentifikasi bidang mana yang berubah sebelum validasi. Validasi lintas bidang juga lebih kompleks. Kemampuan untuk memperlakukan beberapa catatan sebagai hanya-baca dapat membantu dalam kasus ini karena validasi dapat dihindari.

Pada satu sistem I yang saya kerjakan, sistem baru itu ditolak sebagian oleh pelanggan. Mereka menolak untuk mengizinkan modul entri data baru digunakan. Namun, mereka menginginkan pemrosesan batch dari sistem baru. Solusinya adalah dengan memigrasi data setiap malam sebelum menjalankan batch.

Itu kejahatan yang perlu. Saya sudah berada di kedua ujungnya dan ini adalah beberapa masalah lain yang menambah masalah.

1. Terutama di perusahaan, ketika perusahaan pergi ke sistem baru, mereka ingin melakukan semua yang dilakukan sistem lama. Mereka tidak meninjau prosedur mereka. Mereka begitu kewalahan sehingga mereka hanya ingin terus melakukan segala hal dengan cara yang sama. Ini aman bagi mereka.
2. Mereka tidak meluangkan waktu untuk mempelajari sistem baru atau mempekerjakan orang dengan keahlian.
3. Mereka ingin menyesuaikan sistem baru untuk mengakomodasi # 1 atau untuk menangani beberapa aspek baru dari bisnis mereka. Sistem Baru X Kustomisasi X Data Yang Dikonversi = Komplikasi Compounded
4. Tidak cukup waktu yang didedikasikan untuk pengujian.
5. Pelanggan benci berjalan secara paralel / melakukan hal-hal dua kali. Tidak dapat menyalahkan pengguna karena mereka tidak diberi waktu untuk melakukan ini karena semua tugas mereka yang lain dijalankan dengan sangat baik.

Jika manajer Anda dapat membenarkan hilangnya penjualan dengan tidak mengkonversi data, lebih banyak kekuatan untuk mereka. Memberitahu pelanggan Anda bahwa semua konversi data gagal tidak akan berhasil karena orang lain akan selalu mengatakannya kepada mereka (Biasanya pesaing Anda.).

Apa pendapat Anda tentang migrasi data, terutama untuk kasus kehidupan nyata dan tidak hanya dari perspektif pengembang?

perangkat lunak harus ditingkatkan secara berkala. untuk memastikan migrasi tersimpan, Anda perlu cadangan dan pengujian.

Apakah Anda memiliki argumen yang menentang pendapat manajer saya?

dia benar bahwa itu berisiko. tetapi Anda dapat mengadaptasi teknik untuk membuatnya kurang berisiko.

Bagaimana perusahaan Anda menangani migrasi data dan kesulitan yang disebabkan oleh mereka?

kami memiliki cadangan harian, cadangan tambahan, cadangan sebelum setiap penyebaran ke produksi. yang setidaknya membiarkan Anda mengembalikan jika sesuatu yang buruk terjadi.

kami memiliki lingkungan pengujian, pengujian otomatis dan server build harian. juga prosedur uji asap untuk memastikan operasi besar dan fungsi berfungsi dengan baik. Kami melibatkan pengembang, QA, dan pengguna untuk menguji bangunan (yang memiliki data yang dimigrasikan).

kami menggunakan ruby ​​on rails, yang menyediakan versi migrasi data, peningkatan dan rollback. yang membuat hidup kita lebih mudah.

kami menggunakan capistrano untuk menjalankan pembaruan kode dan migrasi data. menjaga migrasi otomatis dan sederhana adalah salah satu kunci untuk memastikan sistem produksi berfungsi.

Adakah pemikiran menarik lain yang termasuk dalam topik ini?

Kekhawatiran lain mengenai migrasi data bagi saya adalah konsistensi peningkatan kode dan migrasi data. dalam kasus saya, sekali lagi, kami menggunakan cara otomatis untuk mengatasinya. dan selalu siap untuk kembalikan.

mengeksekusi migrasi data secara manual dapat mengubah database menjadi status yang tidak diketahui. dan sulit untuk membandingkan versi migrasi data antara lingkungan server yang berbeda.

semoga membantu.

Kami tidak membuang waktu untuk mencoba memigrasikan data dari sistem lama karena waktu dan investasi serta risikonya terlalu tinggi. Kami hanya bergerak maju dengan sistem yang lebih baru dan mengintegrasikan bila perlu.

Setiap bisnis memiliki beberapa bentuk sistem warisan yang harus didukungnya, dan itu hanya biaya normal untuk melakukan bisnis.

Ganjaran yang ingin disadari manajer Anda sebaiknya sangat tinggi mengingat biaya migrasi.