Migrazione dei dati: pericolosa o essenziale?

Il dipartimento di sviluppo software della mia azienda sta affrontando il problema che le migrazioni di dati sono considerate potenzialmente pericolose, specialmente per i miei manager.

Lo sfondo è che i nostri clienti utilizzano una grande quantità di dati di scarsa qualità . Le ragioni di ciò sono legate solo in parte alla qualità del nostro software , ma piuttosto alla storia dei dati: la maggior parte di essi è stata migrata da sistemi precedenti , alcuni bug hanno causato incoerenze (principalmente commerciali) nei set di dati o misentries per caso sul lato cliente (che il nostro software ha consentito per errore).

Le controargomentazioni più importanti dei miei manager sono che i dati errati possono trasformarsi in dati ancora peggiori , i problemi relativi ai dati potrebbero risvegliare alcuni manager presso il cliente e alcuni processi sul lato del cliente potrebbero non funzionare più perché i loro processi sono in qualche modo adattati al nostro sistema.

Personalmente, considero le migrazioni dei dati come parte integrante dello sviluppo del software e che la migrazione dei dati può essere vista dai dati su quale refactoring è codificare. Penso che la migrazione dei dati sia essenziale per la creazione di software che si evolve . Senza di esso, dovremmo creare un software doloroso che funziona in qualche modo attorno a una struttura di dati errata.

Ti sto chiedendo:

• Quali sono i tuoi pensieri sulla migrazione dei dati, in particolare per i casi di vita reale e non solo dalla prospettiva di uno sviluppatore?
• Hai qualche dubbio contro le opinioni dei miei manager?
• In che modo la tua azienda gestisce le migrazioni dei dati e le difficoltà che ne derivano?
• Qualche altro pensiero interessante che appartiene a questi argomenti?

Le migrazioni dei dati sono il mio pane e burro e la pulizia dei dati è davvero una questione estremamente importante. Una strategia che utilizziamo per migrare il 100% dei dati dei nostri clienti è strumenti di pre-migrazione per la pulizia dei dati asintotici.

1. Ciò significa sviluppare decine di controlli di integrità dei dati (principalmente query sql).

2. Scambiare strumenti di pulizia con il cliente (dal momento che sono i suoi dati, progettiamo le utility di patching, le convalida e le esegue).

3. Affinamento dello strumento su iterazioni e raggiungimento della qualità misurabile sostenuta da KPI al più presto.

4. Verifica della coerenza dei dati dopo che è avvenuta la migrazione. Questo aiuta a prendere la decisione GO / NOGO il D-Day.

Alla fine, la migrazione dei dati è un esercizio immensamente benefico che deve avvenire dopo 3-5 anni.

1. Permette di aumentare la capacità della piattaforma di supportare il business.

2. Permette di semplificare il database.

3. Prepara la piattaforma IT per gli strumenti di business di prossima generazione (ESB / EAI, Portali, piattaforme Self-Care, reportistica e data mining, tu lo chiami).

4. Riorganizza i flussi di dati fai-da-te tra piattaforme che si sono accumulate nel corso degli anni in modo rapido e sporco "temporaneo" per soddisfare i "requisiti urgenti".

5. Soprattutto dà potere al team di produzione IT che viene a conoscenza della propria piattaforma e favorisce atteggiamenti "can-do". Questi tipi di benefici sono difficili da misurare, ma quando conosci molti clienti, questa considerazione diventa ovvia. Le aziende che evitano le migrazioni rimangono al livello seguente, quelle audaci guidano il pacchetto.

È un po 'come quando il seminterrato della tua casa è ingombro di legname. Una mattina, devi togliere tutto e rimettere solo le cose di cui hai bisogno e buttare via il resto. Dopodiché, puoi usare di nuovo il seminterrato ;-)

Un'altra considerazione fondamentale è che al giorno d'oggi, le aspettative dei clienti sono sempre in movimento, come in "i clienti sono sempre più esigenti". In modo che ci sia sempre una proporzione significativa di concorrenti di una data azienda alla ricerca di queste nuove tendenze con l'ovvio intento di aumentare la loro quota di mercato. Il modo in cui lo faranno è adattando la loro offerta per attenersi alla tendenza o addirittura guidarla, e ciò comporta una costante reingegnerizzazione del business. Se la tua piattaforma IT è troppo rigida, sarà difficile trascinare o precedere le tendenze del mercato dalla tua parte e, in definitiva, mantenere la tua quota di mercato. In altre parole, in un mercato in movimento l'inerzia è una ricetta per l'irrilevanza.

