Migrazione dei sistemi core legacy senza interrompere l'attività

Le migrazioni core falliscono al momento del cut-over. Non nella progettazione, non nella realizzazione, non nel test: nel fine settimana quando si spegne il vecchio sistema, si accende quello nuovo, e lunedì si apre l'attività per scoprire quello che nessuno sapeva. Il modello è abbastanza comune da avere un nome, il big bang, e abbastanza comune che la maggior parte dei dirigenti che commissionano una sostituzione del nucleo centrale ne hanno vissuto uno.

La posizione qui è che il big bang è una scelta, e una scelta sbagliata. L'alternativa è ben compresa in ingegneria e raramente richiesta dalle persone che firmano il contratto. Uno strato di compatibilità si trova davanti al vecchio sistema. I consumatori vi si spostano uno alla volta. Il nuovo nucleo prende il sopravvento, dominio per dominio. I dati si spostano come un flusso, riconciliato quotidianamente, non come il carico di una singola notte. Ogni passaggio ha un rollback che è stato eseguito, cronometrato e posseduto. Il programma è più lento nel mostrare un risultato drammatico ed è molto più probabile che finisca.

Perché il Big Bang fallisce

Tre cose vanno male e vanno male insieme.

Il congelamento. Per posticipare una data, l'azienda deve interrompere la modifica del vecchio sistema con settimane o mesi di anticipo in modo che quello nuovo possa raggiungere un obiettivo prefissato. Il lancio dei prodotti attende. Le modifiche normative vengono apportate manualmente. L'arretrato cresce, la data slitta, il congelamento si estende e l'organizzazione impara a lavorare attorno al proprio nucleo. Nel momento in cui avviene il passaggio, il nuovo sistema sostituisce una versione di quello vecchio che non esiste più.

Il rollback imprevisto. Il piano di ripristino è un documento. Descrive come, se lunedì il nuovo sistema fallisce, quello vecchio verrà ripristinato. Non è mai stato eseguito, perché gestirlo significherebbe smontare il vecchio sistema in produzione. Quando arriva lunedì e il nuovo sistema sta fallendo in un modo che nessuno aveva previsto, il team scopre che il rollback richiede più tempo di quanto l'azienda possa aspettare, che i dati scritti dopo il cut-over non possono essere spostati indietro e che la decisione di eseguire il rollback non ha alcun proprietario. Quindi spingono avanti, dentro un sistema che non funziona, perché tornare indietro è peggio.

I consumatori sconosciuti. Ogni sistema centrale in funzione da un decennio non ha consumatori elencati. Un foglio di calcolo finanziario che legge direttamente una tabella. Un lavoro batch scritto da un appaltatore defunto. Un'integrazione del partner che esegue l'autenticazione con una credenziale condivisa. Un rapporto che l'autorità di regolamentazione riceve mensilmente. La mappa della dipendenza è stata costruita a partire dalla documentazione e dalle interviste, ma la documentazione era sbagliata e gli intervistati non lo sapevano. Il big bang scopre questi consumatori nel momento in cui si rompono.

Il piano di ripristino non è mai stato eseguito, perché eseguirlo significherebbe smantellare il vecchio sistema. Quando arriva lunedì, la squadra scopre cosa significa.

Il modello alternativo

Il modello ha una manciata di componenti e ognuno rimuove una delle modalità di errore sopra indicate.

Un livello di compatibilità, talvolta chiamato facciata, viene posizionato davanti al nucleo legacy. Parla dei contratti esistenti del sistema legacy, delle stesse interfacce, degli stessi formati di file, delle stesse forme dei messaggi, in modo che nessun consumatore debba cambiare per poter parlare con esso. Il primo giorno non fa altro che passare le chiamate. È la cucitura lungo la quale viene fatto tutto il resto.

Sostituzione in stile strangolatore. Dietro lo strato, il nuovo nucleo viene costruito un dominio alla volta. Quando un dominio è pronto, il livello instrada il traffico di quel dominio alla nuova implementazione e continua a instradare tutto il resto a quella vecchia. Il sistema legacy non è spento; è affamato, dominio per dominio, finché nulla dipende da esso. Poi va in pensione, in un giorno che non conta per nessuno.

Un consumatore alla volta. I consumatori vengono spostati sul livello di compatibilità individualmente, in un ordine scelto in base al rischio: prima i meno critici, quelli con il comportamento più noto, quelli i cui proprietari sono nell'edificio. Ogni mossa è abbastanza piccola da essere compresa e invertita. I consumatori sconosciuti emergono mentre quelli conosciuti si muovono, perché il traffico che ancora raggiunge direttamente il sistema legacy proviene, per definizione, da un consumatore non ancora sulla mappa. La mappa si completa in produzione, in tutta sicurezza.

Doppia corsa e riconciliazione. Per ogni dominio, il nuovo core funziona insieme al vecchio per un periodo concordato. Entrambi ricevono gli stessi input. I loro risultati vengono confrontati, record per record, ogni giorno. Il rapporto di riconciliazione è la prova che il nuovo sistema fa quello che faceva quello vecchio, compreso il comportamento che nessuno ha documentato. Laddove i due differiscono, si indaga sulla differenza, e spesso è il vecchio sistema a rivelarsi sbagliato.

