Storie dalla Sala Macchine


Home Page | Commenti | Articoli | Faq | Documenti | Ricerca | Archivio | Storie dalla Sala Macchine | Contribuire | Imposta lingua:en it | Login/Register


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

Precedente Successivo

I commenti sono aggiunti quando e soprattutto se ho il tempo di guardarli e dopo aver eliminato le cagate, spam, tentativi di phishing et similia. Quindi non trattenete il respiro.

8 messaggi this document does not accept new posts

emi.ska

Di emi.ska postato il 23/07/2018 09:21

"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."

Ero sicuro che sarebbe successo!!! comunque quando il cliente si comporta cosi' se lo merita!

Buon lavoro a tutti coloro che non sono sotto un ombrellone ma davanti ad un PC!!

Emiliano

 

-- emi.ska

Berroll

Di Berroll postato il 23/07/2018 09:25

Ehi, per schiumare il mare ci vuole uno script di snellimento e anonimizzazione che lavori su un piccolo stagno di test!

-- Berroll

Anonymous coward

Di Anonymous coward postato il 24/07/2018 12:04

CL è il meno colpevole, a leggerla così... nelle condizioni imposte dal capo era l'unica cosa sensata da fare in velocità, la mancata copia probabilmente è dipesa dalla tarda ora, dalla stanchezza e dalla pressione ricevuta.

Leggendo la premessa pensavo parlassi del nostro caso: dischi di rete con roba vecchia di EONI, che nessuno vuole buttar via perché "non si sa mai", e direttore che non vuole spendere per il backup perché "prima buttate via quello che non serve". In mezzo, gente sfruttata, malpagata e che ha sempre la colpa di tutto, cioé noi...

-- Anonymous coward

Messer Franz

Di Messer Franz postato il 25/07/2018 05:42

Giorno dopo: hey, DB, c'è da schiumare il mare, $hurryup ce l'ha sul contratto, cioè, non c'era ma glielo abbiamo offerto noi di aggiungerlo, così NOI guadagnamo tanti bei soldi...tu con lo stipendio base meno un quarto devi solo fare tutto ciò che è necessario!

Tra l' altro, per coordinarsi in completa sinergia, abbiamo dato ad $hurryup il tuo numero di cellulare, il tuo numero del fisso di casa ( e se non hai un fisso no problem te l'abbiamo preso noi a spese tue ) e anche il tuo indirizzo e descrizione fisica...

CONTENTO?

Ah, quasi dimenticavo...deve essere finito per stasera...

-- Messer Franz

Anonymous coward

@ Messer Franz Di Anonymous coward postato il 26/07/2018 15:40

Giorno dopo: hey, DB, c'è da schiumare il mare, $hurryup ce l'ha sul contratto, cioè, non c'era ma glielo abbiamo offerto noi di aggiungerlo, così NOI guadagnamo tanti bei soldi...tu con lo stipendio base meno un quarto devi solo fare tutto ciò che è necessario!

Tra l' altro, per coordinarsi in completa sinergia, abbiamo dato ad $hurryup il tuo numero di cellulare, il tuo numero del fisso di casa ( e se non hai un fisso no problem te l'abbiamo preso noi a spese tue ) e anche il tuo indirizzo e descrizione fisica...

CONTENTO?

Ah, quasi dimenticavo...deve essere finito per stasera...

 

Lavori da me? Mi è familiare...

-- Anonymous coward

Guido

Di Guido postato il 30/07/2018 07:14

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

Il nostro hosting pampers quando vuole perdere tempo evita di rispondere al ticket salvo poi chiedere autorizzazione a procedere (nonostante sia esplicita nel ticket stesso) ad orari improbabili...

Oppure chiedere chiarimenti su cosa fare (tipo se l'operazione richiesta e' copiare il contenuto delle tabella A, B...Z da produzione a test loro ti fanno aspettare una giornata poi ti mandano una mail chiedendo "quali tabelle dobbiamo copiare"?)

-- who uses Debian learns Debian but who uses Slackware learns Linux

Luca Ballarati

Di Luca Ballarati postato il 05/08/2018 21:43

Questo $bianconiglio é più un cappellaio matto

-- Luca Ballarati

Massimo m.

Di Massimo m. postato il 03/01/2019 20:15

Penso che ridurre la mole di dati in test sia un'arma a doppio taglio.

Da una parte hai il db più scattante, e per test di aggiornamenti e librerie, dall'altra se ti serve vedere se gli aggiornamenti impattano sulle prestazioni, puoi avere risultati falsati.

 

-- Massimo m.

8 messaggi this document does not accept new posts

Precedente Successivo


Il presente sito e' frutto del sudore della mia fronte (e delle mie dita), se siete interessati a ripubblicare uno degli articoli, documenti o qualunque altra cosa presente in questo sito per cortesia datemene comunicazione (o all'autore dell'articolo se non sono io), cosi' il giorno che faccio delle aggiunte potro' avvisarvi e magari mandarvi il testo aggiornato.


Questo sito era composto con VIM, ora e' composto con VIM ed il famosissimo CMS FdT.

Questo sito non e' ottimizzato per la visione con nessun browser particolare, ne' richiede l'uso di font particolari o risoluzioni speciali. Siete liberi di vederlo come vi pare e piace, o come disse qualcuno: "Finalmente uno dei POCHI siti che ancora funzionano con IE5 dentro Windows 3.1".

Web Interoperability Pleadge Support This Project
Powered By Gojira