Migrazione dei dati: pericoloso o essenziale?

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 è la pulizia asintotica dei dati degli strumenti di pre-migrazione.

1. Ciò significa lo sviluppo di decine di controlli di integrità dei dati (principalmente query SQL).

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

3. Affinamento dello strumento su iterazioni e raggiungimento della qualità misurabile con supporto KPI appena possibile.

4. Verifica della coerenza dei dati dopo la migrazione. Questo aiuta a prendere decisioni GO / NOGO sul D-Day.

Alla fine, una migrazione dei dati è un esercizio estremamente utile che deve verificarsi dopo 3 o 5 anni.

1. Consente di potenziare la capacità della piattaforma di supportare il business.

2. Consente di semplificare il database.

3. Prepara la piattaforma IT per gli strumenti di business di prossima generazione (ESB / EAI, portali, piattaforme Self-Care, reporting e data mining, è il nome)

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

5. Soprattutto consente al team di produzione IT di conoscere meglio la propria piattaforma e di promuovere atteggiamenti "da fare". Questi tipi di benefici sono difficili da misurare, ma quando si arriva a conoscere molti clienti, questa considerazione diventa ovvia. Le aziende che abbandonano le migrazioni rimangono al livello successivo, quelle in grassetto guidano il gruppo.

È un po 'come quando la cantina della tua casa diventa ingombra di legname. Una mattina, devi togliere tutto e rimettere solo le cose che ti servono e buttare via il resto. Dopodiché, puoi usare di nuovo il tuo seminterrato; -)

Un'altra considerazione fondamentale è che al giorno d'oggi le aspettative dei clienti sono sempre in movimento, poiché "i clienti sono sempre più esigenti". In modo che ci sarà sempre una percentuale significativa di concorrenti di una determinata società alla ricerca di queste nuove tendenze con l'intento evidente di aumentare la loro quota di mercato. Il modo in cui lo faranno è adattando la loro offerta per attenersi alla tendenza o addirittura guidare le tendenze e ciò implica una costante reingegnerizzazione del business. Se la tua piattaforma IT è troppo rigida, sarà un ostacolo alla tua attitudine a sposare o precedere le tendenze del mercato dalla tua parte e, in ultima analisi, a mantenere la tua quota di mercato. In altre parole, in un'energica commovente mercato è una ricetta per irrilevanza.

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

Le considerazioni sopra riportate in realtà rispondono solo a metà della domanda posta nel titolo "Migrazione dei dati - pericoloso 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 sia alta è pericolosa; soprattutto se non prendi seriamente la questione. Ma questo è in realtà il modello più comune in IT. Non prendere sul serio data center o alta disponibilità o tolleranza alle catastrofi è pericoloso.
Ciò significa che le aziende odierne dovrebbero rinunciare a questi pilastri dell'attuale panorama dell'Information Technology? Sicuramente no!

Per rendere scherzoso il tuo punto, potresti obiettare che "volare è pericoloso se non usi un aereo fatto da professionisti". È lo stesso per le migrazioni dei dati. Quando viene eseguito e condotto da professionisti, non è più pericoloso che volare su un aereo ben progettato e ben gestito. E il ROI è nella stessa proporzione rispetto al mezzo di trasporto terrestre.
Se affidati a professionisti, la maggior parte delle migrazioni è un successo ben controllato e il tasso di fallimento + abbandono è estremamente basso.

I tuoi manager dovrebbero essere portati a chiedersi "Mentre la maggior parte delle aziende passa con successo ai progetti di migrazione dei dati cosa renderebbe la nostra società così diversa da comportare invece un fallimento? ? "

Alain ha dato una grande risposta in termini di importanza della pulizia dei dati per il successo del progetto di migrazione dei dati e della logica alla base della migrazione dei dati. Vorrei scegliere come target solo le preoccupazioni specifiche del tuo manager.

Secondo me non è questione di fare migrazione dei dati o no, si tratta di quando farlo. Il tuo manager ha assolutamente ragione di affermare che i tuoi dati non sono più solo tuoi e che i clienti finali hanno già costruito le loro procedure. Tuttavia questo stato non cambierà in futuro . Prima o poi la scarsa qualità dei dati diventerà un fattore inevitabile per rallentare il business e sarai costretto a fare migrazione. Fare questo sotto pressione e con scadenze ravvicinate potrebbe portare a decisioni non ottimali. Inoltre, pensa all'esperienza che hai e che avrai tra 2-3 anni. Cosa succede se le persone che capiscono i tuoi dati lasceranno la compagnia? Sei sicuro che la documentazione che hai è adeguata?

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

Lavoravo per una compagnia di assicurazioni e mi occupavo della migrazione dei dati per il sistema principale. Bene, ci sono stati in totale 4 volte. Quindi, ecco i miei commenti:

