În acest moment, aceasta este aproape cea mai scumpă poziție de pe piață. Tam-tam în jurul inginerilor „DevOps” depășește toate limitele imaginabile și chiar mai rău cu inginerii seniori DevOps.
Lucrez ca șef al departamentului de integrare și automatizare, ghiciți decodarea engleză - DevOps Manager. Este puțin probabil ca transcrierea în limba engleză să reflecte activitățile noastre zilnice, dar versiunea rusă în acest caz este mai exactă. Datorită naturii activității mele, este firesc să am nevoie să intervievez viitorii membri ai echipei mele, iar în ultimul an au trecut prin mine aproximativ 50 de persoane, iar același număr a fost tăiat pe prescreen cu angajații mei.
Încă căutăm colegi, deoarece în spatele etichetei DevOps se ascunde un strat foarte mare de diferite tipuri de ingineri.
Tot ce scrie mai jos este părerea mea personală, nu trebuie să fii de acord cu ea, dar recunosc că va adăuga ceva culoare atitudinii tale față de subiect. În ciuda riscului de a cădea în disfavoare, îmi public părerea pentru că cred că are unde să fie.
Companiile au înțelegeri diferite despre cine sunt inginerii DevOps și, de dragul angajării rapide a unei resurse, pun această etichetă pe toată lumea. Situația este destul de ciudată, deoarece companiile sunt gata să plătească remunerații nerealiste acestor oameni, primind, în cele mai multe cazuri, un administrator de instrumente pentru ei.
Deci cine sunt inginerii DevOps?
Să începem cu istoria apariției sale - Operațiunile de Dezvoltare au apărut ca un alt pas spre optimizarea interacțiunii în echipe mici pentru a crește viteza de producție a produsului, ca o consecință așteptată. Ideea a fost de a consolida echipa de dezvoltare cu cunoștințe despre proceduri și abordări în gestionarea mediului de produs. Cu alte cuvinte, dezvoltatorul trebuie să înțeleagă și să cunoască cum funcționează produsul său în anumite condiții, trebuie să înțeleagă cum să-și implementeze produsul, ce caracteristici ale mediului pot fi ajustate pentru a îmbunătăți performanța. Deci, de ceva timp, au apărut dezvoltatori cu o abordare DevOps. Dezvoltatorii DevOps au scris scripturi de compilare și împachetare pentru a-și simplifica activitățile și performanța mediului de producție. Cu toate acestea, complexitatea arhitecturii soluției și influența reciprocă a componentelor infrastructurii de-a lungul timpului au început să deterioreze performanța mediilor; cu fiecare iterație, a fost necesară o înțelegere din ce în ce mai profundă a anumitor componente, reducând productivitatea dezvoltatorului datorită adiționalului. costurile de înțelegere a componentelor și sistemelor de reglare pentru o anumită sarcină. Costul propriu al dezvoltatorului a crescut, costul produsului împreună cu acesta, cerințele pentru noii dezvoltatori din echipă au sărit brusc, pentru că trebuiau să acopere și responsabilitățile „stelei” de dezvoltare și, firește, „stelele” au devenit mai puține. și mai puțin disponibile. De asemenea, este de remarcat faptul că, din experiența mea, puțini dezvoltatori sunt interesați de specificul procesării pachetelor de către nucleul sistemului de operare, regulile de rutare a pachetelor și aspectele de securitate a gazdei. Pasul logic a fost atragerea unui administrator familiarizat cu acest lucru și atribuirea lui de responsabilități similare, ceea ce, datorită experienței sale, a făcut posibilă realizarea acelorași indicatori la un cost mai mic în comparație cu costul unei dezvoltări „vedetă”. Astfel de administratori erau plasați într-o echipă, iar sarcina lui principală era să gestioneze mediile de testare și producție, conform regulilor unei echipe specifice, cu resurse alocate acestei echipe anume. Așa a apărut, de fapt, DevOps-ul în mintea majorității.
Parțial sau complet, de-a lungul timpului, acești administratori de sistem au început să înțeleagă nevoile acestei echipe în special în domeniul dezvoltării, cum să facă viața mai ușoară dezvoltatorilor și testerilor, cum să lanseze o actualizare și să nu fie nevoiți să rămână peste noapte vineri în birou, corectând erorile de desfășurare. Timpul a trecut, iar acum „stelele” erau administratori de sistem care au înțeles ce doreau dezvoltatorii. Pentru a minimiza impactul, au început să apară utilități de management; toată lumea și-a amintit metodele vechi și fiabile de izolare a nivelului de sistem de operare, care au făcut posibilă reducerea la minimum a cerințelor de securitate, managementul părții rețelei și configurația gazdei ca un întreg și, ca urmare, reduceți cerințele pentru noi „stele”.
A apărut un lucru „minunat” - docker. De ce minunat? Da, doar pentru că crearea izolării într-un chroot sau închisoare, precum și OpenVZ, a necesitat cunoștințe non-triviale despre sistemul de operare, în schimb, utilitarul vă permite să creați pur și simplu un mediu de aplicație izolat pe o anumită gazdă, cu tot ce este necesar în interior și în mână. peste frâiele dezvoltării din nou, iar administratorul de sistem se poate gestiona doar cu o singură gazdă, asigurându-i securitatea și disponibilitatea ridicată - o simplificare logică. Dar progresul nu stă pe loc și sistemele devin din nou din ce în ce mai complexe, există din ce în ce mai multe componente, o singură gazdă nu mai satisface nevoile sistemului și este necesar să construim clustere, revenim din nou la administratorii de sistem care sunt capabil să construiască aceste sisteme.
Ciclu după ciclu apar diverse sisteme care simplifică dezvoltarea și/sau administrarea, apar sistemele de orchestrare care, până când trebuie să devii de la procesul standard, sunt ușor de folosit. A apărut și arhitectura microservicii cu scopul de a simplifica tot ceea ce este descris mai sus - mai puține relații, mai ușor de gestionat. Din experiența mea, nu am găsit o arhitectură complet de microservicii, aș spune că 50 până la 50 - 50 la sută dintre microservicii, cutii negre, au intrat, au ieșit procesate, celelalte 50 sunt un monolit rupt, servicii care nu pot funcționa separat de celelalte componente. Toate acestea au impus din nou restricții asupra nivelului de cunoștințe atât al dezvoltatorilor, cât și al administratorilor.
„Modificări” similare ale nivelului de cunoștințe de specialitate a unei anumite resurse continuă până în prezent. Dar ne abatem puțin, sunt multe puncte care merită subliniate.
Inginer constructor/Inginer de lansare
Ingineri foarte specializați care au apărut ca un mijloc de standardizare a proceselor de construire a software-ului și a lansărilor. În procesul de introducere a Agile pe scară largă, s-ar părea că au încetat să mai fie solicitate, dar acest lucru este departe de a fi cazul. Această specializare a apărut ca un mijloc de standardizare a asamblarii și livrării de software la scară industrială, adică. folosind tehnici standard pentru toate produsele companiei. Odată cu apariția DevOps, dezvoltatorii și-au pierdut parțial funcțiile, deoarece dezvoltatorii au fost cei care au început să pregătească produsul pentru livrare și, având în vedere infrastructura în schimbare și abordarea de a livra cât mai repede posibil, fără a ține cont de calitate, în timp s-au transformat în un opritor al schimbărilor, deoarece respectarea standardelor de calitate încetinește inevitabil livrările. Deci, treptat, o parte din funcționalitatea inginerilor Build/Release a migrat pe umerii administratorilor de sistem.
Operațiunile sunt atât de diferite
Trecem și iarăși prezența unei game largi de responsabilități și lipsa personalului calificat ne împinge spre specializare strictă, ca ciupercile după ploaie, apar diverse Operațiuni:
- TechOps - administratori de sistem enikey alias HelpDesk Engineer
- LiveOps - administratorii de sistem responsabili în primul rând pentru mediile de producție
- CloudOps - administratori de sistem specializați în cloud-uri publice Azure, AWS, GCP etc.
- PlatOps/InfraOps/SysOps - administratori de sistem de infrastructură.
- NetOps - administratori de rețea
- SecOps - administratori de sistem specializați în securitatea informațiilor - conformare PCI, conformare CIS, corecție etc.
DevOps este (teoretic) o persoană care înțelege direct toate procesele ciclului de dezvoltare - dezvoltare, testare, înțelege arhitectura produsului, este capabil să evalueze riscurile de securitate, este familiarizat cu abordările și instrumentele de automatizare, cel puțin la un nivel ridicat. nivel, pe lângă aceasta, înțelege și pre- și post-procesare suport pentru lansarea produsului. O persoană capabilă să acționeze ca un avocat atât pentru Operațiuni, cât și pentru Dezvoltare, ceea ce permite o cooperare favorabilă între acești doi piloni. Înțelege procesele de planificare a muncii de către echipe și de gestionare a așteptărilor clienților.
Pentru a îndeplini acest tip de muncă și responsabilități, această persoană trebuie să aibă mijloacele necesare pentru a gestiona nu numai procesele de dezvoltare și testare, ci și managementul infrastructurii produsului, precum și planificarea resurselor. DevOps în această înțelegere nu poate fi localizat nici în IT, nici în R&D, nici chiar în PMO; trebuie să aibă influență în toate aceste domenii - directorul tehnic al companiei, Chief Technical Officer.
Este acest lucru adevărat în compania dumneavoastră? - Mă îndoiesc. În cele mai multe cazuri, acesta este fie IT, fie R&D.
Lipsa fondurilor și capacitatea de a influența cel puțin unul dintre aceste trei domenii de activitate vor muta ponderea problemelor către locurile în care aceste modificări sunt mai ușor de aplicat, cum ar fi aplicarea restricțiilor tehnice asupra versiunilor în legătură cu codul „murdar” conform static. sisteme de analiză. Adică, atunci când PMO stabilește un termen limită strict pentru lansarea funcționalității, R&D nu poate produce un rezultat de înaltă calitate în aceste termene limită și îl produce cât mai bine, lăsând refactorizarea pentru mai târziu, DevOps-ul legat de IT blochează lansarea prin mijloace tehnice. . Lipsa autorității de a schimba situația, în cazul angajaților responsabili, duce la manifestarea unei hiperresponsabilități pentru ceea ce nu pot influența, mai ales dacă acești angajați înțeleg și văd greșelile și cum să le corecteze - „Beatitudinea este ignoranța”, și ca urmare a epuizării și pierderii acestor angajați.
Piața de resurse DevOps
Să ne uităm la mai multe posturi vacante pentru posturi DevOps de la diferite companii.
Suntem gata să ne întâlnim cu tine dacă:
- Dețineți Zabbix și știți ce este Prometeu;
- Iptables;
- Doctorand BASH;
- profesorul Ansible;
- Linux Guru;
- Să știi cum să folosești depanarea și să găsești probleme de aplicație împreună cu dezvoltatorii (php/java/python);
- Rutarea nu te face isteric;
- Acordați o atenție deosebită securității sistemului;
- Faceți backup „orice și totul” și, de asemenea, restabiliți cu succes acest „orice și totul”;
- Stii sa configurezi sistemul in asa fel incat sa scoti maximul din minim;
- Configurați replicarea înainte de a merge la culcare pe Postgres și MySQL;
- Configurarea și ajustarea CI/CD este la fel de necesară pentru dvs. precum micul dejun/pranz/cina.
- Să aibă experiență cu AWS;
- Gata de dezvoltare cu compania;
Deci:
- de la 1 la 6 - administrator de sistem
- 7 - o mică administrare a rețelei, care se încadrează și în administratorul de sistem, nivel mediu
- 8 - puțină securitate, care este obligatorie pentru un administrator de sistem de nivel mediu
- 9-11 – Administrator de sistem mediu
- 12 — În funcție de sarcinile atribuite, fie Administrator de sistem mediu, fie Inginer de construcție
- 13 - Virtualizare - Administrator de sistem mediu, sau așa-numitul CloudOps, cunoaștere avansată a serviciilor unui anumit site de găzduire, pentru utilizarea eficientă a fondurilor și reducerea sarcinii de întreținere
Rezumând acest post vacant, putem spune că Administrator de sistem mediu/senior este suficient pentru băieți.
Apropo, nu ar trebui să divizați puternic administratorii pe Linux/Windows. Desigur, înțeleg că serviciile și sistemele acestor două lumi sunt diferite, dar baza pentru toate este aceeași și orice administrator care se respectă este familiarizat atât cu una, cât și cu cealaltă și, chiar dacă nu este familiarizat, va nu va fi dificil pentru un administrator competent să se familiarizeze cu el.
Să luăm în considerare un alt post vacant:
- Experienta in constructia sistemelor de incarcare mare;
- Cunoștințe excelente de sistem de operare Linux, software de sistem general și stiva web (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Experienta cu sisteme de virtualizare (KVM, VMWare, LXC/Docker);
- Cunostinte in limbaje de scripting;
- Înțelegerea principiilor de funcționare a rețelelor de protocol de rețea;
- Înțelegerea principiilor de construire a sistemelor tolerante la erori;
- Independență și inițiativă;
Să ne uităm la:
- 1 – Administrator principal de sistem
- 2 - În funcție de semnificația pusă în această stivă - Administrator de sistem mediu/senior
- 3 - Experiența de lucru, inclusiv, poate însemna - „Clusterul nu a creat, dar a creat și gestionat mașini virtuale, a existat o gazdă Docker, accesul la containere nu a fost disponibil” - Administrator de sistem mediu
- 4 - Junior System Administrator - da, un admin care nu știe să scrie scripturi de automatizare de bază, indiferent de limbă, nu un admin - enikey.
- 5 - Administrator de sistem mediu
- 6 – Administrator principal de sistem
Pentru a rezuma - Administrator de sistem mediu/senior
Încă unul:
- experiență Devops;
- Experiență în utilizarea unuia sau mai multor produse pentru a crea procese CI/CD. Gitlab CI va fi un avantaj;
- Lucrul cu containere și virtualizare; Dacă ai folosit docker, bine, dar dacă ai folosit k8s, grozav!
- Experiență de lucru într-o echipă agilă;
- Cunoașterea oricărui limbaj de programare;
Sa vedem:
- 1 - Hmm... Ce înseamnă băieții? =) Cel mai probabil, ei înșiși nu știu ce se ascunde în spatele ei
- 2 - Inginer constructor
- 3 - Administrator de sistem mediu
- 4 - Soft skill, nu o vom lua în considerare deocamdată, deși Agile este un alt lucru care este interpretat într-un mod convenabil.
- 5 - Prea verbos - ar putea fi un limbaj de scripting sau unul compilat. Mă întreb dacă li se va potrivi scrisul în Pascal și Basic la școală? =)
De asemenea, aș dori să las o notă cu privire la punctul 3 pentru a întări înțelegerea de ce acest punct este acoperit de administratorul de sistem. Kubernetes este doar o orchestrare, un instrument care include comenzi directe către driverele de rețea și gazdele de virtualizare/izolare în câteva comenzi și vă permite să faceți comunicarea cu ele abstractă, atâta tot. De exemplu, să luăm „build framework” Make, pe care, apropo, nu îl consider un cadru. Da, știu despre moda de a împinge Make oriunde, acolo unde este necesar și nu este necesar - împachetarea lui Maven în Make, de exemplu, serios?
În esență, Make este doar un wrapper peste shell, simplificând comenzile de compilare, legare și mediu de compilare, la fel ca k8s.
Odată, am intervievat un tip care a folosit k8s în munca sa pe lângă OpenStack și a vorbit despre modul în care a implementat serviciile pe acesta, totuși, când am întrebat despre OpenStack, s-a dovedit că acesta a fost administrat, precum și ridicat de sistem. administratori. Chiar crezi că o persoană care a instalat OpenStack, indiferent de platforma pe care o folosește în spatele lui, nu este capabilă să folosească k8s? =)
Acest solicitant nu este de fapt un DevOps, ci un administrator de sistem și, mai precis, un administrator Kubernetes.
Să rezumam încă o dată - Administratorul de sistem mediu/senior va fi suficient pentru ei.
Cât de mult să cântăriți în grame
Gama de salarii propuse pentru posturile vacante indicate este de 90k-200k
Acum aș dori să fac o paralelă între recompensele bănești ale administratorilor de sistem și ale inginerilor DevOps.
În principiu, pentru a simplifica lucrurile, puteți împrăștia notele pe baza experienței de muncă, deși acest lucru nu va fi exact, dar pentru scopurile articolului va fi suficient.
O experienta:
- până la 3 ani – Junior
- până la 6 ani – mijloc
- peste 6 – Senior
Site-ul de căutare de angajați oferă:
Administratori de sistem:
- Junior - 2 ani - 50k rub.
- Mijloc - 5 ani - 70k frec.
- Senior - 11 ani - 100k rub.
Ingineri DevOps:
- Junior - 2 ani - 100k rub.
- Mijloc - 3 ani - 160k frec.
- Senior - 6 ani - 220k rub.
Conform experienței „DevOps”, a fost folosită experiență care a afectat cel puțin cumva SDLC.
Din cele de mai sus rezultă că, de fapt, companiile nu au nevoie de DevOps și, de asemenea, că ar putea economisi cel puțin 50 la sută din costurile planificate inițial prin angajarea unui Administrator; în plus, ar putea defini mai clar responsabilitățile persoanei pe care o caută. și umple nevoia mai repede. De asemenea, nu trebuie să uităm că o împărțire clară a responsabilităților ne permite să reducem cerințele de personal, precum și să creăm o atmosferă mai favorabilă în echipă, datorită absenței suprapunerilor. Marea majoritate a posturilor vacante sunt pline de utilități și etichete DevOps, dar nu se bazează pe cerințele reale pentru un inginer DevOps, ci doar pe cereri pentru un administrator de instrumente.
Procesul de formare a inginerilor DevOps este, de asemenea, limitat doar la un set de lucrări specifice, utilități și nu oferă o înțelegere generală a proceselor și a dependențelor acestora. Este cu siguranță bine când o persoană poate implementa AWS EKS folosind Terraform, împreună cu sidecar-ul Fluentd din acest cluster și stiva AWS ELK pentru sistemul de înregistrare în 10 minute, folosind o singură comandă în consolă, dar dacă nu înțelege principiul procesării în sine a jurnalelor și pentru ce sunt necesare, dacă nu știți cum să colectați valori pentru ele și să urmăriți degradarea serviciului, atunci va fi în continuare același enikey care știe să folosească unele utilități.
Cererea, însă, creează ofertă și vedem o piață extrem de supraîncălzită pentru poziția DevOps, unde cerințele nu corespund rolului real, ci doar permit administratorilor de sistem să câștige mai mult.
Deci cine sunt ei? DevOps sau administratori de sistem lacomi? =)
Cum să trăiești în continuare?
Angajatorii ar trebui să formuleze cerințe mai precis și să caute exact pe cei de care este nevoie, și să nu arunce etichete. Nu știți ce fac DevOps - nu aveți nevoie de ele în acest caz.
Muncitori - Învață. Îmbunătățiți-vă constant cunoștințele, priviți imaginea de ansamblu a proceselor și urmăriți calea către obiectivul dvs. Poți deveni oricine vrei, trebuie doar să încerci.
Sursa: www.habr.com