🥇Chi sono i DevOps?

Attualmente, è quasi la posizione più costosa sul mercato. L'hype attorno agli ingegneri 'DevOps' supera ogni limite immaginabile, e la situazione è ancor peggiore per gli ingegneri Senior DevOps.
Lavoro come responsabile del dipartimento di integrazione e automazione, indovinate l'acronimo inglese: DevOps Manager. Riflette realmente la nostra attività quotidiana? Probabilmente no, mentre la variante russa è più precisa in questo caso. Per la mia professione, è 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.

Siamo ancora alla ricerca di colleghi, perché dietro l'etichetta DevOps si nasconde un'ampia varietà di ingegneri di diversi tipi.

Tutto ciò che segue è 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é credo che meriti di essere condiviso.

Le aziende interpretano in modo diverso chi siano gli ingegneri DevOps e, per assumere rapidamente, etichettano chiunque con questo nome. La situazione è piuttosto strana, poiché 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.

Quindi, chi sono gli ingegneri DevOps?

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à 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à e il funzionamento dell'ambiente produttivo. Tuttavia, la complessità 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ù profonda di ciascun componente, riducendo la produttività 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ì come il costo del prodotto, e le richieste per l'ingresso di nuovi sviluppatori nel team sono aumentate drasticamente, poiché dovevano coprire anche le responsabilità delle 'stelle' dello sviluppo, che diventavano progressivamente sempre meno accessibili. Inoltre, per esperienza, raramente gli sviluppatori si interessano alla specificità 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, è stato logico coinvolgere un amministratore, esperto in questi ambiti, e delegargli queste responsabilità. Ciò 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ì sono nati i DevOps, nel concetto di molti.

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

È arrivata una «meravigliosa» novità: Docker. Perché meravigliosa? Perché la creazione di isolamento in chroot o jail, così come con OpenVZ, richiedeva conoscenze avanzate del sistema operativo. Con questo strumento, invece, è 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à — un semplificazione logica. Ma il progresso non si ferma e i sistemi diventano sempre più complessi, con un numero crescente di componenti. Un singolo host non soddisfa più le esigenze del sistema e diventa necessario costruire cluster. Ritorniamo così agli amministratori di sistema, che sono in grado di costruire queste architetture.

Ciclo dopo ciclo, emergono vari sistemi che semplificano lo sviluppo e/o l'amministrazione; emergono sistemi di orchestrazione, che, finché non è necessario allontanarsi dal processo standard, sono facili da usare. L'architettura a microservizi è emersa anche per semplificare tutto quanto sopra: meno interconnessioni, più 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% è un monolite strappato, servizi incapaci di funzionare indipendentemente dagli altri componenti. Tutto ciò ha nuovamente imposto restrizioni sul livello di conoscenza sia degli sviluppatori che degli amministratori.

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.

Build Engineer/Release Engineer

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

Gli Ops sono così diversi

Proseguiamo e nuovamente la presenza di un'ampia gamma di responsabilità e la mancanza di personale qualificato ci spinge verso una specializzazione rigorosa; come funghi dopo la pioggia, emergono varie Operations:

TechOps — amministratori di sistema e assistenti tecnici
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 dell'infrastruttura.
NetOps — amministratori di rete
SecOps — amministratori di sistema specializzati in sicurezza informatica — conformità PCI, conformità CIS, patching, ecc.

DevOps — (in teoria) una persona che comprende a menadito tutti i processi del ciclo di sviluppo — sviluppo, testing, comprende l'architettura del prodotto, capace di valutare i rischi per la sicurezza, conosce le metodologie e gli strumenti di automazione, almeno a un livello superiore, e comprende anche il supporto pre e post rilascio del prodotto. Una persona capace di fungere da intermediario tra Operations e Development, facilitando la cooperazione tra questi due pilastri. Comprendere i processi di pianificazione lavorativa delle squadre e la gestione delle aspettative dei clienti.

Per svolgere questo tipo di lavoro e responsabilità, questa persona deve avere i mezzi per gestire non solo i processi di sviluppo e testing, ma anche la gestione dell'infrastruttura del prodotto e la pianificazione delle risorse. In questo senso, il DevOps non può essere confinato né nell'IT, né nella R&D, né tantomeno nel PMO; deve avere influenza in tutte queste aree — un direttore tecnico dell'azienda, Chief Technical Officer.

È così anche nella vostra azienda? — Ho dei dubbi. Nella maggior parte dei casi, si tratta o di IT o di R&D.