Nel mio caso, la migrazione dei dati è un must, dal momento che con la regolamentazione 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 che possano continuare a lavorare con la nuova applicazione. Se non riescono a trovare l'oggetto su cui lavorano, l'applicazione è danneggiata 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 minimizzato 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 di master (e loro combinazione) al nuovo sistema
2. Pulizia dei dati. Mappe di eccezioni nei dati, ovvero dati la cui combinazione è considerata non valida sul nuovo sistema. Se possibile, gestisci le attività commerciali per escludere i dati che non possono essere mappati e potenzialmente interrompono il nuovo sistema e preparano il rimedio
3. Migrazione effettiva dei dati. Ci sono molte strategie per eseguire la migrazione dei dati. Ad esempio: big bang, incrementale
4. Consolidamento del report. Se entrambi i sistemi funzionano in parallelo, come produrre un report corretto e coerente

Evento con un piano accurato, succede un cazzo! Una task force speciale dovrebbe essere pronta ad affrontare i problemi legati alla migrazione.

1) Quali sono i tuoi pensieri per la migrazione dei dati, soprattutto per i casi reali e non solo dalla prospettiva di uno sviluppatore?:

La migrazione è 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 meno. Se i dati esistenti sono negativi, rifletteranno male sul nuovo sistema. Pertanto, è di enorme importanza avere una buona strategia di migrazione.

2) Hai argomenti contro le opinioni dei miei manager?

Sì, la migrazione è rischiosa, ma è anche un fatto della vita, quindi affrontala. E affrontarlo il prima possibile.

3) In che modo la tua azienda tratta le migrazioni dei dati e le difficoltà causate da loro?

La mia azienda ha, con crescente successo, coinvolto attivamente i clienti 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 richiediamo 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 vecchi oggetti di sistema a nuovi il 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 rifletteranno in modo negativo sul tuo nuovo sistema, a volte completamente senza motivo. Quando un nuovo sistema non funziona, un cliente raramente incolpa di dati che sembrano funzionare bene nel vecchio sistema.

Se i dati che si pianifica di migrare sono corretti, è necessario correggere se si esegue o meno una migrazione. Dati errati = dati inutili.

Le migrazioni sono rischiose, è vero. Ma lo sono anche tutti i principali progetti IT. Esistono modi per mitigare i rischi e dovrebbero essere pianificati in anticipo in una migrazione.

In primo luogo, dovresti sempre avere un modo per tornare al sistema come è adesso. Le seconde migrazioni dovrebbero essere eseguite sui server di prova impostati solo per la migrazione. È folle fare una migrazione senza la possibilità di testarla prima. Terzo, 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 avevi 1,293,687 record nel vecchio sistema, hai lo stesso nel nuovo o sai dove sono andati (magari in una tabella di eccezioni). Se stai normalizzando uno schema denormalizzato, devi calcolare il numero di record con cui dovresti finire prima di iniziare e poi controllarlo. È necessaria una documentazione che specifichi quali sono le mappature da un sistema all'altro. Ciò aiuterà le persone del tuo QA a controllare che i dati siano andati nel posto giusto.

Devi determinare come gestire i cattivi dati attuali. Cosa può essere pulito, cosa potrebbe aver bisogno di un valore in un campo obbligatorio che dice 'Sconosciuto', cosa deve essere gettato in una tabella delle eccezioni, cosa necessita di un intervento manuale da parte di un gruppo di utenti (decidere se queste due persone sono davvero un duplicato o ci sono due dottori in quella pratica con lo stesso nome, per esempio, e se è un dup i dati da scegliere quando i due record differiscono, ecc.).

La chiave per una migrazione di successo sta pianificando. Ho trovato che la pianificazione (che include la scrittura dei casi di test e dei test unitari) di solito richiede più tempo dello sviluppo effettivo.

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

Un'altra chiave per una migrazione di successo è quella di distribuire la maggior parte dei dati e testarla mentre il sistema originale è ancora in esecuzione. Se si stanno spostando molti record, ciò potrebbe richiedere molto tempo e si verificheranno nuovi cambiamenti. Quindi il tuo processo deve essere in grado di estrarre le modifiche ai dati anche dopo l'inizio della migrazione. SQL Server, per esempio, ha qualcosa chiamato Change Data Capture che può aiutare con questo. È possibile eseguire un backup del sistema originale e attivare contemporaneamente la modifica dell'acquisizione dei dati. Quindi puoi resotre il backup sul tuo server di migrazione, testare la migrazione, ottenere la maggior parte dei dati caricati e quindi devi solo caricare i record che sono stati modificati. Quando si esegue la migrazione dei record finali, disattivare il sistema di origine fino al termine della migrazione. Questo è uno dei motivi per migrare la maggior parte dei record prima del tempo, quindi l'applicazione è in minor tempo. Scegli bene il tuo tempo di migrazione, non chiudere il sistema di gestione stipendi nel giorno in cui dovrebbero elaborare le buste paga o inviare W2. E farlo durante le ore di utilizzo basse. Se si hanno più client, si potrebbe considerare di migrare prima uno e assicurarsi che tutto sia buono prima di fare gli altri. È molto più facile ripristinare i dati di un cliente di 10000 se c'è un problema. Ma pianificalo attentamente se lo fai.