Flag di funzionalità. Le decisioni di routing nel livello di compatibilità sono controllate dalla configurazione, non dalla distribuzione. Una bandiera sposta un consumatore o un dominio nel nuovo core; la stessa bandiera lo sposta indietro. Una versione e un cut-over sono separati: il codice viene distribuito continuamente e il comportamento cambia quando qualcuno decide che dovrebbe.

Migrazione dei dati come flusso. I dati non si spostano in una notte. Un feed di acquisizione dei dati di modifica o un meccanismo equivalente copia continuamente i record dal vecchio al nuovo, in modo che il nuovo nucleo sia sempre vicino a quello attuale. La sincronizzazione finale per qualsiasi dominio richiede minuti di delta, non ore di carico. Se viene eseguito il rollback del dominio, il flusso si inverte oppure il vecchio sistema non ha mai smesso di scrivere.

Rollback provato con trigger definiti

Il rollback è una procedura, non un piano. La differenza è che è stata eseguita una procedura.

Ogni passaggio di cut-over, sia che si tratti di spostare un consumatore, instradare un dominio o ritirare un componente, ha un rollback che è stato eseguito in un ambiente modellato come produzione, cronometrato e documentato con la durata effettiva. La persona che lo eseguirà in produzione lo ha eseguito durante le prove. Il passo non viene compiuto finché la prova non è passata.

I trigger vengono definiti prima del passaggio. Un trigger di rollback è una condizione misurabile concordata in anticipo: un tasso di errore superiore a una soglia per una durata stabilita, una differenza di riconciliazione superiore a un conteggio concordato, un fallimento di un determinato processo aziendale, un rapporto normativo che non può essere prodotto. Quando viene attivato un trigger, viene eseguito il rollback. Non c'è nessun incontro. L’incontro è avvenuto quando è stato concordato il trigger e includeva le persone che altrimenti avrebbero dovuto essere svegliate per decidere.

La decisione ha un proprietario nominato. Una persona ha l'autorità di tornare indietro ogni passo, è presente quando il passo viene compiuto e non è la persona che ha costruito l'oggetto da tagliare.

Osservabilità e riconciliazione come accettazione

Il criterio di accettazione per un consumatore o dominio migrato non è un incontro di approvazione. Si tratta di un rapporto di riconciliazione che mostra una differenza pari a zero tra il vecchio e il nuovo per il periodo concordato e una visione di osservabilità che mostra che il nuovo sistema si sta comportando entro i limiti previsti in condizioni di carico reale.

La riconciliazione confronta gli output al livello che conta per l'azienda: saldi, appuntamenti, politiche, fatture, qualunque sia il nucleo per cui è il sistema di registrazione. Funziona quotidianamente, viene rivisto da qualcuno che capisce il dominio e ogni differenza viene spiegata, accettata o corretta. La relazione viene conservata perché il revisore dei conti la richiederà.

L’osservabilità si progetta con gli operatori che la leggeranno. Registri strutturati, metriche e tracce rispondono alle domande che effettivamente si pongono quando qualcosa non va: cosa è cambiato, chi è interessato, da quando e se la situazione sta peggiorando. Gli avvisi si attivano in condizioni che richiedono un'azione e restano silenziosi altrimenti. Un avviso su cui nessuno agisce è rumore, e il rumore nasconde l’avviso che conta.

Insieme, questi sostituiscono la fiducia che un big bang chiede al consiglio di assumere fiducia. A un direttore può essere mostrata la riconciliazione e i cruscotti e decidere se il passaggio successivo è sicuro, sulla base delle prove piuttosto che delle garanzie.

L'organizzazione attorno alla migrazione

Il modello ingegneristico fallisce se l’organizzazione che lo circonda si comporta ancora come se fosse imminente un big bang.

Un tabellone per il cambio. Un gruppo permanente con rappresentanti della tecnologia, delle operazioni, delle unità aziendali interessate e della conformità si riunisce con cadenza fissa e approva ogni passaggio di cut-over in base alle prove: il registro delle prove, il rapporto di riconciliazione, le definizioni di trigger, il proprietario nominato del rollback. È piccolo e decide. Non è una riunione sullo status.

Finestre di congelamento negoziate, non imposte. Alcuni passaggi necessitano ancora di un periodo di calma: breve, per un ambito specifico, nel momento scelto dall'azienda. La business unit dà un nome alla finestra e la migrazione si inserisce in essa, piuttosto che la migrazione che dichiara un congelamento e l'azienda che lavora attorno ad esso. Viene rispettata una finestra negoziata. Quello imposto viene aggirato.

La formazione come passo, non come ripensamento. Le persone che gestiscono il core, allo sportello, in reparto, al trading desk, si commuovono insieme al consumatore che utilizzano. Vengono formati sul nuovo comportamento prima che i consumatori si spostino, con il vecchio sistema ancora disponibile e il runbook che utilizzano è stato testato da qualcuno che non partecipava al progetto.

Contesti regolamentati

