Ingegnieri...
Notare bene: questa qui non e' esattemente una "storia", e' piu' che altro una mia elucubrazione semi-filosofica su certe attitudini e certi avvenimenti, prendetela un po' come vi pare.
Allora, tanto tempo fa, c'erano i "programmatori" (o "sviluppatori", chiamateli un po' come straminchia volete), che sviluppavano il software, i "capi progetto" che cercavano di gestirsi le cose, gli "architetti" che progettavano i sistemi eccetera eccetera.
Poi c'erano gli Amministratori di Sistema (meglio noti come "tuttofare") che si occupavano di gestire e mantenere in funzione l'intero ambaradan, fare assistenza agli utenti, risolvere i vari casini, gestirsi il parco macchine eccetera eccetera.
Ad un certo punto, per non si sa bene quale motivo, qualcuno ha deciso che il termine "amministratore di sistema" faceva schifo. Era brutto vecchio, faceva venire in mente un tizio tutto grigio seduto in un ufficetto scuro e brutto nel seminterrato di un qualche edificio fatiscente a scrivere su carte polverose, il che, a parte le carte polverose, era piu' o meno come si presentavano gli uffici IT di molti posti. Era ora di svecchiare l'intero mondo dell'it. Ed il miglior modo di svecchiare qualche cosa, come sanno tutti quelli che hanno completato il corso di Magnament & Makreting all'Universita' del Postal Market, e' di cambiare tutti nomi ed i loghi. Fottesega se poi si fanno le stesse cose nello stesso modo. Vedi? Ha un nuovo nome ed un nuovo logo, quindi e' tutto nuovo, splendente e luccicoso.
Ecco che ti arriva il "System Engineer". Che e' lo stesso "amministratore" di prima, solo che prende meno soldi ed ha anche piu' lavoro perche' adesso deve "ingegniarsi" a passare pure ste' cazzo di certificazioni ISO che ci servono senno' non prendiamo piu' soldi.
Il termine "engineer" e' un po' troppo inflazionato ultimamente. All'inizio chi si fregiava di tale titolo lo faceva dopo aver ottenuto un sudato pezzo di carta da un istituto riconosciuto (normalmente una universita'), pezzo di carta che, sostanzialmente, dimostrava che il tizio in questione aveva quanto meno speso dei soldi per ottenere il titolo.
Oggi, chiunque e' un "ingegniere". Ingegnieri del software che non hanno mai usato un debugger e non sanno manco che cosa sia, ingegnieri dell'hardware che non sanno che differenza ci sia tra un disco fisso ed un SSD, ingegnieri della rete che non sanno che cosa sia TLS, e per finire, ingegnieri "di sistema" che non sanno manco cosa sia il sistema.
Io continuo ad insistere che il mio titolo dovrebbe essere sempre e solo System ADMINISTRATOR, o se vogliamo proprio andare sull'esotico "penguin wrangler". Ed ho gia' detto dei problemi insiti nel cercare di descrivere in che cosa consiste il mio lavoro ai non iniziati.
Tutto questo discorso salta fuori perche' qualche tempo addietro sono risultati dei problemi relativi alla gestione di certi "tickets". Per spiegare tutta la faccenda dovro' spiegare come la cosa funziona(va).
$shittyhostingprovider era inizialmente una azienda piccola e svelta in cui non esisteva veramente una divisione di livelli tra i vari 'tecnici'. C'erano quelli piu' esperti di una cosa o dell'altra, ma sostanzialmente tutti quanti si occupavano di tanto in tanto di tirare su il telefono e rispondere alle varie mail dei clienti che domandavano roba, dalla cazzata tipo aggiungere un IP al firewall fino a quello che ordinava un'intero sistema di produzione doppio ridondante con scappellamento a destra. Il che andava piu' o meno bene.
Poi, con l'entrata in azione del Piano Diabolico Per La Conquista Del Pianeta, avevamo acquisito una montagna di altre azienducole con clienti straccioni, e purtroppo nessuno aveva la piu' pallida idea di come gestirsi quella gente. Non solo, ma per "migliorare l'integrazione" era stato deciso di usare il sistema di ticketing di una delle societa' "partner". Sistema di ticketing che, almeno a me, sembrava disegnato appositamente per funzionare in una struttura piu' "rigida" e "classica", con supporto di primo livello, secondo livello e cosi' via.
Tale coso non funzionava molto bene nella nostra struttura, e se a questo si aggiunge la tendenza della gente a fare il minimo indispensabile e qualche volta manco quello, il risultato e' che i tickets restavano pendenti per settimane, finche' il cliente in questione non cominciava a telefonare a tutti i numeri che riusciva a trovare e, per puro caso, beccava quello di qualche UL/SL a caso ed allora qualcuno compariva e cominciava a madonnare.
Dopo che DB avea passato numerosi meeting a consulta con i vari SL/UL per "migliorare l'efficienza del gruppo" ed aveva, sostanzialmente, zero idee di come farlo, aveva finito con il riportare la cosa nel meeting settimanale. Durante il quale si era fatto notare che: 1. il nostro gruppo era oramai diventato in pieno il "supporto di primo livello", data l'insistenza nella "gestione dei ticket" e quindi nessuno aveva piu' tempo per fare altro, il che non era molto gradito da parecchia gente (me compreso), 2. i ticket che riferivano a roba di altri "team" (come venivano denominati i superstiti delle procedure di acquisizione) restavano per parecchio tempo ignorati dato che noi non sapevamo ne' che farne ne' a chi riferirne, 3. l'idea di "scalare" non aveva senso data la mancanza di un effettivo "responsabile" per la cosa.
Durante lo stesso meeting io feci anche notare che il prendere un ticket, farci poco o niente e poi ributtarlo nella coda senza aggiungere una nota non aveva molto senso perche' a quel punto nessuno sapeva piu' quale era lo stato della cosa. La mia proposta era molto semplice: avere una divisione di "help desk" di primo livello, responsabile per rispondere al telefono, risolvere le cazzate quando possibile e "distribuire" i ticket rimanenti ai vari "teams", e poi gestire le cose per "team" a seconda del livello di complessita' e di competenza dei problemi.
La mia proposta tuttavia fu' rigettata immediatamente perche' "non si allinea con lo spirito dell'azienda".
IO - Quale spirito? Quello che si beve?
DB - No, che ci dovrebbe essere qualcuno che risponde sempre al telefono..
IO - E dove sta' la novita'? Non dovremmo sempre rispondere al telefono? Il fatto che, per qualche motivo idiota, il telefono adesso e' automaticamente ruotato sul nostro numero se nessuno alza la cornetta gia' implica che *noi* siamo il supporto di primo livello. Quello che sto dicendo io e' che ci dovrebbe essere un supporto di primo livello RICONOSCIUTO e possibilmente non essere noi.
DB - Ma allora dobbiamo assumere altra gente.
IO - Considerando che stiamo acquistando altre societa' in blocco non dovrebbe essere un grande problema. O tutti quanti sono geni superspecializzati?
DB - No ma...
IO - ...ma?
DB - E' che il management non vuole avere una "prima linea" di supporto...
IO - E che cosa siamo noi ultimamente se non una prima linea di supporto?
Dopo aver girato attorno alla cosa per una buona mezz'ora, la "discussione" si e' spostata sul cosa questo fantomatico "supporto di prima linea" avrebbe dovuto effettivamente fare.
IO - Mi pare ovvio. Per prima cosa rispondere al telefono e cercare di capire chi parla e di chi sono clienti, poi creare un ticket con la migliore descrizione del problema che riescono ad estorcere all'imb... hemmm.. al tizio al telefono. Per seconda cosa guardare i ticket e se e' possibile applicare una soluzione standard applicarla, altrimenti passare il ticket al team che si occupa del cliente.
DB - E come dovrebbero stabilire se una soluzione si applica o no?
IO - Abbiamo sistemi che, regolarmente, manifestano dei problemi, problemi che sono dovuti alle applicazioni che ci girano che sono scritte con il culo, e nella maggioranza dei casi il modo migliore di risolvere la cosa e' di riavviare il servizio o i servizi che sono affetti. Non e' una soluzione e' un palliativo ma per risolvere veramente bisognerebbe buttare a mare i clienti in questione ma apparentemente questa e' una cosa che non si puo' fare.
DB - Si ma come decidono che il problema e' uno di quelli?
IO - Leggendo la documentazione. Che incidentalmente esiste solo per i sistemi che *noi* gestiamo direttamente. Il che ci porta al problema vero e proprio: NON ABBIAMO DOCUMENTAZIONE RELATIVA ALLA ROBA DI QUESTI IMBECILLI!
DB - Ma supponendo che ci fosse tale documentazione, come farebbero questi di "prima linea" a capire le cose?
IO - ...applicando dei normali principi di debugging? Tipo, guardare i log? Provare a fare un telnet? Un ping? Accendere un cero alla madonna? Che cosa ti aspetti?
DB - Si ma allora sono degli ingegnieri.
IO - ...in che senso?
DB - Che allora sono System Engineer e dovrebbero essere pagati come tali.
IO - Se significa che noi dovremmo essere pagati di piu' sono assolutamente d'accordo. Se invece assumi che il sapere fare un telnet ti rende un system engineer... O hai una stima estremamente bassa delle nostre capacita' o non sai che cosa cazzo e' un system engineer.
DB - Allora, debugging, logging, networking...
IO - Sapere fere un ping e guardare un log non e' sufficiente a qualificarti come 'network engineer' o come 'engineer' in tutti sensi. Potrebbe essere utile a stabilire se il problema e' su una macchina o se e' un problema di rete che affligge molteplici macchine e quindi girare il ticket al corretto dipartimento...
DB - Team!
IO - ... Team, quello che cazzo ti pare, ma non ti basta a qualificarti come un 'engineer'.
DB - Si ma..
IO - Tu suoni la chitarra giusto?
DB - Eh? Si ma che c'entra?
IO - Se suoni la chitarra sei una rockstar, ergo: quando vai in tournee?
DB - No ma che c'entra?
IO - Esattamente lo stesso che c'entra la tua idea balzana!
La "discussione" e' andata avanti per un tempo eccessivamente lungo, ed alla fine, come al solito, non e' stato deciso niente. Quello che e' rimasto chiaro e' che DB non aveva la piu' pallida idea di cosa fa effettivamente un "system engineer" o che cosa NON FA. Quello che e' peggio e' che non aveva idea di quello che NON DOVREBBE fare, cioe' perdere tempo in cazzate che qualunque "first line support" dovrebbe essere competenente a risolvere.
E questo e' uno dei motivi per i quali me ne sono andato.
Davide
06/06/2019 15:04