Se la migrazione implica una nuova interfaccia utente, si prega di far sì che gli utenti effettivi la usino come parte del test di migrazione. Quindi istruisci 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 hanno e cosa le persone hanno bisogno di sapere in quale ordine. Ottieni il loro input, rendendo necessario un campo perché ritieni che non dovrebbe essere di aiuto se gli utenti di solito non hanno quei dati quando entrano nei record. Metteranno solo junk nel campo appena richiesto perché non possono ottenere i dati altrimenti.

Guarda cosa c'è di sbagliato con i dati attuali, puoi aggiungere chiavi esterne, vincoli, trigger, regole di business nell'applicazione, valori predefiniti, ecc. per evitare che questo sia cattivo in futuro? Quando si puliscono i dati non validi, è anche necessario creare un modo per evitare che dati simili possano arrivare in futuro. Analizza il motivo per cui i dati errati sono stati assegnati e correggi i fori nella progettazione.

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

Gli altri sistemi con cui ho lavorato dipendevano da dati provenienti da 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 migrazione 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 sono al di fuori del controllo del sistema. Ciò può causare l'invalidità dei dati. Altri problemi di 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 giunto il momento della migrazione. Come è stato notato, la pulizia precoce dei dati può facilitare la migrazione.

Alcune convalide sono sensibili al fattore tempo e non dovrebbero essere applicate ai dati che non sono stati modificati. Questo è comune con 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 più complessa la convalida dell'aggiornamento poiché è necessario identificare i campi modificati prima della convalida. La convalida dei campi incrociati può anche essere più complessa. La possibilità di trattare alcuni record come di sola lettura può essere d'aiuto in questo caso poiché la convalida può essere evitata.

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

È un male necessario. Sono stato su entrambe le estremità e questi sono alcuni degli altri problemi che complicano il problema.

1. Soprattutto in azienda, quando le comitive arrivano a un nuovo sistema, vogliono che faccia tutto ciò che il vecchio sistema ha fatto. Non riesaminano le loro procedure. Sono così sopraffatti che vogliono solo continuare a fare tutto allo stesso modo. Questo è sicuro per loro.
2. Non impiegano il tempo necessario per imparare il nuovo sistema o assumere personale con esperienza.
3. Vogliono personalizzare il nuovo sistema per soddisfare il numero 1 o per gestire alcuni aspetti nuovi della loro attività. Nuove personalizzazioni X del sistema X Dati convertiti = Complicazioni composte
4. Non è dedicato abbastanza tempo al test.
5. I clienti odiano correre in parallelo / fare cose due volte. Non possiamo incolpare gli utenti perché non hanno il tempo di farlo poiché tutti gli altri loro compiti sono tenuti a pieno ritmo.

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 sarà (di solito la tua concorrenza).

What are your thoughts to data migration, especially for the real life cases and not only from a developer's perspecticve?

il software deve essere aggiornato regolarmente. per assicurarti che la migrazione sia salvata, hai bisogno di backup e test.

Do you have any arguments against my managers opinions?

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

How does your company deal with data migrations and the difficulties caused by them?

abbiamo backup giornaliero, backup incrementale, backup prima di ogni implementazione in produzione. che ti consente almeno di eseguire il rollback se succede qualcosa di brutto.

abbiamo ambienti di test, test automatizzati e server di build giornaliero. anche una procedura di prova del fumo per assicurarsi che le operazioni e le funzioni principali 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 della migrazione dei dati, l'aggiornamento e il rollback. che rende la nostra vita più facile.

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

Any other interesting thoughts which belongs to this topics?

un'altra preoccupazione riguardante la migrazione dei dati è la coerenza dell'aggiornamento del codice e la migrazione dei dati. nel mio caso, ancora una volta, stiamo usando modi automatici per gestirlo. e sempre pronto per il rollback.

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

spero che aiuti.

Non sprechiamo il nostro tempo a cercare di migrare i dati da vecchi sistemi legacy perché il tempo, gli investimenti e il rischio sono troppo alti. Andiamo avanti con i nuovi sistemi e 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 dirigenti sperano di realizzare sarebbe stata estremamente elevata dato il costo della migrazione.