La mancanza di fondi e di capacità di influenzare almeno uno di questi tre ambiti porterà a uno spostamento dell'attenzione verso aree dove tali cambiamenti possono essere applicati più facilmente, come ad esempio l'implementazione di limitazioni tecniche sulle versioni a causa di codice 'sporchè' secondo i dati dei sistemi di analisi statica. Così, quando il PMO stabilisce una scadenza rigida per il rilascio di funzionalità, R&D non riesce a fornire un risultato di qualità entro queste scadenze e produce ciò che può, rinviando il refactoring; DevOps, legato all'IT, blocca il rilascio con strumenti tecnici. La mancanza di poteri per modificare la situazione, nel caso dei dipendenti responsabili, porta all'emergere di iper-responsabilità per ciò su cui non possono influire, specialmente se questi dipendenti comprendono e vedono gli errori e come correggerli — 'La felicità sta nell'ignoranza', e, di conseguenza, a esaurimento e perdita di tali dipendenti.

Mercato delle risorse DevOps

Esaminiamo alcune offerte di lavoro per la posizione di DevOps provenienti da diverse aziende.

Siamo pronti a incontrarvi se:

Possedete Zabbix e sapete cos'è Prometheus;

Iptables;

Dottorando BASH;

Professore Ansible;

Guru Linux;

Sai utilizzare il debug e collaborare con gli sviluppatori per individuare i problemi delle applicazioni (php/java/python);

Il routing non ti fa andare in crisi;

Dedichi particolare attenzione alla sicurezza del sistema;

Esegui il backup di 'tutto e di più', e riesci a ripristinare con successo questo 'tutto e di più';

Sai configurare il sistema in modo da massimizzare le risorse disponibili;

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

Configurare e correggere il CI/CD per te è necessario come la colazione/pranzo/cena.

Hai esperienza con AWS;

Sei pronto a crescere insieme all'azienda;

Quindi:

dal 1 al 6 — amministratore di sistema
7 — un po' di amministrazione di rete, che si inserisce anch'essa nell'ambito dell'amministratore di sistema, livello Middle
8 — qualche nozione di sicurezza, fondamentale per un amministratore di sistema di livello Middle
9-11 — Middle System Administrator
12 — A seconda delle esigenze, potrebbe essere un Middle System Administrator oppure un Build Engineer
13 — Virtualizzazione — Middle System Administrator, o così detto CloudOps, conoscenze avanzate sui servizi specifici di hosting una piattaforma, per un utilizzo efficace delle risorse finanziarie e per ridurre il carico di lavoro.

In sintesi, per questa posizione possiamo dire che ai ragazzi basta essere un Sistemista di livello Middle/Senior.

Tra l'altro, non dovremmo dividere troppo gli amministratori in Linux/Windows. Capisco che i servizi e i sistemi di questi due mondi siano diversi, ma la base è comune e ogni amministratore rispettabile conosce sia l'uno che l'altro, e anche se non lo conosce, per un amministratore competente non sarà difficile apprendere.

Consideriamo un'altra posizione:

Esperienza nella costruzione di sistemi ad alta prestazione;

Ottima conoscenza del sistema operativo 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 di linguaggi di scripting;

Comprensione dei principi di funzionamento delle reti e dei protocolli di rete;

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

Autonomia e iniziativa;

Analizziamo:

1 — Sistemista Senior
2 — A seconda del significato attribuito a questo stack — Sistemista Middle/Senior
3 — L'esperienza lavorativa può anche significare — "Non ho creato il cluster, ma ho creato e gestito macchine virtuali, c'era un host Docker, ho configurato l'accesso ai container" — Sistemista Middle
4 — Junior System Administrator — sì, un amministratore che non sa scrivere script di automazione, indipendentemente dal linguaggio, non è un vero amministratore ma solo un esecutore.
5 — Middle System Administrator
6 — Senior System Administrator

In sintesi — Middle/Senior System Administrator

Un altro punto:

Esperienza nel lavoro DevOps;

Esperienza nell'uso di uno o più prodotti per l'implementazione di processi CI/CD. Gitlab CI è un vantaggio;

Lavoro con container e virtualizzazione; Se hai usato docker – ottimo, se k8s – ancora meglio!

Esperienza lavorando in un team agile;

Conoscenza di un linguaggio di programmazione qualsiasi;

Vediamo:

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

