🥇Chi sono i DevOps?

Al momento, questa è quasi la posizione più costosa sul mercato. Il clamore attorno agli ingegneri “DevOps” va oltre ogni limite immaginabile, ed è ancora peggio con gli ingegneri DevOps senior.
Lavoro come capo del dipartimento di integrazione e automazione, indovina la decodifica inglese: DevOps Manager. È improbabile che la trascrizione inglese rifletta le nostre attività quotidiane, ma la versione russa in questo caso è più accurata. A causa della natura della mia attività, è naturale che io abbia bisogno di intervistare i futuri membri del mio team e nell'ultimo anno sono passate da me circa 50 persone e lo stesso numero è stato escluso durante il prescreening con i miei dipendenti.

Stiamo ancora cercando colleghi, perché dietro l'etichetta DevOps si nasconde uno strato molto ampio di diversi tipi di ingegneri.

Tutto ciò che è scritto di seguito è la mia opinione personale, non devi essere d'accordo con essa, ma ammetto che aggiungerà un po' di colore al tuo atteggiamento nei confronti dell'argomento. Nonostante il rischio di cadere in disgrazia, pubblico la mia opinione perché credo che abbia un posto dove stare.

Le aziende hanno una comprensione diversa di chi siano gli ingegneri DevOps e, per il bene di assumere rapidamente una risorsa, appendono questa etichetta a tutti. La situazione è piuttosto strana, dal momento che le aziende sono pronte a pagare compensi irrealistici a queste persone, ricevendo, nella maggior parte dei casi, un amministratore dello strumento per loro.

Allora chi sono gli ingegneri DevOps?

Cominciamo con la storia della sua comparsa: le operazioni di sviluppo sono apparse come un altro passo verso l'ottimizzazione dell'interazione in piccoli team per aumentare la velocità di produzione del prodotto, come conseguenza prevista. L'idea era quella di rafforzare il team di sviluppo con la conoscenza delle procedure e degli approcci nella gestione dell'ambiente del prodotto. In altre parole, lo sviluppatore deve comprendere e sapere come funziona il suo prodotto in determinate condizioni, deve capire come implementare il suo prodotto, quali caratteristiche dell'ambiente possono essere modificate per migliorare le prestazioni. Quindi, per qualche tempo, sono comparsi sviluppatori con un approccio DevOps. Gli sviluppatori DevOps hanno scritto script di compilazione e confezionamento per semplificare le loro attività e le prestazioni dell'ambiente di produzione. Tuttavia, la complessità dell'architettura della soluzione e l'influenza reciproca dei componenti dell'infrastruttura nel tempo hanno cominciato a deteriorare le prestazioni degli ambienti; ad ogni iterazione, era richiesta una comprensione sempre più profonda di alcuni componenti, riducendo la produttività dello sviluppatore a causa del lavoro aggiuntivo costi per comprendere i componenti e i sistemi di ottimizzazione per un compito specifico. Il costo proprio dello sviluppatore è cresciuto, con esso anche il costo del prodotto, i requisiti per i nuovi sviluppatori nel team sono aumentati drasticamente, perché dovevano anche coprire le responsabilità della "stella" dello sviluppo e, naturalmente, le "stelle" sono diminuite e meno disponibile. 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. Il passo logico è stato quello di attrarre un amministratore che avesse familiarità con questo e assegnargli responsabilità simili, il che, grazie alla sua esperienza, ha permesso di raggiungere gli stessi indicatori a un costo inferiore rispetto al costo di uno sviluppo “a stella”. Tali amministratori venivano inseriti in un team e il loro compito principale era gestire gli ambienti di test e produzione, secondo le regole di un team specifico, con le risorse assegnate a questo particolare team. È così che, di fatto, DevOps è apparso nella mente della maggioranza.

Parzialmente o completamente, nel tempo, questi amministratori di sistema hanno iniziato a comprendere le esigenze di questo particolare team nel campo dello sviluppo, come semplificare la vita a sviluppatori e tester, come implementare un aggiornamento e non dover pernottare venerdì in l'ufficio, correggendo gli errori di distribuzione. Il tempo passava e ora le "star" erano amministratori di sistema che capivano cosa volevano gli sviluppatori. Per ridurre al minimo l'impatto, iniziarono ad apparire utilità di gestione; tutti ricordavano i vecchi e affidabili metodi di isolamento a livello di sistema operativo, che consentivano di ridurre al minimo i requisiti di sicurezza, la gestione della parte di rete e la configurazione dell'host come un nel loro insieme e, di conseguenza, ridurre i requisiti per nuove “stelle”.

