Perche' Si?
Quante volte lo abbiamo sentito: "si puo' fare la tal cosa?" "perche' no?"... E poi di solito quello che segue e' una scena alla Michael Bay, solo che invece che essere a buona distanza a gustarsi lo spettacolo con accompagnamento di popcorn, siamo nel mezzo del casino cercando di schivare rottami, proiettili, esplosioni e roba infuocata (e non c'e' una donna manco a pagarla).
Ed ogni volta (dopo aver raggiunto una posizione di quasi-sicurezza intendo), io penso, ma perche' cazzo invece di rispondere "perche' no?" non si risponde "perche' si?".
Che posto in modo meno criptico diventa: perche' accidenti dovremmo fare tale cosa? Quale vantaggio o miglioramento se ne ottiene? Che attenzione, non e' che io sono contrario a priori a qualunque cosa o cambiamento, ma in molti casi mi pare che la "cosa" in questione venga fatta senza un vero motivo pratico. La si fa perche' a qualcuno e' venuto in mente e la risposta alla domanda e' stata "perche' no" invece che "ma che straminchia stai dicendo" come sarebbe meglio qualche volta.
Il problema e' che molto spesso quando la domanda viene posta tutti gli interessati hanno poco... hemm... interesse ad attirare l'attenzione sul fatto che della "cosa" in questione non sanno una sega e preferiscono andare con il sano principio che "se tutti dicono ok nessuno puo' essere incolpato della cagata pazzesca quando viene scoperta". Dove tutti sono colpevoli nessuno e' colpevole. Tranne il capro espiatorio e quello si sostituisce facilmente.
E con questo andiamo a parlare di $sgambini, ennesima ditta che ci siamo ritrovati nel parco-clienti dopo aver acquisito un altro branco di sconvolti.
Il problema di sgambini e' che non avevano nessun problema. E quando non c'e' un problema da risolvere, una societa' che si occupa di IT ha il dovere morale e sociale di inventarsene uno (o una dozzina) in modo da persuadere il gestore del quatrino a farne uso. Ed evidentemente il branco di sconvolti di cui sopra si era prodigato bene.
Ho gia' parlato precedentemente dei "problemi" della cosidetta metodologia "dev-ops", metodologia che consiste sostanzialmente nell'usare sempre e comunque degli script per configurare o modificare la configurazione di sistemi. E quale e' il problema direte voi?
Ora, io sono un fan degli script, e se devo fare una cosa 'n' volte cerchero' di automatizzarla in tutti modi possibili, ma se la possibilita' di dover ripetere la procedura e' relativamente bassa, ed il tempo richiesto ad automatizzarla e' decisamente tanto, preferisco tirarmi su le maniche e fare la cosa manualmente.
Intendiamoci: se ti ritrovi con 'n' (con n >= 2) macchine che sono PERFETTAMENTE IDENTICHE e devono svolgere la stessa funzione, con lo stesso software e piu' o meno la stessa configurazione, allora DevOps e' indicato. Ma se quello che hai di fronte e' un parco macchine con un centinaio di 'fiocchi di neve' unici ed inimitabili, finisci con il dover gestire e mantenere diverse centinaia di scripts, ognuno dei quali unico ed inimitabile e se poi ti sbagli a lanciarli sei introiato perche' non c'e' modo di capire quale e' quello giusto.
Purtroppo, qualcuno si e' fermato alla presentazione PowerPoint senza poi leggere la documentazione e si e' convinto che DevOps sia la miglior cosa sul pianeta terra dopo il pane affettato ed insiste nell'usare tale approccio anche quando non ha nessun senso.
E fu cosi' che UL di $sgambini arrivo' una bella mattina per parlare del "nuovo" ambiente di gestione della loro posta.
UL - ...e quindi grazie alla costruzione autoridimensionanteconscappellamentoadestra come descritto nella presentazione se ci sono dei problemi noi semplicemente rilanciamo il tutto ed i server vengono ricreati da zero con tutte le configurazioni riprese dal repository esterno che... blah blah blah yada yada yada. Che ne pensate?
IO - Ed a che serve tutto questo?
UL - Come a che serve?
IO - Si a che serve.
UL - ...a ricostruire l'intero ambiente.
IO - E perche' vorreste "ricostruire" l'intero ambiente? Non vi basta di "costruirlo" una volta?
UL - Ma... no perche'... il disastro...
IO - Quale disastro?
UL - Quello che potrebbe verificarsi...
IO - Allora, facciamo un attimo mente locale... Quello che volete fare voi e' mettere in piedi un sistema di gestione della posta per il vostro ufficio, si tratta di una ventina di persone che scambiano mah... un centinaio di mail al giorno? Il tutto viene gestito da UN server per Smtp, UN server per IMAP/POP ed UN server per accesso web. Finito. Quello che serve e' un backup giornaliero delle mailbox (che di sicuro non volete "ricostruire" da zero) e della configurazione.
UL - Infatti ed usando lo script possiamo rilanciare il tutto e riavere la struttura completa.
IO - E quando pensate di lanciarlo questo script?
UL - Quando si verifica un problema.
IO - Hmmm.. che tipo di problema dovrebbe provocare una ricostruzione da zero dell'intero ambiente?
UL - Bhe', per esempio un errore nella configurazione...
IO - Se ricostruite l'ambiente inclusa la configurazione e questa e' sbagliata rimane sbagliata eh.
UL - Hemmm... no per quello la configurazione deve essere provata.
IO - Quindi... come la provate la configurazione?
UL - Bhe', si fa la configurazione e la si prova... e se funziona si riporta nel repository.
IO - E chi vi assicura che sia stata riportata nel repository?
UL - ...potremmo riportarla nel repository automaticamente ogni 10 minuti.
IO - Quindi se la configurazione e' sbagliata viene riportata lo stesso?
UL - Hummm...
IO - Il punto e' che certe cose devono necessariamente essere fatte a mano ed a quel punto quello che e' nel repository e quello che e' in effetti usato cominciano ad andare ognuno per conto suo, lo so perche' l'ho visto succedere troppe volte. A quel punto dovrete decidere se volete buttare via tutto e ricominciare da capo o buttare via il repository.
UL - Ma...
IO - Ma la mia domanda rimane: A che serve tutta questa roba? Intendo il DevOps.
UL - In caso di disastro...
IO - E quante volte al giorno vi aspettate questo disastro?
UL - No! Ma che al giorno. Noi speriamo di non vederlo mai il disastro...
IO - Quindi voi volete mettere in piedi un sistema ultracomplesso che richiede procedure ultra rigide per poter funzionare in modo quasi credibile, per una eventualita' che sperate non si verifichi mai e che in ogni caso vi richiede un backup per poter essere utilizzata a pieno?
UL - Hemmm... si'.
IO - E perche' si?
UL - ...come sarebbe a dire perche' si?
IO - Le mie opposizioni all'idea le hai sentite. Adesso, ignorando il problema "disastro" perche' e' la risposta sbagliata, perche' vorreste fare questa roba?
...sto ancora aspettando una risposta.
Davide
04/10/2019 11:47
