Trenutno je to skoraj najdražja pozicija na trgu. Razburjenje okoli inženirjev »DevOps« presega vse meje, še hujše pa je pri višjih inženirjih DevOps.
Delam kot vodja oddelka za integracijo in avtomatizacijo, uganite angleško dekodiranje - DevOps Manager. Malo verjetno je, da angleški prepis odraža naše vsakodnevne dejavnosti, vendar je ruska različica v tem primeru natančnejša. Zaradi narave moje dejavnosti je naravno, da moram opraviti razgovore z bodočimi člani svoje ekipe, in v zadnjem letu je šlo mimo mene okoli 50 ljudi, prav toliko pa jih je bilo prekinjenih na prescreenu z mojimi zaposlenimi.
Še vedno iščemo sodelavce, saj se za oznako DevOps skriva zelo velika plast različnih inženirjev.
Vse spodaj napisano je moje osebno mnenje, ni nujno, da se s tem strinjate, priznam pa, da bo vašemu odnosu do teme dodalo nekaj barve. Kljub nevarnosti, da padem v nemilost, objavljam svoje mnenje, ker verjamem, da mora biti.
Podjetja različno razumejo, kdo so DevOps inženirji in zaradi hitrega najema vira vsem obešajo to oznako. Situacija je precej nenavadna, saj so podjetja tem ljudem pripravljena plačati nerealna plačila, zanje pa v večini primerov prejmejo skrbnika orodja.
Kdo so torej inženirji DevOps?
Začnimo z zgodovino njegovega videza - razvojne operacije so se pojavile kot še en korak k optimizaciji interakcije v majhnih skupinah za povečanje hitrosti proizvodnje izdelkov, kot pričakovana posledica. Ideja je bila razvojno ekipo okrepiti s poznavanjem postopkov in pristopov pri upravljanju produktnega okolja. Z drugimi besedami, razvijalec mora razumeti in vedeti, kako njegov izdelek deluje v določenih pogojih, mora razumeti, kako uvesti svoj izdelek, katere značilnosti okolja je mogoče prilagoditi za izboljšanje učinkovitosti. Tako so se nekaj časa pojavili razvijalci s pristopom DevOps. Razvijalci DevOps so napisali skripte za gradnjo in pakiranje, da bi poenostavili svoje dejavnosti in delovanje produkcijskega okolja. Kompleksnost arhitekture rešitve in medsebojni vpliv infrastrukturnih komponent pa sta sčasoma začela slabšati delovanje okolij, z vsako iteracijo je bilo potrebno vse globlje razumevanje določenih komponent, kar je zmanjševalo produktivnost razvijalca zaradi dodatnih stroški razumevanja komponent in prilagajanja sistemov za določeno nalogo. Narasli so lastni stroški razvijalca, z njim tudi stroški izdelka, močno so poskočile zahteve po novih razvijalcih v ekipi, saj so morali pokriti tudi odgovornosti razvojne »zvezde« in seveda je »zvezd« postalo manj. in manj na voljo. Prav tako je treba omeniti, da po mojih izkušnjah malo razvijalcev zanimajo posebnosti obdelave paketov v jedru operacijskega sistema, pravila usmerjanja paketov in varnostni vidiki gostitelja. Logičen korak je bil pritegniti skrbnika, ki je na to seznanjen, in mu dodeliti podobne odgovornosti, kar je zaradi njegovih izkušenj omogočilo doseganje enakih kazalnikov z nižjimi stroški v primerjavi s stroški "zvezdnega" razvoja. Takšni skrbniki so bili postavljeni v ekipo, njegova glavna naloga pa je bila upravljanje testnih in produkcijskih okolij, po pravilih določene ekipe, s sredstvi, dodeljenimi tej ekipi. Tako se je pravzaprav DevOps pojavil v glavah večine.
Delno ali v celoti so sčasoma ti sistemski skrbniki začeli razumeti potrebe te posebne ekipe na področju razvoja, kako olajšati življenje razvijalcem in preizkuševalcem, kako uvesti posodobitev in ne ostati čez noč v petek v urad, popravljanje napak pri uvajanju. Čas je minil in zdaj so bile "zvezde" sistemski skrbniki, ki so razumeli, kaj želijo razvijalci. Da bi zmanjšali vpliv, so se začeli pojavljati pripomočki za upravljanje; vsi so se spomnili starih in zanesljivih metod izolacije ravni OS, ki so omogočile zmanjšanje zahtev za varnost, upravljanje omrežnega dela in konfiguracijo gostitelja kot celoto in posledično zmanjšati zahteve po novih »zvezdah«.
Pojavila se je "čudovita" stvar - docker. Zakaj čudovito? Da, samo zato, ker je ustvarjanje izolacije v chroot ali zaporu, kot tudi OpenVZ, zahtevalo nepomembno poznavanje OS, v nasprotju s tem pa vam pripomoček omogoča preprosto ustvarjanje izoliranega aplikacijskega okolja na določenem gostitelju z vsem potrebnim znotraj in pri roki znova nad vajeti razvoja, skrbnik sistema pa lahko upravlja samo z enim gostiteljem, kar zagotavlja njegovo varnost in visoko razpoložljivost – logična poenostavitev. Toda napredek ne miruje in sistemi postajajo spet vedno bolj kompleksni, komponent je vedno več, en host ne zadovoljuje več sistemskih potreb in potrebno je graditi grozde, spet se vračamo k sistemskim skrbnikom, ki so sposobni zgraditi te sisteme.
Cikel za ciklom se pojavljajo različni sistemi, ki poenostavljajo razvoj in/ali administracijo, pojavljajo se sistemi za orkestracijo, ki so enostavni za uporabo, dokler ni treba odstopati od standardnega procesa. Mikrostoritvena arhitektura se je pojavila tudi z namenom poenostavitve vsega zgoraj opisanega – manj relacij, lažje upravljanje. Po mojih izkušnjah nisem našel popolnoma mikrostoritvene arhitekture, rekel bi 50 do 50 - 50 odstotkov mikrostoritev, črnih skrinjic, je prišlo noter, izšlo obdelanih, ostalih 50 je raztrgan monolit, storitve, ki ne morejo delovati ločeno od drugih komponente. Vse to je spet naložilo omejitve na ravni znanja tako razvijalcev kot skrbnikov.
Podobna »nihanja« v ravni strokovnega poznavanja posameznega vira se nadaljujejo še danes. Vendar smo se malo oddaljili, veliko točk je vredno poudariti.
Inženir gradnje/inženir izdaje
Zelo visoko specializirani inženirji, ki so se pojavili kot sredstvo za standardizacijo procesov gradnje programske opreme in izdaj. V procesu uvajanja razširjene Agile se zdi, da ni več povpraševanja po njih, vendar še zdaleč ni tako. Ta specializacija se je pojavila kot sredstvo za standardizacijo sestavljanja in dostave programske opreme v industrijskem obsegu, tj. uporabo standardnih tehnik za vse izdelke podjetja. S pojavom DevOps so razvijalci delno izgubili svoje funkcije, saj so bili razvijalci tisti, ki so izdelek začeli pripravljati na dostavo, glede na spreminjajočo se infrastrukturo in pristop k čim hitrejši dostavi ne glede na kakovost pa so se sčasoma spremenili v zamašek sprememb, saj spoštovanje standardov kakovosti neizogibno upočasnjuje dobave. Tako se je postopoma del funkcionalnosti inženirjev Build/Release preselil na ramena sistemskih skrbnikov.
Operacije so tako različne
Gremo naprej in spet nas prisotnost velikega obsega odgovornosti in pomanjkanje usposobljenega kadra potiska v strogo specializacijo, kot gobe po dežju se pojavljajo različne Operacije:
- TechOps - sistemski skrbniki enikey alias HelpDesk Engineer
- LiveOps - sistemski skrbniki, odgovorni predvsem za produkcijska okolja
- CloudOps - sistemski skrbniki, specializirani za javne oblake Azure, AWS, GCP itd.
- PlatOps/InfraOps/SysOps - infrastrukturni sistemski skrbniki.
- NetOps - skrbniki omrežja
- SecOps - sistemski skrbniki, specializirani za informacijsko varnost - skladnost s PCI, skladnost s CIS, popravki itd.
DevOps je (teoretično) oseba, ki iz prve roke razume vse procese razvojnega cikla – razvoj, testiranje, razume arhitekturo produkta, zna oceniti varnostna tveganja, pozna pristope in orodja za avtomatizacijo, vsaj na visoki ravni. ravni, poleg tega razume tudi pred- in naknadno obdelavo, podporo za izdajo izdelka. Oseba, ki je sposobna nastopati kot zagovornik tako Operacije kot Razvoja, kar omogoča ugodno sodelovanje med tema dvema stebroma. Razume procese načrtovanja dela timov in obvladovanja pričakovanj strank.
Za opravljanje tovrstnega dela in odgovornosti mora ta oseba imeti sredstva za upravljanje ne le procesov razvoja in testiranja, temveč tudi upravljanje infrastrukture izdelkov ter načrtovanje virov. DevOps v tem razumevanju ne more biti lociran niti v IT, niti v R&D ali celo v PMO; imeti mora vpliv na vseh teh področjih - tehnični direktor podjetja, glavni tehnični direktor.
Je to res v vašem podjetju? - Dvomim. V večini primerov je to IT ali R&R.
Pomanjkanje sredstev in zmožnosti vplivanja na vsaj eno od teh treh področij dejavnosti bo težo težav premaknilo tja, kjer je te spremembe lažje uporabiti, kot je uporaba tehničnih omejitev pri izdajah v povezavi z "umazano" kodo glede na statično analizatorski sistemi. To pomeni, da ko PMO določi strog rok za izdajo funkcionalnosti, raziskave in razvoj ne morejo proizvesti visokokakovostnega rezultata v teh rokih in ga proizvedejo po najboljših močeh, preoblikovanje pa pustijo za pozneje, DevOps, povezan z IT, blokira izdajo s tehničnimi sredstvi . Pomanjkanje pooblastil za spremembo situacije pri odgovornih zaposlenih vodi v manifestacijo hiperodgovornosti za tisto, na kar ne morejo vplivati, še posebej, če ti zaposleni razumejo in vidijo napake ter kako jih popraviti - "Blaženost je nevednost", in posledično do izgorelosti in izgube teh zaposlenih.
Trg virov DevOps
Oglejmo si več prostih delovnih mest za DevOps položaje v različnih podjetjih.
Pripravljeni smo se srečati z vami, če:
- Imate Zabbix in veste, kaj je Prometheus;
- Iptables;
- doktorski študent BASH;
- profesor Ansible;
- Linux Guru;
- Znati uporabljati razhroščevanje in poiskati težave z aplikacijami skupaj z razvijalci (php/java/python);
- Usmerjanje vas ne naredi histeričnega;
- Veliko pozornosti posvetite varnosti sistema;
- Varnostno kopirajte »vse in vse« in tudi uspešno obnovite to »vse in vse«;
- Veš, kako konfigurirati sistem tako, da iz minimuma izvlečeš največ;
- Nastavite replikacijo pred spanjem na Postgres in MySQL;
- Postavitev in prilagoditev CI/CD je za vas tako potrebna kot zajtrk/kosilo/večerja.
- Imeti izkušnje z AWS;
- Pripravljen na razvoj s podjetjem;
Torej:
- od 1 do 6 - sistemski skrbnik
- 7 - malo omrežne administracije, ki se prilega tudi sistemskemu skrbniku, srednji nivo
- 8 - malo varnosti, ki je obvezna za sistemskega administratorja srednje ravni
- 9-11 – Srednji sistemski skrbnik
- 12 — Glede na dodeljene naloge, bodisi srednji sistemski skrbnik bodisi gradbeni inženir
- 13 - Virtualizacija - Srednji sistemski skrbnik ali t.i. CloudOps, napredno poznavanje storitev določenega gostovanja, za učinkovito porabo sredstev in zmanjšanje obremenitev pri vzdrževanju
Če povzamemo to prosto delovno mesto, lahko rečemo, da je srednji/višji sistemski administrator dovolj za fante.
Mimogrede, skrbnikov v Linuxu/Windowsu ne bi smeli močno deliti. Seveda razumem, da so storitve in sistemi teh dveh svetov različni, vendar je osnova za vse enaka in vsak samospoštljiv administrator pozna tako enega kot drugega, pa tudi če ne pozna, bo Pristojnemu skrbniku se z njim ne bo težko seznaniti.
Poglejmo še eno prosto delovno mesto:
- Izkušnje pri gradnji visokoobremenjenih sistemov;
- Odlično poznavanje OS Linux, splošne sistemske programske opreme in spletnega sklada (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Izkušnje z virtualizacijskimi sistemi (KVM, VMWare, LXC/Docker);
- Obvladanje skriptnih jezikov;
- Razumevanje principov delovanja omrežij omrežnega protokola;
- Razumevanje principov gradnje sistemov, odpornih na napake;
- Neodvisnost in pobuda;
Poglejmo si:
- 1 – višji sistemski skrbnik
- 2 - Odvisno od pomena, ki je vložen v ta sklad - srednji/višji sistemski skrbnik
- 3 - Delovne izkušnje, vključno z, lahko pomenijo - "Gruča ni dvignila, ampak ustvarila in upravljala virtualne stroje, obstajal je en gostitelj Docker, dostop do vsebnikov ni bil na voljo" - Srednji sistemski skrbnik
- 4 - Junior System Administrator - ja, admin, ki ne zna pisati osnovnih skript za avtomatizacijo, ne glede na jezik, ne admin - enikey.
- 5 - Srednji sistemski skrbnik
- 6 – višji sistemski skrbnik
Če povzamem - srednji/višji sistemski administrator
Še en:
- Devops izkušnje;
- Izkušnje z uporabo enega ali več izdelkov za ustvarjanje procesov CI/CD. Gitlab CI bo prednost;
- Delo s kontejnerji in virtualizacija; Če ste uporabili docker, dobro, če pa ste uporabili k8s, super!
- Izkušnje z delom v agilni ekipi;
- Poznavanje katerega koli programskega jezika;
Pa poglejmo:
- 1 - Hmm ... Kaj mislijo fantje? =) Najverjetneje tudi sami ne vedo, kaj se skriva za tem
- 2 - Gradbeni inženir
- 3 - Srednji sistemski skrbnik
- 4 – Mehka spretnost, zaenkrat je ne bomo upoštevali, čeprav je Agile še ena stvar, ki se interpretira na primeren način.
- 5 – Preveč podrobno – lahko je skriptni jezik ali preveden. Zanima me, ali jim bo pisanje v Pascalu in Basicu v šoli ustrezalo? =)
Prav tako bi rad pustil opombo v zvezi s točko 3, da bi bolje razumeli, zakaj to točko pokriva skrbnik sistema. Kubernetes je samo orkestracija, orodje, ki neposredne ukaze omrežnim gonilnikom in gostiteljem za virtualizacijo/izolacijo ovije v nekaj ukazov in vam omogoča, da komunikacijo z njimi naredite abstraktno, to je vse. Za primer vzemimo 'build framework' Make, ki ga mimogrede ne štejem za okvir. Ja, vem za modo riniti Make kamor koli, kjer je treba in kjer ni potrebno - zavijanje Maven v Make, na primer, resno?
V bistvu je Make samo ovoj nad lupino, ki poenostavlja prevajanje, povezovanje in ukaze okolja prevajanja, tako kot k8s.
Nekoč sem intervjuval tipa, ki je pri svojem delu uporabljal k8s na vrhu OpenStacka, in govoril je o tem, kako je na njem namestil storitve, ko pa sem vprašal o OpenStacku, se je izkazalo, da ga upravlja in dviguje sistem skrbniki. Ali res mislite, da oseba, ki ima nameščen OpenStack, ne glede na to, katero platformo uporablja za seboj, ne zna uporabljati k8s? =)
Ta prijavitelj pravzaprav ni DevOps, ampak sistemski skrbnik in, če smo natančnejši, skrbnik Kubernetes.
Naj še enkrat povzamemo - zanje bo zadostoval srednji/višji sistemski administrator.
Koliko tehtati v gramih
Razpon predlaganih plač za navedena prosta delovna mesta je 90k-200k
Zdaj bi rad potegnil vzporednico med denarnimi nagradami sistemskih skrbnikov in DevOps inženirjev.
Načeloma lahko za poenostavitev ocene razpršite glede na delovne izkušnje, čeprav to ne bo natančno, vendar bo za namene članka dovolj.
Izkušnja:
- do 3 let – Junior
- do 6 let – srednji
- več kot 6 – starejši
Spletno mesto za iskanje zaposlenih ponuja:
Sistemski skrbniki:
- Junior - 2 leti - 50k rub.
- Srednje - 5 let - 70k rub.
- Senior - 11 let - 100k rub.
Inženirji DevOps:
- Junior - 2 leti - 100k rub.
- Srednje - 3 leta - 160k rub.
- Senior - 6 let - 220k rub.
Po izkušnjah "DevOps" so bile uporabljene izkušnje, ki so vsaj nekako vplivale na SDLC.
Iz navedenega sledi, da podjetja DevOps dejansko ne potrebujejo, prav tako pa bi lahko z zaposlitvijo skrbnika prihranila vsaj 50 odstotkov prvotno načrtovanih stroškov, poleg tega pa bi lahko jasneje opredelila odgovornosti osebe, ki jo iščejo. in hitreje zapolni potrebe. Prav tako ne smemo pozabiti, da nam jasna delitev odgovornosti omogoča zmanjšanje zahtev za osebje, pa tudi ustvarjanje ugodnejšega vzdušja v ekipi zaradi odsotnosti prekrivanj. Velika večina prostih delovnih mest je polna pripomočkov in oznak DevOps, vendar ne temeljijo na dejanskih zahtevah za inženirja DevOps, ampak samo na zahtevah za skrbnika orodja.
Tudi proces usposabljanja inženirjev DevOps je omejen le na nabor specifičnih del, pripomočkov in ne zagotavlja splošnega razumevanja procesov in njihovih odvisnosti. Vsekakor je dobro, če lahko človek v 10 minutah s samo enim ukazom v konzoli razmesti AWS EKS s pomočjo Terraforma, v povezavi s prikolico Fluentd v tej gruči in skladom AWS ELK za sistem beleženja, če pa ne razume princip same obdelave dnevnikov in za kaj so potrebni, če ne veste, kako zbirati metrike na njih in slediti poslabšanju storitve, potem bo še vedno isti enikey, ki zna uporabljati nekatere pripomočke.
Povpraševanje pa ustvarja ponudbo in vidimo izjemno pregret trg za DevOps pozicijo, kjer zahteve ne ustrezajo dejanski vlogi, ampak sistemskim administratorjem omogočajo le več zaslužka.
Kdo so torej? DevOps ali požrešni sistemski skrbniki? =)
Kako živeti naprej?
Delodajalci bi morali bolj natančno oblikovati zahteve in iskati točno tiste, ki jih potrebujejo, ne pa si nalagati etiket. Ne veste, kaj počne DevOps – v tem primeru jih ne potrebujete.
Delavci - Učite se. Nenehno izpopolnjujte svoje znanje, glejte celotno sliko procesov in spremljajte pot do cilja. Lahko postaneš, kdor hočeš, samo poskusiti moraš.
Vir: www.habr.com