{"id":38521,"date":"2019-10-31T22:24:16","date_gmt":"2019-10-31T19:24:16","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kto-takie-devops\/"},"modified":"2019-10-31T22:24:16","modified_gmt":"2019-10-31T19:24:16","slug":"kto-takie-devops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kto-takie-devops","title":{"rendered":"Chi sono i DevOps?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Attualmente, questa \u00e8 forse la posizione pi\u00f9 costosa sul mercato. Il fervore attorno agli ingegneri DevOps supera ogni immaginabile limite, e le cose sono ancor peggio per gli ingegneri Senior DevOps.
\nLavoro come responsabile del dipartimento di integrazione e automazione, indovinate l'acronimo inglese: DevOps Manager. Riflette realmente la nostra attivit\u00e0 quotidiana? Probabilmente no, mentre la variante russa \u00e8 pi\u00f9 precisa in questo caso. Per la mia professione, \u00e8 naturale dover intervistare i futuri membri del mio team, e nell'ultimo anno, ho visto passare circa 50 persone, mentre altrettante sono state eliminate durante la preselezione con i miei collaboratori.<\/p>\n

<\/p>\n

Siamo ancora alla ricerca di colleghi, perch\u00e9 dietro l'etichetta DevOps si nasconde un'ampia variet\u00e0 di ingegneri di diversi tipi.<\/a><\/noindex><\/p>\n

<\/p>\n

Tutto ci\u00f2 che segue \u00e8 la mia opinione personale, non siete obbligati ad essere d'accordo, ma ammetto che potrebbe influenzare il vostro atteggiamento verso l'argomento. Nonostante il rischio di incorrere in critiche, pubblico il mio parere perch\u00e9 credo che meriti di essere condiviso.<\/p>\n

<\/p>\n

Le aziende interpretano in modo diverso chi siano gli ingegneri DevOps e, per assumere rapidamente, etichettano chiunque con questo nome. La situazione \u00e8 piuttosto strana, poich\u00e9 le aziende sono pronte a pagare somme incredibili a queste persone, ottenendo, nella maggior parte dei casi, un amministratore di sistema piuttosto che un vero professionista.<\/p>\n

<\/p>\n

Quindi, chi sono gli ingegneri DevOps?<\/h2>\n

<\/p>\n

Iniziamo con la storia dell'emergere del concetto di Development Operations, nato come un ulteriore passo verso l'ottimizzazione della collaborazione nei piccoli team per aumentare la velocit\u00e0 di produzione del prodotto. L'idea era quella di fornire al team di sviluppo una comprensione approfondita delle procedure e degli approcci nella gestione dell'ambiente del prodotto. In altre parole, uno sviluppatore deve comprendere e sapere come funziona il suo prodotto in determinate condizioni, deve sapere come implementarlo, quali caratteristiche dell'ambiente ottimizzare per migliorare le prestazioni. Con il tempo, sono emersi sviluppatori con un approccio DevOps. Gli sviluppatori DevOps scrivevano script di build e packaging per semplificare le loro attivit\u00e0 e il funzionamento dell'ambiente produttivo. Tuttavia, la complessit\u00e0 dell'architettura delle soluzioni e l'interazione tra i componenti dell'infrastruttura hanno iniziato a peggiorare le prestazioni degli ambienti, richiedendo con ogni iterazione una comprensione sempre pi\u00f9 profonda di ciascun componente, riducendo la produttivit\u00e0 dello sviluppatore stesso a causa del tempo speso a comprendere i componenti e a ottimizzare i sistemi per compiti specifici. Il costo dello sviluppatore aumentava, cos\u00ec come il costo del prodotto, e le richieste per l'ingresso di nuovi sviluppatori nel team sono aumentate drasticamente, poich\u00e9 dovevano coprire anche le responsabilit\u00e0 delle 'stelle' dello sviluppo, che diventavano progressivamente sempre meno accessibili. Inoltre, per esperienza, raramente gli sviluppatori si interessano alla specificit\u00e0 della gestione dei pacchetti da parte del kernel del sistema operativo, alle regole di instradamento dei pacchetti e agli aspetti di sicurezza dell'host. Di conseguenza, \u00e8 stato logico coinvolgere un amministratore, esperto in questi ambiti, e delegargli queste responsabilit\u00e0. Ci\u00f2 ha permesso di raggiungere risultati equivalenti a un costo inferiore rispetto a quello della 'stella' dello sviluppo. Questi amministratori venivano inseriti nei team con il compito principale di gestire gli ambienti di test e produzione, in base alle regole stabilite dal team stesso, con le risorse allocate specificamente a quel team. Cos\u00ec sono nati i DevOps, nel concetto di molti.<\/p>\n

<\/p>\n

Col tempo, i sistemi di amministrazione hanno iniziato a comprendere le esigenze specifiche di questo team di sviluppo per semplificare la vita di sviluppatori e tester, consentendo il rilascio di aggiornamenti senza dover passare la notte in ufficio a correggere gli errori di deploy. Con il passare del tempo, gli amministratori di sistema sono diventati le \"stelle\", in grado di comprendere ci\u00f2 che gli sviluppatori desiderano. Per minimizzare l'impatto, sono cominciati a diffondersi gli strumenti di gestione, rispolverando i metodi di isolamento a livello di OS che consentivano di ridurre i requisiti di sicurezza, la gestione della rete e la configurazione dell'host nel suo complesso, con il risultato di abbassare le aspettative per le nuove \"stelle\". <\/p>\n

<\/p>\n

\u00c8 arrivata una \u00abmeravigliosa\u00bb novit\u00e0: Docker. Perch\u00e9 meravigliosa? Perch\u00e9 la creazione di isolamento in chroot o jail, cos\u00ec come con OpenVZ, richiedeva conoscenze avanzate del sistema operativo. Con questo strumento, invece, \u00e8 possibile creare facilmente un ambiente isolato per applicazioni su un host, con tutto il necessario all'interno, e restituire il controllo nuovamente agli sviluppatori. Nel frattempo, l'amministratore di sistema deve gestire solo un host, garantendo la sicurezza e l'alta disponibilit\u00e0 \u2014 un semplificazione logica. Ma il progresso non si ferma e i sistemi diventano sempre pi\u00f9 complessi, con un numero crescente di componenti. Un singolo host non soddisfa pi\u00f9 le esigenze del sistema e diventa necessario costruire cluster. Ritorniamo cos\u00ec agli amministratori di sistema, che sono in grado di costruire queste architetture.<\/p>\n

<\/p>\n

Ciclo dopo ciclo, emergono vari sistemi che semplificano lo sviluppo e\/o l'amministrazione; emergono sistemi di orchestrazione, che, finch\u00e9 non \u00e8 necessario allontanarsi dal processo standard, sono facili da usare. L'architettura a microservizi \u00e8 emersa anche per semplificare tutto quanto sopra: meno interconnessioni, pi\u00f9 facile da gestire. Nella mia esperienza non ho mai incontrato completamente un'architettura a microservizi, direi un 50 e 50: il 50% sono microservizi, scatole nere che ricevono input e producono output elaborato, l'altro 50% \u00e8 un monolite strappato, servizi incapaci di funzionare indipendentemente dagli altri componenti. Tutto ci\u00f2 ha nuovamente imposto restrizioni sul livello di conoscenza sia degli sviluppatori che degli amministratori.<\/p>\n

<\/p>\n

Queste \"altalene\" di livello di conoscenza esperta di una risorsa o di un'altra continuano ancora oggi. Ma ci siamo un po' distratti, ci sono molti aspetti che meritano di essere discussi.<\/p>\n

<\/p>\n

Build Engineer\/Release Engineer<\/h2>\n

<\/p>\n

Ingegneri altamente specializzati, emersi come mezzo per standardizzare i processi di assemblaggio e rilascio del software. Con l'avvento del metodo Agile, sembrava che non fossero pi\u00f9 richiesti, ma non \u00e8 affatto cos\u00ec. Questa specializzazione \u00e8 nata per standardizzare proprio l'assemblaggio e la consegna del software su larga scala, utilizzando tecniche standard per tutti i prodotti dell'azienda. Con l'emergere del DevOps, gli sviluppatori hanno parzialmente perso alcune funzioni, dato che sono diventati responsabili della preparazione del prodotto per la consegna. Considerando l'infrastruttura in evoluzione e l'approccio alla consegna rapida senza considerare la qualit\u00e0, sono diventati un freno ai cambiamenti, poich\u00e9 seguire gli standard di qualit\u00e0 inevitabilmente rallenta le consegne. Cos\u00ec, gradualmente, parte delle funzioni degli ingegneri Build\/Release \u00e8 passata alle spalle degli amministratori di sistema.<\/p>\n

<\/p>\n

Gli Ops sono cos\u00ec diversi<\/h2>\n

<\/p>\n

Proseguiamo e nuovamente la presenza di un'ampia gamma di responsabilit\u00e0 e la mancanza di personale qualificato ci spinge verso una specializzazione rigorosa; come funghi dopo la pioggia, emergono varie Operations:<\/p>\n

<\/p>\n