🥇Tko su DevOps?

Trenutno je ovo jedna od najskupljih pozicija na tržištu. Hype oko „DevOps“ inženjera premašuje sve zamišljene granice, a situacija je još teža sa Senior DevOps inženjerima.
Radim kao voditelj odjela za integraciju i automatizaciju, pogodite englesku verziju — DevOps Manager. Odražava li engleski izraz našu svakodnevnu aktivnost — teško, ali ruska verzija u ovom slučaju je preciznija. U okviru mog posla, naravno, trebam intervjuirati buduće članove mog tima i, kroz proteklu godinu, prošlo je kroz mene oko 50 kandidata, a još toliko ih je bilo odbijeno prilikom predselekcije s mojim zaposlenicima.

Još uvijek smo u potrazi za kolegama, jer se iza oznake DevOps skriva vrlo velika struktura raznih inženjera.

Sve što je napisano u nastavku je moje osobno mišljenje, ne morate se slagati s njim, međutim, smatram da bi moglo dodati nijansu vašem stavu o temi. Unatoč riziku da upadnem u nemilost, objavljujem svoje mišljenje jer smatram da mu je mjesto.

Tvrtke različito razumiju tko su DevOps inženjeri i radi brzog zapošljavanja resursa pridaju ovu oznaku svima. Situacija je prilično čudna, jer su tvrtke spremne plaćati nevjerojatne naknade tim ljudima, dok u većini slučajeva dobijaju administratora alatnog inženjera.

Tko su zapravo DevOps inženjeri?

Počnimo s poviješću nastanka — Development Operations se pojavio kao još jedan korak ka optimizaciji suradnje u malim timovima radi povećanja brzine proizvodnje proizvoda, kao očekivana posljedica. Ideja je bila ojačati razvojni tim znanjem o procedurama i pristupima u upravljanju produktnim okruženjem. Drugim riječima, programer mora razumjeti i znati kako njegov proizvod radi u određenim uvjetima, mora znati kako implementirati svoj proizvod, koje karakteristike okruženja podesiti kako bi poboljšao performanse. Tako su s vremenom nastali programeri s DevOps pristupom. DevOps programeri su pisali skripte za gradnju i pakiranje kako bi pojednostavili svoje aktivnosti i radne procese u produkcijskom okruženju. Međutim, složenost arhitekture rješenja i međusobni utjecaj komponenti infrastrukture s vremenom su počeli pogoršavati radne performanse okruženja; s svakom iteracijom bila su potrebna sve dublja razumijevanja određenih komponenti, što je smanjilo produktivnost samog programera zbog dodatnog troška razumijevanja komponenti i optimizacije sustava za određeni zadatak. Trošak programera je rastao, trošak proizvoda zajedno s njim, a zahtjevi za novim programerima u timu su naglo porasli, budući da su oni također trebali pokriti obaveze "zvijezde" razvoja, a "zvijezde" su, prirodno, postajale sve manje dostupne. Također, trebam napomenuti da, prema mom iskustvu, malo koji programer je zainteresiran za specifičnosti obrade paketa od strane jezgre operativnog sustava, pravila usmjeravanja paketa, aspekte sigurnosti hosta. Logičan korak bio je privući administratora, koji je upravo s tim upoznat, i prenijeti takve obaveze upravo na njega, što je, zahvaljujući njegovom iskustvu, omogućilo postizanje istih rezultata po manjoj cijeni u usporedbi s troškom "zvijezde" razvoja. Takvi administratori su se smješteni u tim i njihova glavna zadaća bila je upravljanje testnim i produkcijskim okruženjima, prema pravilima konkretno izabranog tima, s resursima dodijeljenim upravo tom timu. Tako su, zapravo, i DevOps nastali u percepciji većine.

Djelomično ili potpuno, s vremenom su ti sustavni administratori počeli razumijevati potrebe ovog specifičnog razvojnog tima, kako olakšati život programerima i testerima, kako implementirati ažuriranja i ne ostati u uredu u petak navečer ispravljajući greške prilikom implementacije. Vreme je prolazilo i sada su 'zvijezde' postali sustavni administratori koji razumiju što programeri žele. S ciljem minimiziranja utjecaja, počeli su se koristiti alati za upravljanje, svi su se prisjetili starih i pouzdanih metoda izolacije na razini sustava, koje su omogućile minimiziranje zahtjeva za sigurnost, upravljanje mrežnim dijelom, pa i konfiguraciju hosta u cjelini, a kao posljedicu, smanjiti zahtjeve za nove 'zvijezde'.

