Storie dalla Sala Macchine


Home Page | Commenti | Articoli | Faq | Documenti | Ricerca | Archivio | Storie dalla Sala Macchine | Contribuire | Login/Register

Uno, Due e Indietro

DevOps e' la parola del momento, anche se non e' una parola ma la combinazione malfatta di due.

Se putacaso siete reduci da una vacanza lunga un paio d'anni, probabilmente non sapete neanche che cosa cappero sia questo 'devops'. In questo caso consideratevi fortunati. DevOps sta per "developer/operations" che dovrebbe essere la "nuova moda" di fare le cose nell'amministrazione sistemi e che e' il prodotto diretto del selvaggio movimento di virtualizzazione che si e' avuto negli ultimi anni.

Con un ambiente virtuale e' molto facile creare una pletora di servers per coprire eventuali deficienze nelle prestazioni. La vostra applicazione e' lenta come una lumaca morta? Invece di perdere del tempo prezioso cercando di capire cosa effettivamente non funziona, si buttano nel pentolone una dozzina di server virtuali per distribuire il carico e voila', il sistema adesso e' veloce. Vi costera' probabilmente un occhio (o meglio, costera' al cliente) e probabilmente si incatastera' molto rapidamente dato che tutto e' rimasto come era prima ma di piu', ma al meno potete dire che non e' piu' lento. A meno che non lo sia. Perche' il problema probabilmente non era nel numero di application server ma nel modo come funzionano.

In ogni caso, il "buttare dentro" una dozzina di server tutti in un colpo solo provoca non pochi problemi dalla parte dell'amministrazione di questi server, perche' qualcuno deve configurarli quei server, essere sicuro che quello che ci vuole sia installato e che siano attaccati alla rete giusta e con le apposite configurazioni di rete e cosi' via.

E quale modo migliore di configurare una manica di servers che dovrebbero essere tutti identici come gemelli siamesi (ad eccezione delle ovvie differenze di nomi ed IP ovviamente) che usando uno script? Esatto, avete capito benissimo: e' la stessa vecchia roba ma con un nuovo nome.

Ora, se avete un minimo di esperienza, dovreste aver capito al volo che scrivere uno script per configurare una manica di server in un colpo solo funziona in modo decente, fintanto che tutti i server sono uguali identici, ma se il numero di server da configurare e' piccolo... tipo.. UNO, l'intera faccenda perde completamente di significato. Ci vuole piu' tempo a scrivere lo script e provarlo che a configurare il server a mano. E questo e' il principale problema con DevOps: che funziona benissimo fintanto che si applica ad un ambiente "giusto" ma se l'ambiente non e' "ideale"... Non funziona manco un po'.

