Trenutno je ovo gotovo najskuplja pozicija na tržištu. Galama oko “DevOps” inženjera je izvan svih zamislivih granica, a još gore sa Senior DevOps inženjerima.
Radim kao šef odeljenja za integraciju i automatizaciju, valjda englesko dekodiranje - DevOps Manager. Malo je vjerovatno da engleski transkript odražava naše svakodnevne aktivnosti, ali ruska verzija u ovom slučaju je tačnija. Zbog prirode moje djelatnosti, prirodno je da imam potrebu da intervjuišem buduće članove mog tima, a u proteklih godinu dana kroz mene je prošlo oko 50 ljudi, a isto toliko je prekinuto na prescreenu sa mojim zaposlenima.
Još uvijek tražimo kolege, jer se iza DevOps etikete krije veoma veliki sloj različitih vrsta inženjera.
Sve što je dole napisano je moje lično mišljenje, ne morate se složiti sa njim, ali priznajem da će to dodati malo boje vašem stavu prema temi. Uprkos riziku da padnem u nemilost, objavljujem svoje mišljenje jer vjerujem da ono ima mjesto na kojem treba biti.
Kompanije imaju različita shvatanja o tome ko su DevOps inženjeri i, radi brzog angažovanja resursa, stavljaju ovu etiketu na sve. Situacija je prilično čudna, jer su kompanije spremne da isplaćuju nerealne naknade ovim ljudima, primajući, u većini slučajeva, administratora alata za njih.
Dakle, ko su DevOps inženjeri?
Počnimo sa istorijom njegovog pojavljivanja – Razvojne operacije su se pojavile kao još jedan korak ka optimizaciji interakcije u malim timovima kako bi se povećala brzina proizvodnje proizvoda, kao očekivana posledica. Ideja je bila da se razvojni tim ojača poznavanjem procedura i pristupa u upravljanju proizvodnim okruženjem. Drugim riječima, programer mora razumjeti i znati kako njegov proizvod funkcionira u određenim uvjetima, mora razumjeti kako da implementira svoj proizvod, koje karakteristike okruženja se mogu prilagoditi kako bi se poboljšale performanse. Tako su se neko vrijeme pojavili programeri s DevOps pristupom. DevOps programeri su napisali skripte za izradu i pakovanje kako bi pojednostavili svoje aktivnosti i performanse proizvodnog okruženja. Međutim, složenost arhitekture rješenja i međusobni utjecaj infrastrukturnih komponenti s vremenom su počeli pogoršavati performanse okruženja; sa svakom iteracijom bilo je potrebno sve dublje razumijevanje određenih komponenti, smanjujući produktivnost programera zbog dodatnih troškovi razumevanja komponenti i sistema podešavanja za određeni zadatak. Sopstveni troškovi programera su rasli, cijena proizvoda zajedno s njim, zahtjevi za novim programerima u timu su naglo skočili, jer su i oni trebali pokriti odgovornosti razvojne "zvijezde" i, naravno, "zvijezde" su postale manje i manje dostupni. Takođe je vredno napomenuti da je, prema mom iskustvu, malo programera zainteresovano za specifičnosti obrade paketa od strane kernela operativnog sistema, pravila rutiranja paketa i aspekte bezbednosti hosta. Logičan korak je bio da se privuče administrator koji je upoznat s tim i da mu se dodijele slične odgovornosti, što je, zahvaljujući njegovom iskustvu, omogućilo postizanje istih pokazatelja po nižoj cijeni u odnosu na cijenu razvoja “zvijezda”. Takvi administratori su stavljeni u tim i njegov glavni zadatak je bio da upravlja testnim i produkcijskim okruženjima, prema pravilima određenog tima, sa resursima dodijeljenim ovom konkretnom timu. Tako se, zapravo, DevOps pojavio u glavama većine.
Djelomično ili potpuno, s vremenom, ovi sistem administratori su počeli da shvataju potrebe ovog konkretnog tima u oblasti razvoja, kako da olakšaju život programerima i testerima, kako da unesu ažuriranje i da ne moraju da prenoće u petak u ured, ispravljanje grešaka pri postavljanju. Vrijeme je prolazilo, a sada su “zvijezde” bili sistem administratori koji su razumjeli šta programeri žele. Da bi se smanjio uticaj, počeli su da se pojavljuju uslužni programi za upravljanje; svi su se sjećali starih i pouzdanih metoda izolacije nivoa OS-a, što je omogućilo minimiziranje zahtjeva za sigurnost, upravljanje mrežnim dijelom i konfiguraciju hosta kao cjelinu i, kao rezultat, smanjiti zahtjeve za novim “zvijezdama”.
Pojavila se "divna" stvar - docker. Zašto divno? Da, samo zato što je stvaranje izolacije u chroot ili zatvoru, kao i OpenVZ, zahtijevalo netrivijalno poznavanje OS-a, za razliku od toga, uslužni program vam omogućava da jednostavno kreirate izolirano okruženje aplikacije na određenom hostu sa svim potrebnim unutra i rukama ponovo nad uzde razvoja, a administrator sistema može upravljati samo sa samo jednim hostom, osiguravajući njegovu sigurnost i visoku dostupnost - logično pojednostavljenje. Ali napredak ne miruje i sistemi ponovo postaju sve složeniji, komponenti je sve više, jedan host više ne zadovoljava potrebe sistema i potrebno je graditi klastere, opet se vraćamo sistem administratorima koji su sposobni da izgrade ove sisteme.
Ciklus za ciklusom pojavljuju se razni sistemi koji pojednostavljuju razvoj i/ili administraciju, pojavljuju se sistemi orkestracije, koji su, dok ne treba da odstupite od standardnog procesa, jednostavni za korištenje. Mikroservisna arhitektura se takođe pojavila sa ciljem da pojednostavi sve gore opisano - manje odnosa, lakše za upravljanje. Po mom iskustvu, nisam našao kompletnu mikroservisnu arhitekturu, rekao bih 50 do 50 - 50 posto mikroservisa, crnih kutija, ušlo je, izašlo obrađeno, ostalih 50 su pokidani monolit, servisi ne mogu raditi odvojeno od ostalih komponente. Sve je to opet nametnulo ograničenja u nivou znanja i programera i administratora.
Slična „ljuljanja“ u nivou stručnog znanja određenog resursa traju i danas. Ali malo smo skrenuli, ima mnogo tačaka koje vredi istaći.
Inženjer gradnje/inženjer izdanja
Veoma visoko specijalizovani inženjeri koji su se pojavili kao sredstvo za standardizaciju procesa i izdanja softvera. U procesu uvođenja široko rasprostranjenog Agile-a, čini se da su prestali biti traženi, ali to je daleko od slučaja. Ova specijalizacija se pojavila kao sredstvo standardizacije montaže i isporuke softvera u industrijskom obimu, tj. koristeći standardne tehnike za sve proizvode kompanije. Pojavom DevOps-a, programeri su dijelom izgubili svoje funkcije, jer su programeri počeli pripremati proizvod za isporuku, a s obzirom na promjenjivu infrastrukturu i pristup što bržem isporuci bez obzira na kvalitetu, vremenom su se pretvorili u zaustavljač promena, pošto poštovanje standarda kvaliteta neizbežno usporava isporuke. Tako je postepeno dio funkcionalnosti Build/Release inženjera prešao na ramena sistemskih administratora.
Operacije su tako različite
Idemo dalje i iznova prisustvo velikog spektra obaveza i nedostatak kvalifikovanog osoblja gura nas ka striktnoj specijalizaciji, kao gljive posle kiše pojavljuju se razne Operacije:
- TechOps - enikey sistem administratori aka HelpDesk Engineer
- LiveOps - administratori sistema prvenstveno odgovorni za proizvodna okruženja
- CloudOps - sistem administratori specijalizovani za javne oblake Azure, AWS, GCP, itd.
- PlatOps/InfraOps/SysOps - administratori sistema infrastrukture.
- NetOps - mrežni administratori
- SecOps - sistem administratori specijalizovani za sigurnost informacija - PCI usklađenost, CIS usklađenost, zakrpe, itd.
DevOps je (u teoriji) osoba koja iz prve ruke razumije sve procese razvojnog ciklusa - razvoj, testiranje, razumije arhitekturu proizvoda, sposobna je procijeniti sigurnosne rizike, upoznata je s pristupima i alatima za automatizaciju, barem na visokoj razini. nivo, pored ovoga, takođe razume prethodnu i post-procesu podršku za izdavanje proizvoda. Osoba sposobna da djeluje kao zagovornik i za operacije i za razvoj, što omogućava povoljnu saradnju između ova dva stuba. Razumije procese planiranja rada timova i upravljanja očekivanjima kupaca.
Za obavljanje ove vrste posla i odgovornosti, ova osoba mora imati sredstva za upravljanje ne samo procesima razvoja i testiranja, već i upravljanje infrastrukturom proizvoda, kao i planiranje resursa. DevOps u ovom shvatanju ne može se locirati ni u IT, ni u R&D, pa čak ni u PMO; mora imati uticaj u svim ovim oblastima - tehnički direktor kompanije, glavni tehnički direktor.
Da li je to istina u vašoj kompaniji? - Sumnjam. U većini slučajeva to je ili IT ili R&D.
Nedostatak sredstava i mogućnosti utjecaja na barem jedno od ova tri područja aktivnosti pomjerit će težinu problema tamo gdje je ove promjene lakše primijeniti, kao što je primjena tehničkih ograničenja na izdanja u vezi sa "prljavim" kodom prema statičkim analizatorski sistemi. Odnosno, kada PMO postavi strogi rok za puštanje funkcionalnosti, R&D ne može proizvesti visokokvalitetan rezultat u tim rokovima i proizvodi ga najbolje što može, ostavljajući refaktoring za kasnije, DevOps vezan za IT blokira izdavanje tehničkim sredstvima . Nedostatak ovlasti za promenu situacije, kod odgovornih zaposlenih, dovodi do ispoljavanja hiperodgovornosti za ono na šta ne mogu uticati, posebno ako ovi zaposleni razumeju i vide greške, i kako da ih isprave – „Blaženstvo je neznanje“, i kao posljedicu sagorijevanja i gubitka ovih zaposlenih.
Tržište DevOps resursa
Pogledajmo nekoliko slobodnih radnih mjesta za DevOps pozicije iz različitih kompanija.
Spremni smo za susret sa Vama ako:
- Vi posjedujete Zabbix i znate šta je Prometheus;
- Iptables;
- BASH doktorant;
- profesor Ansible;
- Linux Guru;
- Znati kako koristiti otklanjanje grešaka i pronaći probleme sa aplikacijama zajedno sa programerima (php/java/python);
- Usmjeravanje vas ne čini histeričnim;
- Obratite značajnu pažnju na sigurnost sistema;
- Napravite sigurnosnu kopiju „svega i svega“ i također uspješno vratite ovo „sve i svašta“;
- Znate kako da konfigurišete sistem na takav način da izvučete maksimum od minimuma;
- Postavite replikaciju prije spavanja na Postgres i MySQL;
- Podešavanje i podešavanje CI/CD-a vam je potrebno kao doručak/ručak/večera.
- Imati iskustva sa AWS-om;
- Spremni za razvoj sa kompanijom;
Dakle:
- od 1 do 6 - sistem administrator
- 7 - malo mrežne administracije, što se takođe uklapa u sistem administratora, srednji nivo
- 8 - malo sigurnosti, što je obavezno za sistem administratora srednjeg nivoa
- 9-11 – Srednji sistem administrator
- 12 — Ovisno o dodijeljenim zadacima, ili srednji sistem administrator ili inženjer izgradnje
- 13 - Virtuelizacija - Middle System Administrator, ili tzv. CloudOps, napredno poznavanje usluga određenog hosting sajta, za efikasno korišćenje sredstava i smanjenje opterećenja održavanja
Sumirajući ovo radno mjesto, možemo reći da je Srednji/Senior System Administrator dovoljan momcima.
Usput, ne biste trebali snažno dijeliti administratore na Linux/Windows. Naravno da razumem da su servisi i sistemi ova dva sveta različiti, ali osnova za sve je ista i svaki admin koji poštuje sebe je upoznat i sa jednim i sa drugim, pa čak i ako nije upoznat, biće kompetentnom administratoru nije teško da se upozna sa tim.
Razmotrimo još jedno slobodno radno mjesto:
- Iskustvo u izgradnji sistema visokog opterećenja;
- Odlično poznavanje Linux OS-a, opšteg sistemskog softvera i web steka (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Iskustvo sa sistemima virtuelizacije (KVM, VMWare, LXC/Docker);
- Poznavanje jezika skripte;
- Razumijevanje principa rada mreža mrežnih protokola;
- Razumijevanje principa izgradnje sistema otpornih na greške;
- Nezavisnost i inicijativa;
Pogledajmo:
- 1 – viši sistem administrator
- 2 - Ovisno o značenju koje se stavlja u ovaj stog - Srednji/Viši sistemski administrator
- 3 - Radno iskustvo, uključujući, može značiti - "Klaster nije podigao, već je kreirao i upravljao virtuelnim mašinama, postojao je jedan Docker host, pristup kontejnerima nije bio dostupan" - Srednji sistemski administrator
- 4 - Junior System Administrator - da, administrator koji ne zna da napiše osnovne skripte za automatizaciju, bez obzira na jezik, a ne admin - enikey.
- 5 - Srednji sistem administrator
- 6 – viši sistem administrator
Da rezimiramo - srednji/viši sistem administrator
Drugi:
- Devops iskustvo;
- Iskustvo u korištenju jednog ili više proizvoda za kreiranje CI/CD procesa. Gitlab CI će biti prednost;
- Rad sa kontejnerima i virtuelizacija; Ako ste koristili docker, dobro, ali ako ste koristili k8s, odlično!
- Iskustvo rada u agilnom timu;
- Poznavanje bilo kojeg programskog jezika;
da vidimo:
- 1 - Hmm... Šta momci misle? =) Najvjerovatnije ni sami ne znaju šta se krije iza toga
- 2 - Građevinski inženjer
- 3 - Srednji sistem administrator
- 4 - Soft skill, za sada to nećemo razmatrati, iako je Agile još jedna stvar koja se tumači na način koji je pogodan.
- 5 - Previše opširno - može biti skriptni jezik ili kompajlirani. Pitam se da li će im odgovarati pisanje na Pascal i Basic u školi? =)
Takođe bih želeo da ostavim napomenu u vezi sa tačkom 3 kako bih ojačao razumevanje zašto ovu tačku pokriva administrator sistema. Kubernetes je samo orkestracija, alat koji umotava direktne komande mrežnim drajverima i virtuelizovanim/izolacionim hostovima u nekoliko naredbi i omogućava vam da komunikaciju sa njima učinite apstraktnom, to je sve. Na primjer, uzmimo 'build framework' Make, koji, inače, ne smatram okvirom. Da, znam za modu guranja Make bilo gdje, gdje je potrebno, a gdje nije potrebno - umotavanje Mavena u Make, na primjer, ozbiljno?
U suštini, Make je samo omotač preko ljuske, koji pojednostavljuje naredbe okruženja za kompilaciju, povezivanje i kompilaciju, baš kao k8s.
Jednom sam intervjuisao tipa koji je koristio k8s u svom radu na OpenStack-u, i on je pričao o tome kako je postavio servise na njemu, međutim, kada sam pitao za OpenStack, ispostavilo se da je on administriran, kao i podigao sistem administratori. Da li zaista mislite da osoba koja je instalirala OpenStack, bez obzira koju platformu koristi iza sebe, ne može koristiti k8s? =)
Ovaj aplikant zapravo nije DevOps, već sistem administrator i, preciznije, Kubernetes administrator.
Da sumiramo još jednom – srednji/viši sistem administrator će im biti dovoljni.
Koliko težiti u gramima
Raspon predloženih plata za navedena slobodna radna mjesta je 90k-200k
Sada bih želeo da povučem paralelu između novčanih nagrada sistemskih administratora i DevOps inženjera.
U principu, da pojednostavite stvari, možete razbacati ocjene na osnovu radnog iskustva, iako to neće biti točno, ali za potrebe članka to će biti dovoljno.
Iskustvo:
- do 3 godine – Junior
- do 6 godina – srednji
- više od 6 – Senior
Stranica za pretragu zaposlenih nudi:
Administratori sistema:
- Junior - 2 godine - 50k rub.
- Srednji - 5 godina - 70k rub.
- Senior - 11 godina - 100k rub.
DevOps inženjeri:
- Junior - 2 godine - 100k rub.
- Srednji - 3 godine - 160k rub.
- Senior - 6 godina - 220k rub.
Prema iskustvu „DevOpsa“, korišćeno je iskustvo koje je bar nekako uticalo na SDLC.
Iz navedenog proizilazi da kompanijama zapravo nije potreban DevOps, kao i da bi angažovanjem Administratora mogle uštedjeti najmanje 50 posto prvobitno planiranih troškova, štoviše, jasnije definisati odgovornosti osobe koju traže. i brže ispunite potrebu. Također ne treba zaboraviti da nam jasna podjela odgovornosti omogućava smanjenje zahtjeva za osobljem, kao i stvaranje povoljnije atmosfere u timu, zbog odsustva preklapanja. Ogromna većina slobodnih radnih mjesta je puna uslužnih programa i DevOps oznaka, ali se ne zasnivaju na stvarnim zahtjevima za DevOps inženjera, već samo na zahtjevima za administratora alata.
Proces obuke DevOps inženjera je takođe ograničen samo na skup specifičnih radova, uslužnih programa i ne pruža opšte razumevanje procesa i njihovih zavisnosti. Svakako je dobro kada osoba može da implementira AWS EKS koristeći Terraform, u kombinaciji sa Fluentd sidecarom u ovom klasteru i AWS ELK stekom za logging sistem za 10 minuta, koristeći samo jednu komandu u konzoli, ali ako ne razume princip obrade samih logova i za šta su oni potrebni, ako ne znate kako prikupiti metriku o njima i pratiti degradaciju servisa, onda će i dalje biti isti enikey koji zna koristiti neke uslužne programe.
Potražnja, međutim, stvara ponudu i vidimo izuzetno pregrijano tržište za DevOps poziciju, gdje zahtjevi ne odgovaraju stvarnoj ulozi, već samo omogućavaju administratorima sistema da zarade više.
Pa ko su oni? DevOps ili pohlepni sistemski administratori? =)
Kako nastaviti živjeti?
Poslodavci bi trebali preciznije formulirati zahtjeve i tražiti upravo one koji su potrebni, a ne bacati etikete. Ne znate šta DevOps rade - u tom slučaju vam ne trebaju.
Radnici - Učite. Neprestano usavršavajte svoje znanje, gledajte cjelokupnu sliku procesa i pratite put do svog cilja. Možete postati ko god želite, samo morate pokušati.
izvor: www.habr.com