Dev-OOPS!
Se avete seguito le mie disavventure nel corso della storia, vi sarete resi conto che io sono un appassionato di scripting e che ogni volta che e' possibile automatizzare o semplificare una procedura, io mi ci butto a pesce.
Tuttavia, bisogna sempre notare che la "procedura automatica" non e' sempre la migliore strategia, in alcuni casi la cosa migliore e' la procedura MANUALE. Che dovrebbe essere SEMPRE una possibilita'. Ci sono situazioni in cui il sistema automatico fallisce, ed e' giusto che fallisca, ed il modo migliore di procedere e' il sistema manuale. Inoltre, il sistema manuale dovrebbe essere sempre documentato insieme alla procedura automatica, per avere le informazioni di cosa fa' la procedura automatica, cosi' quando questa si schianta miserandamente (e notare che ho detto "quando" e non "se") e' possibile procedere con il /debugging/ e vedere quale e' il problema.
Ma come sempre, c'e' gente che non gradisce "leggere la documentazione" se questa e' piu' complicata di uno schemino dell'Ikea. Quello che vogliono loro e' fare un bel copia-incolla delle istruzioni nel loro terminale, schissare invio e poi andare a fumarsi una sigaretta (o quello che hanno in tasca che passa per "sigaretta").
Questo tipo di persone sono quelle che si sorprendono quando scoprono che il termine "autopilota" della loro nuovissima automobile, in realta' non riesce ad "autopilotare" la macchina e non e' altro che un "cruise control" con qualche gingillo in piu', o che si intestardiscono ad urlare comandi vocali al loro telefono che insiste nel volergli ordinare una pizza (o peggio).
Un altro punto di dissenso e' che io tendo a fare scripts quando, effettivamente, le operazioni da eseguire sono molteplici e sempre uguali, fare uno script per "automatizzare" UNA operazione che deve essere eseguita al peggio 2 volte su un unico sistema, non e' un risparmio di tempo e' solo una rottura di balle. Ma i promotori del 'dev-ops' sempre e dappertutto insistono che se dev-ops deve essere, dev-ops deve essere sempre, non importa in quale contesto.
E dopo questa confusa introduzione, parliamo di $confusi, i quali erano una piccola societa' di Hosting che ha avuto la malaugurata sorte di finire nel mirino della mia societa' quando questi erano alla continua ricerca di altre societa' da acquisire. Il risultato e' che $confusi e' adesso un'altra "divisione" che dovrebbe occuparsi dei suoi clienti fintanto che non viene deciso cosa farne.
Ora, a parte il fuggi-fuggi generale che e' seguito all'acquisizione, il "personale" di $confusi che e' rimasto e "coopera" (di malavoglia quando proprio devono farlo) per la gestione delle cose si conta sulle dita di una mano. Da quello che ho capito quelli che erano i piu' furbi ed esperti hanno deciso di passare ad altri lidi e quelli che sono rimasti sono quelli che o sono troppo pigri o non avevano un altra scappatoia a portata di mano. Quello che li accomuna e' che hanno scoperto il "dev-ops" qualche tempo fa e ci si sono buttati sopra come lupi famelici su una bella bistecca succosa. E come tali si sono dimenticati completamente di attivare il cervello prima di saltare.
E fu' cosi' che una bella mattina, mi beccai la telefonata di un CL a caso, che lamentava che qualche cosa non funzionava nel loro sistema.
Per qualche motivo che non sono mai riuscito a debuggare completamente, il "nostro" numero era usato come standard di help-desk, indipendentemente da chi o che cosa chiamava, il fatto che noi non avevamo l'esclusiva di risoluzione dei problemi e che le varie societa' che avevamo acquisito non avevano ancora riportato la loro documentazione nel "wiki" aziendale, ed in effetti resistevano tenacemente alla cosa, non rendeva il lavoro piu' semplice, semmai il contrario. Il risultato e' che dopo una vana ricerca per capire chi stracazzo era il CL del momento, di quale sistema parlava, chi lo avrebbe dovuto gestire e come, ho "delegato" il tutto a DB e buona fortuna. Perche' tu puoi rompere i marroni quanto ti pare che "noi" dovremmo essere quelli competenti, ma se non mi passi le informazioni non posso di certo essere competente.
Dopo un paio di giorni (si', eravamo arrivati a metterci dei giorni per individuare chi sapeva di cosa), salta fuori che la societa' di CL ha un paio di macchine che erano gestite da $confusi, parte per cui una richiesta a qualcuno dei superstiti per la gestione del ticket. Richiesta che rimane inascoltata. Nel frattempo, ovviamente, CL e' ritornato alla carica. E posso anche capirlo.
Anche perche' la sua richiesta (sua di CL intendo) non era niente di spettacolare: modificare il timeout del server web. Una cosa che, avendo accesso al server, si farebbe in 5 minuti. Solo che dopo due giorni noi stavamo ancora cercando chi aveva installato questa roba, dove e come.
Dopo una settimana (!) siamo riusciti ad individuare uno dei poveri pinguini rimasti e, dopo averlo torchiato a dovere, siamo riusciti a scovare che la roba era in Azure.
Ok, non e' che Azure sia particolarmente malvagia, a parte la loro interfaccia Web che e' abbastanza orrenda, ma a parte quello non ci sono grossi problemi.
A questo punto pero' ci siamo scontrati con un problema Tattico: chi avrebbe dovuto occuparsi della cosa? Noi o i superstiti di $confusi? Dopo un po' di discussioni, si e' deciso che $confusi avrebbe dovuto farsi carico dei loro ex-clienti mentre documentavano l'intero arsenale e preparavano il terreno per trasportare il tutto nel nostro datacenter e quidni essere in grado di gestire questo tipo di "emergenze". Io feci notare che piu' a lungo ci mettevano, maggiori erano le possibilita' che i loro "clienti" diventassero "clienti di qualcun altro"... Ma tante'...
Comunque sia, io passai il ticket a qualcuno dei pinguini e basta. Un paio di giorni dopo, cominciammo a ricevere chiamate allarmate da diversi ex-clienti di $confusi che riportavano strane anomalie sui loro sistemi. Come da istruzioni, noi ci limitammo a girare la cosa ai suddetti pinguini, ma la cosa non si risolse.
Finche' non cominciai a scavare un po' piu' a fondo e beccai uno dei suddetti pinguini al telefono. Chiamiamolo CL1.
CL1 - ...perche' noi usiamo sempre devops per fare queste cose, perche' devops e' il metodo migliore per fare queste cose...
IO - Si' ok, sicuro. E allora come mai abbiamo tutta questa gente che chiama che hanno dei problemi?
CL1 - Non lo so perche', perche' e' tutto fatto a devops e quindi...
IO - Fammi capire, che cosa e' fatto 'a devops' ?
CL1 - Tutto.
IO - ...andando nel dettaglio?
CL1 - Tutto. Se dobbiamo fare qualche cosa lo facciamo a dev-ops.
IO - ...Per esempio, se un certo cliente dice di aumentare il timeout del suo server web... voi che fate?
CL1 - Devops.
IO - ...che significa?
CL1 - Hemmm.. che significa che facciamo uno script e lo eseguiamo.
IO - Che script e dove lo eseguite e come?
CL1 - Ah noi usiamo puppet.
IO - Ok, e dove e come lo eseguite?
CL1 - Ma sei scemo? Lo lasciamo eseguire a puppet ovviamente.
IO - Ho capito, ma dove?
CL1 - Dappertutto ovviamente. E' tutto fatto a devops!
IO - ...ma io ti ho detto che UN cliente vuole cambiare il timeout... quindi dovrete avere un modo per limitare lo scopo di quello script no?
CL1 - Ma no, che... momento... come sarebbe a dire UN cliente?
IO - Riguardati un po' il ticket che vi ho girato il mese scorso...
Ebbene si'! I pinguini, dev-opsando di qua' e di la', hanno lanciato un qualche script su TUTTI i sistemi che avevano, senza riguardo di chi o cosa fossero, e senza controllare che la roba che stavano modificando fosse da modificare oppure no.
Ed ecco che il dev-ops e' diventato dev-UOPS!
Vabbe', tanto devono solo documentare no?
Davide
11/06/2018 16:53