Se avete seguito le mie (dis)avventure fino a qui, dovreste aver capito che l'ambiente di $ShittyHostingProvided, essendo composto per lo piu' da una pletora di server unici come fiocchi di neve, ognuno con le sue idiosincrasie, ognuno speciale per il proprio cliente, non era molto orientato verso il DevOpsing. Certo, vi erano delle somiglianze (un server TomCat e' un server TomCat) ma neanche tanto dato che la maggioranza dei sistemi erano stati installati da gente diversa con richieste diverse per ogni singolo cliente, anche servers con gli stessi scopi erano stati installati con diverse modalita' "preferite" a seconda dei ruoli che dovevano ricoprire nel contesto del sistema del cliente. E non parliamo delle varie versioni della applicazioni e librerie che non potevano essere aggiornate per incompatibilita' con le diverse applicazioni.

Cercare di configurare servers usando scripts in quella situazione significava fare uno script per ogni singola macchina, trasformando una serie di operazioni per lo piu' manuali in operazioni sempre manuali ma che pretendevano di essere automatizzate.

Questo finche' qualche cosa non va male ovviamente.

Ed ecco a voi $NoiSiamoIlFuturo. Un altro cliente acquisito tramite l'acquisizione di un'altra societa' da parte di $Shitty durante l'anno precedente.

Questi erano "imparati", con questo intendo dire che erano sufficientemente intelligenti da capire che le cose vanno male piu' spesso di quanto vadano bene, quindi volevano un sistema "robusto". Ondepercui, optarono per 2 load-balancer, uno per datacenter, con un Round-robin DNS, e due application server dietro ad ogni load-balancer (totale di 4) e 2 database server (uno per datacenter). I db server con replicazione master/master tra di loro in maniera che, nel caso fortuito che un'intero blocco fosse inagibile, l'intero sistema avrebbe dovuto essere ancora raggiungibile e funzionante.

Ora, potremmo discutere dei problemi di un sistema siffatto per parecchio tempo... Il fatto di avere i due load-balancer in round-robin non significa che nel caso di fallimento di uno dei due l'altro entri automaticamente in sostituzione del primo, ed anche se lo facesse, i client remoti probabilmente continuerebbero a cercare di parlare con il precedente per parecchio tempo.
Ed in ogni caso CHE COSA PUO' FALLIRE? Non di certo l'hardware. Stiamo pur sempre parlando di server VIRTUALI che funzionano su un Cluster di hosts. Che l'hardware si possa rompere non e' piu' una possibilita'. A meno che non si consideri una bomba nucleare che distrugge un'intero datacenter ovviamente, ma questo e' un po' oltre le "normali" possibilita'.

Ah, e la ciliegina sulla torta? Gli application servers erano Windows. Con applicazioni sviluppate ad-hoc e funzionanti come servizi in windows ovviamente.

Nonostante parecchie discussioni questa... cosa venne implementata. Ma con una aggiunta: un server di "management" per fare rilasci in stile "dev-ops". Ed il server di management era, ovviamente, Linux.

Dopo un po' di tira-e-molla, qualcuno (non so con sicurezza a chi era stata mollata la patata, penso che abbia lasciato la ditta poco dopo che il progetto divenne operativo) incollo' insieme alla meno peggio una serie di scripts che usavano Puppet e Python per fare i rilasci nell'intera cosa. Questi richiedeavano comunque parecchio smaneggiamento manuale (disabilitare servizi in Windows perche' 'Net-stop' fallisce piu' si che no, cancellare i file manualmente perche' XDEL fa buca e cosi' via), fondamentalmente l'intero rilascio era sempre una operazione manuale, ma veniva venduto come 'semi-automatico'.

Il mio coinvolgimento nel progetto fu minimo, fino ad un piovoso giorno, quando pescai il bastoncino piu' corto e finii con il gestirmi il ticket che chiedeva un nuovo rilascio del "backoffice" lo stesso giorno. Il "rilascio" risulto' essere l'aggiornamento di una serie di servizi che, in teoria, non avrebbero dovuto influire sulle funzioni "pubbliche" del sito, pertanto poteva essere effettuato durante il normale funzionamento del sistema. Io acchiappai la documentazione e scoprii che i dettagli sul da farsi erano... a dir poco scarsi.

Dopo un giro di domande abbastanza infruttuoso, finii con il domandare al cliente stesso, il quale reagi' con un certo stupore al fatto che noi non si conoscessero i dettagli relativi alla manutenzione del sistema che loro ci pagavano per mantenere. Ah, le nuove tecnologie...

In ogni caso, dopo un certo tempo, riuscii a farmi un'idea di come le cose avrebbero dovuto funzionare, cosi' che, quando il momento venne, io cominciai con la sequenza di operazioni che... ando' quasi troppo bene per essere vero. E in effetti non era vero. Circa una mezz'ora dopo ricevetti la chiamata dal cliente che lamentava che la versione dell'applicazione rilasciata era tutt'ora quella vecchia.

Una rapida verifica mi disse che il "timestamp" era quello nuovo, ma la versione ritornata dall'applicazione era ancora quella vecchia. Un po' perplesso, ripetei tutti i passagi e verificai la versione ritornata che era a quel punto quella corretta. Ma quando chiamai il cliente per una verifica mi ri-confermo' che la versione non era cambiata e quando controllai nuovamente l'applicazione era tornata alla versione precedente (?!?)

A questo punto cominciai una indagine approfondita.

La procedura seguita pareva quella corretta. O per meglio dire: nessuno si ricordava niente e l'unico che avesse fatto un rilascio precedentemente (CL) non era disponibile al momento perche' "lavorava da casa", il che significa che non era in ufficio, il suo telefono era spento e non rispondeva alle mail o alla chat, io lo chiamo "giorno di ferie non riportato come tale". In ogni caso, dopo diverse ore perse a cercare di capire cosa diavolo non funzionava senza trovare niente di risolutivo, ho deciso di dichiarare chiusa la giornata ed informare il cliente che non era il giorno per un rilascio.

Ho gia' detto che nella loro visione di "alta disponibilita'" c'era posto per solo un sistema di produzione e niente altro, quindi nessun sistema su cui testare le cose prima?

Il giorno dopo, circa a meta' mattinata, CL entra trionfalmente in ufficio ed io lo placco immediatamente. Ovviamente lui prima vuole fare colazione, questo ritarda l'inizio della sua giornata fino circa a mezzogiorno, dopo di che e' praticamente ora di pranzo e tutto diventa lento e complicato fino circa alle 2 del pomeriggio, dopo di che io sono gia' pronto a passare direttamente alla mazza da baseball.

In ogni caso, sembra ricordarsi che c'era stato qualche problema con il rilascio, anche se non e' in grado di specificare quale dettaglio era mancante.

A questo punto il cliente aveva chiamato approssimativamente 25 volte per sapere quando noi si sarebbe fatta quella cosa che loro ci pagavano per fare (penso anche avessero incominciato a domandarsi che cavolo voleva dire il "managed" che stava scritto sul loro contratto e sulle fatture che ricevevano proprio accanto alla parola "hosting"), richiamato dallo Squillo del Destino, DumBoss si auto-invito' alla discussione.

Cominciammo quindi (io, CL e DumBoss) a controllare questo 'rilascio' e dopo diversi tentativi che finirono tutti nello stesso modo (cioe' con la 'nuova' versione dell'applicazione sostituita silenziosamente con la versione precedente), finalmente il cervello di CL comincio' a dare segni di attivita'.

CL - Oh, gia', adesso mi ricordo... e' davvero semplice.
IO - Ah si?
CL - Si...
IO - ...quindi ce lo dici o devo cominciare con la tenaglia e la morsa?
CL - Eh?
DB - (vedendo la mia pressione sanguigna aumentare) Quale e' il problema?
CL - Bhe'... bisogna spegnere questo o quel servizio e dopo il rilascio copiare l'applicazione anche in questa-e-quella directory, altrimenti la versione installata viene sovrascritta da quella nella directory.
IO - ...Domanda uno: che cazzo vuol dire? Domanda due: no, seriamente, COSA CAZZO VUOL DIRE? E domanda tre: Perche' la stracazzo di documentazione non riporta questo insignificante dettaglio?
CL - Penso che fosse un qualche tentativo di auto-rilascio che pero' non ha mai funzionato perche' i vari servizi senno' si bloccano.
IO - Ok, per la prima domanda che mi dici delle altre due? CL - Eh?
IO - Perche' questa merda non e' documentata? CL - ...Non lo so.
IO - Tu ti sei occupato di questa merda l'ultima volta, non hai pensato che fosse una buona idea scriverlo da qualche parte?
CL - Bhe...
IO - Bhe cosa?
CL - E' ora di farsi una tazza di tea.

E se ne ando' a prendersi una tazza di tea, lasciandomi li' a sperare che ci si strozzasse. No, non e' successo.

Davide
13/02/2017 16:15

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.

14 messaggi posta messaggio
Guido Di Guido - postato il 06/03/2017 09:24 - rispondi

DevOps, almeno a me, da l'idea di qualcuno che voleva pronunciare la parola "Development" e poi e' scivolato nel frattempo...

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


Paolo@ Guido Di Paolo - postato il 08/04/2017 11:26 - rispondi

Bhe, anche io ne sento parlare dagli sviluppatori e mi fa ridere, perchè fino a quando sono arrivato sviluppavano applicazioni / web app che non si preoccupavano di gestire eventuali intolleranze / failure delle risorse utilizzate e imputavano tutto sempre al sistemista che in effetti non aveva nulla per evitare dei failure ot simila, come se SysAdmin significa il secondo server in un sistema di bilanciamento. Menomale che la mia precedente exp da sviluppatore mi ha portato in un certo qual modo a costringerli a considerare alcuni aspetti ... però purtroppo la loro forma mentis è sempre la stessa: "funziona sul mio pc e va veloce, quindi se va lento o non funziona in produzione non è colpa mia" e mai a considerare che una cosa è sviluppare un'applicazione che gira su un pc e serve un solo utente, e un'altra rendere disponibile una web app che serve centinaia, se non migliaia, di utenti e che i sistemi hanno comportamenti strani quando messi sotto pressione, proprio come gli esseri umani.

Alla fine sembra quasi che dando un sistema come servizio da gestire tramite degli script risolva tutti i problemi, magari imparare come sviluppare applicazioni efficienti e scalabili no????

Però sembra che il mondo, causa anche tutti questi Cloud Provider, stia andando verso questa direzione.

Mhaaaaaa!?!?!?!

 

--
Paolo


Mattia Di Mattia - postato il 06/03/2017 13:47 - rispondi

Oh mioddio... E questo CL riesce ancora a deambulare con le proprie gambe? Sei troppo buono...

--
Mattia


trekfan1 Di trekfan1 - postato il 07/03/2017 10:22 - rispondi

Ci fossi stato io al tuo posto quel CL avrebbe subito  aggiornato la documentazione ovviamente a suon di frustate s $postodovenonbatteilsole, altro che tea!

--
trekfan1


Anonymous coward Di Anonymous coward - postato il 07/03/2017 10:30 - rispondi

Più che altro, DaBoss tiene elementi del genere?

--
Anonymous coward


Francesco Di Francesco - postato il 07/03/2017 13:09 - rispondi

Davide una curiosità ma come mai fate script "CMD" invece che powershell?

--
Francesco


Davide Bianchi@ Francesco Di Davide Bianchi - postato il 07/03/2017 16:51 - rispondi

Davide una curiosità ma come mai fate script "CMD" invece che powershell?

Dove vedi "cmd" ?

--
Davide Bianchi


Francesco Di Francesco - postato il 08/03/2017 07:35 - rispondi

Dai comandi che hai citato che sono quello di cmd non quelli che si usano in ps

--
Francesco


Boso Di Boso - postato il 08/03/2017 13:37 - rispondi

Penso che la cosa peggiore di queste situzioni sia la totale e spudorata mancanza di vergogna e di interesse da parte di tutti, che siano impiegati o dirigenti. Non va un tubazzo e sembra non importare a nessuno. Almeno una volta frignavano perche' qualcuno (di solito il SysAdmin) risolvesse il problema.

Davide, ma DumBoss non ha battuto ciglio? Questo può prendere e farsi un tea in mezzo a una discussione del genere?

--
Boso


Anonimo codardo (!!!) Di Anonimo codardo (!!!) - postato il 08/03/2017 15:24 - rispondi

Dopo un devOooops di questo genere non hai scuoiato vivo il CL? Non è da te!

--
Anonimo codardo (!!!)


Anonymous coward Di Anonymous coward - postato il 08/03/2017 16:45 - rispondi

ma DB non ha pensato di fare qualcosa a CL? Tipo levargli dallo stipendio una cifra sufficente a pagare una penale per il ritardo del rilascio?

Se la risposta è DB non sarebbe dumBoss se lo facesse, non serve dirlo :D

--
Anonymous coward


trekfan1 Di trekfan1 - postato il 10/03/2017 12:06 - rispondi

Ma allora perché non mettere direttamente l'applicazione nuova nella directory da dove poi viene "installata" nella giusta posizione? O non è possibile?

--
trekfan1


Davide Bianchi@ trekfan1 Di Davide Bianchi - postato il 13/03/2017 07:18 - rispondi

Ma allora perché non mettere direttamente l'applicazione nuova nella directory da dove poi viene "installata" nella giusta posizione? O non è possibile?

Non fare di queste domande... la risposta potrebbe spaventarti...

--
Davide Bianchi


Sciking Di Sciking - postato il 05/04/2017 12:35 - rispondi

Ma l'hosting non quello che sa che hai il sito web? Chiamarlo $shitty voluto per farglielo leggere?

--
Sciking


14 messaggi posta messaggio

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 Gort