Al contrario, una migrazione dei dati verso un sistema più recente implementerà uno strumento di produttività più moderno e più versatile, rendendo il meglio delle nuove tecnologie, più attraente per i dipendenti e questo a sua volta, contribuirà a supportare o addirittura a guidare il processo di innovazione interna dell'azienda , garantendo in tal modo o aumentando la sua quota di mercato relativa.

Le considerazioni di cui sopra in realtà rispondono solo alla metà della domanda posta nel titolo "Migrazione dei dati - pericolosa o essenziale". Sì Le migrazioni dei dati sono essenziali, ma sono anche pericolose? Per questo motivo, molte cose nell'IT sono pericolose allora. Per definizione, qualsiasi cosa in cui la posta in gioco è alta è pericolosa; soprattutto se non prendi sul serio la questione. Ma questo è in realtà il modello più comune nell'IT. Non prendere sul serio i data center o l'alta disponibilità o la tolleranza alle catastrofi è pericoloso.
Ciò significa che le aziende di oggi dovrebbero rinunciare a questi pilastri del panorama informatico odierno? Sicuramente no !

Per fare il punto scherzosamente, si potrebbe sostenere che "volare è pericoloso se non si utilizza un aereo realizzato da professionisti". È lo stesso per le migrazioni dei dati. Se eseguito e condotto da professionisti, non è più pericoloso che volare in un aereo ben progettato e ben gestito. E il ROI è nella stessa proporzione rispetto ai mezzi di trasporto terrestri.
Se affidata a professionisti, la maggior parte delle migrazioni sono successi ben controllati e il tasso di fallimento + abbandono è estremamente basso.

I tuoi manager dovrebbero essere portati a chiedersi "Mentre la maggior parte delle aziende attraversa con successo i progetti di migrazione dei dati, cosa renderebbe la nostra azienda così diversa da subire un fallimento? E può andare bene senza?"

Alain ha dato un'ottima risposta in termini di importanza della pulizia dei dati per il successo del progetto di migrazione dei dati e la logica alla base della migrazione dei dati. Vorrei prendere di mira solo le preoccupazioni specifiche del vostro manager.

Secondo me non si tratta di eseguire o meno la migrazione dei dati, si tratta di quando farlo. Il tuo manager ha assolutamente ragione nel dire che i tuoi dati non sono più solo tuoi e che i clienti finali hanno già costruito le loro procedure attorno ad essi. Tuttavia, questo stato non cambierà in futuro . Prima o poi la scarsa qualità dei dati diventerà inevitabile fattore di rallentamento della tua attività e sarai costretto a effettuare la migrazione. Farlo sotto pressione e con scadenze ravvicinate potrebbe portare a decisioni non ottimali. Inoltre, pensa alle competenze che hai ora e avrai tra 2-3 anni. E se le persone che comprendono i tuoi dati lasceranno la compagnia? Sei sicuro che la documentazione che hai sia adeguata?

Forse fare la migrazione ora non è necessario, ma almeno il tuo manager deve avere una visione per quando verrà eseguita esattamente la migrazione.

Lavoravo per una compagnia assicurativa e mi occupavo della migrazione dei dati per il sistema centrale. Bene, ce n'erano in totale 4 volte. Quindi, ecco i miei commenti:

Nel mio caso, la migrazione dei dati è un must, poiché per regolamento dobbiamo conservare i dati per almeno 10 anni e non possiamo permetterci di supportare il doppio sistema a lungo termine. L'altro motivo è che gli utenti si aspettano di poter continuare a lavorare con la nuova applicazione. Se non riescono a trovare l'elemento in cui funzionano, la tua applicazione è difettosa, e ancora peggio quando i dati non sono corretti.

Bene, la migrazione dei dati è una bestia orribile ed è reale, quindi affrontala. È rischioso ma può essere ridotto al minimo affrontandolo prima e con attenzione. Come guida, ci sono quattro grandi processi che dovrebbero essere presi in considerazione nella migrazione dei dati:

1. Mappatura dei dati. Mappe del master (e la loro combinazione) sul nuovo sistema
2. Pulizia dei dati. Mappe di eccezione nei dati, ovvero dati la cui combinazione è considerata non valida sul nuovo sistema. Se possibile, trattare con le aziende per escludere dati che non hanno modo di essere mappati e potenzialmente rompere il nuovo sistema e preparare soluzioni alternative
3. Migrazione effettiva dei dati. Esistono molte strategie per eseguire la migrazione dei dati. Ad esempio: big bang, incrementale
4. Consolidamento del rapporto. Se entrambi i sistemi funzionano in parallelo, come produrre report corretti e coerenti

