Murphy
Tutto quello che puo' andare male, lo fara'. Questa e' la Legge di Murphy, che non e' proprio una legge, ma il semplice risultato del fatto che le cose tendono a rompersi o a non funzionare in ordine di importanza decrescente. Quello che e' piu' importante, dato che e' la parte piu' stressata, finira' con il rompersi prima. E se quello che ci sta' sotto non e' piu'che robusto, si rompera' anche lui. Da li' in poi, le cose vanno di seguito come un ben progettato gioco del domino. Solo che il risultato finale non e', in genere, un successo spettacolare.
Tutta via, sono quegli spettacoli che non si puo' fare a meno di guardare, in parte per il fascino della catastrofe, ma soprattutto perche' la teoria e' che si impara di piu' da un disastro che da un successo. O almeno, si imparerebbe se non fosse che tutti sono troppo occupati a pararsi il culo e cercare di spiegare che loro sono li' solo per caso e non c'entrano niente.
Prendiamo per esempio $companyX, di cui parlai tempo addietro. Come gia' detto questa gente aveva un sistema tutto sommato semplice, ma basato su una marea di roba che era a) obsoleta, b) mai mantenuta o upgradata e c) completamente non documentata.
E nel loro "piano" di aggiornamento avevano accuratamente evitato di considerare cose come testing ed informare gli utenti.
Dopo un primo tentativo di "buttiamo tutto in produzione e vedrai che va bene", ed un immediato scontro con la Legge di cui sopra, avevano fatto un rapido dietro-front e deciso che forse era il caso di fare le cose con un pelo di calma.
Uno dei problemi che avevano incontrato era il famosissimo billing. Che, in termini semplici, significa farsi pagare.
Che vor di'? Se ricordate la base della faccenda che era stata spiegata precedentemente, questa gente gestiva un sistema di messaggistica B2B. Ora, girala come ti pare, ma si tratta di messaggi di mail che vengono inviati e ricevuti. Quindi che cosa vuoi che sia il "billing"? Quanti messaggi sono inviati, quanti sono ricevuti, quanti ce ne sono nelle varie caselle di posta, quante caselle di posta e poco altro. Alla fine tutti questi numeri vengono messi dentra un paio di semplici formule matematiche e vuoila', salta fuori la cifra che questa gente deve pagare.
Che sembra facile, ma ovviamente, quando ci metti di mezzo un UL... o dieci... In particolare il "sistema di billing" sembrava essere stato progettato da un Torquemada annoiato.
Per prima cosa, una batteria di scripts recuperavano i logs dei vari server di posta e li processavano, costruendo non uno ma 3 databases, poi un altro gruppo di scripts si occupava di calcolare il numero di messaggi presenti in ogni casella di posta e dividere in "gruppi" a seconda della dimensione (meno di 1kb, tra 1 e 2 Kb, tra 2 e 4...). No, non chiedetemi perche' che non lo so nemmeno io e non ha molto senso. Comunque sia, dopo tutto questo, alla fine del mese un'altra masnada di scripts procedeva a dissettare i vari databases producendo una marea di files .csv, i quali poi erano ri-processati e producevano una serie di 'reports' che avrebbero dovuto essere spediti ai clienti ed un mastodontico file .csv che avrebbe contenuto i totali ed avrebbe dovuto essere spedito a $companyX per produrre poi le reali fatture.
Perche' "avrebbero dovuto"? Perche' in realta' la procedure era assai piu' complicata. Si', perche', non contenti di tutto questo casino, $CompanyX, nella persona del "Manager Clientela", aveva deciso che la cosa migliore da fare era continuare a cambiare le carte in tavola, percui ogni mese (piu' o meno), arrivavano "modifiche" manuali da fare ai vari totali per cliente. Cose come "cliente X questo mese paga una tariffa fissa di X", quindi dal suo rapportino cancella tutto e mettici X invece che il totale calcolato e riporta i cambiamenti sul rapportone totale. Cliente Y invece riceve uno sconto extra del 97.3%, quindi c'e' da cambiare il rapportino ed il rapportone in funzione... TUTTI I FOTTUTI MESI QUALCHE COSA DI DIVERSO!
Chiaramente, come potete immaginarvi, questo significa fare cambiamenti MANUALI sui vari files prodotti, e dato che i cambiamenti sono sempre diversi, non ha alcun senso cercare di automatizzarli.
Ed indovinate un po' chi e' che deve farsi questi smandruppamenti? Yep. Indovinato. Perche'? Perche' cosi' c'e' scritto sul contratto di supporto. Ora, sorvoliamo che dato che si tratta di modifiche MANUALI, ci sono ampie possibilita' che si facciano degli errori nella procedura, e quindi che poi sia necessario rifare il tutto. Cosa che e' successa piu' di una volta e noi abbiamo fatto presente che "finche' si tratta di modifiche manuali c'e' sempre la possibilita' che si facciano degli errori".
Ondepercui, quando e' saltata fuori la faccenda della migrazione, io mi immaginavo che questa gente ne avrebe approfittato per rifare tutta la fottuta procedura di billing in maniera piu' umana, ed incorporare queste "modifiche" in qualche modo.
Si, nonostante non sia piu' giovane continuo ed essere un coglione.
CompanyX ha immediatamente comunicato che "non c'e' il budget per rifare la procedure di billing, quindi e' assolutamente imperativo che questa rimanga intatta e funzionante anche se l'infrastruttura cambia".
IO - ... cioe', fammi capire, questi vogliono cambiare TUTTA l'infrastruttura, soprattutto la parte che produce i DATI che la procedura di billing utilizza, ma la procedura di billing dovrebbe rimanere identica? E come pensano di ottenere tale effetto?
UL - La procedura di billing usa i dati del database, basta che noi riempiamo il database nello stesso modo e la procedura non dovrebbe nemmeno accorgersene.
IO - Si, bello. L'unico modo per riempire il database nello stesso modo e' cercare di capire che accidenti fanno quegli scripts che leggono i files di log e vedere dove possiamo trovare dati simili nei nuovi files di log, e che succede se non ci sono tutti i dati?
UL - No, noi non guardiamo gli script vecchi.
IO - ...say again...
UL - Gli script vecchi non si guardano. Non c'e' il budget.
IO - ...quindi?
UL - Quindi guardiamo solo il database.
IO - ...cioe' cerchiamo di capire che cazzo fanno gli script senza manco guardarli?
UL - Esatto!
IO - ...ed eventualmente come facciamo a sapere se la procedura funziona e produce i numeri giusti?
UL - Beh, se il database vecchio e quello nuovo sono uguali, i numeri dovrebbero essere giusti.
IO - L'unico modo per confrontare i due database e' avere gli stessi dati di input da entrambe le parti, cosa che e' un po' difficile da fare dato che uno solo dei due ambienti puo' essere in funzione.
Perche' o processi i messaggi nell'ambiente vecchio o li processi nell'ambiente nuovo, se cerchi di fare entrambi finirai con il duplicare i dati da qualche parte.
Comunque sia, una software house esterna fu' arruolata per produrre queste "procedure di lettura-dati". Dopo diversi mesi di smandruppamenti, questa gente aveva prodotto una serie di scripts che avrebbero dovuto leggersi i file di log del nuovo ambiene e riempire il vecchio database con le stesse informazioni che erano gestite dal vecchio. Ovviamente, dato che il nuovo ambiente non era in uso, il quantitativo di "test" che potevano essere effettuati era abbastanza basso.
Ora, ripeto, qui stiamo parlando di un sistema di messaggistica. Mail. Che sara' peculiare ma quanto stracazzo ci vuole per metterlo in piedi? Bhe, salta fuori che il tempo richiesto e' maggiore di un anno. O meglio, l'intero ambiente diventa "funzionale" nel giro di due mesi, ma rimangono un paio di problemi di fondo, uno di questi e' il fottuto billing. Perche' nessuno ha avuto modo di "provarlo". Ed il secondo e' collegato al primo. Pare che, chiunque abbia progettato questo infame "billing" ha deciso che Cron non basta. Cosi' hanno sviluppato la loro versione speciale di cron.
Io, ritrovandomi con un bel po' di niente da fare, mentre aspetto che qualcuno si svegli e decida cosa cazzo fare con il resto del progetto, decido di mettermi a guardare questo arnese. Decido rapidamente che il sistema piu' semplice di testare questa roba e' prendere i log del sistema vecchio e "tradurli" in un equivalente postfix, e far digerire questi pesudo-log alla procedura nuova. Secondo l'idea di UL, se l'input e' lo stesso, l'output (aka: il database) dovrebbe anche lui essere lo stesso. Dopo un po' di madonne spese per capire come sono organizzati i file di log di questo arnese, scrivo un paio di procedure perl per fare la traduzione e le sguinzaglio sui log di questo coso. Dopodiche, esegui le procedure scritte dai softwaristi. Che girano senza dare nessun messaggio di errore, me senza aggiungere un fico secco al database.
Ok, direi che questo si qualifica come "fallimento".
Riporto le scoperte ad UL che si dimostra abbastanza stizzito della cosa.
UL - Come non funzionano?
IO - Come ho detto: non danno nessun messaggio ma non fanno un tubo.
UL - E cosa dicono i programmatori?
IO - A me niente, sei tu che hai contatti con questa gente.
Si, perche' UL ha fatto in modo di essere l'unico contatto con i programmatori, quindi tutti passa da lui.
Dopo un po' ricevo un paio di mail in copia con alcune discussioni di come il software dovrebbe funzionare e del fatto che, in effetti, non funziona e basta. Le discussioni si trascinano per un paio di mesi, durante i quali vi sono diverse discussioni di come quei cosi dovrebbero funzionare e la mia linea e' "guardate i files di log originali e cosa viene inserito in risposta nel database originale, e cercate di capire cosa cazzo succede partendo da quello". E si', mi rendo anche conto che, magari, andare a guardare gli scripts originali potrebbe essere una cosa utile, ma UL e' sempre dell'opinione che non e' il caso di farlo.
Comunque sia, si arriva al punto in cui $softwarehouse decide che quello che ci vuole e' il fare una ANALISI della procedura, mentre, secondo loro, sono stati chiamati per SCRIVERE un software e l'analisi avrebbe dovuto essere fatta da noi. E se adesso vogliamo una analisi, dobbiamo pagarla a parte. Ora, dato che tutti i contatti con questa gente sono stati fatti da UL, io mi limito a guardare la faccenda con aria disinteressata. Soprattutto durante i vari 'meeting' dove si continua a ripetere che no, la procedura di billing continua a non funzionare.
UL - Ma hai parlato con i programmatori?
IO - Che ci parlo a fare con i programmatori? Per ripetergli che quello che hanno fatto non funziona? Lo sanno gia'.
UL - Ma loro dovevano fare l'analisi, sono stato chiarissimo al riguardo quando abbiamo cominciato hemmm... sei mesi fa...
IO - (tendendo la mano verso UL) Ottimo, vediamo l'accordo.
UL - Quale accordo ?
IO - Questa gente e' stata contrattata per fare un lavoro, ci dovrebbe essere un pezzo di carta dove si definisce che lavoro dovevano fare e come. E che deve essere firmato da entrambe le parti. Anche chiamato CONTRATTO. Se quel pezzo di carta dice che devono fare un'analisi e noi dobbiamo approvare l'analisi prima che loro comincino a scrivere il codice avrebbero dovuto presentare un'analisi, io non ho visto nessuna analisi. Quindi vediamo questo accordo (sempre tendendo la mano)
UL - Ma lo avevo detto...
IO - Lo avevi detto, lo avevi anche SCRITTO?
UL - Scritto?
IO - Si, su quel famoso pezzo di carta di cui ho appena parlato. Quello che dice chi deve fare cosa.
UL - Ma non saprei...
IO - Tu non hai scritto una sega vero?
UL - Ma io lo avevo detto...
IO - E loro dicono il contrario. Dato che sono due contro uno non mi pare che ci sia da discutere sul chi ha ragione ma sul chi puo' far valere la cosa dal punto legale. E cambiando discorso. Che e' successo a quel famoso "scheduler"?
UL - Scheduler?
IO - Si', quella specie di "cron-che-non-e-cron" che serve a far funzionare tutta la procedura, quello che noi non abbiamo per il nuovo ambiente.
UL - Ma abbiamo i sorgenti... da qualche parte...
IO - Si, lo hai gia' detto sei mesi fa. Lo hai anche ripetuto numerose volte. Dove sono?
UL - Non sono sicuro...
IO - Lo hai compilato? Intendo su qualche cosa che non fosse Solaris 8. Tipo negli ultimi 5 anni? E si compila? E che librerie ci vogliono per compilarlo? E quando si compila funziona? E funziona nel senso che fa quello che dovrebbe fare e non, per esempio, cancella settori a random dal disco?
UL - Hmmm...
IO - Perche' dato che abbiamo tempo adesso intanto che aspettiamo che qualcuno decida qualche cosa si potrebbe guardare queste cose invece di stare a girarci i pollici.
UL - Ha si, volevo fare dei test ma mi e' passato di mente...
IO - Per essere uno che ha sempre una penna in mano mi sembra che non trovi mai la maniera di scrivere niente eh?
Qualche cosa mi fa pensare che questo progetto continuera' per parecchio tempo.
Davide
28/07/2020 13:58