Pojavila se 'izvrsna' stvar — docker. Zašto izvrsna? Jednostavno zato što je stvaranje izolacije u chroot ili jail, kao i OpenVZ, tražilo ne trivijalna znanja o operativnom sustavu, dok je kontra alat omogućio jednostavno stvaranje izoliranog okruženja aplikacije na nekom hostu sa svime potrebnim unutar i ponovno predavanje kontrole razvoju, dok je sustavni administrator upravljao samo jednim hostom, osiguravajući njegovu sigurnost i visoku dostupnost — logično pojednostavljenje. No, napredak ne miruje i sustavi ponovno postaju sve složeniji, komponenti sve više i više, jedan host više ne zadovoljava potrebe sustava i potrebno je izgraditi klastere, ponovno se vraćamo sustavnim administratorima koji su sposobni izgraditi te sustave.

Ciklus za ciklusom, pojavljuju se razni sustavi koji pojednostavljuju razvoj i/ili administraciju, pojavljuju se sustavi orkestracije koji su, sve do trenutka kada se ne zahtijeva odstupanje od standardnog procesa, jednostavni za korištenje. Mikroslužbena arhitektura također se pojavila s ciljem pojednostavljenja svega navedenog — manje međusobnih povezanosti, jednostavnije upravljanje. U svom iskustvu nisam doživio potpuno mikroslužbenu arhitekturu, rekao bih 50 naprema 50 — 50 posto mikroslužbi, crne kutije, ono što je ušlo je obrađeno, a ostalih 50 — rastrgani monolit, usluge nesposobne raditi odvojeno od drugih komponenti. Sve to ponovno je nametnulo ograničenja na razini znanja kako programera, tako i administratora.

Slični "ljuljački" na razini stručnog znanja određenog resursa nastavljaju se i danas. No, malo smo skrenuli s teme, postoje brojni aspekti koje vrijedi istaknuti.

Inženjer izrade/ Inženjer izdavanja

Vrlo usko specijalizirani inženjeri, koji su se pojavili kao sredstvo standardizacije procesa izrade softvera i njegovih izdanja. Tijekom uvođenja Agile metodologije činilo se da su postali manje traženi, no to nije točno. Ova specijalizacija pojavljivala se kao sredstvo standardizacije upravo izrade i isporuke softvera u industrijskim razmjerima, tj. korištenjem standardnih tehnika za sve proizvode tvrtke. S pojavljivanjem DevOps-a programeri su djelomično izgubili svoje funkcije, jer su programeri počeli pripremati proizvod za isporuku, a s obzirom na promjenjivu infrastrukturu i pristup brzom isporučivanju bez povratka na kvalitetu, s vremenom su postali kočnica promjena, budući da slijeđenje standarda kvalitete neizbježno usporava isporuke. Tako je postupno, dio funkcionalnosti Build/Release inženjera prešao na teret sistemskih administratora.

Ops-ovi su tako različiti

Idemo dalje i ponovno prisustvo širokog spektra obveza i nedostatak kvalificiranih kadrova tjera nas na strogu specijalizaciju, kao gljive nakon kiše, pojavljuju se različite Operacije:

TechOps — sistemski administratori e-nikea aka HelpDesk inženjer
LiveOps — sistemski administratori, prvenstveno odgovorni za proizvodne okruženja
CloudOps — sistemski administratori specijalizirani za javne "oblake" Azure, AWS, GCP, itd.
PlatOps/InfraOps/SysOps — sistemski administratori infrastrukture.
NetOps — mrežni administratori
SecOps — sistemski administratori specijalizirani za informatičku sigurnost — PCI usklađenost, CIS usklađenost, zakrčivanje, itd.

DevOps — (u teoriji) osoba koja iz prve ruke razumije sve procese u razvoju ciklusa — razvoj, testiranje, razumije arhitekturu proizvoda, sposobna je procijeniti rizike sigurnosti, upoznata je s pristupima i sredstvima automatizacije, barem na visokoj razini, uz to razumije i pred- i post-release podršku proizvoda. Osoba sposobna djelovati kao advokat i Operations i Development, što omogućava izgradnju povoljne suradnje između ova dva stupa. Razumije procese planiranja rada timova i upravljanja očekivanjima klijenta.

Za obavljanje sličnih poslova i odgovornosti, ova osoba treba imati sredstva za upravljanje ne samo procesima razvoja i testiranja, već i upravljanjem infrastrukturom proizvoda, kao i planiranjem resursa. DevOps u ovom smislu ne može se nalaziti ni u IT-u, ni u R&D-u, niti čak u PMO-u, mora imati utjecaj u svim ovim područjima — tehnički direktor tvrtke, Chief Technical Officer.

Je li to slučaj u vašoj tvrtki? — Sumnjam. U većini slučajeva to je ili IT, ili R&D.

