Cosa serve per avere successo nel settore IT nel 2019? I relatori nei convegni e nei meet-up parlano molto di termini altisonanti e non sempre comprensibili per le persone comuni. La lotta per il tempo di deployment, i microservizi, l'abbandono del monolite, la trasformazione DevOps e tanto altro ancora. Se lasciamo da parte la bellezza delle parole e parliamo chiaro, tutto si riduce a un semplice concetto: create un prodotto di qualità, e fatelo in modo che la squadra si senta a proprio agio.
Questo è diventato critico. Il business ha finalmente compreso che un processo di sviluppo fluido aumenta la produttività e, se tutto è collaudato e funziona a meraviglia, offre anche spazio di manovra in situazioni critiche. Un tempo, per garantire questo margine di manovra, un certo intelligente ha inventato i backup, ma l'industria si evolve e siamo arrivati agli ingegneri DevOps: persone che trasformano il processo di interazione tra lo sviluppo e l'infrastruttura esterna in qualcosa di adeguato e lontano dal ciarlatanismo.
Tutta questa storia del "modulo" è affascinante, ma... È successo che alcuni amministratori siano stati improvvisamente ribattezzati DevOps, mentre agli ingegneri DevOps si sono richiesti, quantomeno, abilità di telepatia e chiaroveggenza.
Prima di discutere i problemi moderni nella gestione dell'infrastruttura, definiamo cosa intendiamo con questo termine. Al momento attuale, la situazione si è evoluta in una dualità di questo concetto: l'infrastruttura può essere considerata esterna o interna.
Per infrastruttura esterna si intende tutto ciò che assicura la funzionalità del servizio o del prodotto sviluppato dal team. Si tratta di server applicativi o web, hosting e altri servizi che garantiscono il funzionamento del prodotto.
L'infrastruttura interna comprende i servizi e l'hardware utilizzati dal team di sviluppo e dai vari collaboratori, che di solito non sono pochi. Questi includono server interni per la gestione del codice, un task manager implementato localmente e tutto ciò che esiste nell'ambito dell'intranet aziendale.
Qual è il ruolo di un amministratore di sistema in un'azienda? Oltre a gestire l'intranet aziendale, spesso si occupa anche della manutenzione delle attrezzature per garantire il funzionamento dell'ufficio. L'amministratore è quella persona che porta rapidamente un nuovo computer dal magazzino o un laptop di riserva pronto all'uso, fornisce una nuova tastiera e si muove in giro per gli uffici strisciando per connettere un cavo Ethernet. L'amministratore è il padrone locale e il sovrano non solo dell'infrastruttura interna ma anche di quella esterna server, ma anche un gestore. Sì, alcuni amministratori possono lavorare solo nella sfera dei sistemi, senza hardware. È utile distinguerli come un sottogruppo di "amministratori di sistema infrastrutturali". Altri si specializzano nella manutenzione esclusiva dell'attrezzatura per ufficio, soprattutto nelle aziende con oltre un centinaio di dipendenti, in cui il lavoro non finisce mai. Tuttavia, né l'uno né l'altro sono devops.
E chi sono i DevOps? I DevOps sono professionisti che si occupano dell'interazione tra lo sviluppo software e le infrastrutture esterne. Più precisamente, i DevOps moderni sono coinvolti nei processi di sviluppo e deployment a un livello molto più profondo rispetto a quanto mai siano stati coinvolti gli amministratori, che si limitavano a caricare aggiornamenti tramite FTP. Uno dei principali compiti di un ingegnere DevOps oggi è garantire un processo di collaborazione ben strutturato ed efficace tra i team di sviluppo e l'infrastruttura del prodotto. Queste persone sono responsabili per il deployment dei sistemi di rollback e per il deployment stesso; esse alleviano parte del carico dai programmatori e si concentrano al massimo sul loro compito estremamente importante. Tuttavia, un DevOps non tirerà mai un nuovo cavo o distribuirà un nuovo laptop dal magazzino (c) KO.
Qual è il trucco?
Alla domanda «Chi è il DevOps?» metà dei lavoratori del settore inizia a rispondere qualcosa come «Beh, è una sorta di amministratore che...» e così via. Sì, tanto tempo fa, quando la professione di ingegnere DevOps stava appena emergendo dai più talentuosi amministratori di sistema per il servizio, le differenze tra di loro non erano chiare a tutti. Ma ora, quando le funzioni del DevOps e dell'amministratore in un team sono diventate radicalmente diverse, confonderli o addirittura metterli sullo stesso piano è inaccettabile.
Ma quali sono le conseguenze per il business?
L'assunzione, tutto ruota attorno a questo.
Apri una posizione per «Amministratore di sistema», e lì vengono elencati requisiti come «interazione con sviluppo e clienti», «sistema di distribuzione CI/CD», «manutenzione dei server e delle attrezzature aziendali», «amministrazione dei sistemi interni» e così via; capisci che chi assume sta dicendo qualcosa di illogico. Il fatto è che invece di «Amministratore di sistema» nel titolo dell'offerta di lavoro dovrebbe esserci «Ingegnere DevOps», e se cambi questo titolo, tutto torna al suo posto.
E qual è l'impressione che si crea leggendo un annuncio del genere? Che l'azienda cerca un tuttofare che riesca a gestire sia i sistemi di controllo delle versioni che le monitorizzazioni…
In realtà, per non aumentare il livello di confusione nel mercato del lavoro, è sufficiente chiamare le posizioni con il loro nome e comprendere chiaramente che un ingegnere DevOps e un amministratore di sistema sono due entità distinte. Tuttavia, il desiderio inestinguibile di alcuni datori di lavoro di presentare un elenco di requisiti il più ampio possibile porta al fatto che gli "amministratori di sistema classici" smettono di comprendere cosa accade attorno a loro. Che la professione sta mutando e che sono rimasti indietro rispetto ai tempi?
No, no e ancora no. Gli amministratori di infrastruttura, che gestiranno i server interni dell'azienda o assumeranno posizioni di supporto L2/L3 e aiuteranno altri dipendenti, non sono scomparsi e non hanno intenzione di farlo.
Possono questi specialisti diventare ingegneri DevOps? Certo, possono. Infatti, si tratta di un ambiente affine che richiede competenze di amministrazione di sistema, ma oltre a questo, include lavoro su monitoraggio, sistemi di distribuzione e, in generale, una stretta interazione con il team di sviluppo e di testing.
Un altro problema del DevOps
In realtà, il problema non si limita solo all'assunzione e alla costante confusione tra amministratori e DevOps. A un certo punto, le aziende si sono trovate ad affrontare il problema della distribuzione degli aggiornamenti e dell'interazione del team di sviluppo con l'infrastruttura finale.
Forse è stato allora, quando un tizio con gli occhi ardenti è salito sul palco di qualche conferenza e ha detto: «E noi facciamo così e lo chiamiamo DevOps. Questi ragazzi risolveranno tutti i vostri problemi» — e ha cominciato a raccontare quanto sia bello lavorare in un'azienda dopo l'implementazione delle pratiche DevOps.
Tuttavia, non è sufficiente assumere un ingegnere DevOps affinché tutto funzioni "come dovrebbe". L'azienda deve completare una trasformazione DevOps, il che significa che il ruolo e le competenze del nostro DevOps devono essere chiaramente riconosciuti anche dal team di sviluppo e di test del prodotto. A questo proposito, abbiamo una "storia interessante" che illustra appieno l'assurdità che a volte si verifica.
Situazione. DevOps è stato incaricato di implementare un sistema di rollback senza approfondire il funzionamento. Supponiamo che all'interno del sistema Users ci siano campi separati per nome, cognome e password. Esce una nuova versione del prodotto, ma per gli sviluppatori il "rollback" è solo una bacchetta magica che sistemerà tutto, e non hanno idea di come funzioni. Ad esempio, gli sviluppatori in un patch successivo hanno unito i campi nome e cognome, l'hanno lanciato in produzione, ma la versione rallenta per qualche motivo. Cosa succede? La direzione si reca da DevOps e dice: "Tira la leva!", chiedendo di tornare alla versione precedente. Cosa fa DevOps? Torna alla versione precedente, ma poiché gli sviluppatori non si sono voluti prendere la briga di capire come si effettua questo rollback, nessuno ha detto a DevOps che doveva ripristinare anche il database. Di conseguenza, tutto crolla, e gli utenti invece di un sito lento vedono l'errore "500", perché la vecchia versione non funziona con i campi del nuovo database. DevOps non ne è a conoscenza. Gli sviluppatori tacciono. La direzione inizia a perdere la calma e denaro, ricordandosi dei backup e proponendo di ripristinare da essi per far funzionare "almeno qualcosa". Di conseguenza, gli utenti perdono tutti i loro dati per un certo periodo di tempo.
Certo, i colpi vanno a finire sul DevOps che "non ha creato il giusto sistema di rollback", mentre i veri colpevoli in questa storia — gli sviluppatori — non interessano a nessuno.
La conclusione è semplice: senza un approccio adeguato al DevOps, il suo valore è piuttosto limitato.
La cosa principale da ricordare è che un ingegnere DevOps non è un mago e senza comunicazioni di qualità e interazioni bidirezionali con gli sviluppatori non sarà in grado di gestire i propri compiti. Non si possono lasciare i DevOps da soli con i loro "problemi" o dire "non toccare gli sviluppatori, tocca solo a loro scrivere codice", per poi sperare che nel momento critico tutto funzioni come deve. Non è così che funziona.
In sostanza, il DevOps rappresenta competenze che si collocano al confine tra management e tecnologia. È importante notare che in questo mix tecnologico non è sempre chiaro che ci debba essere più tecnologia che management. Se desiderate effettivamente costruire processi di sviluppo più veloci ed efficaci, dovete fidarvi del vostro DevOps. Lui conosce gli strumenti necessari, ha implementato progetti simili e sa come procedere. Aiutatelo, ascoltate i suoi consigli, non cercate di isolarlo in un'unità autonoma. Se gli amministratori possono lavorare in autonomia, i DevOps in tal caso sono inutili; non potranno aiutarvi a migliorare se non volete accettare il loro aiuto.
E infine, smettila di offendere gli amministratori delle infrastrutture. Hanno un fronte di lavoro molto importante. Sì, un amministratore può diventare un ingegnere DevOps, ma deve avvenire per volontà della persona stessa, non per imposizione. Non c'è nulla di sbagliato nel fatto che un amministratore di sistema voglia rimanere tale: è una professione a sé stante e un suo diritto. Se c'è il desiderio di intraprendere una trasformazione professionale, è fondamentale non dimenticare che si dovranno sviluppare non solo competenze tecniche, ma anche abilità manageriali. Sarà probabilmente compito vostro, come leader, riunire tutte queste persone e insegnare loro a comunicare nella stessa lingua.
Fonte: habr.com
