Storie dalla Sala Macchine


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

Pronto o No...

L'essere "pronti" e' parte integrante di molte attivita'. Pronti per cosa? State sicuramente chiedendo, bhe', dipende da quello che state facendo… e da quello che dovreste fare. Siete pronti per la vostra giornata lavorativa? Forse... Siete pronti per una maratona di 40 Km? Io... no. Ma, spero, nessuno mi chiedera' di correre una maratona senza preavviso. Ovviamente, se sapete che dovete fare o fornire qualche cosa in anticipo, le cose sono molto semplificate. Avendone il tempo, praticamente chiunque dovrebbe essere capace di "essere pronto" a qualunque cosa. A meno che non siate un imbecille o delegate a qualcuno che capiti essere un imbecille. Purtroppo, a volte non avete nessuna scelta. Dovete fare qualche cosa e quella cose coinvolge un imbecille. E dopo questa introduzione, andiamo ad incominciare con la Storia del giorno.

Noi abbiamo un cliente le cui richieste di risorse avevano rapidamente sorpassato quello che il disco e la ram del suo sistema potevano fornire. Si trattava di un sistema fisico, non virtuale, quindi quando un disco diventava troppo pieno o la ram si trovava al 100% per un po' troppo tempo, l'unica cosa da fare era acquistare altra ram/dischi, andare al datacenter, spegnere tutto, aprire il case ed aggiungere il disco o la ram e quindi riaccendere tutto sperando che continui a funzionare. Questo ipotizzando che noi si potesse aggiungere il disco o la ram al sistema e non trovarsi con tutti gli slot utilizzati. Per non parlare di qualche strana incompatibilita' con gli altri pezzi gia' presenti. Oppure potevamo lasciare tutto com'era e cercare di spostare/cancellare/riarrangiare roba in modo da strizzare piu' spazio/performance dall'hardware esistente. Ma prima o poi, si finisce con l'esaurire tutte le opzioni, e' solo questione di tempo.

Quindi, un giorno di fine estate, dopo aver visto il messaggio "Partizione X 98% in uso" per un po' troppo tempo nel nostro monitor di sistema, abbiamo deciso che era il momento di chiappare il Cliente e trascinarlo nell'era virtuale. E' ora di pensionare il vecchio server e scatenare il nostro MarketingMan sulla preda con una succosa offerta per un server virtuale.

Dopo diversi giorni (o settimane) di negoziati, soprattutto perche' il cliente era "cauto" (leggi: non voleva pagare piu' di quanto gia' pagava per il server fisico che era di sua proprieta') ed era piu' preoccupato di come pensavamo di "muovere" da un sistema all'altro piuttosto del sistema stesso. Ovviamente il nostro "MarketingMan" non aveva la piu' pallida idea di come risolvere quel particolare problema ed aveva tagliato corto il discorso dicendo "lo faremo con ZERO downtime"... Ora, io apprezzerei moltissimo se prima di uscirsene con certe stronzate colossali, si prendesse 30 secondi per domandare a qualcuno con un minimo di competenza.

In ogni caso, e' riuscito ad estorcere una firma e quindi abbiamo un ordine per una VPS nuova di zecca per il Cliente, inclusa migrazione dal vecchio sistema. Ed ovviamente abbiamo saputo del fatto durante uno dei "meeting" settimanali direttamente da DaBoss nel seguente modo (all'incirca):

DB - ...e $Cliente ha bisogno di un server nuovo cosi' non dovremmo piu' avere problemi con lo spazio su disco e la ram, chi fa l'installazione? (si guarda intorno aspettando volontari)
IO – Installazione di cosa? Dove e' il foglio con i dati?
MarketingMan – Devo metterlo nel wiki...
IO – Ottimo, quando e' nel wiki lo installeremo.
DB - CI pensi tu quindi?
IO - No, quando e' nel sistema chi e' di turno per "installazioni e decomissioni" lo installera', che non sono io per default, questo e' il motivo per cui hai messi "installazioni" nel piano settimanale no?
DB - Si ma e' abbastanza urgente...
IO - Se e' urgente perche' il foglio di installazioni non e' nel sistema? Abbiamo avuto quel rottame lampeggiante nel monitor per settimane...
Marketing Man - Il cliente mi ha dato l'ok solo questa mattina.
IO - In tal caso non verra' installato per questa settimana, garantito.