Vorrei anche fare una nota riguardo al punto 3, per rafforzare la comprensione del motivo per cui questo punto è coperto dall'amministratore di sistema. Kubernetes è semplicemente un'operazione di orchestrazione, uno strumento che incapsula i comandi diretti per i driver di rete e gli host di virtualizzazione/isolamento in un paio di comandi e consente di comunicare con essi in modo astratto, tutto qui. Per esempio, prendiamo il framework di costruzione Make, che non considero affatto un vero framework. Sì, sono consapevole della moda di infilare Make ovunque, dove è necessario e dove non lo è — avvolgere Maven in Make, per esempio, sul serio?
Fondamentalmente, Make è semplicemente un involucro sopra la shell, che semplifica in particolare i comandi di compilazione, di collegamento, e dell'ambiente di compilazione, proprio come fa k8s.

Una volta ho intervistato un ragazzo che utilizzava k8s nel suo lavoro sopra OpenStack, e lui raccontava come distribuiva i servizi su di esso, ma quando ho chiesto proprio di OpenStack, si è scoperto che veniva amministrato, così come veniva sollevato dagli amministratori di sistema. Davvero pensate che una persona che ha messo su OpenStack, indipendentemente dalla piattaforma che ha usato dietro di lui, non sia in grado di utilizzare k8s?=)
Questo candidato non è realmente un DevOps, ma un normale Amministratore di Sistema, per essere più precisi, un Amministratore Kubernetes.

Riassumendo ancora una volta: un Amministratore di Sistema di livello Middle/Senior sarà sufficiente.

Quanto peso in grammi

L'intervallo di stipendio offerto per le posizioni indicate varia da 90k a 200k.
Vorrei ora fare un parallelismo tra le retribuzioni degli Amministratori di Sistema e degli Ingegneri DevOps.

In linea di principio, per semplificare, si possono attribuire i gradi in base all'esperienza lavorativa, anche se non sarà preciso; per gli scopi dell'articolo sarà sufficiente.

Esperienza:

fino a 3 anni — Junior
fino a 6 anni — Middle
oltre 6 anni — Senior

Il sito per la ricerca di personale offre:
Amministratori di Sistema:

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 degli 'DevOps' è stata considerata una carriera che toccasse in qualche modo il SDLC.

Dallo sopraesposto si evince che, in realtà, le aziende non hanno bisogno di DevOps, e che avrebbero potuto risparmiare almeno il 50% dei costi inizialmente previsti assumendo un Amministratore. Inoltre, avrebbero potuto definire più chiaramente le responsabilità della persona ricercata e soddisfare più rapidamente le loro esigenze. Non bisogna dimenticare che una divisione chiara delle responsabilità permette di ridurre le richieste al personale e di creare un ambiente di lavoro più favorevole, grazie all'assenza di sovrapposizioni. Nella grande maggioranza delle offerte di lavoro si notano etichette di strumenti e DevOps, ma che non hanno realmente alla base esigenze di un DevOps Engineer, bensì richieste per un amministratore di strumenti.

Il processo di formazione degli ingegneri DevOps è limitato a un insieme specifico di attività e strumenti, senza fornire una comprensione generale dei processi e delle loro interrelazioni. Certo, è positivo che una persona possa utilizzare Terraform per deployare AWS EKS, insieme a un sidecar Fluentd in questo cluster e a una stack AWS ELK per il sistema di logging in 10 minuti, usando solo un comando nella console, ma se non capisce il principio stesso del trattamento dei log e a cosa servono, se non sa come raccogliere metriche sui log e monitorare la degradazione del servizio, rimarrà sempre un tecnico che sa usare solo alcune utilità.

La domanda, tuttavia, genera offerta, e vediamo un mercato estremamente surriscaldato per le posizioni DevOps, dove le richieste non corrispondono al ruolo reale, ma permettono solo agli amministratori di sistema di guadagnare di più.

Quindi, chi sono? DevOps o avidi amministratori di sistema? =)

Come andare avanti?

I datori di lavoro devono formulare con precisione le richieste e cercare esattamente le persone di cui hanno bisogno, invece di distribuire etichette. Se non sapete cosa fanno i DevOps, in questo caso non vi servono.

Ai lavoratori — Imparare. Perfezionare continuamente le proprie conoscenze, avere una visione d'insieme dei processi e monitorare il percorso verso l'obiettivo stabilito. Puoi diventare chi vuoi, basta solo impegnarsi.

Fonte: habr.com