Storie dalla Sala Macchine


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

Stati di alterazione (di sistema)

Tanto tempo fa, quasi 20 anni fa per la precisione. C'erano i SysAdmin, che gestivano i server. Che erano dei cosi grossi, rumorosi e che davano piu' problemi di quanti ne risolvevano. I server intendo, non i SysAdmin. Poi qualcuno penso' che si poteva fare i soldi "affittando" i sysadmin insieme alle macchine. E la professione di "managed hosting" fu inventata. Poi ci fu la rivoluzione del "cloud" e tutti cominciarono ad affittare hardware inesistente.

on the left: the sysadmin, on the right: the appadmin

In tutto questo casino, i vari "sysadmin" si ritrovarono in diverse situazioni. Ci sono diversi "stati" in cui un sistema puo' essere a seconda del tipo di "gestione" che si decide di usare.

1. Io Sono Il SysAdmin (e non mi rompete i coglioni)

La societa' paga l'hosting di una o piu' macchine (virtuali o fisiche) e basta, l'installazione, monitoring, gestione, risoluzione dei problemi, manutenzione ecceterazione sono fatte da uno o piu' sysadmin che conosco l'intero ambiente dentro e fuori. La societa' di hosting si preoccupa solo di fare arrivare corrente e rete alle macchine.

Questa era la condizione "standard" una decina o giu' di li' di anni fa. In genere i problemi erano che il/i sysadmin dovevano essere molto competenti e saper fare il loro lavoro oltre che essere in grado di prevedere i possibili sviluppi dell'azienda nell'arco di diversi anni per evitare di ritrovarsi con un sistema composto da pezze raffazzonate alla bell'e'meglio. Cosa che era la normalita'. Lo svantaggio essenziale era che il/i sysadmin diventavano praticamente quello che teneva il tutto in funzione e se venivano a mancare erano dolori.

2. Io Sono Il SysAdmin ma voi gestite il SO

La societa' paga per l'hosting e la manutenzione a livello OS di una o piu' macchine (virtuali o fisiche), tutto quello che e' software applicativo viene installato, gestito e mantenuto da uno o piu' sysadmin che conoscono l'applicazione ed hanno diritti di Root sul sistema per installare patch e configurazioni. La societa' di hosting si occupa di installare aggiornamenti a livello di OS ad intervalli regolari e fare manutenzione all'hardware ed ai dispositivi di rete.

Questa e' una situazione alternativa alla precedente. Il problema maggiore e' quando la societa' di hosting decide di rilasciare degli aggiornamenti sul sistema senza avvertire o senza una pianificazione decente.

3. Io Sono l'AppAdmin

Lo societa' paga per l'hosting e la manutenzione a livello OS di una o piu' macchine (virtuali o fisiche), la societa' che provvede l'hosting rimane l'unica ad avere i diritti di root sulle macchine. Le applicazioni sono in genere installate dalla societa' di hosting ma uno o piu' "appadmin" hanno la possibilita' di riavviarle e/o aggiornarle usando appositi strumenti.

Questa e' una situazione abbastanza normale (purtroppo) quando la societa' che paga per l'hosting non vuole spendere troppo. Il risultato in genere e' che si creano dei problemi quando una delle applicazioni richiede interventi che sono al di fuori delle capacita' dei syadmin della societa' di hosting ma che non possono essere effettuate dagli "appadmin" per mancanza di diritti. Aspettatevi complicazioni ed un numero molto elevato di problemi.

4. LORO sono i sysadmin

Questa e' la situazione peggiore in assoluto. Si verifica quando la societa' non vuole spendere per una soluzione migliore e decide di appoggiarsi ad una societa' che non fornisce solo l'hosting ma anche la gestione dell'intera applicazione. Chiamatela "fully managed" o come diavolo volete. Il problema e' che tutte le attivita' sui servers sono delegate alla societa' di hosting, questi ultimi devono avere tutte le competenze necessarie per eseguirle. In sostanza e' una situazione come la prima descritta, solo che i sysadmin lavorano per qualcun altro ed hanno un tempo ristretto che possono dedicare ad un singolo "cliente".

Il risultato e' che il "cliente" non potra' mai avere il livello di servizio che si aspetterebbe, i sysadmin si ritrovano a dover gestire un numero elevato di sistemi tutti diversi e che richiedono diverse competenze e chi sviluppa l'applicazione non ha idea di chi fa cosa e come.