La "discussione" ando' avanti ancora per un po' senza nessuna decisione sostanziale. Durante la settimana tutti sono stati occupati con altre cose (io almeno lo sono stato) ed apparentemente nessuno ha fatto niente fino alla settimana successiva, quando $Collega (CL) si ritrovo' con il bastoncino piu' corto in mano e gli fu assegnato il piacevole compito di installare il nuovo server per $Cliente. Io ero occupato con altra roba e, francamente, non avevo alcun interesse nell'essere coinvolto con la cosa quindi non ho manco guardato la ‘pagina di installazione' di quell'affare e quindi non ho idea se CL abbia ricevuto istruzioni o informazioni particolari.

Un altro paio di settimane passarono, poi una bella mattina, io risposi al telefono che stava squillando come un indemoniato (secondo errore della giornata, il primo fu di alzarmi dal letto quella mattina).

IO - ShittyHostingProvider, desidera?
Client - Salve, sono Cliente. Vorrei sapere quando avete pianificato di andare in produzione con il nuovo server, dato che lo stiamo pagando gia' da un mese senza farci niente. L'ultima volta che abbiamo parlato con il vostro MarketingDude si era parlato di una "messa in produzione rapida".
IO - Oh... hemmm... Devo vedere quale e' lo stato di quella cosa... vi faccio sapere...

Ovviamente MarketingDude non era in ufficio quel giorno, il che mi ha lasciato a cercare di capire che cosa era stato fatto, da chi, quando e come (non il perche' che lo sapevo gia'). Da quello che ho capito il server era stato installato da CL ma non sono riuscito a trovare niente relativo ad un "andare in produzione". Quindi ho chiappato CL ed ho fatto direttamente la domanda.

IO - Come hai pianificato di andare in produzione?
CL - IO ?
IO - Si, tu. Tu hai installato questo mucchio di rottami no? Quindi dovresti esserti anche fatto un'idea di cosa bisogna fare per spostarsi dal vecchio mucchio al nuovo. Quindi?
CL - Ma... hemmm... e' roba di base...
IO - Di base intendi?
CL - Di base...

Per un attimo mi sono chiesto se prendere CL ripetutamente a cazzotti in faccia avrebbe potuto migliorare le sue funzioni cognitive, ma poi ho pensato che probabilmente mi sarei fatto piu' male io di lui.

IO - Quindi cosa bisogna fare per mettere in produzione questa roba?
CL - Hu..... dovrebbe essere facile..
IO - "dovrebbe" ?

Pare che l'unico modo di procedere sia il modo "duro", quindi mi prendo la "pagina di installazione" e comincio a controllare le cose. Standard MySQL e TomCat. Primo problema: sul server non e' installato Java, e TomCat senza Java non funziona molto bene. Scaricati Java ed installalo. TomCat e' stato "installato" (cioe' copiato) sul sistema ma non e' mai stato ne' configurato ne' avviato ovviamente, quindi acchiappa la configurazione di default quindi la configurazione del vecchio server e confrontale per vedere che differenze ci sono. E qui casca l'asina: sembra che noi non si abbia la password di root del sistema vecchio ed il mio account non puo' fare sudo. E' ora di tirare in mezzo DaBoss.

