Trenutno je to možda najskuplja pozicija na tržištu. Hrupnost oko 'DevOps' inženjera prevazilazi sve zamislive granice, a još je i teže sa Senior DevOps inženjerima.
Radim kao vođa odeljenja za integraciju i automatizaciju, pogodite englesku skraćenicu — DevOps Manager. Da li engleska skraćenica zaista odražava naše svakodnevne aktivnosti — teško, ali ruska verzija u ovom slučaju je tačnija. U svom poslu, naravno, moram da razgovaram sa budućim članovima mog tima, a kroz mene je prošlo oko 50 ljudi tokom prošle godine, dok je još toliko njih otpalo tokom preskrinovanja sa mojim zaposlenima.
Još uvek smo u potrazi za kolegama, jer se iza oznake DevOps krije veoma velika slojevitost raznovrsnih inženjera.
Sve napisano u nastavku je moje lično mišljenje, ne morate se složiti s njim, ali dopuštam da će uneti nijansu u vaše viđenje teme. I pored rizika od gneva, objavljujem svoje mišljenje, jer smatram da ima pravo da bude izneseno.
Kompanije različito razumeju ko su DevOps inženjeri i radi brzog zapošljavanja resursa stavljaju ovu oznaku svima. Situacija je dovoljno čudna, jer su kompanije spremne da plate nestvarne nagrade tim ljudima, često dobijajući administratore - alatne stručnjake umesto.
Pa, ko su zapravo DevOps inženjeri?
Začnimo s zgodovino razvoja – Development Operations je nastal kot še en korak k optimizaciji sodelovanja v manjših skupinah, da bi povečali hitrost izdelave produkta, kar je pričakovani rezultat. Ideja je bila okrepiti razvojno ekipo z znanjem o postopkih in pristopih k upravljanju produkcijskega okolja. Z drugimi besedami, razvijalec mora razumeti in vedeti, kako njegov izdelek deluje v različnih pogojih, kako izvesti njegovo nameščanje in katere lastnosti okolja prilagoditi, da bi povečali zmogljivost. Tako so se sčasoma pojavili razvijalci z DevOps pristopom. DevOps razvijalci so pisali skripte za gradnjo in pakiranje, da bi poenostavili svoje delo in delovanje produkcijskega okolja. Vendar pa je kompleksnost arhitekture rešitev in medsebojni vpliv komponent infrastrukture s časom začel slabšati delovno učinkovitost okolij, saj so bile z vsako novo iteracijo potrebne vedno globlje razumevanje določenih komponent, kar je skozi dodatne stroške za razumevanje komponent in prilagajanje sistemov za konkretne naloge zmanjšalo produktivnost samega razvijalca. Strošek razvijalca se je povečeval, strošek produkta pa skupaj z njim, zahteve po novih razvijalcih v ekipi so močno narasle, saj so morali pokrivati tudi obveznosti „zvezde“ razvoja, kar je naravno pomenilo, da je bilo „zvezdam“ vse težje dostopno. Prav tako je treba poudariti, da zanimanje razvijalcev za specifike obdelave paketov s strani jedra operacijskega sistema, pravila usmerjanja paketov in varnostne vidike gostitelja ni veliko. Logičen korak je bil vključiti administratorja, ki se s tem dobro spozna in mu naložiti take naloge, kar zahvaljujoč njegovim izkušnjam omogoča dosego istih rezultatov po nižji ceni v primerjavi s stroški „zvezde“ razvoja. Takšne administratorje so vključili v ekipo, njihova glavna naloga pa je bilo upravljanje testnih in produkcijskih okolij, upoštevajoč pravila konkretne skupine, s sredstvi, dodeljenimi prav tej skupini. Tako so v bistvu nastali DevOps v reprezentaciji večine.
Delomi ali popolnoma, skozi čas so ti sistemski skrbniki začeli razumeti potrebe te specifične razvojne ekipe, kako olajšati življenje razvijalcem in testerjem, kako izvajati nadgradnje in ne ostati v petek ponoči v pisarni, da bi odpravljali napake pri nameščanju. Čas je mineval, zdaj so sistemski skrbniki postali 'zvezde', ki razumejo, kaj želi razvojna ekipa. Z namenom minimalizacije vpliva so se začele pojavljati upravljalske orodja, vsi so se spomnili starih in zanesljivih metod izolacije na ravni operacijskega sistema, ki so omogočale zmanjšanje zahtev po varnosti, upravljanju omrežja in zavoljo celotne konfiguracije gostitelja ter posledično zmanjšale zahteve za nove 'zvezde'.
Pojavila se je 'čudovita' stvar - docker. Zakaj čudovita? Preprosto zato, ker je izdelava izolacije v chroot ali jail, prav tako kot OpenVZ, zahtevala nenavadna znanja operacijskega sistema, v nasprotju z orodjem, ki omogoča preprosto ustvarjanje izoliranega okolja aplikacij na določenem gostitelju z vsemi potrebnimi elementi in ponovno predajo vajeti razvoja, medtem ko lahko sistemski skrbnik upravlja le en gostitelj, zagotavljajoč varnost in visoko razpoložljivost - logično poenostavljenje. Ampak napredek ne miruje in sistemi postajajo vse bolj zapleteni, komponent pa vse več in več, en gostitelj več ne zadostuje potrebam sistema in graditi je treba klastre, ponovno se vračamo k sistemskim skrbnikom, ki so sposobni zgraditi te sisteme.
Cikel za ciklom, se pojavijo različni sistemi, ki poenostavljajo razvoj in/ali upravljanje, pojavijo se orkestracijski sistemi, ki so, dokler ni treba odstopiti od standardnega procesa, enostavni za uporabo. Mikrostoritvena arhitektura se je prav tako pojavila z namenom poenostavitve vsega zgoraj naštetega - manj medsebojnih povezav, enostavnejše upravljanje. V svoji izkušnji nisem doživel popolne mikrostoritvene arhitekture, rekel bi 50 na 50 - 50 odstotkov mikrostoritev, črne škatle, kar je prišlo notri, je bilo obdelano, drugih 50 - raztrgan monolit, storitve, ki niso sposobne delovati ločeno od drugih komponent. Vse to je ponovno nalagalo omejitve na raven znanja tako razvijalcev kot skrbnikov.
Podobni „gibljivi“ nivoji ekspertnega znanja posameznih virov se nadaljujejo še danes. A malo smo odtavali, obstaja še veliko točk, ki jih je treba osvetliti.
Build Engineer/Release Engineer
Zelo specializirani inženirji, ki so se pojavili kot sredstvo za standardizacijo procesov sestavljanja programske opreme in njenih izdaj. Med uvajanjem splošnega Agile sistema se je zdelo, da so postali manj iskani, a to nikakor ne drži. Ta specializacija se je pojavila kot sredstvo za standardizacijo ravno dela in dobave programske opreme v industrijskem obsegu, torej z uporabo standardnih tehnik za vse izdelke podjetja. S pojavom DevOps so razvijalci delno izgubili funkcije, saj so razvijalci začeli pripravljati izdelke za dostavo, a ob upoštevanju spremenljive infrastrukture in pristopa do kar se da hitre dobave, brez posvečanja pozornosti kakovosti, so se sčasoma spremenili v oviro sprememb, saj sleditve standardom kakovosti neizogibno upočasnijo dostave. Tako je postopoma del funkcionalnosti Build/Release inženirjev prešel na ramena sistemskih administratorjev.
Ops-i so tako različni
Gremo naprej in spet prisotnost širokega spektra nalog ter pomanjkanje kvalificiranih kadrov spodbuja strogo specializacijo, kot gobe po dežju, se pojavljajo različni Operations:
- TechOps — sistemski administratorji e-niki aka HelpDesk inženir
- LiveOps — sistemski administratorji, ki predvsem odgovarjajo za proizvodna okolja
- CloudOps — sistemski administratorji, specializirani za javne „oblake“ Azure, AWS, GCP itd.
- PlatOps/InfraOps/SysOps — sistemski administratorji infrastrukture.
- NetOps — mrežni administratorji
- SecOps — sistemski administratorji, specializirani za informacijsko varnost — PCI skladnost, CIS skladnost, popravki itd.
DevOps je (teoretično) oseba, ki na podlagi izkušenj razume vse procese razvojnega cikla – razvoj, testiranje, razume arhitekturo izdelka, sposobna je oceniti varnostna tveganja, spoznata se z metodami in orodji avtomatizacije, vsaj na visoki ravni, poleg tega pa razume tudi pred- in post-vrelease podporo izdelka. Oseba, ki lahko deluje kot zagovornik tako operacij kot razvojnih procesov, kar omogoča ugodno sodelovanje med tema dvema stebroma. Razume procese načrtovanja dela ekip in upravljanja pričakovanj naročnika.
Za opravljanje te vrste nalog in odgovornosti mora imeti ta oseba sredstva za upravljanje ne samo razvojnih in testnih procesov, temveč tudi upravljanje infrastrukture izdelka ter načrtovanje virov. DevOps v tem smislu ne sme biti niti v IT, niti v R&D, niti celo v PMO; mora imeti vpliv na vsa ta področja – tehnični direktor podjetja, Chief Technical Officer.
Je to tudi v vašem podjetju? – Dvomim. V večini primerov je to ali IT ali R&D.
Pomanjkanje sredstev in možnosti vplivanja vsaj na eno od teh treh področij dela bo povzročilo premik težav v smeri, kjer je te spremembe lažje uvesti, kot na primer uvajanje tehničnih omejitev na izdaje zaradi 'onesnaženega' kode v skladu z podatki sistemov za statično analizo. To pomeni, da ko PMO določi stroge roke za izdajo funkcionalnosti, R&D ne more zagotoviti kakovostnega rezultata v teh rokih in ga izdaja, kolikor lahko, preložitev refaktorizacije na kasneje, DevOps, povezan z IT, z tehničnimi sredstvi blokira izdajo. Pomanjkanje pooblastil za spremembo situacije v primeru odgovornih zaposlenih vodi do prekomerne odgovornosti za tisto, na kar ne morejo vplivati, še posebej, če ti zaposleni razumejo in vidijo napake ter kako jih odpraviti – 'Sreča je v nevednosti', kar vodi do izgorelosti in izgube teh zaposlenih.
Trg DevOps virov
Poglejmo nekaj prostih delovnih mest za pozicije DevOps iz različnih podjetij.
Pripravljeni smo se srečati z vami, če:
- Obvladate Zabbix in veste, kaj je Prometheus;
- Iptables;
- Poznavalec BASH;
- Profesor Ansible;
- Guru Linux;
- Znate li koristiti debag i zajednički s programerima nalaziti probleme aplikacija (php/java/python);
- Rutiranje ne izaziva kod vas histeriju;
- Posvećujete značajnu pažnju sigurnosti sistema;
- Pravite backup „svega i svačega“, a takođe uspešno obnavljate to „sve i sva“;
- Znate obezbediti sistem tako da iz minimuma izvučete maksimum;
- Podešavate replikacije pre spavanja na Postgres i MySQL;
- Podešavanje i uređivanje CI/CD za vas je obavezno kao doručak/ručak/večera.
- Imate iskustvo rada sa AWS;
- Spremni ste da se razvijate zajedno sa kompanijom;
Dakle:
- od 1 do 6 — sistemski administrator
- 7 — malo mrežnog administriranja, što takođe spada u sistemskog administratora nivoa Middle
- 8 — malo sigurnosti, što je obavezno za sistemskog administratora nivoa Middle
- 9-11 — Middle System Administrator
- 12 — U zavisnosti od postavljenih zadataka bilo Middle System Administrator, bilo Build Engineer
- 13 — Virtualizacija — Middle System Administrator, ili takozvani CloudOps, proširena znanja konkretnih usluga gostovanje platforme, za efikasno korišćenje sredstava i smanjenje opterećenja na održavanje
Sumirajući ovu poziciju, može se reći da je kandidatima dovoljno Middle/Senior System Administrator.
Usput, ne treba previše deliti administratore na Linux/Windows. Razumem da se usluge i sistemi ovih dvaju svetova razlikuju, ali osnova im je zajednička i svaki poštovan administrator je upoznat i sa jednim i sa drugim, a čak i ako nije upoznat, ne bi bilo teško veštom administratoru da se upozna s tim.
Razmotrićemo drugu poziciju:
- Iskustvo u izgradnji visoko opterećenih sistema;
- Odlična znanja o OS Linux, opštem softveru i web steku (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Iskustvo s sistemima virtualizacije (KVM, VMWare, LXC/Docker);
- Poznavanje skriptnih jezika;
- Razumevanje principa rada mreža i mrežnih protokola;
- Razumevanje principa izgradnje otpornih sistema;
- Samostalnost i inicijativa;
Analiziramo:
- 1 — Senior System Administrator
- 2 — U zavisnosti od značenja koje ulažemo u ovu steku — Middle/Senior System Administrator
- 3 — Iskustvo rada, takođe može značiti — „Klaster nisam podizao, ali sam kreirao i upravljao virtuelkama, bio sam jedini Docker host, usmerenu na kontejnere“ — Middle System Administrator
- 4 — Junior System Administrator — ja, admin, ki ne zna pisati osnovnih skripta za automatizacijo, ne glede na jezik, ni admin — enikej.
- 5 — Middle System Administrator
- 6 — Senior System Administrator
Na kratko — Middle/Senior System Administrator
Še ena:
- Izkušnje z devops;
- Izkušnje z uporabo enega ali več proizvodov za oblikovanje CI/CD procesov. Gitlab CI bo prednost;
- Delo s kontejnerji in virtualizacijo; Če ste uporabljali docker – super, še bolje, če Kubernetes – odlično!
- Izkušnje z delom v agilni ekipi;
- Poznavanje katerega koli programskega jezika;
Poglejmo:
- 1 — Hm… Kaj mislijo fantje? =) Verjetno sami ne vedo, kaj se za tem skriva.
- 2 — Build Engineer
- 3 — Middle System Administrator
- 4 — Mehke veščine, zaenkrat ne bomo obravnavali, čeprav je Agil še ena stvar, ki jo interpretirajo, kot jim ustreza.
- 5 — Preveč splošno — to je lahko skriptnik, ali pa kompiliran jezik. Zanimivo, ali bi jih prepričala, da so pisali v šoli v Pascalu in Basicu?=)
Želel bi tudi omeniti 3. točko, da bi okrepil razumevanje, zakaj ta točka spada k sistemskemu administratorju. Kubernetes je le orkestracija, orodje, ki oblači neposredne ukaze omrežnim gonilnikom in gostiteljem virtualizacije/izolacije v nekaj ukazov in omogoča abstraktno komunikacijo z njimi, to je vse. Kot primer, vzemimo 'build framework' Make, katerega okvirja jaz, mimogrede, ne štejem. Ja, vem za modo vključevanja Make povsod, kjer je potrebno in kjer ni — oviti Maven v Make, na primer, resno?
V bistvu je Make le ovitek okoli shell-a, ki poenostavi ukaze za kompilacijo, povezovanje, okolje kompilacije, prav tako kot Kubernetes.
Nekoč sem intervjueval fanta, ki je uporabljal Kubernetes v svojem delu nad OpenStack, in je govoril, kako je razporedil storitve na njem, vendar ko sem ga vprašal o OpenStacku, se je izkazalo, da ga upravljajo, pa tudi dvignejo sistemski administratorji. Ali res mislite, da oseba, ki je dvignila OpenStack, ne glede na to, katero platformo ima za seboj, ni sposobna uporabiti K8s?=)
Ta kandidat v resnici ni DevOps, temveč je enak sistemski administrator in, da bi bili natančnejši, administrator Kubernetes.
Na kratko še enkrat — Middle/Senior System Administrator jim bo zadostoval.
Koliko težiti v gramih
Razpon ponujenih plač za navedene zaposlitve — 90k-200k
Sedaj bi rad potegnil primerjavo med denarnimi nagradami sistemskih administratorjev in inženirjev DevOps.
V bistvu lahko za poenostavitev razdelimo stopnje glede na delovne izkušnje, čeprav to ne bo natančno, za potrebe članka pa bo dovolj.
Izkušnje:
- do 3 let — Junior
- do 6 let — Middle
- več kot 6 let — Senior
Spletna stran za iskanje zaposlenih ponuja:
Sistemski administratorji:
- Junior — 2 leti — 50k руб.
- Middle — 5 let — 70k руб.
- Senior — 11 let — 100k руб.
Inženirji DevOps:
- Junior — 2 leti — 100k руб.
- Middle — 3 leti — 160k руб.
- Senior — 6 let — 220k руб.
Pri izkušnjah 'DevOps' so upoštevane izkušnje, ki so se kakorkoli dotikale SDLC.
Iz navedenega izhaja, da podjetjem dejansko ne potrebujejo DevOps-ov, in da bi lahko prihranila vsaj 50 odstotkov prvotno načrtovanih stroškov, če bi najeti sistemskega administratorja; več kot to, lahko bi bolje opredelili naloge iskanega osebja in hitreje zadovoljili potrebe. Ne smemo tudi pozabiti, da jasno ločevanje odgovornosti zmanjšuje zahteve do osebja in ustvarja ugodnejšo delovno okolje, saj ni prekrivanja nalog. V pretežni večini delovnih mest zasledimo orodja in označbe DevOps, ki pa nimajo resničnih zahtev po inženirju DevOps, temveč le zahteve po orodnem administratorju.
Postopek usposabljanja inženirjev DevOps je prav tako omejen le na nabor specifičnih nalog, orodij, in ne zagotavlja splošnega razumevanja procesov in njihovih odvisnosti. To je seveda dobro, ko lahko nekdo z uporabo Terraform-a izvaja razporejanje AWS EKS, skupaj z Fluentd sidecar-jem v tem sklopu in AWS ELK skladom za sistemno beleženje v 10 minutah, z uporabo le ene ukazne vrstice, toda če ne razume samega načela obdelave logov in zakaj so ti potrebni, ter ne ve, kako zbirati metrike glede nanje in spremljati degradacijo storitve, bo to še vedno enak enikaj, ki zna uporabljati nekatera orodja.
Povpraševanje pa ustvarja ponudbo, in vidimo izjemno prenapolnjen trg pozicij DevOps, kjer zahteve ne ustrezajo dejanski vlogi, temveč omogočajo sistemskim administratorjem zaslužiti več.
Kdo so torej oni? DevOps-ji ali pohlepni sistemski administratorji? =)
Kako naprej?
Delodajalcem je smiselno natančneje opredeliti zahteve in iskati točno tiste, ki jih potrebujejo, namesto da se obremenjujejo s oznakami. Če ne veste, kaj počnejo DevOps, jih v tem primeru ne potrebujete.
Zaposlenim svetujemo, naj se učijo. Nenehno izboljšujte svoje znanje, poglejte širšo sliko procesov in spremljajte pot do zastavljenih ciljev. Lahko postanete, kar želite, le truditi se morate.
Izvor: habr.com
