Sei Anonimizzato?
Parliamo di dati. Tanti dati. Il tipo di massa di dati che si ottengono quando usi lo stesso sistema informatico per un po' di anni senza mai ripulire i tuoi dati da robaccia morta ed inutile. Che ne fai di tutta quella roba? Be', per la maggioranza un fico secco. La tieni li' ovviamente, ne fai dei backup di tanto in tanto e continui a tenerla li. Il problema e' che di tanto in tanto, devi provare delle cose. E se hai un ambiente di Test, dovresti avere la' dentro la stessa roba che hai in produzione, cioe' una bella, grassa copia di tutta quella roba.
Ma questo comporta due problemi: primo: hai tanti dati di cui non te ne fai niente e secondo: non dovresti tenere VERI dati di VERA gente in 'test' perche' un sacco di cose possono andare male.
Che fare?
Semplice: Invece di tenere tutti i dati in maniera permanente, ogni tanto si da' una bella 'rinfrescata', che significa fare una copia dei dati di produzione, copiarla in test e quindi eliminare tutti i dati piu' vecchi di un mese (per esempio) e sostituire tutti i nomi e gli indirizzi con robaccia a caso. In questo modo il database e' parecchio piu' magro e scattante ma i dati contenuti sono sempre coerenti e non ci sono tutti quei "dati personali" che possono causare problemi.
Adesso, fate caso che ho indicato la cosa come 'semplice', non 'facile', perche' l'intero processo per passare da un database completo e pieno di dati ad un database magro-e-scattante e' tutto ma non facile. Prima di tutto, ci vuole una copia dell'intero database. Il che significa un sacco di dati ed ogni volta che occorre eseguire la procedura, sono PIU' DATI della volta precedente. Dopodiche', bisogna inventarsi un sistema per cancellare la roba vecchia senza perdere la coerenza dei dati.
Il che non e' facile e richiede un puttanaio di tempo per farlo giusto.
E adesso, dite "ciao" ad $hurryupitslate, una compagnia che... non lo so cosa cazzo fanno, so solo che sono... sempre in ritardo per qualche cosa apparentemente.
La loro normale procedura operativa, consiste nel telefonare e richiedere qualche cosa, qualunque cosa, e quando il tizio al telefono richiede l'apertura di un normale "ticket", la loro risposta consiste nell'urlare a qualcun altro nella stanza di aprire un ticket mentre continuano a parlare inperterriti e contiunare a domandare se il ticket e' arrivato e quando e' arrivato cominciano a domandare perche' non e' stato eseguito.
Non e' tanto strano che quando il telefono suona ed il loro numero appare sul display, improvvisamente nessuno vuole rispondere e tutti sono incredibilimente occupati.
In ogni caso, tempo addietro questi richiesero (a modo loro) di fare una copia del loro database di produzione e trasferirla sul database di Test. Sfortunatamente per loro, quel giorno beccarono ME. Ed il che significa che io li informai puntualmente che a) nessun database poteva essere copiato sull'ambiente di test perche' non esisteva un ambiente di test ed io non ne creavo di certo uno senza un contratto firmato, per il quale li gettai in pasto ai lupi, cioe' Marketing Man.
Quando furono risputati fuori, li informai anche che la dimensione speficata per il database server era parecchio sullo scarso se confrontata con la dimensione del loro database di produzione e che la procedura di 'copia e snellimento' non era faccenda nostra perche' noi non sapevamo nulla del loro database di produzione e di andare a discuterne con i loro programmatori.
Parecchie discussioni dopo, i suddetti sviluppatori inviarono uno script che avrebbe dovuto eseguire l'intera procedura di 'cancella-ed-anonimizza', era solo questione di provarlo.
E adesso, facciamo la conoscenza della stella del giorno: CL! Che era in "stand-by" nel fatidico giorno in cui $hurryup decise di chiamare il numero di emergenza alle 9 di sera per dare inizio all'intera procedura.
Dire che CL non era esattamente contento di essere chiamato alle 9 di sera e' dire poco, lui contava di passare una serata tranquilla senza dover fare un accidente di niente, ma come avrete capito dall'introduzione, $hurryup non era del tipo che accetta 'no' come risposta. E prima che qualcuno cominci a parlare, NO, quella non era una attivita' che avrebbe dovuto essere svolta dalla persona in stand-by, non senza averla decisa ed organizzata prima, ma e' il modo come $hurryup era solita operare: chiama il 'numero di emergenza' ed ignora il fatto che non sia una emergenza.
In ogni caso, una mezz'ora dopo l'inizio di tutta la faccenda, CL scopri' una discrepanza fondamentale tra l'ambiente di Test e quello di Produzione: la dimensione del disco. In particolare, il disco del database server. Tuttavia, $hurryup semplicemente ignoro' la cosa sostenendo che "lo script avrebbe ridotto le dimensioni del database a sufficienza". E CL semplicemente ando' avanti con l'intera faccenda come istruito.
Il problema era che l'intero processo richiedeva che TUTTO il database venisse importato prima di procedere alla riduzione dei dati, e quando CL tento' l'import, questo falli' perche' il disco era troppo piccolo per contenere l'intero database di produzione. Il risultato fu che il processo si interruppe e lascio' il sistema di test praticamente vuoto.
Ed a questo punto cominciano i casini.
L'unica procedura corretta a questo punto sarebbe stata di lasciare tutto come era ed il giorno dopo tirare dentro DB e MarketingMan e richiedere una diversa procedura o un incremento nella dimensione del disco del sistema, ma ovviamente $hurryup non era contento della cosa e quindi continuarono a rompere per una soluzione differente. Una soluzione che ovviamente non esisteva. E questo confuse CL. E quando CL diventa confuso, prende decisioni idiote. Quello che probabilmente passo' nella sua testa era qualcosa di simile a "hey, perche' non fare una copia del db in produzione e far girare lo script sulla copia? Dovrebbe esserci abbastanza spazio per fare un dump della copia ridotta e copiare quello in test".
Che e' un'idea, non posso fare a meno di ammetterlo, ma... Richiede di fare cose potenzialmente distruttive su un sistema di PRODUZIONE, e con un cliente che e' gia' una rottura di coglioni normalmente che rompe ancora di piu' al telefono ed ad una ora abbastanza tarda. Potete immaginarvi gia' che cosa successe ovviamente.
Success che CL creo' un nuovo database in produzione e poi esegui' lo script ma senza fare la copia dei dati. Il risultato fu un database di produzione perfettamente anonimizzato e molto ridotto. Ed un bel test dell'intera procedure di restore del database di produzione e tutti i dati del giorno persi ovviamente.
Che cosa abbiamo imparato quel giorno? Prima cosa: non dare il numero di emergenza a clienti, seconda cosa: il numero di emergenza e' solo per EMERGENZE, che significa "qualche cosa non funziona in produzione", qualunque altra cosa NON E' UNA EMERGENZA! Terza cosa: $hurryup puo' andare a schiumare il mare.
Davide
31/05/2018 16:30