DB - Cosa significa che non abbiamo la password di root?
IO - Che non e' nella lista di password standard.
DB - Dovrebbe essere li'.
IO - Si, ma non c'e'.
DB - Non puoi domandare al cliente?
IO - Sicuro che posso. Devo anche fargli presente che abbiamo perso la password in un momento non precisato del passato e quindi non abbiamo mai potuto fare le attivita' per le quali ci pagavano? Tipo, fare manutenzione al server?
DB - Dovremmo poter fare sudo...
IO - Di nuovo quel 'dovremmo'...

Contattiamo il Cliente quindi con una richiesta per la password che pero' non ci frutta niente di nuovo (Password? Quale password?) quindi io acchiappo MarketingDude e lo tracino nella discussione perche' se vogliamo andare avanti con questa cosa dobbiamo recuperare quella password e questo comporta un reboot in single-user-mode con un rescue disk, il che significa un viaggetto al datacenter. E dato che il cliente vuole "zero downtime" il che significa farlo durante i normali "upgrade" (che non possiamo fare in ogni caso non avendo l'accesso di root al sistema e comunque il sistema e' EOL) o in qualche ora della notte che significa a costo TRIPLO. Dopo una discussione lunga e pietosa, decidiamo che al mattino presto e' meglio. Quindi galoppo la mia moto fino al datacenter, metto le zampe sul server ed un reboot dopo ho la password di root. E nello stesso tempo mi rendo conto che quel server e' vecchio... intendo VECCHIO, veramente vecchio. Non solo il software e' EOL, anche l'hardware e' fuori manutenzione, questo coso e' un disastro in attesa di verificarsi.

Con la password di root posso finalmente procedere e copiare i files di configurazione da un sistema all'altro e mettere a posto altra roba... e scoprire altri problemi, per esemio, dovrebbe (di nuovo con il 'dovrebbe') esserci MySQL Server installato sul nuovo sistema, ma c'e' solo il client installato.

Ovviamente a questo punto CL e' in ferie e non posso prenderlo a cazzotti. Faccio presente a DB che la pagina di installazione e' un cumulo di infami menzogne, che cio' che dovrebbe essere installato non e' e che il segno di spunta che dice "controllato ed approvato" presuppone che chi lo mette abbia in effetti CONTROLLATO le cose prima di APPROVARE. Ma questo e' argomento per un'altra storia probabilmente.

E' arrivato il momento di contattare il cliente ed organizzare, finalemente, il "tasbordo". Il mio piano: copiare il database dal server vecchio a quello nuovo e riconfigurare l'applicazione in modo che usi il database nuovo, configurare quello vecchio come 'slave' del nuovo in modo che entrambi siano sempre up-to-date nel caso si debba fare un 'fallback' sul vecchio server. Quindi il giorno che decidiamo di fare il cambio, aggiungere un RDR sul firewall, cambiare la configurazione del DNS e via, il nuovo sistema e' in produzione. Se qualche cosa va male possiamo sempre RDR sul vecchio.

Sulla carta dovrebbe funzionare... finche' non mi rendo conto che i due sistemi sono in due subnets completamente differenti.

Dopo un numero sufficientemente grande di madonne, comincio il processo di migrare il server dalla sua subnet a quella del vecchio server, fortunatamente questo richiede solo una serie di cambiamenti nel firewall ed un trasferimento da un datastore all'altro.

A questo punto MarketingDude mi informa che Cliente ha deciso di andare in produzione il giorno dopo. Alle 4 del mattino!

Io faccio presente (con un numero di improperi sorprendentemente basso) che noi non abbiamo ancora verificato l'applicazione e che grazie al lavoro "superlativo" di CL sono stato occupato a ri-fare il 99% dell'installazione di base, quindi se vogliono andare in produzione io non mi prendo nessuna responsabilita' se questo coso esplode nel momento in cui io schisso il tasto rosso.

Segue, ovviamente, un lungo piagnucolio di "soddisfazione del cliente" al quale io rispondo domandando cosa e' meglio? Una accurata e pianificata transizione dal sistema vecchio a quello nuovo o una cosa raffazzonata ed alla cazzo che potenzialmente puo' introiare tutto? Tristemente, non ricevo nessuna risposta a quella domanda.