Negli ultimi anni si e' visto un aumento della situazione (4), chiamatela "Platform as a service" se volete, ma il problema rimane.

Certo, vi potete trovare nella situazione "perfetta", dove il sysadmin della societa' di hosting sa tutto ed e' capace di organizzarsi ed il "sysadmin" del cliente e' capace di comunicare in maniera efficiente. Allora i due si fondono in un super-sysadmin (come nei cartoni animati giapponesi) e qualunque problema viene disintegrato con un Kamehameha attack...

Ma e' molto piu' probabile che uno dei due sia un interdetto (raramente entrambi) o che la comunicazione tra i due sia meno che ottimale, ed il risultato e' che qualunque problema viene trascinato per giorni, se non per settimane.

E adesso, bando ai preamboli e sotto con la storia.

$ShittyHostingProvider forniva servizi del 4o tipo, avevamo un paio di clienti che erano del primo tipo, ma con il passare degli anni ed il presentarsi di servizi molto piu' convenienti (AWS, Azure) erano migrati altrove. Il parco clienti era percio' composto per lo piu' da societa' che non avevano nessuna capacita' amministrativa o in cui le capacita' erano molto ridotte. Stiamo parlando di "supporto utenti" a cui era delegato l'incarico di interfacciarsi con noi.

Ora, avendo una base di sviluppo software ed altre cose, io ero in grado di prendere in mano una applicazione e cercare di capire cosa faceva e come, e quindi, in caso di problemi, applicare alcuni principi di "debugging" che in molti casi erano necessari ad identificare e risolvere i guai. Ma non tutti i sysadmin sono nati programmatori e non tutti hanno il tempo e/o la voglia di applicarsi ad un debugging per capire perche' una applicazione improvvisamente smette di funzionare.

In molti casi e' perche un sistema che e' progettato per funzionare sotto diretto controllo e supervisione (aka: babysitting) di uno o piu' sysadmin, funziona molto male quando tale supervisione viene a mancare. Ed il che puo' essere addotto ad una scadente progettazione, realizzazione o semplicemente perche' il sistema e' molto "fragile" e reagisce male a qualunque cambiamento imprevisto. E nessun cambiamento e' previsto. Mai.

Parliamo del sistema di $fankazzari, i quali avevano cominciato con "un serveruccio" e dopo un paio di anni di attivita' erano arrivati a quota 18 servers, di cui due load-balancer, 8 application servers, due database servers (uno dei quali MS SQL Server), un LAMP per gestire dei "forum" ed una serie di macchine di "supporto" che facevano funzionare applicazioni tomcats il cui scopo era poco chiaro ed ancora meno documentato.

Questo ambiente era noto per essere estremamente schizzinoso e suscettibile a qualunque cosa. Piove? Il sistema comincia a sparare fuori errori senza senso. Un piccione passa davanti alla finestra? Uno degli application server si schianta da brutto. Un piccione caga passando fuori dalla finestra? Il load balancer comincia a sclerare. E cosi' via.

Strano a dirsi, ma l'unica macchina che non dava mai rogne era SQL Server.

Ed arriviamo ad un bel sabato mattina. Sabato in cui io ero di "stand-by". E mi stavo rilassando cazzeggiando amabilmente sul divano, quando il foxxuto pager comincia a suonare con un bel (si fa per dire) errore sul sistema di $fankazzari.

Mi collego via vpn e comincio a cercare di capire che cosa cazzo c'e' che non va. Allora, tutti gli application server sono lenti come la fame ed alcune pagine del loro sito apparentemente ritornano errore. Solo ALCUNE pagine pero'. Un rapido controllo mi dice che i due database servers non stanno facendo nulla di particolare e quindi sembrano innocenti.

I log degli application server sono pieni zeppi di errori ed exception, ma sono SEMPRE pieni di quella roba al punto che diventa inutile avere un log.

Dopo una buona mezz'ora passata a cercare di capire cosa fa cosa in questo casino, DB mi compare in chat e domanda WTF. Apparentemente qualcuno di $fankazzari si e' accorto della situazione ed ha cominciato ad imbizzarrirsi. Io riferisco i problemi riscontrati. DB mi domanda subito se ho riavviato i servers, si', ma non fa nessuna differenza. A questo punto DB ha deciso che il suo dovere era continuare a rompere i marroni con suggerimenti e/o commenti che non solo non erano di nessun aiuto ma mi distraevano dal cercare di capire cosa cappero stava succedendo su quel coso.

