🥇Chi sono i DevOps?

Attualmente, questa è quasi la posizione più costosa sul mercato. La frenesia attorno agli ingegneri «DevOps» supera ogni limite concepibile, e tanto peggio per gli ingegneri Senior DevOps.
Lavoro come responsabile del dipartimento di integrazione e automazione, e indovinate l'abbreviazione inglese — DevOps Manager. Riflette davvero l'abbreviazione inglese la nostra attività quotidiana? Difficilmente, ma la variante russa è più precisa in questo caso. Per il mio lavoro, è 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.

Siamo ancora alla ricerca di colleghi, perché dietro l'etichetta DevOps si nasconde uno strato molto ampio di ingegneri di vario tipo.

Tutto ciò che segue è la mia opinione personale, non siete obbligati ad accordarvi con essa, però ammetto che potrebbe influenzare il vostro atteggiamento verso l'argomento. Nonostante il rischio di suscitare disapprovazione, pubblico il mio punto di vista, poiché credo che abbia ragion d'essere.

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

Quindi, chi sono gli ingegneri DevOps?

Iniziamo con la storia dell'emergere delle Operations Development: questo è emerso come un ulteriore passo per ottimizzare la collaborazione nei piccoli team al fine di aumentare la velocità 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ì, 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à e il funzionamento dell'ambiente produttivo. Tuttavia, la complessità 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ù approfondita di determinati componenti, riducendo la produttività stessa dello sviluppatore a causa dei costi aggiuntivi per comprendere i componenti e ottimizzare i sistemi per compiti specifici. Il costo effettivo dello sviluppatore è aumentato, il costo del prodotto è aumentato di conseguenza e le richieste per nuovi sviluppatori nel team sono aumentate drasticamente, poiché era necessario anche coprire le responsabilità 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 è 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 è esattamente ciò che ha portato all'emergere dei DevOps nella percezione della maggior parte.

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ì 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".

È emersa una cosa "meravigliosa" — docker. Perché meravigliosa? Solo perché la creazione di isolamento in chroot o jail, così 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ì che l'amministratore di sistema gestisse solo un host, garantendone la sicurezza e l'alta disponibilità — un semplificazione logica. Ma il progresso non si ferma e i sistemi diventano nuovamente sempre più complessi, i componenti aumentano, un solo host non soddisfa più le esigenze del sistema ed è necessario costruire cluster, torniamo di nuovo agli amministratori di sistema, capaci di costruire tali sistemi.

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 è necessario allontanarsi dal processo standard. L'architettura a microservizi è emersa anche con l'obiettivo di semplificare tutto quanto detto sopra — meno interrelazioni, più facile da gestire. Nella mia esperienza, non ho mai visto completamente un'architettura a microservizi, direi 50 su 50 — 50 percento microservizi, scatole nere, quello che entra viene elaborato, i restanti 50 — un monolite lacerato, servizi incapaci di funzionare separatamente da altri componenti. Tutto ciò ha nuovamente imposto delle limitazioni sul livello di conoscenza sia degli sviluppatori che degli amministratori.

Questi «dondoli» 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.

Ingegnere di Build/Ingenger di Release

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ù richiesti, ma non è affatto così. Questa specializzazione è 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é 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à, nel tempo si sono trasformati in un freno ai cambiamenti, poiché seguire gli standard di qualità rallenta inevitabilmente le consegne. Così, gradualmente, parte delle funzioni degli ingegneri di Build/Release è stata trasferita sulle spalle degli amministratori di sistema.

Ops così diversi

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:

TechOps — amministratori di sistema che forniscono assistenza aka HelpDesk Engineer
LiveOps — amministratori di sistema, principalmente responsabili degli ambienti produttivi
CloudOps — amministratori di sistema specializzati in «cloud» pubblici come Azure, AWS, GCP, ecc.
PlatOps/InfraOps/SysOps — amministratori di sistema per l'infrastruttura.
NetOps — amministratori di rete
SecOps — amministratori di sistema specializzati in sicurezza informatica — conformità PCI, conformità CIS, aggiornamenti, ecc.

DevOps - (in teoria) una persona che comprende a menadito tutti i processi del ciclo di sviluppo - sviluppo, testing, comprendendo l'architettura del prodotto, capace di valutare i rischi per la sicurezza, familiare con gli approcci e gli strumenti di automazione, almeno a un livello elevato, e inoltre comprensiva anche del supporto pre e post-rilascio del prodotto. Una persona che può fungere da avvocato sia per le Operations che per lo sviluppo, il che consente di costruire una collaborazione proficua tra questi due pilastri. Comprende i processi di pianificazione del lavoro dei team e la gestione delle aspettative del cliente.

Per svolgere questo tipo di lavoro e responsabilità, questa persona deve avere gli strumenti per gestire non solo i processi di sviluppo e testing, ma anche la gestione dell'infrastruttura del prodotto e la pianificazione delle risorse. In questa accezione, DevOps non può trovarsi né nell'IT, né nell'R&D, né addirittura nel PMO; deve avere influenza in tutti questi ambiti: direttore tecnico dell'azienda, Chief Technical Officer.