In una rete ospedaliera o in una banca, la migrazione è un cambiamento regolamentato e lo schema sopra riportato rappresenta anche il modo in cui vengono soddisfatti gli obblighi.

Secondo l’HIPAA, una rete ospedaliera negli Stati Uniti gestisce informazioni sanitarie protette e la regola di sicurezza richiede garanzie amministrative, fisiche e tecniche, inclusi controlli di accesso, controlli di audit e controlli di integrità. Una migrazione tocca tutti e tre. La doppia esecuzione significa che le informazioni sanitarie protette esistono in due sistemi per un periodo ed entrambi devono soddisfare le garanzie. Il report di riconciliazione è un controllo di integrità. I log di accesso sul livello di compatibilità rappresentano un controllo di audit. Gli accordi di socio in affari con i fornitori coinvolti devono coprire esplicitamente il periodo di migrazione.

In Svizzera tra le aspettative della FINMA nei confronti degli assoggettati figurano requisiti in materia di outsourcing, resilienza operativa e gestione dei rischi legati alla tecnologia dell'informazione e della comunicazione. In termini generici, ci si aspetta che una banca vigilata mantenga il controllo sulle funzioni sostanziali esternalizzate, identifichi le sue funzioni critiche e le tolleranze per la loro interruzione e sia in grado di dimostrare all’autorità di vigilanza che una modifica significativa a un sistema centrale è stata governata, testata e reversibile. Una migrazione che sposta un consumatore alla volta con un rollback provato e una riconciliazione quotidiana produce quella prova come sottoprodotto. Un big bang produce una promessa.

In ogni contesto regolamentato gli audit trail non sono facoltativi. Ogni modifica di routing nel livello di compatibilità, ogni flag invertito, ogni risultato di riconciliazione e ogni rollback viene registrato con chi, quando e perché, e il registro viene conservato per il periodo richiesto dal regolatore. La pipeline che distribuisce il codice produce la propria traccia: cosa è stato modificato, chi lo ha rivisto, quali test hanno superato. La conformità diventa una proprietà del sistema piuttosto che un foglio di calcolo accanto ad esso.

Come contrattare per questo

Il contratto modella il comportamento. Un contratto con un'unica data di go-live e un pagamento ad esso allegato produce un big bang, qualunque sia la dichiarazione del metodo, perché il venditore viene pagato per la data.

Contratto da parte del consumatore migrato. Definire i consumatori e i domini nella mappa delle dipendenze, concordare un ordine e allegare un traguardo a ciascuno: il consumatore si trova sul livello di compatibilità, la riconciliazione ha mostrato una differenza pari a zero per il periodo concordato, il rollback è stato provato e gli operatori hanno eseguito il runbook. Il pagamento segue la pietra miliare. La data è una previsione, non un termine.

Scrivi la definizione di fatto nel contratto: test, osservabilità, documentazione e registro delle prove per ogni passaggio. Scrivi l'uscita nel contratto fin dall'inizio: sorgente nei vostri repository dalla prima settimana e un cancello che richiede al vostro team di rilasciare, ripristinare e risolvere un incidente senza il fornitore prima del pagamento finale.

I segnali che stanno comunque diventando un big bang

Un contratto ben redatto non ferma da solo la deriva. I programmi che iniziano in modo incrementale si muovono verso il big bang sotto pressione, e i segnali sono visibili con mesi di anticipo.

Il livello di compatibilità viene saltato per i consumatori "semplici" e il numero di consumatori spostati direttamente nel nuovo nucleo è in crescita. Il periodo di doppia esecuzione verrà abbreviato per adattarsi a una data. Le differenze di riconciliazione vengono accettate senza spiegazione perché indagarle richiede tempo. Le prove di rollback sono state interrotte e l'ultima registrata riguarda un passaggio tre passaggi fa. Il congelamento è stato annunciato anziché negoziato. Il change board è diventato uno status meeting che approva tutto. Una singola data è apparsa su un documento del consiglio con la parola go-live accanto. Qualcuno ha proposto di spostare insieme i restanti consumatori, per risparmiare tempo.

Ognuna di queste è una conversazione. Tre insieme sono un big bang con un nome diverso e il consiglio dovrebbe chiedere i registri delle prove prima del passaggio successivo.

Cosa fare lunedì

1. Richiedi la mappa delle dipendenze e chiedete come è stata costruita. Se proviene solo da documentazione e interviste, commissiona l'analisi del traffico per individuare i consumatori che non sono stati elencati.
2. Richiedi il registro delle prove di rollback per il passaggio di cut-over più recente. Se non ce n'è, interrompi il passaggio successivo finché non c'è.
3. Richiedi il report di riconciliazione per il dominio migrato più recentemente e il nome della persona che lo esamina quotidianamente.
4. Leggi il contratto. Se il pagamento è collegato a una data anziché ai consumatori migrati, rinegozialo prima che la data diventi il ​​piano.
5. Convocare il comitato di modifica con l'autorità di approvare o bloccare ogni passo contro le prove e rimuovere da esso chiunque non possa partecipare.
6. Scrivi i trigger di rollback per il passaggio successivo, con i numeri, e nomina la persona che detiene la decisione.