Nedostatak sredstava i mogućnosti utjecaja barem na jedno od ta tri područja djelovanja dovodi do pomaka težine problema prema onome gdje je lakše primijeniti promjene, kao što je primjerice postavljanje tehničkih ograničenja na izdanja zbog "prljavog" koda prema podacima sustava statičke analize. To jest, kada PMO postavlja strogi rok za isporuku funkcionalnosti, R&D ne može isporučiti kvalitetan rezultat u tim rokovima i daje ga kako može, ostavljajući refaktoring za kasnije, a DevOps vezan za IT, tehničkim sredstvima blokira izdavanje. Nedostatak ovlasti za promjenu situacije, u slučaju odgovornih zaposlenika vodi do prekomjernog preuzimanja odgovornosti za ono na što ne mogu utjecati, posebno ako ti zaposlenici razumiju i vide greške, i kako ih ispraviti — "Sreća u neznanju", a kao posljedica toga dolazi do izgaranja i gubitka tih zaposlenika.

Tržište DevOps resursa

Pogledajmo nekoliko oglasa za poziciju DevOps iz različitih kompanija.

Spremni smo se sastati s vama ako:

Posjedujete Zabbix i znate što je Prometheus;

Iptables;

Apsolvent BASH;

Profesor Ansible;

Guru Linux;

Znate koristiti debag i surađivati s programerima u pronalaženju problema s aplikacijama (php/java/python);

Routing ne izaziva paniku kod vas;

Posvećujete veliku pažnju sigurnosti sustava;

Radite backup „svega” i uspješno vraćate to „sve”;

Znate postaviti sustav tako da iz minimuma izvučete maksimum;

Postavljate replikacije prije spavanja na Postgresu i MySQL-u;

Postavljanje i podešavanje CI/CD-a za vas su nužnost kao doručak/ručak/večera.

Imate iskustva s AWS-om;

Spremni ste razvijati se zajedno s kompanijom;

Dakle:

od 1 do 6 — sistemski administrator
7 — malo mrežnog administriranja, što također spada u sistemske administratore razine Middle
8 — malo sigurnosti, što je obavezno za sistemskog administratora razine Middle
9-11 — Middle System Administrator
12 — Ovisno o postavljenim zadacima, ili Middle System Administrator ili Build Engineer
13 — Virtualizacija — Middle System Administrator, ili takozvani CloudOps, proširano znanje konkretnih servisa hosting platforme za učinkovito korištenje sredstava i smanjenje opterećenja na održavanje

Zaključujući ovu poziciju, možemo reći da su dečki dovoljni Middle/Senior System Administrator.

Usput, ne bi trebali previše dijeliti administratore na Linux/Windows. Razumijem da se servisi i sustavi ovih dvaju svjetova razlikuju, ali osnova je svima zajednička i svaki poštovani administrator upoznat je s jednim i drugim, pa čak i ako nije upoznat, za dobrog administratora ne bi trebalo biti teško upoznati se s tim.

Razmotrimo drugu poziciju:

Iskustvo u izgradnji visoko opterećenih sustava;

Odlična znanja o OS Linux, općem softveru i web stogu (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);

Iskustvo s virtualizacijskim sustavima (KVM, VMWare, LXC/Docker);

Poznavanje skriptnih jezika;

Razumijevanje principa rada mreža i mrežnih protokola;

Razumijevanje principa izrade sustava otpornog na kvarove;

Samostalnost i inicijativa;

Razmatramo:

1 — Senior System Administrator
2 — Ovisno o značenju koje stavljamo u ovu stack — Middle/Senior System Administrator
3 — Iskustvo rada, također, može značiti — "Klaster nisam podigao, ali sam kreirao i upravljao virtualkama, bio je jedan Docker host, pristup kontejnerima sam natavio" — Middle System Administrator
4 — Junior System Administrator — da, administrator koji ne zna pisati osnovne skripte za automatizaciju, bez obzira na jezik, nije administrator — 'enikej'.
5 — Middle System Administrator
6 — Senior System Administrator

Ukratko — Middle/Senior System Administrator

Još jedna:

Iskustvo u devops-u;

Iskustvo u korištenju jednog ili više proizvoda za oblikovanje CI/CD procesa. Gitlab CI će biti prednost;

Rad s kontejnerima i virtualizacijom; Ako ste koristili docker – odlično, a ako k8s – još bolje!

Iskustvo u agile timu;

Poznavanje bilo kojeg programskog jezika;

Pogledajmo:

1 — Hmm… Što dečki misle? =) Vjerojatno ni sami ne znaju što se iza toga skriva.
2 — Build Engineer
3 — Middle System Administrator
4 — Soft skills nećemo razmatrati, iako je Agile još jedna stvar koja se interpretira kako im odgovara.
5 — Previše opširno — to može biti skriptni jezik, ili kompajlirani. Zanimljivo, hoće li im odgovarati ako sam u školi pisao na Pascal-u i Basic-u? =)