Evento con un piano attento, la merda succede! Una task force speciale dovrebbe essere pronta ad affrontare i problemi relativi alla migrazione.

1) Quali sono i tuoi pensieri sulla migrazione dei dati, in particolare per i casi di vita reale e non solo dalla prospettiva di uno sviluppatore ?:

La migrazione è una parte essenziale dello sviluppo dei sistemi. Se sostituisci parzialmente o interamente i vecchi sistemi, la migrazione è un dato di fatto che la direzione lo voglia o no. Se i dati esistenti sono errati, si riflettono negativamente sul nuovo sistema. Pertanto, è di enorme importanza disporre di una buona strategia di migrazione.

2) Hai qualche argomento contro le opinioni dei miei manager?

Sì, la migrazione è rischiosa, ma è anche un dato di fatto, quindi affrontala. E affrontalo il prima possibile.

3) In che modo la tua azienda gestisce le migrazioni dei dati e le difficoltà che ne derivano?

La mia azienda ha coinvolto, con crescente successo, i clienti attivamente nel processo di migrazione. Esaminiamo i dati esistenti nel miglior modo possibile nelle fasi iniziali del progetto e incoraggiamo il cliente a migliorare la qualità dei dati prima di iniziare la migrazione. A volte lo chiediamo davvero.

4: Qualsiasi altro pensiero interessante che appartiene a questi argomenti

Il mio consiglio è di dividere il processo di migrazione in due passaggi: conversione e pulizia dei dati. La conversione è abbastanza semplice: si tratta di mappare gli oggetti del vecchio sistema con il nuovo nuovo sistema. La pulizia dei dati d'altra parte può essere una cosa molto complicata (come menzionato sopra). Coinvolgi il cliente il più possibile e avvia il processo il prima possibile. Tieni presente che i dati errati si riflettono negativamente sul tuo nuovo sistema, a volte completamente senza motivo. Quando un nuovo sistema non funziona, un cliente raramente incolpa i dati che sembravano funzionare bene nel vecchio sistema.

Se i dati che si prevede di migrare sono attualmente errati, è necessario correggerli indipendentemente dal fatto che si esegua o meno una migrazione. Dati errati = dati inutili.

Le migrazioni sono rischiose, è vero. Ma lo è anche ogni grande progetto IT. Esistono modi per mitigare il rischio e dovrebbero certamente essere pianificati in anticipo in una migrazione.

Innanzitutto, dovresti sempre avere un modo per tornare al sistema come è adesso. Le seconde migrazioni devono essere eseguite su server di test impostati solo per la migrazione. È una follia fare una migrazione senza la possibilità di testarla prima. In terzo luogo, tutto il codice per la migrazione dovrebbe essere nel controllo del codice sorgente.

In quarto luogo, sono necessari requisiti e piani di test prima di iniziare la migrazione. Devi sapere che se hai avuto 1.293.687 record nel vecchio sistema, che hai lo stesso nel nuovo o sai dove sono andati (forse a una tabella delle eccezioni). Se si sta normalizzando uno schema denormalizzato, è necessario calcolare il numero di record con cui si dovrebbe finire prima di iniziare e quindi verificarlo. È necessaria la documentazione che specifica quali sono i mapping da un sistema all'altro. Ciò aiuterà i tuoi addetti al controllo qualità a verificare che i dati siano andati nel posto giusto.

È necessario determinare come gestire i dati errati correnti. Cosa può essere ripulito, cosa potrebbe aver bisogno di un valore in un campo obbligatorio che dice 'Sconosciuto', cosa dovrebbe essere gettato in una tabella delle eccezioni, cosa ha bisogno di un intervento manuale da parte di un gruppo di utenti (decidere se queste due persone sono davvero un dup o ci sono due medici in quella pratica con lo stesso nome per esempio e se si tratta di un dup di quali dati scegliere quando i due record differiscono, ecc.).

La chiave per una migrazione di successo è la pianificazione. Ho scoperto che la pianificazione (che comprende la scrittura dei casi di test e dei test unitari) di solito richiede più tempo rispetto allo sviluppo effettivo.

