În prezent, aceasta este aproape cea mai scumpă poziție de pe piață. Hype-ul din jurul inginerilor „DevOps” depășește toate limitele imaginabile, iar lucrurile sunt și mai dificile cu inginerii Senior DevOps.
Lucrez ca șef al departamentului de integrare și automatizare, ghiciți traducerea în engleză — DevOps Manager. Reflectă oare exact traducerea în engleză activitățile noastre zilnice — în niciun caz, însă varianta în rusă este în acest caz mai exactă. Din natura activității mele, este evident că trebuie să intervievez viitorii membri ai echipei mele și, în ultimul an, aproximativ 50 de persoane au trecut prin fața mea, iar încă atât de multe au fost eliminate în pre-scriere cu colaboratorii mei.
Încă suntem în căutarea de colegi, deoarece sub eticheta DevOps se ascunde un strat foarte mare de diferite tipuri de ingineri.
Tot ceea ce este scris mai jos este doar opinia mea personală, nu sunteți obligați să fiți de acord cu ea, totuși admit că ar putea adăuga o nuanță în percepția dumneavoastră asupra subiectului. În ciuda riscului de a cădea în dizgrație, public opinia mea, deoarece consider că are un loc de a fi.
Companiile înțeleg diferit cine sunt inginerii DevOps și, pentru a angaja rapid resurse, lipește această etichetă tuturor. Situația este destul de ciudată, deoarece companiile sunt dispuse să plătească recompense nerealiste acestor persoane, obținând pentru ele, în cele mai multe cazuri, un administrator-toolist.
Atunci, cine sunt inginerii DevOps?
Să începem cu istoria apariției — Development Operations a apărut ca un pas suplimentar în optimizarea interacțiunii în echipe mici pentru a spori viteza de producție a produselor, ca o consecință așteptată. Ideea era de a întări echipa de dezvoltare cu cunoștințe despre procedurile și abordările din managementul mediului de produs. Cu alte cuvinte, un dezvoltator trebuie să înțeleagă și să știe cum funcționează produsul său în diferite condiții, trebuie să înțeleagă cum să îl desfășoare, ce caracteristici ale mediului să ajusteze pentru a îmbunătăți performanța. Astfel, în decursul timpului, au apărut dezvoltatori cu o abordare DevOps. Dezvoltatorii DevOps scriau scripturi de construire și ambalare pentru a-și simplifica activitatea și operarea mediului de producție. Totuși, complexitatea arhitecturii soluțiilor și interacțiunea reciprocă a componentelor infrastructurii au început să afecteze performanțele mediilor; cu fiecare iterație, erau necesare înțelegeri tot mai profunde ale diferitelor componente, reducând productivitatea dezvoltatorului din cauza costurilor suplimentare pentru înțelegerea componentelor și tuning-ul sistemelor pentru sarcini specifice. Costul propriu-zis al dezvoltatorului a crescut, costul produsului odată cu el, cererea pentru noi dezvoltatori din echipă a crescut drastic, având în vedere că aceștia trebuiau să îndeplinească și responsabilitățile „starului” dezvoltării, iar, bineînțeles, „starurile” deveneau din ce în ce mai puțin accesibile. De asemenea, 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, aspectele de securitate ale gazdelor. O măsură logică a fost să angajeze un administrator care să fie familiarizat cu acest lucru și să încredințeze acest tip de responsabilități, ceea ce, datorită experienței sale, a permis atingerea unor indicatori similari la un cost mai mic în comparație cu costul „starului” dezvoltării. Aceștia erau integrați în echipă, iar principalul său obiectiv era gestionarea mediilor de testare și de producție, conform regulilor echipei respective, cu resursele alocate specific acestei echipe. Astfel, au apărut DevOps în viziunea majorității.
Parțial sau complet, în timp, acești administratori de sistem au început să înțeleagă nevoile acestei echipe specifice în dezvoltare, cum să le simplifice viața dezvoltatorilor și testerilor, cum să gestioneze actualizările și să nu rămână să îndrepte greșelile de implementare vineri noapte la birou. Timpul a trecut, iar administratorii de sistem au devenit „staruri”, înțelegând ceea ce își doresc dezvoltatorii. Cu scopul de a minimiza impactul, au început să apară utilitățile de gestionare, iar toți și-au amintit metodele vechi și de încredere de izolare la nivel de sistem de operare, care permiteau minimizarea cerințelor de securitate, gestionarea rețelei și chiar a configurației gazdelor în ansamblu, și, prin urmare, reducerea cerințelor pentru noile „staruri”.
A apărut un lucru „minunat” — docker. De ce minunat? Doar pentru că crearea izolației în chroot sau jail, la fel ca OpenVZ, necesita cunoștințe considerabile despre sistemele de operare, în timp ce utilitatea care permite să creezi ușor un mediu izolat de aplicație pe o gazdă cu tot ce este necesar în interior și să predai din nou conducerea dezvoltării, în timp ce administratorul de sistem se ocupă doar de o singură gazdă, asigurându-i securitatea și disponibilitatea — o simplificare logică. Dar progresul nu stă pe loc și sistemele devin din ce în ce mai complexe, cu din ce în ce mai multe componente; o singură gazdă nu mai satisface nevoile sistemului și este necesar să construiești clustere. Ne întoarcem din nou la administratorii de sistem care pot construi aceste sisteme.
Cicluri după cicluri, apar diverse sisteme care simplifică dezvoltarea și/sau administrarea, apar sisteme de orchestrare care, până în momentul în care nu este necesar să te abateți de la procesul standard, sunt ușor de utilizat. Arhitectura microserviciilor a apărut de asemenea cu scopul de a simplifica tot ce este descris mai sus — mai puține interconexiuni, mai ușor de gestionat. Din experiența mea, nu am întâlnit o arhitectură microserviciu completă; aș spune că este un 50% — 50%: 50% microservicii, cutii negre, intră ce a fost procesat, ieșit, iar celelalte 50% — un monolit distras, servicii incapabile să funcționeze separat de celelalte componente. Toate acestea au impus din nou restricții asupra nivelului de cunoștințe atât pentru dezvoltatori, cât și pentru administratori.
Aceste „balansoare” de nivel expert al unei resurse sau altuia continuă și astăzi. Dar ne-am abătut puțin, sunt multe puncte care merită discutate.
Inginer de construcție / Inginer de lansare
Inginerii foarte specializați, apăruti ca un mijloc de standardizare a proceselor de construire a software-ului și a lansărilor acestuia. Odată cu introducerea pe scară largă a Agile, părea că nu mai sunt solicitați, totuși acest lucru nu este deloc adevărat. Această specializare a apărut ca un mijloc de standardizare a construirii și livrării software-ului la scară industrială, adică utilizând tehnici standard pentru toate produsele companiei. Odată cu apariția DevOps, dezvoltatorii au pierdut parțial funcții, deoarece aceștia au început să pregătească produsul pentru livrare, iar având în vedere infrastructura în continuă schimbare și abordarea în livrarea cât mai rapidă fără a lua în considerare calitatea, cu timpul au devenit un blocaj în procesele de schimbare, deoarece respectarea standardelor de calitate încetinește inevitabil livrările. Astfel, treptat, o parte din funcționalitatea inginerilor de Build/Release a fost transferată pe umerii administratorilor de sistem.
Ops-urile sunt atât de diferite
Continuăm mai departe și din nou, existența unui număr mare de responsabilități și lipsa personalului calificat ne împinge către o specializare riguroasă, cum ar fi ciupercile după ploaie, apar diferite Operations:
- TechOps — administratori de sistem en-gros aka HelpDesk Engineer
- LiveOps — administratori de sistem, predominant responsabili pentru medii productive
- CloudOps — administratori de sistem specializați în „cloud”-uri publice Azure, AWS, GCP etc.
- PlatOps / InfraOps / SysOps — administratori de sistem pentru infrastructură.
- NetOps — administratori de rețea
- SecOps — administratori de sistem specializați în securitatea informațiilor — conformitate PCI, conformitate CIS, actualizări etc.
DevOps — (în teorie) o persoană care înțelege din experiență toate procesele ciclului de dezvoltare — dezvoltarea, testarea, înțelegând arhitectura produsului, capabilă să evalueze riscurile de securitate, familiarizată cu abordările și instrumentele de automatizare, măcar la un nivel înalt, pe lângă aceasta înțelegând și suportul pre și post-lansare al produsului. O persoană capabilă să funcționeze ca avocat atât pentru Operations, cât și pentru Development, ceea ce permite construirea unei colaborări favorabile între aceste două pilonii. Înțelegând procesele de planificare a muncii echipelor și gestionarea așteptărilor clienților.
Pentru a îndeplini un astfel de tip de muncă și responsabilități, această persoană trebuie să aibă instrumente de gestionare nu doar a proceselor de dezvoltare, testare, ci și a infrastructurii produsului, precum și a planificării resurselor. DevOps în această înțelegere nu poate fi situat nici în IT, nici în R&D, nici măcar în PMO, el/ea trebuie să aibă influență în toate aceste domenii — director tehnic al companiei, Chief Technical Officer.
Este astfel în compania dumneavoastră? — Mă îndoiesc. În cele mai multe cazuri, este fie IT, fie R&D.
Lipsa instrumentelor și a capacității de influență asupra măcar uneia dintre aceste trei direcții de activitate va produce o deplasare a greutății problemelor spre partea în care aceste modificări sunt mai ușor de aplicat, cum ar fi aplicarea de restricții tehnice asupra lansărilor din cauza „codului murdar” conform sistemelor de analiză statică. Asta înseamnă că atunci când PMO stabilește un termen strict pentru livrarea funcționalității, R&D nu poate oferi un rezultat de calitate în aceste termene și îl livrează așa cum poate, lăsând refactoringul pe mai târziu, iar DevOps, care se referă la IT, prin instrumente tehnice blochează lansarea. Lipsa de autoritate pentru a modifica situația, în cazul angajaților responsabili, duce la o responsabilitate exagerată 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 — „Fericirea se află în ignoranță”, și ca urmare, la epuizare și pierderea acestor angajați.
Piața resurselor DevOps
Să analizăm câteva oferte de muncă pentru poziția DevOps de la diferite companii.
Suntem pregătiți să ne întâlnim cu dumneavoastră, dacă:
- Cunoașteți Zabbix și știți ce este Prometheus;
- Iptables;
- Studii avansate în BASH;
- Profesor în Ansible;
- Guru Linux;
- Știți să utilizați debugging-ul și, împreună cu dezvoltatorii, să identificați problemele aplicațiilor (php/java/python);
- Routing-ul nu vă provoacă panică;
- Acordați o atenție semnificativă securității sistemului;
- Faceți backup la „tot și toate”, și de asemenea reușiți să restaurați acest „tot și toate”;
- Știți să configurați sistemul pentru a obține maximul din minim;
- Configurați replicarea înainte de culcare pe Postgres și MySQL;
- Configurarea și ajustarea CI/CD sunt pentru dumneavoastră o necesitate, la fel ca micul dejun/prânzul/cina.
- Aveți experiență în lucru cu AWS;
- Sunteți pregătiți să vă dezvoltați împreună cu compania;
Deci:
- de la 1 la 6 — administrator de sistem
- 7 — puțin network administration, care se încadrează și în profilul administratorului de sistem, nivel Middle
- 8 — puțin de securitate, ceea ce este obligatoriu pentru un administrator de sistem de nivel Middle
- 9-11 — Administrator de Sistem Middle
- 12 — În funcție de sarcinile date, fie Administrator de Sistem Middle, fie Build Engineer
- 13 — Virtualizare — Administrator de Sistem Middle, sau așa-numitul CloudOps, cunoștințe avansate specifice serviciilor unei platforme hosting pentru utilizarea eficientă a fondurilor și reducerea încărcării de întreținere
În concluzie, pentru acest anunț de muncă, putem spune că băieții au nevoie de un Administrator de Sistem Middle/Senior.
Apropo, nu ar trebui să separăm prea mult administratorii în Linux/Windows. Înțeleg că serviciile și sistemele acestor două lumi diferă, dar baza este aceeași, iar orice administrator respectabil este familiarizat atât cu un sistem, cât și cu celălalt, și chiar dacă nu este familiarizat, pentru un administrator competent nu va fi o problemă să se familiarizeze cu acesta.
Să luăm în considerare o altă ofertă de muncă:
- Experiență în construirea sistemelor cu o sarcină mare;
- Cunoștințe excelente ale sistemului de operare Linux, software de sistem și stiva web (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Experiență în lucrul cu sistemele de virtualizare (KVM, VMWare, LXC/Docker);
- Cunoștințe de limbaje de scripting;
- Înțelegerea principiilor de funcționare a rețelelor și a protocoalelor de rețea;
- Înțelegerea principiilor de construirea sistemelor reziliente;
- Autonomie și inițiativă;
Analizăm:
- 1 — Administrator de Sistem Senior
- 2 — În funcție de semnificația pe care o atribuim acestui stack — Administrator de Sistem Middle/Senior
- 3 — Experiența de lucru, de asemenea, poate însemna — „Cluster-ul nu a fost ridicat, dar am creat și gestionat mașini virtuale, am avut un singur host Docker, accesul la containere am făcut pe NAT” — Administrator de Sistem Middle
- 4 — Administrator Sistem Junior — da, un administrator care nu știe să scrie scripturi simple de automatizare, indiferent de limbaj, nu este administrator — este un „enigmatic”.
- 5 — Administrator Sistem Middle
- 6 — Administrator Sistem Senior
În concluzie — Administrator Sistem Middle/Senior
Încă una:
- Experiență în devops;
- Experiență în utilizarea unuia sau mai multor produse pentru formarea proceselor CI/CD. Gitlab CI va fi un avantaj;
- Lucrul cu containere și virtualizare; Dacă ați folosit docker – este bine, iar dacă ați folosit k8s – excelent!
- Experiență în echipe Agile;
- Cunoașterea oricărui limbaj de programare;
Să vedem:
- 1 — Hmm… Ce vreau să spună băieții? =) Cel mai probabil, ei înșiși nu știu ce se ascunde în spatele acestui lucru.
- 2 — Inginer de Build
- 3 — Administrator Sistem Middle
- 4 — Soft skills, momentan nu le vom analiza, deși Agile este încă un lucru, pe care îl interpretează cum le convine.
- 5 — Prea vagi — poate fi un limbaj de scripting sau unul compilat. Este interesant, oare, dacă am scris în școală în Pascal și Basic, le-ar conveni? =)
Aș dori de asemenea să fac o remarcă referitoare la punctul 3, pentru a întări înțelegerea de ce acest punct este acoperit de administratorul de sistem. Kubernetes este doar o orchestration, un instrument care învăluie comenzile directe pentru driverele de rețea și gazde de virtualizare/izolare în câteva comenzi și permite interacțiunea cu ele într-un mod abstract, asta e tot. Ca exemplu, putem lua ‘build framework’ Make, pe care, apropo, nu-l consider un framework. Da, știu despre tendința de a introduce Make oriunde, unde este nevoie și unde nu — a învălui Maven în Make, de exemplu, serios?
Practic, Make este doar un wrapper de shell, care simplifică comenzile de compilare, linkare, mediu de compilare, la fel cum face și k8s.
Odată, am avut un interviu cu un tip care folosea k8s în munca sa pe OpenStack, și el povestea cum a desfășurat serviciile pe el, totuși, când l-am întrebat exact despre OpenStack, s-a dovedit că este administrat, la fel cum este și ridicat, de administratorii sistemului. Chiar credeți că o persoană care a ridicat OpenStack, indiferent de platforma pe care o folosește în spate, nu este capabilă să folosească k8s?=)
Acest candidat nu este, de fapt, un DevOps, ci un simplu Administrator de Sistem și, pentru a fi mai precis, un Administrator Kubernetes.
Să concluzionăm încă o dată — Administrator Sistem Middle/Senior le-ar fi suficient.
Cât să cântărim în grame
Intervalul salariilor propuse pentru posturile menționate este de 90k-200k
Acum aș dori să fac o paralelă între recompensele financiare pentru Administratorii de Sisteme și Inginerii DevOps.
În principiu, pentru simplificare, putem clasifica gradele în funcție de experiența profesională, chiar dacă nu va fi exact, pentru scopurile articolului este suficient.
Experiență:
- până la 3 ani — Junior
- până la 6 ani — Middle
- peste 6 ani — Senior
Site-ul de căutare a angajaților oferă:
Administratorii de Sisteme:
- Junior — 2 ani — 50k RON.
- Middle — 5 ani — 70k RON.
- Senior — 11 ani — 100k RON.
Inginerii DevOps:
- Junior — 2 ani — 100k RON.
- Middle — 3 ani — 160k RON.
- Senior — 6 ani — 220k RON.
Pentru pozitia de DevOps, s-a folosit stagiul, oricum atinge SDLC.
Din cele menționate mai sus, reiese că, de fapt, companiile nu au nevoie de DevOps, iar acestea ar fi putut economisi nu mai puțin de 50% din costurile inițiale planificate, angajând un Administrator, mai mult decât atât, ar fi putut defini mai clar responsabilitățile persoanei căutate și să îndeplinească mai rapid cerințele. De asemenea, nu trebuie să uităm că o separare clară a responsabilităților permite reducerea cerințelor pentru personal și crearea unei atmosfere de lucru mai favorabile, datorită absenței suprapunerilor. În majoritatea covârșitoare a anunțurilor de angajare, se răspândesc uneltele și etichetele DevOps, însă fără cerințe reale pentru Inginerul DevOps, ci doar solicitări pentru un administrator de unelte.
Procesul de formare a inginerilor DevOps este, de asemenea, limitat doar la un set de lucrări specifice și unelte, fără a oferi o înțelegere generală a proceselor și dependențelor acestora. Este evident că este bine când o persoană poate desfășura un AWS EKS folosind Terraform, într-o legătură cu Fluentd side-car în acest cluster și un stack AWS ELK pentru sistemul de logging în 10 minute, folosind doar o comandă în consolă, dar dacă nu va înțelege principiul procesării logurilor și pentru ce sunt acestea necesare, nu va ști cum să colecteze metricile pe baza acestora și să urmărească degradarea serviciului, atunci aceasta va rămâne același utilizator de unelte.
Cererea, totuși, generează ofertă, iar noi vedem o piață extrem de suprasolicitată pentru poziția de DevOps, unde cerințele nu corespund rolului real și permit doar administratorilor de sisteme să câștige mai mult.
Deci, cine sunt ei? DevOps sau administratori de sisteme avariți? =)
Ce facem mai departe?
Angajatorilor - să formuleze mai precis cerințele și să caute exact persoanele de care au nevoie, fără a se dispersa cu etichete. Dacă nu știți ce fac DevOps - atunci nu vă sunt necesari în acest caz.
Angajaților - să învețe. Să își perfecționeze continuu cunoștințele, să privească imaginea de ansamblu a proceselor și să urmărească drumul către obiectivele stabilite. Poți deveni oricine îți dorești, trebuie doar să te străduiești.
Sursa: habr.com