Također bih volio ostaviti komentar u vezi s točkom 3, kako bih pojasnio zašto ovaj punkt pokriva sistemski administrator. Kubernetes je samo orkestracija, alat koji obavija izravne komande mrežnim drajverima i hostovima virtualizacije/izolacije u nekoliko komandi i omogućuje apstraktno komuniciranje s njima, to je sve. Za primjer, uzmimo 'build framework' Make, kojeg ne smatram frameworkom. Da, znam za modu stavljanja Make gdje god to bilo potrebno i nepotrebno — obavijati Maven u Make, na primjer, ozbiljno?
U suštini, Make je samo obavijanje nad shell-om, koje olakšava upravo komande kompilacije, linkanja, okruženja kompilacije, kao i k8s.

Jednom sam razgovarao s dečkom koji je koristio k8s u svom radu iznad OpenStack-a, i on je pričao o tome kako je razvio usluge na njemu, međutim, kada sam ga pitao točno o OpenStack-u, ispostavilo se da njime upravljaju i podižu sistemski administratori. Doista mislite da osoba koja je podigla OpenStack, bez obzira na to koju platformu koristi iza njega, nije sposobna koristiti k8s? =)
Ovaj kandidat zapravo nije DevOps, već sličan sistemskom administratoru i da budem točniji, Kubernetes administrator.

Ponovno sažimamo — Middle/Senior System Administrator bit će im dovoljno.

Koliko treba staviti u gramima

Raspon predloženih plaća za navedene pozicije — 90k-200k
Sada bih volio povući paralelu između novčanih nagrada sistemskih administratora i DevOps inženjera.

U principu, za pojednostavljenje možemo rasporediti razrede prema radnom iskustvu, iako to neće biti točno, za svrhe članka bit će dovoljno.

Iskustvo:

do 3 godine — Junior
do 6 godina — Middle
preko 6 godina — Senior

Web stranica za pronalazak zaposlenika nudi:
Sistemski administratori:

Junior — 2 godine — 50k kuna.
Middle — 5 godina — 70k kuna.
Senior — 11 godina — 100k kuna.

DevOps inženjeri:

Junior — 2 godine — 100k kuna.
Middle — 3 godine — 160k kuna.
Senior — 6 godina — 220k kuna.

Za staž 'DevOps' inženjera koristio se staž koji se barem donekle odnosi na SDLC.

Iz navedenog slijedi da kompanijama zapravo nisu potrebni DevOps inženjeri, te da su mogle uštedjeti najmanje 50 posto od prvotno planiranih troškova zapošljavanjem administratora; štoviše, mogle bi jasnije definirati obaveze tražene osobe i brže zadovoljiti potrebe. Također, ne zaboravite da jasno razdvajanje odgovornosti smanjuje zahtjeve prema osoblju, te stvara povoljniju atmosferu u timu, zbog izostanka preklapanja. U prevladavajućem broju oglasa za posao ističu se alati i DevOps oznake, no zapravo ne sadrže istinske zahtjeve prema DevOps inženjeru, već samo upite za administratora alata.

Proces obuke DevOps inženjera također je ograničen samo na skup specifičnih zadataka i alata, ne pružajući opće razumijevanje procesa i njihovih zavisnosti. To je svakako dobro kada osoba može upotrebom Terraform-a postaviti AWS EKS, u kombinaciji s Fluentd sidecar-om u ovom klasteru i AWS ELK stakom za sustav logiranja za 10 minuta, koristeći samo jednu naredbu u konzoli, ali ako ne razumije samu svrhu obrade logova i zašto su potrebni, ne zna kako prikupljati metrike o njima i pratiti degradaciju usluge, onda će to biti isti onaj koji zna koristiti određene alate.

Međutim, potražnja stvara ponudu, i vidimo izrazito pregrijeno tržište za poziciju DevOps, gdje zahtjevi ne odgovaraju stvarnoj ulozi, već samo omogućuju sistemskim administratorima da zarađuju više.

Pa tko su oni? DevOps inženjeri ili pohlepni sistemski administratori? =)

Kako dalje živjeti?

Poslodavcima - preciznije formulirati zahtjeve i tražiti točno one koji su potrebni, umjesto rasipanja oznakama. Ako ne znate čime se DevOps bave - nisu vam tada potrebni.

Radnicima - učiti. Stalno usavršavati svoje znanje, gledati cjelokupnu sliku procesa i pratiti put do postavljenog cilja. Možete postati tko god želite, samo se treba potruditi.

Izvor: habr.com