{"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 quasi la posizione pi\u00f9 costosa sul mercato. La frenesia intorno agli ingegneri \"DevOps\" supera ogni limite immaginabile, e la situazione \u00e8 ancora pi\u00f9 grave con gli ingegneri Senior DevOps.
\nLavoro come responsabile del dipartimento di integrazione e automazione, e indovinate l'abbreviazione inglese \u2014 DevOps Manager. Riflette davvero l'abbreviazione inglese la nostra attivit\u00e0 quotidiana? Difficilmente, ma la variante russa \u00e8 pi\u00f9 precisa in questo caso. Per il mio lavoro, \u00e8 naturale che debba intervistare i potenziali membri del mio team e, nell'ultimo anno, ho visto passare circa 50 persone, e altrettante sono state scartate durante il prescreening con i miei collaboratori.<\/p>\n

<\/p>\n

Siamo ancora alla ricerca di colleghi, perch\u00e9 dietro l'etichetta DevOps si nasconde uno strato molto ampio di ingegneri di vario tipo.<\/a><\/noindex><\/p>\n

<\/p>\n

Tutto ci\u00f2 che segue \u00e8 la mia opinione personale, non siete obbligati ad accordarvi con essa, per\u00f2 ammetto che potrebbe influenzare il vostro atteggiamento verso l'argomento. Nonostante il rischio di suscitare disapprovazione, pubblico il mio punto di vista, poich\u00e9 credo che abbia ragion d'essere.<\/p>\n

<\/p>\n

Le aziende comprendono in modo diverso chi siano gli ingegneri DevOps e, per facilitare una rapida assunzione, appiccicano questa etichetta a tutti. La situazione \u00e8 piuttosto strana, poich\u00e9 le aziende sono pronte a pagare retribuzioni incredibili a queste persone, ottenendo nella maggior parte dei casi solo un amministratore di strumenti.<\/p>\n

<\/p>\n

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

<\/p>\n

Iniziamo con la storia dell'emergere delle Operations Development: questo \u00e8 emerso come un ulteriore passo per ottimizzare la collaborazione nei piccoli team al fine di aumentare la velocit\u00e0 di produzione del prodotto, come conseguenza attesa. L'idea era quella di rafforzare il team di sviluppo con la conoscenza delle procedure e degli approcci nella gestione dell'ambiente di prodotto. In altre parole, uno sviluppatore deve comprendere e sapere come funziona il suo prodotto in determinate condizioni, deve sapere come implementare il suo prodotto, quali caratteristiche dell'ambiente modificare per aumentare le prestazioni. Cos\u00ec, per un certo periodo, sono emersi sviluppatori con un approccio DevOps. Gli sviluppatori DevOps scrivevano script di costruzione e imballaggio per semplificare le loro attivit\u00e0 e il funzionamento dell'ambiente produttivo. Tuttavia, la complessit\u00e0 dell'architettura delle soluzioni e l'interazione reciproca tra i componenti dell'infrastruttura hanno cominciato a deteriorare le prestazioni degli ambienti, richiedendo iterazione dopo iterazione una comprensione sempre pi\u00f9 approfondita di determinati componenti, riducendo la produttivit\u00e0 stessa dello sviluppatore a causa dei costi aggiuntivi per comprendere i componenti e ottimizzare i sistemi per compiti specifici. Il costo effettivo dello sviluppatore \u00e8 aumentato, il costo del prodotto \u00e8 aumentato di conseguenza e le richieste per nuovi sviluppatori nel team sono aumentate drasticamente, poich\u00e9 era necessario anche coprire le responsabilit\u00e0 delle 'stelle' dello sviluppo, e naturalmente le 'stelle' diventavano sempre meno disponibili. Vale anche la pena notare che, secondo la mia esperienza, pochi sviluppatori sono interessati alle specifiche dell'elaborazione dei pacchetti da parte del kernel del sistema operativo, alle regole di instradamento dei pacchetti e agli aspetti di sicurezza dell'host. Un passo logico \u00e8 stato quello di coinvolgere un amministratore, che conosceva esattamente questo, e di trasferire a lui compiti di tale tipo, il che, grazie alla sua esperienza, ha permesso di raggiungere gli stessi risultati a un costo inferiore rispetto a quello della 'stella' dello sviluppo. Questi amministratori sono stati inseriti nella squadra e il loro compito principale era gestire gli ambienti di test e di produzione, secondo le regole di un determinato team, con le risorse assegnate specificamente a quel team. Questo \u00e8 esattamente ci\u00f2 che ha portato all'emergere dei DevOps nella percezione della maggior parte.<\/p>\n

<\/p>\n

Parzialmente o completamente, nel corso del tempo, questi amministratori di sistema hanno cominciato a comprendere le esigenze di questo specifico team di sviluppo, su come semplificare la vita a sviluppatori e tester, come rilasciare un aggiornamento senza dover passare la notte in ufficio il venerd\u00ec a correggere errori di deployment. Il tempo passava, ora sono diventati \"stelle\" gli amministratori di sistema che capiscono cosa vogliono gli sviluppatori. Con l'obiettivo di minimizzare l'impatto, hanno iniziato ad emergere strumenti di gestione, tutti hanno ricordato i vecchi e affidabili metodi di isolamento a livello di OS, che consentivano di ridurre al minimo i requisiti di sicurezza, gestione della rete e configurazione dell'host in generale e, di conseguenza, ridurre i requisiti per le nuove \"stelle\". <\/p>\n

<\/p>\n

\u00c8 emersa una cosa \"meravigliosa\" \u2014 docker. Perch\u00e9 meravigliosa? Solo perch\u00e9 la creazione di isolamento in chroot o jail, cos\u00ec come OpenVZ, richiedeva una conoscenza non banale del sistema operativo, mentre la controparte dell'utility consentiva di creare facilmente un ambiente isolato per l'applicazione su un host con tutto il necessario all'interno e di restituire le redini dello sviluppo, cos\u00ec che l'amministratore di sistema gestisse solo un host, garantendone la sicurezza e l'alta disponibilit\u00e0 \u2014 un semplificazione logica. Ma il progresso non si ferma e i sistemi diventano nuovamente sempre pi\u00f9 complessi, i componenti aumentano, un solo host non soddisfa pi\u00f9 le esigenze del sistema ed \u00e8 necessario costruire cluster, torniamo di nuovo agli amministratori di sistema, capaci di costruire tali sistemi.<\/p>\n

<\/p>\n

Ciclo dopo ciclo, emergono vari sistemi che semplificano lo sviluppo e\/o l'amministrazione, compaiono i sistemi di orchestrazione, i quali sono semplici da usare fino a quando non \u00e8 necessario allontanarsi dal processo standard. L'architettura a microservizi \u00e8 emersa anche con l'obiettivo di semplificare tutto quanto detto sopra \u2014 meno interrelazioni, pi\u00f9 facile da gestire. Nella mia esperienza, non ho mai visto completamente un'architettura a microservizi, direi 50 su 50 \u2014 50 percento microservizi, scatole nere, quello che entra viene elaborato, i restanti 50 \u2014 un monolite lacerato, servizi incapaci di funzionare separatamente da altri componenti. Tutto ci\u00f2 ha nuovamente imposto delle limitazioni sul livello di conoscenza sia degli sviluppatori che degli amministratori.<\/p>\n

<\/p>\n

Questi \u00abdondoli\u00bb del livello di conoscenze esperte di una risorsa continua ancora oggi. Ma ci siamo un po' distratti, ci sono tanti aspetti che vale la pena illuminare.<\/p>\n

<\/p>\n

Ingegnere di Build\/Ingenger di Release<\/h2>\n

<\/p>\n

Ingegneri altamente specializzati, emersi come strumento di standardizzazione dei processi di compilazione del software e delle sue versioni. Con l'introduzione dell'Agile, sembrava che non fossero pi\u00f9 richiesti, ma non \u00e8 affatto cos\u00ec. Questa specializzazione \u00e8 emersa come mezzo di standardizzazione per la compilazione e la distribuzione del software su larga scala, utilizzando tecniche standard per tutti i prodotti dell'azienda. Con l'emergere del DevOps, gli sviluppatori hanno perso parzialmente alcune funzioni, poich\u00e9 sono diventati loro a preparare il prodotto per la distribuzione, e considerando l'infrastruttura in continua evoluzione e l'approccio a una distribuzione rapida senza prestare attenzione alla qualit\u00e0, nel tempo si sono trasformati in un freno ai cambiamenti, poich\u00e9 seguire gli standard di qualit\u00e0 rallenta inevitabilmente le consegne. Cos\u00ec, gradualmente, parte delle funzioni degli ingegneri di Build\/Release \u00e8 stata trasferita sulle spalle degli amministratori di sistema.<\/p>\n

<\/p>\n

Le varianti di Ops sono molteplici<\/h2>\n

<\/p>\n

Avanziamo e ancora una volta la presenza di un ampio insieme di doveri e la mancanza di personale qualificato ci spinge verso una specializzazione severa, come funghi dopo la pioggia, emergono diverse Operations:<\/p>\n

<\/p>\n