Le 4 del mattino arrivano, scendo dal letto (aiutato dai gatti che vogliono la colazione), acchiappo una tazza di caffe, accendo il pc e comincio a ravanare.

Ed a questo punto scopro la gabola, il dettaglio che, nella furia di cercare di avere tutto pronto e di fare anche il resto del lavoro "normale", ho completamente ignorato: noi non manteniamo il DNS del cliente, quindi io posso aggiungere un RDR ma sono sicuro che qualche cosa andra' male da qualche parte.

E' intorno alle 3 del pomeriggio che il "qualche cosa" salta fuori. Ed in effetti non ha niente a che vedere con il DNS. Il cliente riporta che qualche cosa non funziona nell'applicazione. Dato che non riesco a vedere niente nei log, cerco di ottenere piu' dettagli dal cliente stesso. Ma a parte che "riceve un errore e di contattare il sysdadmin" non mi dice niente di piu'. In un impeto di ispirazione decido di controllare la configurazione del firewall del sistema vecchio e noto un "pass any" dal server vecchio verso Internet, che ovviamente il server nuovo non ha. Un controllo nei log del firewall mi rileva migliaia di "block" dal server nuovo verso qualche IP in UK.

IO - (Al telefono con il Cliente) ...e quindi sembra che il vostro server stia cercando di connettersi con un qualche sistema in UK su porta 8080, e' un qualche tipo di webservice oppure... ?
Cliente - Non ne sono sicuro. Siete voialtri che dovreste sapere queste cose!
IO - Scusate, ma noi facciamo solo la manutenzione di base al sistema, che significa mantenerlo up-to-date come OS, noi non facciamo manutenzione all'applicazione e non siamo a conoscenza dei dettagli di funzionamento.
Cliente - Be', io non lo so.
IO - Non puo' domandare agli sviluppatori di quell'applicazione?
Cliente - Non credo, gli sviluppatori sono andati da parechio...
IO - E nessuno fa manutenzione all'applicazione?
Cliente - No.

...ovviamente no. A giudicare dall'eta' del server vecchio, probabilmente questa e' l'unica copia esistente di quel coso.

Al che io aggiungo una regola "pass any" al server e dopo poco il cliente mi conferma che l'errore non si presenta piu'. Ovviamente non abbiamo modo di sapere che problemi quella cosa ha causato durante la giornata, ne' se vi sono altri problemi che girano nei meandri oscuri ed inesplorati di quella applicazione.

E la ciliegina sulla torta? Manco il backup era configurato sul server nuovo, ne' l'analisi dei log ed il monitoring. In sostanza, quando CL ha detto che il server era "finito, di base", intendeva dire che non lo era manco un po'.

Davide
21/12/2016 13:29

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.

5 messaggi posta messaggio
Guido Di Guido - postato il 16/01/2017 07:50 - rispondi

Fammi capire una cosa ma com'e' che alla fine il pesce padulo torna sempre a te? :\)

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


Davide Bianchi@ Guido Di Davide Bianchi - postato il 16/01/2017 10:04 - rispondi

Fammi capire una cosa ma com'e' che alla fine il pesce padulo torna sempre a te? :\)

Perche' sono scemo evidentemente...

--
Davide Bianchi


Guido@ Davide Bianchi Di Guido - postato il 16/01/2017 11:35 - rispondi

Perche' sono scemo evidentemente...

...penso sia comune a tutti quelli che preferiscono risolvere i problemi invece di scrollare le spalle e fregarsene...

un saluto!

--
vuoi essere positivo? Perdi un elettrone!


trekfan1 Di trekfan1 - postato il 17/01/2017 08:25 - rispondi

Ma le storie più recenti non dovrebbero essere in alto nel feed?

--
trekfan1


pif Di pif - postato il 02/02/2017 13:55 - rispondi

Ma bentornato!

--
pif


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