La faccenda e' andata avanti per un po', finche' non gli ho detto chiaro e tondo di starsene zitto e non rompere.

Nel frattempo io ero anche in contatto con uno dei programmatori di quella chiavica, il quale pero' si era rivelato non molto ferrato nella parte sistemistica della cosa. In particolare, questo tizio sapeva di parte dell'applicazione ma non aveva la piu' pallida idea di tutto quello che vi era attorno. Insomma, pare che anche lo sviluppo dell'applicazione fosse stato "compartimentelizzato" e distribuito tra vari gruppi, nessuno dei quali aveva il minimo interesse ad avere una immagine completa della cosa. Il che probabilmente spiega il perche' l'intero arnese era tanto instabile.

Il tizio insisteva che dato che noi eravamo quelli che gestivano il sistema, dovevamo anche essere in grado di gestire l'applicazione. Tutto regolare, il problema era che noi non avevamo nessuna documentazione o informazione sull'applicazione. E dato che la struttura della stessa era in uno stato di evoluzione permanente era anche difficile farsi un'idea di come tale cosa funzionava.

Comunque sia, dopo svariate ORE perse a ravanare nei meandri di quell'accrocchio, ho cominciato a vedere un certo "trend". Ogni 2 errori dell'applicazione, veniva riportata una "failed connection" verso uno di quei server "strani" che non si capiva esattamente che facessero. Il programmatroto non era d'aiuto in questo perche' non si occupava della cosa e quindi non sapeva che dire.

A questo punto, non avendo molto da perdere, io decido di riavviare quella particolare applicazione... ed improvvisamente tutto l'arnese comincia a riassestarsi. Nel giro di 10 minuti le cose ritornano "normali".

Dopo aver documentato la cosa al meglio possibile, ho deciso di richiedere ufficialmente della documentazione riguardo le relazioni tra le varie applicazioni del sistema e di richiedere delle funzioni di monitoring all'interno di ciascuna applicazione. In modo che quando qualche cosa non funziona che fornisca almeno un messaggio di errore che abbia un senso.

Oh, e SQL Server? Scoprimmo poi che quella macchina non era mai usata.

Davide
06/10/2017 13:59

Precedente

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.

5 messaggi posta messaggio
Il solito anonimo codardo Di Il solito anonimo codardo - postato il 09/10/2017 09:44 - rispondi

Ah, ecco perché l'SQL Server non si incriccava mai: non sapevano nemmeno di averlo!

crying e ancora crying per come il mondo del web si sta autodistruggendo un pezzo alla volta...

--
Il solito anonimo codardo


Jepessen Di Jepessen - postato il 09/10/2017 10:04 - rispondi

Che un programmatore non conosca tutto l'accrocchio ci sta, se non è l'unico. Quelli che stanno sopra di lui gli dicono quali parti fare, lui le fa, le testa ed è contento. Al telefono doveva esserci un project manager, che dovrebbe avere le conoscenze di tutto l'insieme, localizzare il problema e, se non era in grado di risolverlo, rompere i maroni al programmatore che aveva fatto quella parte. Così non è stato perché il project manager probabilmente manco sapeva di esserlo e quindi hanno scaricato il problema al poveretto di turno...

--
Jepessen


stecolna Di stecolna - postato il 09/10/2017 13:22 - rispondi

e smettiamola con questa storia che SQL Server si incricca ogni due per tre!

Sinceramente avete tutti rotto il c...o!

--
stecolna


Guido Di Guido - postato il 09/10/2017 13:23 - rispondi

La societa' per la quale lavoro ha un hosting del IV tipo - pero' siamo noi che dobbiamo dirgli qual'e' il problema e come si risolve (es. quando spostarono l'application server da un server ad un altro senza modificare l'ip binding del db server il quale - a ragione - rifiutava le connessioni dal nuovo)

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


Manuel Di Manuel - postato il 09/10/2017 18:19 - rispondi

Il 4o tipo sta diventando un pò la norma, ma per ora non vedo solo lati negativi.

C'è da dire che sto vedendo qualcosa su Google Cloud Platform, e non mi sembra malvagio, affatto.

Però c'è anche da dire che per ora non ho gestito (personalmente) grossi progetti su GCP, quindi boh...non mi pronuncio.

Mi sembra evidente che i SysAdmin "vecchia scuola" debbano spostarsi verso il cloud, anche perchè, data la complessità delle cose, l'esperienza serve... 

--
::: meksONE :::


Precedente


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