Il tema DevOps è diventato molto popolare negli ultimi anni. Molti sognano di entrarvi, ma, come dimostrano i fatti, spesso lo fanno solo per l'altezza degli stipendi.
Alcuni indicano DevOps nel proprio curriculum, anche se non sempre conoscono e comprendono il significato del termine. C'è chi pensa che, dopo aver studiato Ansible, GitLab, Jenkins, Terraform e simili (la lista può continuare a piacere), diventerà subito un 'DevOps'. Ovviamente, non è così.
Negli ultimi anni mi sono occupato principalmente dell'implementazione di DevOps in diverse aziende. Prima di ciò, ho lavorato per oltre 20 anni in posizioni che vanno da amministratore di sistema a direttore IT. Ora sono DevOps Lead Engineer in Playgendary.
Chi è DevOps
L'idea di scrivere un articolo è nata dopo l'ennesima domanda: 'chi è DevOps?'. Non esiste ancora un termine consolidato per definire cosa o chi sia. Parte delle risposte è già presente in questo . Inizialmente evidenzierò i punti principali e poi condividerò le mie osservazioni e pensieri.
DevOps non è uno specialista che si può assumere, non è un insieme di strumenti e non è un reparto di sviluppatori ed ingegneri.
DevOps è una filosofia e una metodologia.
In altre parole, è un insieme di pratiche che aiuta a far interagire attivamente gli sviluppatori con gli amministratori di sistema. Vale a dire, collegare e integrare i flussi di lavoro l'uno nell'altro.
Con l'arrivo di DevOps, la struttura e i ruoli degli specialisti sono rimasti gli stessi (ci sono sviluppatori, ci sono ingegneri), ma sono cambiate le regole d'interazione. I confini tra i reparti si sono sfumati.
Gli obiettivi di DevOps possono essere riassunti in tre punti:
- Il software deve essere aggiornato regolarmente.
- Il software deve essere realizzato rapidamente.
- Il software deve essere implementato in modo conveniente e in tempi brevi.
DevOps non ha uno strumento unico. Configurare, installare e studiare diversi prodotti non significa che in azienda sia apparso DevOps. Ci sono molti strumenti e vengono utilizzati in diverse fasi, ma servono a un unico obiettivo.
E questa è solo una parte degli strumenti DevOps
Da oltre due anni intervisto persone per il ruolo di ingegnere DevOps e ho realizzato quanto sia importante capire chiaramente il significato del termine. Ho accumulato esperienze, osservazioni e pensieri specifici che voglio condividere.
Dalla mia esperienza negli colloqui vedo questa situazione: gli specialisti che considerano DevOps come una posizione solitamente hanno incomprensioni con i colleghi.
C'era un chiaro esempio. A un colloquio è venuto un giovane con un sacco di parole intelligenti nel curriculum. Negli ultimi tre posti di lavoro ha avuto un'esperienza di 5-6 mesi. È uscito da due startup perché "non sono decollate". E riguardo alla terza azienda ha detto che lì nessuno lo capisce: i programmatori scrivono codice per Windows, e il direttore lo costringe a "impacchettare" quel codice in un normale Docker e integrarlo nel pipeline CI/CD. Il ragazzo ha raccontato molte cose negative riguardo al suo attuale posto di lavoro e ai suoi colleghi — sembrava quasi di voler rispondere: "Così non venderai nemmeno un elefante".
Poi gli ho fatto una domanda, che nel mio elenco è una delle prime per ogni candidato.
— Cosa significa per te DevOps?
— In generale o come lo percepisco io?
Mi interessava la sua opinione personale. Conosceva la teoria e l'origine del termine, ma era categoricamente in disaccordo. Credeva che DevOps fosse una posizione. Qui risiede la radice dei suoi problemi. Come per altri specialisti con la stessa opinione.
I datori di lavoro, dopo aver sentito parlare della "magia del DevOps", vogliono trovare qualcuno che venga e crei questa "magia". E i candidati che pensano "DevOps è una posizione" non capiscono che con questo approccio non saranno in grado di soddisfare le aspettative. E, in generale, hanno scritto nel loro curriculum DevOps perché è una tendenza e perché pagano molto per questo.
Metodologia e filosofia del DevOps
La metodologia può essere teorica o pratica. Nel nostro caso — la seconda. Come ho accennato prima, 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ò differire notevolmente. Il che non lo rende né migliore né peggiore.
La metodologia DevOps è solo un mezzo per raggiungere gli obiettivi fissati.
Ora parliamo di cosa sia la filosofia DevOps. E questa è probabilmente la domanda più difficile.
Formulare una risposta breve e concisa è abbastanza difficile, perché non è ancora stato formalizzato. E poiché gli aderenti alla filosofia DevOps si occupano più di pratica — non c'è tempo per la filosofia. Tuttavia, è un processo molto importante. Inoltre, è direttamente correlato all'attività ingegneristica. Esiste anche un'area di studio specializzata — .
Nel mio ateneo non esisteva questa materia, 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 formalizzazione della risposta. Ma le persone che si sono immerse seriamente nel DevOps iniziano a percepire un certo 'spirito' o una 'totalità inconscia' di tutti i processi dell'azienda.
Ho cercato, sulla base della mia esperienza, di formalizzare alcuni 'postulati' di questa filosofia. Ecco cosa ne è venuto fuori:
- Il DevOps non è qualcosa di autonomo, che può essere distinto come un'area separata di conoscenza o attività.
- Tutti i dipendenti dell'azienda devono seguire la metodologia DevOps pianificando la loro attività.
- Il DevOps interessa tutti i processi all'interno dell'azienda.
- Il DevOps esiste per ridurre il tempo dedicato a qualsiasi processo all'interno dell'azienda per garantire lo sviluppo dei suoi servizi e il massimo comfort per il cliente.
- Il DevOps, in termini moderni, è la posizione proattiva di ogni dipendente dell'azienda, mirata a ridurre i costi temporali e migliorare la qualità dei prodotti IT che ci circondano.
Penso che i miei 'postulati' siano un argomento a parte da discutere. Ma ora c'è un punto di partenza.
Cosa fa il DevOps
La parola chiave qui è comunicazione. Ci sono molte comunicazioni, di cui dovrebbe essere iniziatore proprio quell'ingegnere DevOps. Perché? Perché è filosofia e metodologia, e solo dopo arriva la competenza ingegneristica.
Non posso parlare del mercato del lavoro occidentale con il 100% di certezza. Ma conosco piuttosto bene il mercato del DevOps in Russia. Oltre a centinaia di colloqui, negli ultimi un anno e mezzo ho partecipato a un centinaio di presales tecnici per il servizio 'Implementazione del DevOps' per grandi aziende e banche russe.
In Italia, il DevOps è ancora un tema molto giovane, ma già di tendenza. Per quanto ne so, solo a Roma, la carenza di tali professionisti nel 2019 ha superato le 1000 unità. E il termine Kubernetes è per i datori di lavoro quasi come un panno rosso per un toro. I sostenitori di questo strumento sono pronti a utilizzarlo anche dove non è necessario e non è economicamente vantaggioso. Il datore di lavoro non sempre comprende in quali casi sarebbe più opportuno utilizzare questo approccio; con una distribuzione adeguata, il costo di implementazione di un cluster Kubernetes è da 2 a 3 volte superiore rispetto a quello di una distribuzione di un'applicazione secondo uno schema di clustering tradizionale. Utilizzatelo dove è veramente necessario.
L'implementazione del DevOps dal punto di vista economico è costosa. Ed è giustificata solo dove apporta vantaggi economici in altri ambiti, e non per il suo stesso valore.
Gli ingegneri DevOps sono, di fatto, i pionieri: sono loro i primi a dover implementare questa metodologia in azienda e a costruire processi. Per avere successo, un professionista deve interagire costantemente con i dipendenti e i colleghi a tutti i livelli. Come dico di solito, nel processo di implementazione del DevOps devono essere coinvolti tutti i dipendenti dell’azienda: dall'addetto alle pulizie al CEO. Questa è una condizione imprescindibile. Se il membro più giovane del team non conosce e non comprende cosa sia il DevOps e perché vengano effettuate determinate azioni organizzative, non si potrà avere successo nell'implementazione.
Inoltre, l'ingegnere DevOps deve di tanto in tanto utilizzare risorse amministrative. Ad esempio, per superare la "resistenza dell'ambiente" — quando il team non è pronto ad accettare gli strumenti e la metodologia DevOps.
Il programmatore deve scrivere solo codice e test. Per questo non ha bisogno di un laptop potente, sul quale stia distribuendo e mantenendo localmente l'intera infrastruttura del progetto. Ad esempio, un front-end developer tiene sul proprio laptop tutti gli elementi dell'applicazione, inclusa la base di dati, l'emulatore S3 (minio) e altro. Quindi, spende molto tempo per mantenere questa infrastruttura locale e combatte da solo con tutti i problemi di tale soluzione. Invece di sviluppare codice per il front-end. Queste persone possono opporsi fortemente a qualsiasi cambiamento.
Ci sono team, che al contrario, sono felici di adottare nuovi strumenti e metodi e partecipano attivamente a questo processo. Anche in questo caso, però, 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. È un dato di fatto — bisogna comprenderlo e accettarlo.
In primo luogo, questo vale per tutte le aziende (specialmente le piccole imprese) quando il loro profitto non dipende direttamente dalla presenza o assenza di prodotti IT che forniscono servizi informativi ai clienti. Qui non si tratta solo del sito web dell'azienda, sia esso una semplice "vetrina" statica o con sezioni dinamiche come notizie, ecc.
Il DevOps è richiesto quando la disponibilità di questi servizi informativi per l'interazione con il cliente, la loro qualità e targetizzazione influiscono sulla soddisfazione del cliente e sul suo desiderio di tornare da voi.
Un esempio lampante è una nota banca. L'azienda non ha uffici tradizionali, la gestione della documentazione avviene 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 una compagnia IT con tecnologie DevOps avanzate.
Molti altri esempi e conferenze possono essere trovati nei materiali di meetup tematici e conferenze. Parte di essi ho potuto seguirli di persona — è un'esperienza molto utile per chi desidera svilupparsi in questo campo. Ecco i link ai canali YouTube con buone conferenze e materiali su DevOps:
Ora guarda il tuo business e chiediti: quanto dipende la tua azienda e il suo profitto dai prodotti IT che garantiscono l'interazione con il cliente?
Se la tua azienda vende pesce in un piccolo negozio e l'unico prodotto IT sono due configurazioni di 1C: Enterprise (Contabilità e Gestione delle vendite), è improbabile che abbia senso parlare di DevOps.
Se invece lavori in una grande azienda commerciale e manifatturiera (ad esempio, producendo fucili da caccia), vale la pena rifletterci. Puoi prendere l'iniziativa e comunicare alla tua direzione le prospettive di implementazione del DevOps, e nel contempo guidare questo processo. Avere un atteggiamento proattivo è uno dei principi fondamentali della filosofia DevOps.
La dimensione e il volume del fatturato annuale non sono criteri principali per determinare se alla tua azienda serve il DevOps.
Immaginiamo una grande azienda industriale che non interagisce direttamente con i clienti. Ad esempio, alcune case automobilistiche e aziende di produzione di automobili. Attualmente non sono sicuro, ma, dalla mia esperienza passata, per molti anni tutta l'interazione con i clienti avveniva via email e telefono.
I loro clienti sono un elenco ristretto di concessionari automobilistici. E a ciascuno è assegnato uno specialista del produttore. Tutta la documentazione interna avviene tramite ERP SAP. I dipendenti interni sono, in sostanza, i clienti del sistema informatico. Ma la gestione di questo sistema informatico avviene con metodi tradizionali di gestione dei sistemi a cluster, escludendo così la possibilità di utilizzare pratiche DevOps.
La conclusione è chiara: per tali aziende, l'implementazione di DevOps non è qualcosa di criticamente importante, se si considerano gli obiettivi della metodologia menzionati all'inizio dell'articolo. Tuttavia, non escludo che alcuni strumenti DevOps vengano utilizzati da loro oggi.
D'altra parte, ci sono molte piccole aziende che sviluppano software utilizzando metodologie, filosofie, pratiche e strumenti DevOps. E credono che i costi per l'implementazione di DevOps siano spese che consentono loro di competere efficacemente nel mercato del software. Esempi di tali aziende possono essere osservati .
Il criterio principale per comprendere se DevOps è necessario: quale importanza hanno i vostri prodotti IT per l'azienda e i clienti.
Se il prodotto principale dell'azienda, che porta profitto, è software — avete bisogno di DevOps. E non è così importante se guadagnate soldi reali tramite altri beni. Questo include anche negozi online o applicazioni mobili con giochi.
Qualsiasi gioco esiste grazie a finanziamenti: diretti o indiretti da parte dei giocatori. In Playgendary sviluppiamo giochi mobili gratuiti, nel cui sviluppo sono coinvolte più di 200 persone. Come utilizziamo DevOps?
Esattamente come descritto sopra. Comunico costantemente con sviluppatori e tester, organizzo formazioni interne per i dipendenti sulla metodologia e sugli strumenti DevOps.
Attualmente utilizziamo attivamente Jenkins come strumento per i pipeline CI/CD per eseguire tutte le configurazioni di build con Unity e il successivo deployment nell'App Store e nel Play Market. Inoltre, dal classico set di strumenti:
- Asana — per la gestione dei progetti. Integrazione configurata con Jenkins.
- Google Meet — per videoconferenze.
- Slack — per comunicazione e varie notifiche, comprese quelle da Jenkins.
- Atlassian Confluence — per documentazione e lavoro di gruppo.
Nei prossimi piani c'è l'implementazione di analisi statica del codice con SonarQube e l'esecuzione di test UI automatizzati utilizzando Selenium durante la Continuous Integration.
In conclusione
Voglio concludere con questa riflessione: per diventare un ingegnere DevOps di alta qualifica, è vitale imparare a comunicare efficacemente con le persone.
L'ingegnere DevOps è un giocatore di squadra. E non può essere altrimenti. L'iniziativa nella comunicazione con i colleghi dovrebbe partire da lui stesso, e non in risposta a qualche circostanza. Un professionista DevOps deve vedere e proporre la soluzione migliore per il team.
E sì, l'implementazione di qualsiasi soluzione richiederà molte discussioni, e alla fine potrebbe anche cambiare del tutto. Crescendo autonomamente, proponendo e realizzando le proprie idee, una persona diventa sempre più preziosa sia per il team che per il datore di lavoro. Questo, alla fine, si riflette anche sull'importo della sua remunerazione mensile o sotto forma di premi aggiuntivi.
Fonte: habr.com