È apparsa una cosa "meravigliosa": docker. Perché meraviglioso? Sì, solo perché creare l'isolamento in chroot o jail, così come OpenVZ, richiedeva una conoscenza non banale del sistema operativo, al contrario, l'utility consente semplicemente di creare un ambiente applicativo isolato su un determinato host con tutto il necessario all'interno e a portata di mano di nuovo le redini dello sviluppo e l'amministratore di sistema può gestire solo un host, garantendone la sicurezza e l'elevata disponibilità: una semplificazione logica. Ma il progresso non si ferma e i sistemi tornano a diventare sempre più complessi, ci sono sempre più componenti, un host non soddisfa più le esigenze del sistema ed è necessario costruire cluster, torniamo di nuovo agli amministratori di sistema che sono in grado di costruire questi sistemi.

Ciclo dopo ciclo compaiono vari sistemi che semplificano lo sviluppo e/o l'amministrazione, compaiono sistemi di orchestrazione che, finché non è necessario discostarsi dal processo standard, sono facili da usare. È apparsa anche l'architettura dei microservizi con l'obiettivo di semplificare tutto quanto sopra descritto: meno relazioni, più facile da gestire. Nella mia esperienza, non ho trovato un'architettura completamente a microservizi, direi dal 50 al 50: il 50% dei microservizi, scatole nere, entravano e uscivano elaborati, gli altri 50 sono un monolite strappato, servizi incapaci di funzionare separatamente dagli altri componenti. Tutto ciò ha nuovamente imposto restrizioni al livello di conoscenza sia degli sviluppatori che degli amministratori.

Simili “oscillazioni” nel livello di conoscenza approfondita di una particolare risorsa continuano ancora oggi. Ma divaghiamo un po’, ci sono molti punti che vale la pena sottolineare.

Ingegnere di costruzione/Ingegnere di rilascio

Ingegneri altamente specializzati emersi come mezzo per standardizzare i processi di creazione e rilascio del software. Nel processo di introduzione dell'Agile diffuso, sembrerebbe che abbiano cessato di essere richiesti, ma questo è tutt'altro che vero. Questa specializzazione è apparsa come un mezzo per standardizzare l'assemblaggio e la fornitura di software su scala industriale, ad es. utilizzando tecniche standard per tutti i prodotti aziendali. Con l'avvento di DevOps, gli sviluppatori hanno parzialmente perso le loro funzioni, poiché sono stati gli sviluppatori a iniziare a preparare il prodotto per la consegna e, dati i cambiamenti dell'infrastruttura e l'approccio alla consegna il più rapidamente possibile senza riguardo alla qualità, nel tempo si sono trasformati in un freno al cambiamento, poiché il rispetto degli standard di qualità rallenta inevitabilmente le consegne. Quindi, gradualmente, parte delle funzionalità degli ingegneri di Build/Release sono passate alle spalle degli amministratori di sistema.

Le operazioni sono così diverse

Andiamo avanti e ancora la presenza di una vasta gamma di responsabilità e la mancanza di personale qualificato ci spinge verso una rigorosa specializzazione, come i funghi dopo la pioggia compaiono varie Operazioni:

TechOps: amministratori di sistema enikey, ovvero HelpDesk Engineer
LiveOps: amministratori di sistema principalmente responsabili degli ambienti di produzione
CloudOps: amministratori di sistema specializzati in cloud pubblici Azure, AWS, GCP, ecc.
PlatOps/InfraOps/SysOps - amministratori di sistema dell'infrastruttura.
NetOps: amministratori di rete
SecOps - amministratori di sistema specializzati nella sicurezza delle informazioni - conformità PCI, conformità CIS, patching, ecc.

DevOps è (in teoria) una persona che comprende in prima persona tutti i processi del ciclo di sviluppo: sviluppo, test, comprende l'architettura del prodotto, è in grado di valutare i rischi per la sicurezza, ha familiarità con approcci e strumenti di automazione, almeno a un livello elevato livello, oltre a questo, comprende anche il supporto pre e post-elaborazione per il rilascio del prodotto. Una persona in grado di agire come difensore sia delle Operazioni che dello Sviluppo, il che consente una cooperazione favorevole tra questi due pilastri. Comprende i processi di pianificazione del lavoro da parte dei team e di 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 test, ma anche la gestione dell'infrastruttura del prodotto, nonché la pianificazione delle risorse. In questo senso, DevOps non può essere collocato né nell'IT, né nella ricerca e sviluppo, né nel PMO; deve avere influenza in tutte queste aree: il direttore tecnico dell'azienda, il Chief Technical Officer.

È vero nella tua azienda? - Dubito. Nella maggior parte dei casi si tratta di IT o di ricerca e sviluppo.