È così nella vostra azienda? - Dubito. Nella maggior parte dei casi si tratta o di IT, o di R&D.

La mancanza di mezzi e di possibilità di influenzare anche solo uno di questi tre ambiti porterà a uno spostamento del peso dei problemi verso la direzione in cui è più facile applicare tali cambiamenti, come ad esempio l'applicazione di limitazioni tecniche sulle versioni a causa di codice "sporco" secondo i dati dei sistemi di analisi statica. Ovvero, quando il PMO fissa una scadenza rigida per il rilascio di funzionalità, l'R&D non può fornire risultati di qualità in tali tempi e li produce come può, rimandando il refactoring a dopo; DevOps riferito all'IT, con mezzi tecnici, blocca il rilascio. La mancanza di poteri per cambiare la situazione, nel caso dei dipendenti responsabili, porta a manifestazioni di iper-responsabilità per cose su cui non possono influire, specialmente se questi dipendenti comprendono e vedono gli errori e come correggerli — "La felicità è nell'ignoranza", e di conseguenza porta a esaurimento e perdita di questi dipendenti.

Mercato delle risorse DevOps

Diamo un'occhiata a diverse offerte di lavoro per la posizione di DevOps da diverse aziende.

Siamo pronti a incontrarvi se:

Conoscete Zabbix e sapete cosa sia Prometheus;

Iptables;

Studente laureato in BASH;

Professore di Ansible;

Guru di Linux;

Sai utilizzare il debug e collaborare con gli sviluppatori per trovare problemi nelle applicazioni (php/java/python);

Il routing non ti fa venire crisi di nervi;

Dedichi attenzione alla sicurezza del sistema;

Fai il backup di "tutto e di tutti", oltre a riuscire a ripristinare "tutto e di tutti";

Sai configurare il sistema per ottenere il massimo dal minimo;

Imposti le repliche prima di andare a dormire su Postgres e MySQL;

La configurazione e la correzione del CI/CD sono per te una necessità come colazione/pranzo/cena.

Hai esperienza con AWS;

Sei pronto a crescere insieme all'azienda;

Ecco:

dal 1 al 6 - amministratore di sistema
7 - un po' di amministrazione di rete, che rientra nel livello di amministrazione di sistema, livello Middle
8 - un po' di sicurezza, che è obbligatoria per un amministratore di sistema di livello Middle
9-11 - Middle System Administrator
12 - A seconda dei compiti assegnati, sia Middle System Administrator che Build Engineer
13 - Virtualizzazione - Middle System Administrator, oppure il cosiddetto CloudOps, conoscenze avanzate su servizi specifici hosting della piattaforma, per un uso efficace delle risorse finanziarie e una riduzione del carico sulla manutenzione

Riassumendo questa posizione, si può dire che ai ragazzi serve un Middle/Senior System Administrator.

Tra l'altro, non è necessario separare troppo gli amministratori in Linux/Windows. Certo, capisco che i servizi e i sistemi di questi due mondi differiscono, ma le basi sono comuni e ogni amministratore rispettabile è familiare con entrambi, e anche se non lo fosse, per un amministratore competente non è difficile familiarizzare con l'altro.

Consideriamo un'altra posizione:

Esperienza nella costruzione di sistemi ad alto carico;

Ottima conoscenza dei sistemi operativi Linux, software di sistema e stack web (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);

Esperienza con sistemi di virtualizzazione (KVM, VMWare, LXC/Docker);

Conoscenza dei linguaggi di scripting;

Comprensione dei principi di funzionamento dei protocolli di rete;

Comprensione dei principi di costruzione di sistemi ad alta disponibilità;

Autonomia e iniziativa;

Esaminiamo:

1 - Senior System Administrator
2 - A seconda del significato attribuito a questo stack - Middle/Senior System Administrator
3 - L'esperienza lavorativa può anche significare - "Non ho alzato il cluster, ma ho creato e gestito virtual machine, avevo un host Docker, l'accesso ai container era configurato" - Middle System Administrator
4 — Junior System Administrator — sì, un amministratore che non sa scrivere semplici script di automazione, a prescindere dal linguaggio, non è un amministratore — è un semplice tecnico.
5 — Middle System Administrator
6 — Senior System Administrator

Riassumendo — Middle/Senior System Administrator

Un'altra:

Esperienza di lavoro devops;

Esperienza nell'utilizzo di uno o più prodotti per la formazione di processi CI/CD. Gitlab CI è un vantaggio;

Lavorare con contenitori e virtualizzazione; Se hai usato docker – va bene, ma se hai usato k8s – ottimo!

Esperienza di lavoro in team agile;

Conoscenza di un qualsiasi linguaggio di programmazione;

Vediamo:

1 — Hmm... Cosa intendono i ragazzi? =) Probabilmente non sanno nemmeno loro cosa si nasconde dietro.
2 — Build Engineer
3 — Middle System Administrator
4 — Soft-skill, per ora non consideriamo, anche se Agile è un'altra cosa che viene interpretata come fa comodo.
5 — Troppo vago — potrebbe essere un linguaggio di script o compilato. Mi chiedo, se ho scritto a scuola in Pascal e Basic, andrà bene? =)

Vorrei anche fare un commento riguardo al punto 3, per rafforzare la comprensione del perché questo punto è coperto dall'amministratore di sistema. Kubernetes è solo orchestrazione, uno strumento che avvolge i comandi diretti ai driver di rete e agli host di virtualizzazione/isolamento in pochi comandi e permette di rendere la comunicazione con essi astratta, tutto qui. Prendiamo ad esempio il 'build framework' Make, che io, a proposito, non considero un framework. Sì, so della moda di infilare Make ovunque, dove necessario e non — avvolgere Maven in Make ad esempio, sul serio?
Essenzialmente Make è solo un involucro sopra il shell, semplificando proprio i comandi di compilazione, linking, ambiente di compilazione, proprio come k8s.

Una volta ho intervistato un ragazzo che usava k8s nel suo lavoro sopra OpenStack, e raccontava come distribuiva i servizi su di esso, però, quando ho chiesto proprio di OpenStack, si è scoperto che veniva amministrato, così come veniva avviato dagli amministratori di sistema. Davvero pensate che una persona che ha alzato OpenStack, a prescindere dalla piattaforma che usa dietro di esso, non sia capace di utilizzare k8s?=)
Questo candidato in realtà non è un DevOps, ma un normale Amministratore di Sistema e, per essere più precisi, un Kubernetes Administrator.

Riassumiamo ancora una volta — Middle/Senior System Administrator sarà sufficiente per loro.

Quanto pesa in grammi

Scostamento delle retribuzioni proposte per le posizioni indicate — 90k-200k
Ora vorrei fare un parallelo tra le retribuzioni dei Sistemisti e degli Ingegneri DevOps.

In linea di principio, per semplificare si possono suddividere i livelli in base all'esperienza lavorativa, anche se non sarà preciso, per gli scopi dell'articolo va bene così.

Esperienza:

fino a 3 anni — Junior
fino a 6 anni — Middle
più di 6 anni — Senior

Il sito di ricerca personale offre:
Sistemisti:

Junior — 2 anni — 50k rub.
Middle — 5 anni — 70k rub.
Senior — 11 anni — 100k rub.

Ingegneri DevOps:

Junior — 2 anni — 100k rub.
Middle — 3 anni — 160k rub.
Senior — 6 anni — 220k rub.

Per l'esperienza dei DevOps è stato considerato solo il tempo speso in attività che in qualche modo toccano il SDLC.

Da quanto sopra ne deriva che in realtà le aziende non hanno bisogno di DevOps e che potrebbero risparmiare almeno il 50% dei costi inizialmente pianificati assumendo un Amministratore; inoltre, avrebbero potuto definire più chiaramente i compiti della persona ricercata e soddisfare le esigenze più rapidamente. Non bisogna dimenticare che una chiara divisione delle responsabilità consente di ridurre i requisiti per il personale e creare un'atmosfera più favorevole nel team, a causa della mancanza di sovrapposizioni. Nella stragrande maggioranza delle offerte di lavoro si vedono strumenti e etichette DevOps, che però non si basano su reali esigenze per un Ingegnere DevOps, ma solo su richieste per un amministratore di strumenti.

Il processo di formazione degli ingegneri DevOps è anche limitato a un insieme specifico di compiti e strumenti, non fornendo una comprensione generale dei processi e delle loro dipendenze. È senza dubbio positivo che una persona possa usare Terraform per distribuite AWS EKS, in combinazione con il sidecar Fluentd in questo cluster e lo stack AWS ELK per il sistema di logging in 10 minuti, usando solo un comando nel terminale, ma se non comprende il principio di elaborazione dei log e a cosa servono, non sa come raccogliere metriche e monitorare la degradazione del servizio, allora sarà sempre lo stesso tecnico che sa solo usare alcuni strumenti.

La domanda, tuttavia, genera offerta, e vediamo un mercato estremamente surriscaldato per la posizione di DevOps, dove le esigenze non corrispondono al ruolo reale, ma permettono solo ai sistemisti di guadagnare di più.

Quindi chi sono? DevOps o avidi sistemisti? =)

Come procedere?

Ai datori di lavoro – formulare in modo più preciso i requisiti e cercare esattamente ciò di cui si ha bisogno, invece di disperdere il tempo con etichette. Se non sapete cosa fanno i DevOps, non vi servono in questo caso.

Ai lavoratori – Studiare. Migliorare costantemente le proprie conoscenze, osservare il quadro complessivo dei processi e monitorare il percorso verso l'obiettivo stabilito. Si può diventare chiunque si desideri, basta impegnarsi.

Fonte: habr.com