Cosa serve per il successo di un'azienda IT nel 2019? I relatori ai convegni e meet-up usano molte parole altisonanti e non sempre comprensibili per le persone normali. La competizione per il tempo di deployment, i microservizi, l'abbandono del monolite, la trasformazione DevOps e molto, molto altro. Se si scarta la bellezza verbale e si parla chiaro e in russo, tutto si riduce a un semplice concetto: create un prodotto di qualità, e farlo in modo confortevole per il team.
Quest'ultimo aspetto è diventato critico. Finalmente le aziende hanno compreso che un processo di sviluppo confortevole aumenta la produttività e, se tutto è collaudato e funziona come un orologio, offre anche un margine di manovra in situazioni critiche. Una volta, per questo margine, un certo intelligente inventò i backup, ma l'industria si evolve, e siamo giunti agli ingegneri DevOps: persone che trasformano il processo di interazione tra sviluppo e infrastruttura esterna in qualcosa di adeguato e non legato allo sciamanesimo.
Tutta questa storia di "per modulo" è splendida, ma… È successo che parte degli amministratori siano stati improvvisamente etichettati come DevOps, e dagli stessi ingegneri DevOps iniziò ad essere richiesta, perlomeno, la telepatia e la chiaroveggenza.
Prima di parlare dei problemi moderni nella gestione dell'infrastruttura, definiamo cosa intendiamo con questo termine. Attualmente, la situazione è tale che abbiamo raggiunto una dualità di questo concetto: l'infrastruttura può essere considerata esterna e interna.
Per infrastruttura esterna si intende tutto ciò che garantisce il funzionamento del servizio o del prodotto di cui si occupa il team. Questi sono i server dell'applicazione o del sito, hosting e altri servizi che assicurano l'operatività del prodotto.
L'infrastruttura interna comprende i servizi e l'attrezzatura utilizzata dal team di sviluppo e da altri dipendenti, che di solito non sono pochi. Questi includono server interni per il sistema di archiviazione del codice, un task manager implementato localmente e tutto ciò che esiste all'interno dell'intranet aziendale.
Cosa fa un amministratore di sistema in azienda? Oltre a gestire l'amministrazione di questa intranet aziendale, spesso è responsabile della manutenzione del funzionamento delle attrezzature per ufficio. L'amministratore è proprio quel ragazzo che rapidamente porta un nuovo sistema dalla riserva o un notebook di riserva pronto all'uso, consegna una tastiera fresca e striscia a quattro zampe negli uffici per far passare il cavo Ethernet. L'amministratore è il vero padrone e signore non solo delle risorse interne ed esterne server, ma anche di quelle gestionali. Sì, alcuni amministratori possono lavorare solo a livello sistemico, senza occuparsi dell'hardware. È utile distinguerli in una sotto-categoria chiamata "amministratori di sistema infrastrutturali". Altri invece si specializzano esclusivamente nella manutenzione delle attrezzature per ufficio; se l'azienda conta più di cento persone, il lavoro non finisce mai. Ma né gli uni né gli altri sono DevOps.
E chi sono i DevOps? I DevOps sono ragazzi che si occupano dell'interazione tra lo sviluppo di software e l'infrastruttura esterna. Piuttosto, i moderni DevOps sono coinvolti nei processi di sviluppo e deployment molto più a fondo rispetto a quanto lo fossero mai gli amministratori che semplicemente caricavano aggiornamenti su ftp. Uno degli obiettivi principali di un ingegnere DevOps oggi è garantire un processo di interazione fluido ed efficientemente strutturato tra i team di sviluppo e l'infrastruttura del prodotto. Queste persone sono responsabili del deployment di sistemi di rollback e di deploy; esse alleviano parte del carico dai programmatori e si concentrano al massimo sul loro compito altamente critico. Tuttavia, un DevOps non tirerà mai un nuovo cavo o non fornirà un nuovo notebook dalla riserva (c) КО
Qual è il trucco?
Alla domanda «E chi è DevOps?» metà dei lavoratori del settore inizia a rispondere qualcosa come «Beh, insomma, è un amministratore che…» e così via. Sì, tanto tempo fa, quando la professione di ingegnere DevOps stava appena emergendo da alcuni degli amministratori più talentuosi nella gestione dei servizi, le differenze tra loro non erano così evidenti. Ma ora, quando le funzioni del DevOps e dell'amministratore nel team sono diventate radicalmente diverse, confonderli tra loro, o addirittura mettere un segno di uguaglianza tra di loro, è inaccettabile.
Ma in cosa si traduce questo per il business?
L'assunzione, è tutto un problema di assunzione.
Apri un annuncio per la posizione di «Amministratore di sistema», e trovi i requisiti come «interazione con lo sviluppo e i clienti», «sistema di consegna CI/CD», «manutenzione dei server e delle attrezzature aziendali», «amministrazione dei sistemi interni» e così via; capisci che il datore di lavoro sta dicendo qualche assurdità. Il punto è che invece di «Amministratore di sistema» nel titolo dell'annuncio dovrebbe esserci scritto «Ingegnere DevOps», e se si cambia quel titolo, tutto torna al suo posto.
Tuttavia, che impressione si ha leggendo un annuncio del genere? Che l'azienda cerca un jolly che possa gestire sia il sistema di controllo versione che quello di monitoraggio, e stringere una vite con i denti…
Eppure, per non aumentare il grado di confusione nel mercato del lavoro, è sufficiente chiamare i lavori con il loro nome e avere chiaro che ingegnere DevOps e amministratore di sistema sono due entità distinte. Solo che il desiderio irrefrenabile di alcuni datori di lavoro di presentare al candidato un elenco di requisiti il più ampio possibile porta al fatto che gli amministratori di sistema «classici» smettono di capire cosa stia succedendo intorno a loro. Cosa, la professione sta mutando e loro si sono messi al passo coi tempi?
No, no e ancora no. Gli amministratori infrastrutturali, che gestiranno i server interni dell'azienda, o occuperanno posizioni di supporto L2/L3 e aiuteranno gli altri dipendenti, non sono scomparsi e non hanno intenzione di andarsene.
E questi specialisti possono diventare ingegneri DevOps? Certo che possono. In effetti, si tratta di un ambiente affine che richiede competenze in amministrazione di sistema, ma oltre a questo, comporta anche lavoro con il monitoraggio, i sistemi di consegna e, in generale, un'interazione stretta con il team di sviluppo e testing.
Un altro problema del DevOps
In realtà, il problema non si limita solo all'assunzione e alla continua confusione tra amministratori e devops. A un certo punto, l'azienda si è trovata ad affrontare la questione della consegna degli aggiornamenti e dell'interazione del team di sviluppo con l'infrastruttura finale.
Forse è stata proprio allora che a un certo convegno è salito sul palco un tizio con gli occhi che brillavano e ha detto «E noi facciamo in questo modo e lo chiamiamo DevOps. Questi ragazzi risolveranno tutti i vostri problemi» — e ha cominciato a raccontare quanto fosse bello lavorare in azienda dopo l'implementazione delle pratiche DevOps.
Tuttavia, non basta assumere un ingegnere DevOps perché tutto funzioni «come dovrebbe». L'azienda deve intraprendere un'intera trasformazione DevOps, il che significa che il ruolo e le capacità del nostro devops devono essere ben compresi anche dal team di sviluppo e testing del prodotto. A proposito di questo, abbiamo una «bellissima» storia che illustra perfettamente la follia che a volte si verifica.
Situazione. Dal DevOps richiedono di implementare un sistema di rollback, senza approfondire come funzioni. 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» è semplicemente una bacchetta magica che aggiusta tutto, e non hanno idea di come funzioni. Quindi, ad esempio, gli sviluppatori in un aggiornamento hanno unito i campi nome e cognome, lo hanno rilasciato in produzione, ma la versione va lenta per chissà quale motivo. Cosa succede? La direzione si rivolge al DevOps e dice «Attiva l'interruttore!», cioè chiede di tornare alla versione precedente. Cosa fa il DevOps? Torna alla versione precedente, ma poiché gli sviluppatori non hanno voluto capire come si fa questo rollback, nessuno ha detto al DevOps che bisogna rollbackare anche il database. Alla fine, crolla tutto e gli utenti invece di un sito lento vedono l'errore «500», perché la vecchia versione non funziona con i campi del nuovo database. Il DevOps non ne è a conoscenza. Gli sviluppatori tacciono. La direzione inizia a perdere i nervi e i soldi e si ricorda dei backup, proponendo di tornare a quelli, affinché «qualcosa funzioni». Di conseguenza, gli utenti perdono tutti i propri dati per un certo periodo di tempo.
Naturalmente, il DevOps viene criticato per «non aver creato un sistema di rollback corretto», mentre nessuno si preoccupa del fatto che i veri responsabili in questa storia siano gli sviluppatori.
La conclusione è semplice: senza un approccio adeguato al DevOps, i risultati sono piuttosto scarsi.
La cosa principale da ricordare è: l'ingegnere DevOps non è un mago e senza comunicazioni di qualità e interazioni bidirezionali con gli sviluppatori non riuscirà a gestire i suoi compiti. Non si può lasciare il DevOps da solo con i suoi «problemi» o dirgli «non disturbare gli sviluppatori, tocca a loro scrivere codice», e poi sperare che nel momento critico tutto funzioni come dovrebbe. Non funziona in questo modo.
In sostanza, DevOps è una competenza che si colloca tra gestione e tecnologia. E non è affatto ovvio che in questo cocktail tecnologico debba esserci più tecnologia che gestione. Se desideri davvero costruire processi di sviluppo più rapidi ed efficaci, devi fidarti del tuo DevOps. Loro conoscono gli strumenti necessari, hanno realizzato progetti simili e sanno come agire. Aiutali, ascolta i loro consigli, non cercare di isolarli in qualche divisione autonoma. Se gli admin possono lavorare da soli, i DevOps in questo caso diventano inutili; non potranno aiutarti a diventare migliore se non sei tu a voler accettare questo aiuto.
E l'ultima cosa: smettila di offendere gli amministratori delle infrastrutture. Hanno un fronte di lavoro molto importante. Sì, un admin può diventare un ingegnere DevOps, ma ciò deve avvenire per scelta personale, non sotto costrizione. Non c'è nulla di male se un amministratore di sistema desidera restare tale — è una professione distinta e un suo diritto. Se c'è la volontà di intraprendere una trasformazione professionale, non bisogna mai dimenticare che dovrà essere migliorata non solo la competenza tecnologica, ma anche quella gestionale. Sarà probabilmente tuo compito riunire queste persone e insegnare loro a comunicare nella stessa lingua.
Fonte: habr.com