La mancanza di fondi e di capacità di influenzare almeno una di queste tre aree di attività sposterà il peso dei problemi dove questi cambiamenti sono più facili da applicare, come l’applicazione di restrizioni tecniche sui rilasci in connessione con codice “sporco” secondo norme statiche. sistemi di analisi. Cioè, quando il PMO fissa una scadenza rigorosa per il rilascio della funzionalità, la ricerca e sviluppo non può produrre un risultato di alta qualità entro queste scadenze e lo produce nel miglior modo possibile, lasciando il refactoring per dopo, DevOps relativo all'IT blocca il rilascio con mezzi tecnici . La mancanza di autorità per cambiare la situazione, nel caso di dipendenti responsabili, porta alla manifestazione di iperresponsabilità per ciò che non possono influenzare, soprattutto se questi dipendenti comprendono e vedono gli errori e come correggerli - "La felicità è ignoranza", e di conseguenza al burnout e alla perdita di questi dipendenti.

Mercato delle risorse DevOps

Diamo un'occhiata ai diversi posti vacanti per posizioni DevOps di diverse aziende.

Siamo pronti a incontrarti se:

Possiedi Zabbix e sai cos'è Prometeo;

Iptables;

Dottorando BASH;

Professor Ansible;

Guru di Linux;

Sapere come utilizzare il debug e trovare problemi applicativi insieme agli sviluppatori (php/java/python);

Il routing non ti rende isterico;

Prestare particolare attenzione alla sicurezza del sistema;

Eseguire il backup di "tutto e di tutto" e anche ripristinare con successo questo "tutto e di tutto";

Sai come configurare il sistema in modo tale da ottenere il massimo dal minimo;

Configura la replica prima di andare a letto su Postgres e MySQL;

L'impostazione e la regolazione di CI/CD sono necessarie quanto la colazione/pranzo/cena.

Avere esperienza con AWS;

Pronto a svilupparsi con l'azienda;

Quindi:

da 1 a 6 - amministratore di sistema
7 - una piccola amministrazione di rete, che rientra anche nell'amministratore di sistema, livello medio
8 - un po' di sicurezza, obbligatoria per un amministratore di sistema di livello medio
9-11 – Amministratore di sistema intermedio
12 — A seconda delle attività assegnate, amministratore di sistema intermedio o ingegnere di costruzione
13 - Virtualizzazione - Middle System Administrator, o il cosiddetto CloudOps, conoscenza avanzata dei servizi di uno specifico sito di hosting, per l'uso efficiente dei fondi e la riduzione del carico di manutenzione

Riassumendo questo posto vacante, possiamo dire che per i ragazzi è sufficiente l'Amministratore di sistema Middle/Senior.

A proposito, non dovresti dividere fortemente gli amministratori su Linux/Windows. Certo, capisco che i servizi e i sistemi di questi due mondi sono diversi, ma la base per tutti è la stessa e ogni amministratore che si rispetti conosce sia l'uno che l'altro, e anche se non ha familiarità, lo farà non sarà difficile per un amministratore competente prenderne dimestichezza.

Consideriamo un altro posto vacante:

Esperienza nella costruzione di sistemi ad alto carico;

Ottima conoscenza del sistema operativo Linux, del software di sistema generale e dello stack web (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);

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

Competenza nei linguaggi di scripting;

Comprensione dei principi di funzionamento delle reti con protocollo di rete;

Comprensione dei principi della costruzione di sistemi tolleranti ai guasti;

Indipendenza e iniziativa;

Guardiamo:

1 – Amministratore di sistema senior
2 - A seconda del significato inserito in questo stack: amministratore di sistema medio/senior
3 - Esperienza lavorativa, incluso, può significare: "Il cluster non ha creato, ma ha creato e gestito macchine virtuali, c'era un host Docker, l'accesso ai contenitori non era disponibile" - Amministratore di sistema centrale
4 - Amministratore di sistema junior - sì, un amministratore che non sa scrivere script di automazione di base, indipendentemente dalla lingua, non un amministratore - enikey.
5 - Amministratore di sistema intermedio
6 – Amministratore di sistema senior

Per riassumere: amministratore di sistema medio/senior

Ancora uno:

Esperienza Devops;

Esperienza nell'utilizzo di uno o più prodotti per creare processi CI/CD. Gitlab CI sarà un vantaggio;

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

Esperienza di lavoro in un team agile;

Conoscenza di qualsiasi linguaggio di programmazione;

Vedremo:

1 - Hmm... Cosa intendono i ragazzi? =) Molto probabilmente loro stessi non sanno cosa si nasconde dietro
2 - Ingegnere di costruzione
3 - Amministratore di sistema intermedio
4 - Soft skill, per ora non la consideriamo, anche se Agile è un'altra cosa che viene interpretata in modo conveniente.
5 - Troppo prolisso: potrebbe essere un linguaggio di scripting o compilato. Mi chiedo se scrivere in Pascal e Basic a scuola andrà bene per loro? =)