La chiave successiva per una corretta migrazione dei dati è il QA. Questo non è un progetto da lanciare al team QA il giorno prima del lancio. Questo non è un progetto da avviare quando il QA dice che c'è un problema.

Un'altra chiave per una corretta migrazione è distribuire la maggior parte dei dati e testarli mentre il sistema originale è ancora in esecuzione. Se si spostano molti record, ciò potrebbe richiedere molto tempo e potrebbero verificarsi nuove modifiche. Pertanto, anche il processo deve essere in grado di eseguire il pull delle modifiche ai dati dopo l'avvio della migrazione. SQL Server, ad esempio, ha qualcosa chiamato Change Data Capture che può aiutare in questo. È possibile eseguire un backup del sistema originale e attivare contemporaneamente l'acquisizione dei dati di modifica. Quindi è possibile resotre il backup sul server di migrazione, testare la migrazione, ottenere la maggior parte dei dati caricati e quindi caricare solo i record che sono stati modificati. Quando si esegue la migrazione dei record finali, disattivare il sistema di origine fino al completamento della migrazione. Questo è uno dei motivi per migrare la maggior parte dei record in anticipo, quindi l'applicazione è inattiva nel minor tempo possibile. Scegli bene il tuo tempo di migrazione, non chiudere il sistema di gestione stipendi nel giorno in cui dovrebbe elaborare la gestione stipendi o inviare W2. E farlo durante le ore di scarso utilizzo. Se hai più client, potresti considerare di migrarne uno prima e assicurarti che tutto vada bene prima di fare gli altri. È molto più semplice ripristinare i dati di un cliente rispetto a 10000 in caso di problemi. Ma pianifica attentamente se lo fai. s dati di 10000 in caso di problemi. Ma pianifica attentamente se lo fai. s dati di 10000 in caso di problemi. Ma pianifica attentamente se lo fai.

Se la migrazione prevede una nuova interfaccia utente, indurre gli utenti effettivi a utilizzarla come parte del test di migrazione. Quindi formare gli altri utenti prima di andare in diretta (ma meno di una settimana prima di andare in diretta o se ne dimenticheranno). Gli utenti coinvolti nei test aiutano a progettare la formazione, sanno quali domande avevano e cosa le persone devono sapere in quale ordine. Ottieni il loro input, rendendo obbligatorio un campo perché pensi che dovrebbe essere non utile se gli utenti di solito non dispongono di tali dati quando inseriscono i record. Metteranno semplicemente spazzatura nel campo appena richiesto perché non possono ottenere i dati in altro modo.

Guarda cosa c'è che non va nei dati attuali, puoi aggiungere chiavi esterne, vincoli, trigger, regole di business nell'applicazione, valori predefiniti, ecc. Al fine di evitare che ciò sia negativo in futuro? Quando si puliscono i dati errati, è necessario anche creare un modo per evitare che quei dati erroneamente simili entrino in futuro. Analizzare il motivo per cui i dati errati sono stati assegnati e correggere il design dei fori.

La migrazione dei dati è una necessità. Senza la migrazione dei dati spesso non è possibile andare avanti. Molti sistemi con cui ho lavorato hanno richiesto la cronologia disponibile solo da sistemi precedenti. La migrazione è l'unico metodo pratico per farlo. La qualità dei dati è spesso un problema. In generale, questo dovrebbe essere affrontato nel sistema precedente. Ciò potrebbe richiedere modifiche ai dati per riacquistare qualità.

Altri sistemi con cui ho lavorato dipendevano dai dati di altri sistemi. Questo è un problema diverso ma significativo. In alcuni casi i dati possono essere completamente sostituiti. Altri casi possono essere gestiti meglio unendo le modifiche incluse nei nuovi dati nel set esistente. Questi tipi di migrazioni dovrebbero includere controlli di validità per il feed in entrata.

La capacità di convalidare e pulire i dati esistenti può essere una caratteristica importante di un sistema. Questo è indipendente dalla migrazione. Esistono spesso meccanismi per modificare i dati che esulano dal controllo del sistema. Ciò può rendere non validi i dati. Altri problemi relativi ai dati derivano da bug nell'applicazione. L'esecuzione periodica delle routine di convalida può aiutare a identificare il problema e consentire la pulizia dei dati prima che sia il momento della migrazione. Come è stato notato, la pulizia anticipata dei dati può facilitare la migrazione.

