DevOps è diventato un argomento molto popolare negli ultimi anni. Molte persone sognano di aderirvi, ma, come dimostra la pratica, spesso solo a causa del livello dei salari.
Alcune persone elencano DevOps nel proprio curriculum, anche se non sempre conoscono o comprendono l'essenza del termine. Alcune persone pensano che dopo aver studiato Ansible, GitLab, Jenkins, Terraform e simili (l'elenco può continuare secondo i tuoi gusti), diventerai immediatamente un “devopsista”. Questo ovviamente non è vero.
Negli ultimi anni mi sono occupato principalmente dell'implementazione di DevOps in varie aziende. In precedenza, ha lavorato per oltre 20 anni in posizioni che vanno dall'amministratore di sistema al direttore IT. Attualmente ingegnere capo DevOps presso Playgendary.
Chi è DevOps
L’idea di scrivere un articolo è nata dopo un’altra domanda: “chi è DevOps?” Non esiste ancora un termine stabilito per cosa o chi sia. Alcune delle risposte sono già qui . Per prima cosa ne evidenzierò i punti principali e poi condividerò le mie osservazioni e i miei pensieri.
DevOps non è uno specialista che può essere assunto, non un insieme di utilità e non un dipartimento di sviluppatori con ingegneri.
DevOps è una filosofia e una metodologia.
In altre parole, si tratta di un insieme di pratiche che aiutano gli sviluppatori a interagire attivamente con gli amministratori di sistema. Cioè, connettere e integrare i processi lavorativi tra loro.
Con l'avvento di DevOps, la struttura e i ruoli degli specialisti sono rimasti gli stessi (ci sono gli sviluppatori, ci sono gli ingegneri), ma le regole di interazione sono cambiate. I confini tra i dipartimenti sono sfumati.
Gli obiettivi di DevOps possono essere descritti in tre punti:
- Il software deve essere aggiornato regolarmente.
- Il software deve essere eseguito rapidamente.
- Il software dovrebbe essere distribuito comodamente e in breve tempo.
Non esiste un unico strumento per DevOps. Configurare, consegnare e studiare diversi prodotti non significa che DevOps sia apparso in azienda. Esistono molti strumenti e vengono tutti utilizzati in fasi diverse, ma hanno uno scopo comune.
E questa è solo una parte degli strumenti DevOps
Sono ormai più di 2 anni che intervisto persone per la posizione di ingegnere DevOps e mi sono reso conto di quanto sia importante comprendere chiaramente l'essenza del termine. Ho accumulato esperienze, osservazioni e pensieri specifici che voglio condividere.
Dall'esperienza del colloquio, vedo la seguente immagine: gli specialisti che considerano DevOps un titolo professionale di solito hanno incomprensioni con i colleghi.
C'è stato un esempio lampante. Un giovane è venuto al colloquio con molte parole intelligenti sul suo curriculum. Nei suoi ultimi tre lavori aveva 5-6 mesi di esperienza. Ho lasciato due startup perché “non decollavano”. Ma riguardo alla terza azienda, ha detto che lì nessuno lo capisce: gli sviluppatori scrivono codice su Windows e il direttore costringe questo codice a essere "avvolto" in un normale Docker e integrato nella pipeline CI/CD. Il ragazzo ha detto molte cose negative sul suo attuale posto di lavoro e sui suoi colleghi - volevo solo rispondere: "Quindi non venderai un elefante".
Poi gli ho posto una domanda che è in cima alla mia lista 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 era fortemente in disaccordo con esse. Credeva che DevOps fosse un titolo professionale. È qui che risiede la radice dei suoi problemi. Così come altri specialisti con la stessa opinione.
I datori di lavoro, avendo sentito parlare molto della “magia di DevOps”, vogliono trovare una persona che venga e crei questa “magia”. E i candidati della categoria “DevOps è un lavoro” non capiscono che con questo approccio non saranno in grado di soddisfare le aspettative. E, in generale, hanno scritto DevOps nel curriculum perché è una tendenza e lo pagano molto.
Metodologia e filosofia DevOps
La metodologia può essere teorica e pratica. Nel nostro caso, è il secondo. Come accennato in precedenza, DevOps è un insieme di pratiche e strategie utilizzate per raggiungere gli obiettivi prefissati. E in ciascun caso, a seconda dei processi aziendali dell’azienda, potrebbe differire in modo significativo. Il che non lo rende né migliore né peggiore.
La metodologia DevOps è solo un mezzo per raggiungere gli obiettivi.
Ora qual è la filosofia DevOps. E questa è probabilmente la domanda più difficile.
È abbastanza difficile formulare una risposta breve e concisa, perché non è stata ancora formalizzata. E poiché i sostenitori della filosofia DevOps sono più impegnati nella pratica, semplicemente non c’è tempo per filosofare. Tuttavia, questo è un processo molto importante. Inoltre, è direttamente correlato alle attività di ingegneria. Esiste persino un'area specializzata della conoscenza: .
Nella mia università non esistevano materie del genere, dovevo studiare tutto da solo utilizzando i materiali che potevo trovare negli anni '90. L'argomento è facoltativo per la formazione in ingegneria, da qui la mancanza di formalizzazione della risposta. Ma quelle persone che sono seriamente immerse nel DevOps iniziano a sentire un certo “spirito” o “comprensione inconscia” di tutti i processi aziendali.
Utilizzando la mia esperienza, ho cercato di formalizzare alcuni dei “postulati” di questa filosofia. Il risultato è il seguente:
- DevOps non è qualcosa di indipendente che possa essere separato in un'area separata di conoscenza o attività.
- Tutti i dipendenti dell'azienda dovrebbero essere guidati dalla metodologia DevOps quando pianificano le proprie attività.
- DevOps influisce su tutti i processi all'interno di un'azienda.
- DevOps esiste per ridurre i costi temporali per qualsiasi processo all'interno di un'azienda per garantire lo sviluppo dei suoi servizi e il massimo comfort del cliente.
- DevOps, in linguaggio moderno, è la posizione proattiva di ogni dipendente dell'azienda, volta a ridurre i costi in termini di tempo e migliorare la qualità dei prodotti IT che ci circondano.
Penso che i miei "postulati" siano un argomento di discussione separato. Ma ora c’è qualcosa su cui costruire.
Cosa fa DevOps
La parola chiave qui è comunicazione. Ci sono molte comunicazioni, il cui iniziatore dovrebbe essere esattamente lo stesso ingegnere DevOps. Perché? Perché questa è filosofia e metodologia, e solo allora conoscenza ingegneristica.
Non posso parlare con certezza al 100% del mercato del lavoro occidentale. Ma so molto del mercato DevOps in Russia. Oltre a centinaia di interviste, nell'ultimo anno e mezzo ho partecipato a centinaia di prevendite tecniche per il servizio “Implementazione di DevOps” per grandi aziende e banche russe.
In Russia, DevOps è un argomento ancora molto giovane, ma già di tendenza. Per quanto ne so, solo a Mosca nel 2019 la carenza di tali specialisti ammontava a oltre 1000 persone. E la parola Kubernetes per i datori di lavoro è quasi come uno straccio rosso per un toro. Gli aderenti a questo strumento sono pronti a utilizzarlo anche dove non è necessario ed economicamente redditizio. Il datore di lavoro non sempre capisce in quali casi cosa è più appropriato utilizzare e, con una corretta implementazione, la manutenzione di un cluster Kubernetes costa 2-3 volte di più rispetto alla distribuzione di un'applicazione utilizzando uno schema di cluster convenzionale. Usalo dove ne hai veramente bisogno.
L’implementazione di DevOps è costosa in termini economici. Ed è giustificato solo laddove apporta benefici economici in altri settori, e non da solo.
Gli ingegneri DevOps sono, infatti, pionieri: sono loro che dovrebbero essere i primi a implementare questa metodologia in azienda e costruire processi. Affinché ciò abbia successo, lo specialista deve interagire costantemente con dipendenti e colleghi a tutti i livelli. Come dico spesso, tutti i dipendenti dell’azienda dovrebbero essere coinvolti nel processo di implementazione di DevOps: dalla donna delle pulizie al CEO. E questo è un prerequisito. Se il membro più giovane del team non sa e non comprende cos'è DevOps e perché vengono eseguite determinate azioni organizzative, un'implementazione di successo non funzionerà.
Inoltre, un ingegnere DevOps deve utilizzare di tanto in tanto una risorsa amministrativa. Ad esempio, per superare la "resistenza ambientale", quando il team non è pronto ad accettare gli strumenti e la metodologia DevOps.
Lo sviluppatore dovrebbe solo scrivere codice e test. Per fare ciò, non ha bisogno di un laptop super potente su cui distribuire e supportare localmente l'intera infrastruttura del progetto. Ad esempio, uno sviluppatore front-end mantiene tutti gli elementi dell'applicazione sul suo laptop, incluso il database, l'emulatore S3 (minio), ecc. Cioè, dedica molto tempo alla manutenzione di questa infrastruttura locale e lotta da solo con tutti i problemi di tale soluzione. Invece di sviluppare il codice per il fronte. Queste persone possono essere molto resistenti a qualsiasi cambiamento.
Ma ci sono team che, al contrario, sono felici di introdurre nuovi strumenti e metodi e di partecipare attivamente a questo processo. Anche se anche in questo caso la comunicazione tra l’ingegnere DevOps e il team non è stata cancellata.
Quando DevOps non è necessario
Ci sono situazioni in cui DevOps non è necessario. Questo è un dato di fatto: deve essere compreso e accettato.
Ciò vale innanzitutto per qualsiasi azienda (soprattutto per le piccole imprese), quando il loro profitto non dipende direttamente dalla presenza o dall'assenza di prodotti IT che forniscono servizi informativi ai clienti. E qui non stiamo parlando del sito web dell’azienda, sia esso un “biglietto da visita” statico o con blocchi di notizie dinamiche, ecc.
DevOps è necessario quando la soddisfazione del tuo cliente e il suo desiderio di tornare da te dipendono dalla disponibilità di questi servizi informativi per l'interazione con il cliente, dalla loro qualità e dal targeting.
Un esempio lampante è una banca ben nota. L'azienda non dispone di uffici clienti tradizionali, il flusso dei documenti viene effettuato tramite posta o corrieri e molti dipendenti lavorano da casa. L'azienda ha cessato di essere solo una banca e, secondo me, si è trasformata in un'azienda IT con tecnologie DevOps sviluppate.
Molti altri esempi e conferenze si trovano nelle registrazioni di incontri e conferenze tematiche. Alcuni di loro li ho visitati personalmente: è un'esperienza molto utile per chi vuole svilupparsi in questa direzione. Ecco i collegamenti ai canali YouTube con ottime lezioni e materiali su DevOps:
Ora osserva la tua attività e pensa a questo: quanto la tua azienda e i suoi profitti dipendono dai prodotti IT per consentire l'interazione con i clienti?
Se la tua azienda vende pesce in un piccolo negozio e l'unico prodotto IT sono due 1C: configurazioni aziendali (contabilità e UNF), difficilmente ha senso parlare di DevOps.
Se lavori in una grande impresa commerciale e manifatturiera (ad esempio, produci fucili da caccia), allora dovresti pensarci. Puoi prendere l'iniziativa e trasmettere al tuo management le prospettive di implementazione di DevOps. Bene, e allo stesso tempo, guida questo processo. Una posizione proattiva è uno dei principi importanti della filosofia DevOps.
La dimensione e il volume del fatturato finanziario annuale 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. Ad esempio, alcune case automobilistiche e aziende produttrici di automobili. Adesso non ne sono sicuro, ma in base alla mia esperienza passata, per molti anni tutte le interazioni con i clienti avvenivano tramite e-mail e telefono.
I loro clienti sono un elenco limitato di concessionari di automobili. E a ciascuno viene assegnato uno specialista del produttore. Tutto il flusso di documenti interni avviene tramite SAP ERP. I dipendenti interni sono essenzialmente clienti del sistema informativo. Ma questo IS è controllato con i mezzi classici di gestione dei sistemi cluster. Il che esclude la possibilità di utilizzare pratiche DevOps.
Da qui la conclusione: per tali imprese, l'implementazione di DevOps non è qualcosa di fondamentale, se ricordiamo gli obiettivi della metodologia dall'inizio dell'articolo. Ma non escludo che oggi utilizzino alcuni strumenti DevOps.
D’altra parte, ci sono molte piccole aziende che sviluppano software utilizzando la metodologia, la filosofia, le pratiche e gli strumenti DevOps. E credono che il costo dell’implementazione di DevOps sia il costo che consente loro di competere efficacemente nel mercato del software. Si possono vedere esempi di tali società .
Il criterio principale per capire se è necessario DevOps: quale valore hanno i tuoi prodotti IT per l'azienda e i clienti.
Se il prodotto principale dell'azienda che genera profitti è il software, è necessario DevOps. E non è così importante se guadagni soldi veri usando altri prodotti. Ciò include anche negozi online o applicazioni mobili con giochi.
Tutti i giochi esistono grazie ai finanziamenti: diretti o indiretti da parte dei giocatori. A Playgendary sviluppiamo giochi mobili gratuiti con oltre 200 persone direttamente coinvolte nella loro creazione. Come utilizziamo DevOps?
Sì, esattamente come descritto sopra. Comunico costantemente con sviluppatori e tester e conduco formazione interna per i dipendenti sulla metodologia e sugli strumenti DevOps.
Ora stiamo utilizzando attivamente Jenkins come strumento di pipeline CI/CD per l'esecuzione di tutte le pipeline di assemblaggio con Unity e la successiva distribuzione su App Store e Play Market. Altro dal toolkit classico:
- Asana: per la gestione del progetto. L'integrazione con Jenkins è stata configurata.
- Google Meet: per riunioni video.
- Slack: per comunicazioni e vari avvisi, comprese le notifiche di Jenkins.
- Atlassian Confluence: per documentazione e lavoro di gruppo.
I nostri piani immediati includono l'introduzione dell'analisi statica del codice utilizzando SonarQube e la conduzione di test automatizzati dell'interfaccia utente utilizzando Selenium nella fase di integrazione continua.
Invece di una conclusione
Vorrei concludere con la seguente riflessione: per diventare un ingegnere DevOps altamente qualificato, è fondamentale imparare a comunicare dal vivo con le persone.
Un ingegnere DevOps è un giocatore di squadra. E nient'altro. L'iniziativa nel comunicare con i colleghi dovrebbe venire da lui e non sotto l'influenza di alcune circostanze. Uno specialista 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 cambiare del tutto. Sviluppandosi in modo indipendente, proponendo e implementando le sue idee, una persona del genere ha un valore crescente sia per il team che per il datore di lavoro. Il che, in definitiva, si riflette nell'importo della sua retribuzione mensile o sotto forma di bonus aggiuntivi.
Fonte: habr.com