Negli ultimi anni, il tema del DevOps è diventato molto popolare. Molti desiderano entrarvi, ma, come dimostra la pratica, spesso lo fanno solo per il livello salariale.
Alcuni menzionano il DevOps nel proprio curriculum, anche se non sempre conoscono e comprendono il significato del termine. Alcuni pensano che, una volta appresi Ansible, GitLab, Jenkins, Terraform e simili (il tutto può continuare a piacere), diventeranno immediatamente dei "DevOps". Ma non è affatto così.
Negli ultimi anni mi sono occupato principalmente dell'implementazione del DevOps in diverse aziende. Prima di questo, ho lavorato più di 20 anni in posizioni che vanno dal sistemista all'IT Director. Attualmente sono DevOps Lead Engineer in Playgendary.
Chi è il DevOps
L'idea di scrivere un articolo è nata dopo l'ennesima domanda: "Chi è il DevOps?". Non c'è ancora un termine ben definito per descrivere cosa o chi sia. Alcune risposte si possono trovare in questo . Prima evidenzierò i punti principali e poi condividerò le mie osservazioni e riflessioni.
Il DevOps non è uno specialista che si può assumere, né un insieme di strumenti, né un reparto di sviluppatori con ingegneri.
Il DevOps è una filosofia e una metodologia.
In altre parole, si tratta di un insieme di pratiche che aiuta a favorire l'interazione tra sviluppatori e amministratori di sistema. Ossia, a collegare e integrare i flussi di lavoro tra loro.
Con l'arrivo del DevOps, la struttura e i ruoli dei professionisti sono rimasti gli stessi (ci sono sviluppatori, ci sono ingegneri), ma sono cambiate le regole di interazione. I confini tra i reparti si sono sfumati.
Gli obiettivi del DevOps possono essere riassunti in tre punti:
- Il software deve essere aggiornato regolarmente.
- Il software deve essere realizzato rapidamente.
- Il software deve essere distribuito in modo semplice e in tempi brevi.
Il DevOps non ha uno strumento unico. Configurare, installare e studiare diversi prodotti non significa che in azienda sia presente DevOps. Gli strumenti sono molti e vengono utilizzati in diverse fasi, ma servono a un unico obiettivo.
E questa è solo una parte degli strumenti DevOps.
Da oltre 2 anni intervisto persone per la posizione di ingegnere DevOps e ho realizzato quanto sia importante comprendere chiaramente il significato del termine. Ho accumulato esperienza specifica, osservazioni e riflessioni che desidero condividere.
Dalla mia esperienza di interviste vedo un quadro del genere: In generale, i professionisti che considerano il DevOps una posizione spesso hanno fraintendimenti con i colleghi..
C'era un esempio lampante. A un colloquio si è presentato un giovane con un sacco di parole intelligenti nel suo curriculum. Negli ultimi tre posti di lavoro, ha lavorato per 5-6 mesi. È uscito da due startup perché "non hanno decollato". Riguardo alla terza azienda ha detto che lì nessuno lo capisce: gli sviluppatori scrivono codice per Windows, e il direttore lo costringe a 'impacchettare' quel codice in un normale Docker da integrare nel pipeline CI/CD. Il ragazzo ha raccontato molte cose negative riguardo il suo attuale posto di lavoro e i suoi colleghi — è stato naturale voler rispondere: "Ma non puoi vendere quell'elefante".
Poi gli ho fatto una domanda che nella mia lista è una delle prime per ogni candidato.
— Cosa significa DevOps per te personalmente?
— In generale o come lo percepisco?
Mi interessava la sua opinione personale. Conosceva la teoria e l'origine del termine, ma non era affatto d'accordo. Credeva che DevOps fosse una posizione. Qui si nasconde la radice dei suoi problemi, proprio come per altri professionisti con la stessa opinione.
I datori di lavoro, ascoltando la "magia del DevOps", cercano una persona che possa creare questa "magia". Tuttavia, i candidati che pensano che "DevOps sia una posizione" non comprendono che con questo approccio non potranno soddisfare le aspettative. In effetti, hanno menzionato DevOps nel loro curriculum solo perché è una moda e si paga molto per questo.
Metodologia e filosofia del DevOps
La metodologia può essere teorica o pratica. Nel nostro caso, si tratta della seconda. Come ho menzionato in precedenza, il DevOps è un insieme di pratiche e strategie utilizzate per raggiungere gli obiettivi dichiarati. E in ogni caso, a seconda dei processi aziendali dell'azienda, può variare notevolmente. Questo non lo rende migliore o peggiore.
La metodologia del DevOps è solo uno strumento per raggiungere gli obiettivi prefissati.
Ora parliamo di cosa sia la filosofia del DevOps. E questo è probabilmente il tema più difficile.
Formulare una risposta breve e concisa è piuttosto difficile, poiché non è ancora stata formalizzata. E poiché gli adepti della filosofia DevOps si concentrano più sulla pratica, non c'è tempo per filosofeggiare. Tuttavia, è un processo molto importante, direttamente legato all'attività ingegneristica. Esiste anche un'area di conoscenza specializzata — .
Nella mia università non c'era un materia del genere, quindi ho dovuto studiare tutto autonomamente con i materiali che sono riuscito a trovare negli anni '90. L'argomento non è obbligatorio per la formazione ingegneristica, da qui l'assenza di una risposta formalizzata. Ma coloro che si sono immersi seriamente in DevOps iniziano a percepire un certo ‘spirito’ o una ‘onnipresenza inconscia’ di tutti i processi aziendali.
Ho cercato di formalizzare alcune ‘asserzioni’ di questa filosofia basandomi sulla mia esperienza. Ecco cosa è emerso:
- DevOps non è qualcosa di autonomo che può essere individuato come una direzione separata di conoscenza o attività.
- Tutti i dipendenti dell'azienda dovrebbero seguire la metodologia DevOps nel pianificare la loro attività.
- DevOps coinvolge tutti i processi all'interno dell'azienda.
- Il DevOps esiste per ridurre il tempo speso in qualsiasi processo all'interno dell'azienda, garantendo così lo sviluppo dei suoi servizi e il massimo comfort per il cliente.
- Il DevOps, in termini moderni, rappresenta un atteggiamento proattivo di ogni dipendente dell'azienda, mirato a ridurre i costi temporali e migliorare la qualità dei prodotti IT che ci circondano.
Ritengo che i miei «postulati» siano un argomento a parte per una discussione. Ma adesso c'è una base da cui partire.
Cosa fa il DevOps
La parola chiave qui è comunicazione. Ci sono molte comunicazioni, di cui deve farsi carico proprio quell'ingegnere DevOps. Perché? Perché si tratta di una filosofia e di una metodologia, e solo dopo di conoscenze ingegneristiche.
Non posso parlare con certezza al 100% del mercato del lavoro occidentale. Tuttavia, conosco abbastanza bene il mercato del DevOps in Russia. Oltre a centinaia di colloqui, negli ultimi diciotto mesi ho partecipato a un centinaio di pre-vendite tecniche per il servizio «Implementazione del DevOps» per grandi aziende e banche russe.
In Italia, DevOps è ancora un argomento relativamente nuovo, ma già in forte crescita. A quanto pare, solo a Roma la carenza di tali specialisti nel 2019 ha superato le 1000 unità. E la parola Kubernetes è per i datori di lavoro come un drago rosso per un toro. I sostenitori di questo strumento sono pronti a utilizzarlo anche dove non è necessario e non è economicamente vantaggioso. I datori di lavoro non sempre comprendono in quali casi sia più appropriato usarlo, e nel caso di un corretto deployment, il costo di un cluster Kubernetes è 2-3 volte superiore a quello di un'applicazione distribuita secondo un normale schema di clustering. Utilizzatelo dove è davvero necessario.
L'implementazione di DevOps, dal punto di vista economico, è costosa. Ed è giustificata solo dove porta un vantaggio economico in altri ambiti, e non per sè stessa.
Gli ingegneri DevOps sono, in effetti, dei pionieri: sono loro i primi a dover implementare questa metodologia all'interno delle aziende e a strutturare i processi. Per avere successo, un professionista deve interagire costantemente con i dipendenti e i colleghi a tutti i livelli. Come dico spesso, nel processo di implementazione del DevOps devono essere coinvolti tutti i membri dell'azienda: dal personale delle pulizie fino al CEO. Questa è una condizione imprescindibile. Se il membro più junior del team non sa e non comprende che cos'è il DevOps e perché vengono eseguite determinate azioni organizzative, l'implementazione non avrà successo.
Inoltre, l'ingegnere DevOps deve anche ogni tanto sfruttare le risorse amministrative. Per esempio, per superare la 'resistenza dell'ambiente' — quando il team non è pronto ad accettare gli strumenti e la metodologia DevOps.
Lo sviluppatore deve concentrarsi solo sulla scrittura di codice e test. Per questo non ha bisogno di un laptop super potente su cui gestire e mantenere localmente tutta l'infrastruttura del progetto. Ad esempio, un frontend developer mantiene sul proprio laptop tutti gli elementi dell'applicazione, inclusa la base di dati, l'emulatore S3 (minio) e altro ancora. Questo significa che trascorre molto tempo a gestire questa infrastruttura locale e affronta da solo tutte le problematiche di tale soluzione, invece di dedicarsi allo sviluppo del codice frontend. Queste persone possono opporsi fortemente a qualsiasi cambiamento.
Ma ci sono squadre che, al contrario, sono entusiaste dell'introduzione di nuovi strumenti e metodi e partecipano attivamente a questo processo. Anche in questo caso, la comunicazione tra l'ingegnere DevOps e il team rimane fondamentale.
Quando il DevOps non è necessario
Ci sono situazioni in cui il DevOps non è necessario. Questo è un dato di fatto che bisogna riconoscere e accettare.
In primo luogo, questo riguarda qualsiasi azienda (soprattutto le piccole imprese), la cui redditività non dipende direttamente dalla presenza o assenza di prodotti IT che forniscono servizi informativi ai clienti. E qui non parliamo solo del sito web dell'azienda, che sia una semplice "visita" statica o con blocchi di notizie dinamiche, ecc.
Il DevOps è necessario quando la soddisfazione del cliente e il suo desiderio di tornare da voi dipendono dall'esistenza, dalla qualità e dalla targetizzazione di questi servizi informativi per l'interazione con il cliente.
Un esempio evidente è una banca molto conosciuta. L'azienda non ha uffici clienti tradizionali; la documentazione viene gestita tramite posta o corrieri, e molti dipendenti lavorano da casa. L'azienda ha smesso di essere semplicemente una banca e, a mio avviso, si è trasformata in un'azienda IT con tecnologie DevOps avanzate.
Molti altri esempi e conferenze possono essere trovati nelle registrazioni di meetup e conferenze tematiche. Parte di esse le ho seguite di persona: è un'esperienza molto utile per chi desidera svilupparsi in questa direzione. Ecco i link ai canali YouTube con buone conferenze e materiali sul DevOps:
Ora guarda il tuo business e chiediti: quanto dipende la tua azienda e il suo profitto dai prodotti IT che facilitano l'interazione con i clienti?
Se la tua azienda vende pesce in un piccolo negozio e l'unico prodotto IT consiste in due configurazioni di 1C: Enterprise (Contabilità e UNF), non ha molto senso parlare di DevOps.
Se lavori in una grande azienda commerciale e di produzione (ad esempio, producendo fucili da caccia), allora vale la pena riflettere. Puoi prendere l'iniziativa e comunicare alla tua direzione le potenzialità dell'implementazione di DevOps. Inoltre, puoi guidare questo processo. Avere una posizione proattiva è uno dei principali principi della filosofia DevOps.
La dimensione e il volume del fatturato annuo non sono il criterio principale per determinare se la tua azienda ha bisogno di DevOps.
Immaginiamo una grande impresa industriale che non interagisce direttamente con i clienti. Per esempio, alcune case automobilistiche e produttori di auto. Non ne sono certo, ma dalla mia esperienza passata, per molti anni tutta l'interazione con i clienti è avvenuta tramite email e telefono.
I loro clienti sono una lista ristretta di concessionarie automobilistiche. A ciascuna è assegnato uno specialista del produttore. Tutta la documentazione interna avviene tramite ERP SAP. I dipendenti interni sono, in sostanza, i clienti del sistema informativo. Tuttavia, la gestione di questo sistema viene effettuata con metodi classici per la gestione di sistemi cluster. Questo esclude la possibilità di utilizzare pratiche DevOps.
Da qui la conclusione: per tali imprese, l'implementazione di DevOps non è qualcosa di fondamentale importanza, se consideriamo gli obiettivi della metodologia citati all'inizio dell'articolo. Tuttavia, non escludo che alcuni strumenti DevOps possano essere utilizzati da loro oggi.
D'altra parte, ci sono molte piccole aziende che sviluppano software utilizzando metodologie, filosofie, pratiche e strumenti DevOps. E considerano i costi per l'implementazione del DevOps come spese necessarie per competere efficacemente nel mercato del software. Esempi di queste aziende possono essere visti .
Il criterio principale per capire se hai bisogno del DevOps è: quale valore hanno i tuoi prodotti IT per l'azienda e per i clienti.
Se il prodotto principale dell'azienda, che genera profitto, è un software — hai bisogno del DevOps. E non è così importante se guadagni realmente soldi con altri prodotti. Questi includono anche negozi online o app mobili con giochi.
Qualsiasi gioco esiste grazie al finanziamento: diretto o indiretto da parte dei giocatori. In Playgendary sviluppiamo giochi mobili gratuiti, in cui sono coinvolte direttamente oltre 200 persone. Come utilizziamo il DevOps?
Sì, esattamente come descritto sopra. Comunico continuamente con sviluppatori e tester, e fornisco formazione interna ai dipendenti sulla metodologia e sugli strumenti del DevOps.
Attualmente utilizziamo Jenkins come strumento per i pipeline CI/CD per eseguire tutti i processi di build con Unity e successivamente effettuare il deployment su App Store e Play Market. Inoltre, far parte di un set di strumenti classici:
- Asana — per la gestione dei progetti. È stata configurata l'integrazione con Jenkins.
- Google Meet — per le videoconferenze.
- Slack — per le comunicazioni e vari avvisi, incluse le notifiche da Jenkins.
- Atlassian Confluence — per la documentazione e il lavoro di gruppo.
Nei prossimi piani c'è l'implementazione di un'analisi statica del codice tramite SonarQube e la conduzione di test UI automatizzati con Selenium nella fase di Continuous Integration.
In conclusion
Vorrei concludere con questa riflessione: per diventare un ingegnere DevOps altamente qualificato è fondamentale imparare a comunicare efficacemente con le persone.
L'ingegnere DevOps è un giocatore di squadra. Non ci sono alternative. L'iniziativa nella comunicazione con i colleghi deve provenire da lui stesso, e non deve essere una risposta a circostanze esterne. Un professionista DevOps deve saper identificare e proporre la soluzione migliore per il team.
Sì, implementare qualsiasi soluzione richiede molte discussioni e potrebbe anche cambiare completamente alla fine. Sviluppandosi autonomamente, proponendo e realizzando le proprie idee, una persona rappresenta un valore sempre maggiore sia per il team che per il datore di lavoro. Questo, in definitiva, si riflette anche sull'entità della sua retribuzione mensile o sotto forma di premi extra.
Fonte: habr.com