Alcune convalide sono sensibili al tempo e non dovrebbero essere applicate ai dati che non sono stati modificati. Questo è comune con i valori codificati, in cui i codici sono stati ritirati. Dovrebbe essere possibile modificare altri campi nel record senza attivare errori di convalida. Ciò può rendere la convalida dell'aggiornamento più complessa in quanto deve identificare quali campi sono stati modificati prima della convalida. La convalida del campo incrociato può anche essere più complessa. La possibilità di trattare alcuni record come di sola lettura può aiutare in questo caso poiché la convalida può essere evitata.

Su un sistema I su cui ho lavorato, il nuovo sistema è stato parzialmente rifiutato dal cliente. Si sono rifiutati di consentire l'utilizzo dei nuovi moduli di immissione dati. Tuttavia, volevano l'elaborazione batch dal nuovo sistema. La soluzione era migrare i dati ogni sera prima dell'esecuzione in batch.

È un male necessario. Sono stato su entrambi i fronti e questi sono alcuni degli altri problemi che aggravano il problema.

1. Soprattutto nell'azienda, quando i comapnies vanno in un nuovo sistema, vogliono che faccia tutto quello che faceva il vecchio sistema. Non riesaminano le loro procedure. Sono così sopraffatti che vogliono solo continuare a fare tutto allo stesso modo. Questo è sicuro per loro.
2. Non si prendono il tempo per imparare il nuovo sistema o assumere persone con esperienza.
3. Vogliono personalizzare il nuovo sistema per adattarsi al primo posto o per gestire alcuni nuovi aspetti della loro attività. Nuovo sistema X Personalizzazioni X Dati convertiti = Complicazioni composte
4. Non è dedicato abbastanza tempo ai test.
5. I clienti odiano correre in parallelo / fare le cose due volte. Non posso incolpare gli utenti perché non hanno il tempo di farlo poiché tutte le loro altre funzioni sono mantenute a pieno regime.

Se i tuoi manager possono giustificare la perdita di vendite non convertendo i dati, più potere a loro. Dire ai tuoi clienti che tutte le conversioni di dati falliscono non funzionerà perché qualcun altro gli dirà sempre che lo farà (di solito la tua concorrenza).

Quali sono i tuoi pensieri sulla migrazione dei dati, in particolare per i casi di vita reale e non solo dalla prospettiva di uno sviluppatore?

il software deve essere aggiornato regolarmente. per assicurarsi che la migrazione sia salvata, è necessario il backup e i test.

Hai qualche dubbio contro le opinioni dei miei manager?

ha ragione che è rischioso. ma puoi adattare le tecniche per renderlo meno rischioso.

In che modo la tua azienda gestisce le migrazioni dei dati e le difficoltà che ne derivano?

abbiamo backup giornalieri, backup incrementali, backup prima di ogni distribuzione in produzione. che almeno ti permettono di tornare indietro se succede qualcosa di brutto.

abbiamo un ambiente di test, test automatizzati e server di build giornaliero. anche una procedura di prova del fumo per assicurarsi che le principali operazioni e funzioni funzionino correttamente. Coinvolgiamo sviluppatori, QA e utenti per testare la build (che ha migrato i dati).

stiamo usando ruby ​​on rails, che fornisce il controllo delle versioni di migrazione, aggiornamento e rollback dei dati. che ci semplifica la vita.

stiamo usando capistrano per eseguire l'aggiornamento del codice e la migrazione dei dati. mantenere la migrazione automatizzata e semplice è una delle cose chiave per assicurarsi che il sistema di produzione funzioni.

Qualche altro pensiero interessante che appartiene a questi argomenti?

un'altra preoccupazione per quanto riguarda la migrazione dei dati per me è la coerenza dell'aggiornamento del codice e della migrazione dei dati. nel mio caso, di nuovo, stiamo usando modi automatizzati per gestirlo. e sempre pronto al rollback.

l'esecuzione manuale della migrazione dei dati può trasformare il database in uno stato sconosciuto. ed è difficile confrontare la versione di migrazione dei dati tra diversi ambienti server.

spero che sia d'aiuto.

Non perdiamo tempo a cercare di migrare i dati da vecchi sistemi legacy perché il tempo, gli investimenti e i rischi sono troppo alti. Andiamo avanti con i sistemi più recenti e ci integriamo quando necessario.

Ogni azienda ha una qualche forma di sistema legacy che deve supportare e questo è solo un normale costo per fare affari.

La ricompensa che i tuoi manager sperano di realizzare sarebbe stata molto elevata dato il costo della migrazione.