Vorrei lasciare anche una nota riguardo al punto 3 per rafforzare la comprensione del motivo per cui questo punto viene trattato dall'amministratore di sistema. Kubernetes è solo un'orchestrazione, uno strumento che racchiude i comandi diretti ai driver di rete e agli host di virtualizzazione/isolamento in un paio di comandi e consente di rendere astratta la comunicazione con loro, tutto qui. Ad esempio, prendiamo 'build framework' Make, che, tra l'altro, non considero un framework. Sì, conosco la moda di spingere Make ovunque, dove è necessario e non necessario, ad esempio avvolgendo Maven in Make, sul serio?
Essenzialmente, Make è solo un wrapper sulla shell, che semplifica i comandi di compilazione, collegamento e ambiente di compilazione, proprio come k8s.

Una volta ho intervistato un ragazzo che utilizzava k8 nel suo lavoro su OpenStack e mi ha parlato di come distribuiva i servizi su di esso, tuttavia, quando ho chiesto informazioni su OpenStack, ho scoperto che era amministrato e generato dal sistema amministratori. Pensi davvero che una persona che ha installato OpenStack, indipendentemente da quale piattaforma utilizzi alle sue spalle, non sia in grado di utilizzare k8s? =)
Questo candidato non è in realtà un DevOps, ma un amministratore di sistema e, per essere più precisi, un amministratore Kubernetes.

Riassumiamo ancora una volta: per loro sarà sufficiente un amministratore di sistema medio/senior.

Quanto appendere in grammi

La gamma di retribuzioni proposte per i posti vacanti indicati è compresa tra 90 e 200
Ora vorrei tracciare un parallelo tra le ricompense monetarie degli amministratori di sistema e degli ingegneri DevOps.

In linea di principio, per semplificare le cose, puoi disperdere i voti in base all'esperienza lavorativa, anche se questo non sarà esatto, ma ai fini dell'articolo sarà sufficiente.

esperienza:

fino a 3 anni – Junior
fino a 6 anni – Medio
più di 6 – Senior

Il sito di ricerca dei dipendenti offre:
Amministratori di sistema:

Junior - 2 anni - 50k rub.
Medio - 5 anni - 70k rub.
Senior - 11 anni - 100k rub.

Ingegneri DevOps:

Junior - 2 anni - 100k rub.
Medio - 3 anni - 160k rub.
Senior - 6 anni - 220k rub.

Secondo l’esperienza di “DevOps”, è stata utilizzata l’esperienza che almeno in qualche modo ha influenzato l’SDLC.

Da quanto sopra ne consegue che in realtà le aziende non hanno bisogno di DevOps, e anche che potrebbero risparmiare almeno il 50% dei costi inizialmente previsti assumendo un Amministratore; inoltre, potrebbero definire più chiaramente le responsabilità della persona che stanno cercando e soddisfare il bisogno più velocemente. Non dobbiamo inoltre dimenticare che una chiara divisione delle responsabilità ci consente di ridurre i requisiti di personale, nonché di creare un'atmosfera più favorevole nella squadra, grazie all'assenza di sovrapposizioni. La stragrande maggioranza dei posti vacanti è piena di utilità ed etichette DevOps, ma non si basano sui requisiti effettivi per un ingegnere DevOps, ma solo sulle richieste di un amministratore dello strumento.

Inoltre, il processo di formazione degli ingegneri DevOps è limitato solo a una serie di lavori e utilità specifici e non fornisce una comprensione generale dei processi e delle loro dipendenze. È sicuramente positivo quando una persona può distribuire AWS EKS utilizzando Terraform, insieme al sidecar Fluentd in questo cluster e allo stack AWS ELK per il sistema di registrazione in 10 minuti, utilizzando un solo comando nella console, ma se non capisce il principio di elaborazione stessa dei log e a cosa servono, se non sai come raccogliere parametri su di essi e tenere traccia del degrado del servizio, sarà comunque la stessa enikey a sapere come utilizzare alcune utilità.

La domanda, tuttavia, crea offerta e vediamo un mercato estremamente surriscaldato per la posizione DevOps, dove i requisiti non corrispondono al ruolo effettivo, ma consentono solo agli amministratori di sistema di guadagnare di più.

Allora chi sono? DevOps o avidi amministratori di sistema? =)

Come vivere ulteriormente?

I datori di lavoro dovrebbero formulare i requisiti in modo più preciso e cercare esattamente coloro che sono necessari, senza gettare etichette. Non sai cosa fanno i DevOps: in questo caso non ti servono.

Lavoratori: imparate. Migliora costantemente le tue conoscenze, osserva il quadro generale dei processi e segui il percorso verso il tuo obiettivo. Puoi diventare chi vuoi, devi solo provarci.

Fonte: habr.com

Chi sono i DevOps?