Ovo je trenutno gotovo najskuplja pozicija na tržištu. Galama oko “DevOps” inženjera je izvan svih zamislivih granica, a još je gora sa Senior DevOps inženjerima.
Radim kao voditelj odjela integracije i automatizacije, pogodite englesko dekodiranje - DevOps Manager. Malo je vjerojatno da engleski transkript odražava naše svakodnevne aktivnosti, ali ruska verzija je u ovom slučaju točnija. Zbog prirode moje djelatnosti prirodno je da imam potrebu intervjuirati buduće članove svog tima, au proteklih godinu dana kroz mene je prošlo 50-ak ljudi, a isto toliko ih je prekinuto na prescreenu s mojim zaposlenicima.
Još uvijek tražimo kolege, jer se iza oznake DevOps krije jako velik sloj različitih vrsta inženjera.
Sve što je dolje napisano je moje osobno mišljenje, ne morate se složiti s njim, ali priznajem da će dati malo boje vašem stavu o temi. Unatoč riziku da padnem u nemilost, objavljujem svoje mišljenje jer vjerujem da ono ima gdje biti.
Kompanije različito shvaćaju tko su DevOps inženjeri i, radi brzog angažiranja resursa, svima lijepe ovu etiketu. Situacija je prilično čudna, budući da su tvrtke tim ljudima spremne plaćati nerealne naknade, a za njih dobivaju, u većini slučajeva, administratora alata.
Dakle, tko su DevOps inženjeri?
Počnimo s poviješću njegovog pojavljivanja - Development Operations se pojavio kao još jedan korak prema optimizaciji interakcije u malim timovima za povećanje brzine proizvodnje proizvoda, kao očekivana posljedica. Ideja je bila osnažiti razvojni tim poznavanjem procedura i pristupa u upravljanju okruženjem proizvoda. Drugim riječima, programer mora razumjeti i znati kako njegov proizvod radi u određenim uvjetima, mora razumjeti kako implementirati svoj proizvod, koje se karakteristike okoline mogu prilagoditi za poboljšanje performansi. Tako su se neko vrijeme pojavili programeri s DevOps pristupom. DevOps programeri napisali su skripte za izradu i pakiranje kako bi pojednostavili svoje aktivnosti i performanse proizvodnog okruženja. Međutim, složenost arhitekture rješenja i međusobni utjecaj komponenti infrastrukture 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 razumijevanja komponenti i sustava za podešavanje za određeni zadatak. Vlastiti trošak programera je rastao, trošak proizvoda zajedno s njim, zahtjevi za novim programerima u timu naglo su skočili, jer su trebali pokriti i odgovornosti razvojne “zvijezde” i, naravno, “zvijezda” je postalo manje a manje dostupno. Također je vrijedno napomenuti da je, prema mom iskustvu, nekoliko programera zainteresirano za specifičnosti obrade paketa od strane jezgre operativnog sustava, pravila usmjeravanja paketa i aspekte sigurnosti glavnog računala. Logičan korak bio je privući administratora koji je u to upoznat i dodijeliti mu slične odgovornosti, što je zahvaljujući njegovom iskustvu omogućilo postizanje istih pokazatelja uz nižu cijenu u odnosu na cijenu razvoja "zvijezde". Takvi administratori bili su raspoređeni u tim, a njegova glavna zadaća bila je upravljanje testnim i produkcijskim okruženjima, prema pravilima određenog tima, s resursima dodijeljenim tom timu. Tako se, zapravo, DevOps pojavio u glavama većine.
Djelomično ili u potpunosti, s vremenom su ovi administratori sustava počeli shvaćati potrebe ovog konkretnog tima u području razvoja, kako olakšati život programerima i testerima, kako izbaciti ažuriranje i ne morati prespavati u petak u ured, ispravljanje pogrešaka u implementaciji. Vrijeme je prolazilo, a sada su "zvijezde" bili administratori sustava koji su razumjeli što programeri žele. Kako bi se smanjio utjecaj, počeli su se pojavljivati pomoćni programi za upravljanje; svi su se sjetili starih i pouzdanih metoda izolacije razine OS-a, što je omogućilo minimiziranje zahtjeva za sigurnošću, upravljanjem mrežnim dijelom i konfiguracijom glavnog računala kao cjeline i, kao rezultat toga, smanjuju zahtjeve za novim "zvijezdama".
Pojavila se "čudesna" stvar - docker. Zašto divno? Da, samo zato što je stvaranje izolacije u chroot-u ili zatvoru, kao i OpenVZ, zahtijevalo ne-trivijalno poznavanje OS-a, nasuprot tome, uslužni program vam omogućuje jednostavno stvaranje izoliranog okruženja aplikacije na određenom hostu sa svime što je potrebno iznutra i pri ruci ponovno nad uzde razvoja, a administrator sustava može upravljati samo s jednim hostom, osiguravajući njegovu sigurnost i visoku dostupnost - logično pojednostavljenje. Ali napredak ne stoji i sustavi opet postaju sve složeniji, komponenti je sve više, jedan host više ne zadovoljava potrebe sustava i potrebno je graditi klastere, opet se vraćamo na administratore sustava koji su sposobni izgraditi te sustave.
Ciklus za ciklusom pojavljuju se različiti sustavi koji pojednostavljuju razvoj i/ili administraciju, pojavljuju se sustavi orkestracije koji su, dok ne treba odstupiti od standardnog procesa, jednostavni za korištenje. Pojavila se i mikroservisna arhitektura s ciljem pojednostavljenja svega gore opisanog – manje odnosa, lakše upravljanje. Prema mom iskustvu, nisam pronašao potpunu arhitekturu mikroservisa, rekao bih 50 do 50 - 50 posto mikroservisa, crnih kutija, ušlo je, izašlo obrađeno, ostalih 50 je rastrgan monolit, servisi koji ne mogu raditi odvojeno od ostalih komponente. Sve je to ponovno nametnulo ograničenja na razini znanja i programera i administratora.
Slične "ljuljačke" u razini stručnog znanja o određenom resursu traju do danas. No, malo smo skrenuli, ima mnogo točaka koje vrijedi istaknuti.
Inženjer izrade/inženjer izdanja
Vrlo visoko specijalizirani inženjeri koji su se pojavili kao sredstvo standardizacije procesa izrade softvera i izdanja. U procesu uvođenja široko rasprostranjenog Agilea, čini se da su prestali biti traženi, ali to je daleko od slučaja. Ova se specijalizacija pojavila kao sredstvo standardizacije sastavljanja i isporuke softvera na industrijskoj razini, tj. koristeći standardne tehnike za sve proizvode tvrtke. Dolaskom DevOps-a programeri su dijelom izgubili svoje funkcije, jer su programeri bili ti koji su počeli pripremati proizvod za isporuku, a s obzirom na promjenjivu infrastrukturu i pristup što bržoj isporuci bez obzira na kvalitetu, s vremenom su se pretvorili u zaustavljač promjena, jer poštivanje standarda kvalitete neizbježno usporava isporuke. Tako je postupno dio funkcionalnosti Build/Release inženjera migrirao na ramena administratora sustava.
Operacije su tako različite
Idemo dalje i opet nas prisutnost velikog spektra odgovornosti i nedostatak kvalificiranog osoblja gura prema strogoj specijalizaciji, kao gljive poslije kiše pojavljuju se razne Operacije:
- TechOps - enikey sistemski administratori poznati kao HelpDesk Engineer
- LiveOps - administratori sustava primarno odgovorni za proizvodna okruženja
- CloudOps - administratori sustava specijalizirani za javne oblake Azure, AWS, GCP itd.
- PlatOps/InfraOps/SysOps - administratori infrastrukturnih sustava.
- NetOps - mrežni administratori
- SecOps - administratori sustava specijalizirani za informacijsku sigurnost - PCI usklađenost, CIS usklađenost, patching, itd.
DevOps je (u teoriji) osoba koja iz prve ruke razumije sve procese razvojnog ciklusa - razvoj, testiranje, razumije arhitekturu proizvoda, može procijeniti sigurnosne rizike, poznaje pristupe i alate za automatizaciju, barem na visokoj razina, uz to, također razumije prethodnu i naknadnu obradu.podrška za izdavanje proizvoda. Osoba sposobna djelovati kao zagovornik i operacija i razvoja, što omogućuje povoljnu suradnju između ova dva stupa. Razumije procese planiranja rada timova i upravljanja očekivanjima kupaca.
Da bi obavljala ovu vrstu 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 prema ovom razumijevanju ne može se nalaziti ni u IT-u, ni u istraživanju i razvoju, pa čak ni u PMO-u; on mora imati utjecaj u svim tim područjima - tehnički direktor tvrtke, glavni tehnički direktor.
Je li to istina u vašoj tvrtki? - Sumnjam. U većini slučajeva to je ili IT ili istraživanje i razvoj.
Nedostatak sredstava i mogućnosti utjecaja na barem jedno od ova tri područja djelovanja pomaknut će težinu problema prema mjestima gdje je te promjene lakše primijeniti, kao što je primjena tehničkih ograničenja na izdanja u vezi s "prljavim" kodom prema statici sustavi analizatora. Odnosno, kada PMO postavi strogi rok za izdavanje funkcionalnosti, istraživanje i razvoj ne može proizvesti visokokvalitetni rezultat unutar tih rokova i proizvodi ga najbolje što može, ostavljajući refaktoriranje za kasnije, DevOps povezan s IT-om blokira izdanje tehničkim sredstvima . Nedostatak ovlasti za promjenu situacije, kod odgovornih zaposlenika, dovodi do ispoljavanja hiperodgovornosti za ono na što ne mogu utjecati, pogotovo ako ti zaposlenici razumiju i uviđaju pogreške, te kako ih ispraviti - “Blaženstvo je neznanje”, a kao posljedica izgaranja i gubitka tih zaposlenika.
DevOps tržište resursa
Pogledajmo nekoliko slobodnih radnih mjesta za DevOps pozicije iz različitih tvrtki.
Spremni smo se sastati s vama ako:
- Posjedujete Zabbix i znate što je Prometheus;
- Iptables;
- doktorand BASH;
- profesor Ansible;
- Linux Guru;
- Znati koristiti debugging i pronaći probleme u aplikaciji zajedno s programerima (php/java/python);
- Usmjeravanje vas ne čini histeričnim;
- Obratite značajnu pozornost na sigurnost sustava;
- Izradite sigurnosnu kopiju “svega i svačega”, a također uspješno vratite ovo “sve i svašta”;
- Znate kako konfigurirati sustav na takav način da izvučete maksimum iz minimuma;
- Postavite replikaciju prije spavanja na Postgres i MySQL;
- Postavljanje i podešavanje CI/CD-a jednako vam je potrebno kao doručak/ručak/večera.
- Imati iskustvo s AWS-om;
- Spremni za razvoj s tvrtkom;
Dakle:
- od 1 do 6 - administrator sustava
- 7 - mala mrežna administracija, koja se također uklapa u administratora sustava, srednja razina
- 8 - mala sigurnost, koja je obavezna za administratora sustava srednje razine
- 9-11 – Srednji administrator sustava
- 12 — Ovisno o dodijeljenim zadacima, ili Administrator srednjeg sustava ili Inženjer izgradnje
- 13 - Virtualizacija - Middle System Administrator ili tzv. CloudOps, napredno poznavanje usluga određene hosting stranice, za učinkovito korištenje sredstava i smanjenje opterećenja na održavanju
Rezimirajući ovaj natječaj, možemo reći da je za dečke dovoljan Middle/Senior System Administrator.
Usput, ne biste trebali jako dijeliti administratore na Linuxu/Windowsu. Naravno, razumijem da su usluge i sustavi ova dva svijeta različiti, ali osnova za sve je ista i svaki admin koji drži do sebe je upoznat i s jednim i s drugim, pa čak i ako nije upoznat, bit će kompetentnom administratoru neće biti teško upoznati se s njim.
Razmotrimo još jedno slobodno mjesto:
- Iskustvo u izgradnji visokoopterećenih sustava;
- Odlično poznavanje Linux OS-a, općeg sistemskog softvera i web stacka (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 mrežnog protokola;
- Razumijevanje principa izgradnje sustava otpornih na pogreške;
- Samostalnost i inicijativa;
Pogledajmo:
- 1 – Viši administrator sustava
- 2 - Ovisno o značenju koje se stavlja u ovaj skup - srednji/viši administrator sustava
- 3 - Radno iskustvo, uključujući, može značiti - "Kluster nije podizao, nego je stvarao i upravljao virtualnim strojevima, postojao je jedan Docker host, pristup spremnicima nije bio dostupan" - Administrator srednjeg sustava
- 4 - Junior System Administrator - da, admin koji ne zna pisati osnovne skripte za automatizaciju, bez obzira na jezik, nije admin - enikey.
- 5 - Srednji administrator sustava
- 6 – Viši administrator sustava
Da rezimiramo - srednji/viši sistemski administrator
Još jedan:
- Devops iskustvo;
- Iskustvo u korištenju jednog ili više proizvoda za stvaranje CI/CD procesa. Gitlab CI bit će prednost;
- Rad s kontejnerima i virtualizacija; Ako ste koristili docker, dobro, ali ako ste koristili k8s, super!
- Iskustvo rada u agilnom timu;
- Poznavanje bilo kojeg programskog jezika;
Da vidimo:
- 1 - Hmm... Što misle dečki? =) Najvjerojatnije ni oni sami ne znaju što se krije iza toga
- 2 - Građevinski inženjer
- 3 - Srednji administrator sustava
- 4 - Soft skill, nećemo ga razmatrati za sada, iako je Agile još jedna stvar koja se tumači na način koji je prikladan.
- 5 - Previše opširno - može biti skriptni jezik ili prevedeni. Pitam se hoće li im pisanje na Pascalu i Basicu u školi odgovarati? =)
Također bih želio ostaviti napomenu u vezi s točkom 3 kako bih bolje razumio zašto ovu točku pokriva administrator sustava. Kubernetes je samo orkestracija, alat koji umata izravne naredbe mrežnim upravljačkim programima i hostovima za virtualizaciju/izolaciju u nekoliko naredbi i omogućuje vam da komunikaciju s njima učinite apstraktnom, to je sve. Na primjer, uzmimo 'build framework' Make, koji, usput rečeno, ne smatram okvirom. Da, znam za modu guranja Make-a bilo gdje, gdje treba i gdje ne treba - umotavanje Mavena u Make, na primjer, ozbiljno?
U biti, Make je samo omotač preko ljuske, pojednostavljujući naredbe kompilacije, povezivanja i okoline kompilacije, baš kao k8s.
Jednom sam intervjuirao tipa koji je koristio k8s u svom radu na OpenStacku, i on je govorio o tome kako je implementirao usluge na njemu, međutim, kada sam pitao za OpenStack, ispostavilo se da je administriran, kao i da ga je podigao sustav administratori. Zar stvarno misliš da osoba koja ima instaliran OpenStack, bez obzira koju platformu koristi iza sebe, ne može koristiti k8s? =)
Ovaj kandidat zapravo nije DevOps, već System Administrator i točnije, Kubernetes Administrator.
Rezimirajmo još jednom - njima će biti dovoljan Middle/Senior System Administrator.
Koliko treba težiti u gramima
Raspon predloženih plaća za navedena slobodna radna mjesta je 90k-200k
Sada bih želio povući paralelu između novčanih nagrada sistemskih administratora i DevOps inženjera.
U principu, da pojednostavimo stvari, možete razbacati ocjene na temelju radnog iskustva, iako to neće biti točno, ali za potrebe članka bit će dovoljno.
Iskustvo:
- do 3 godine – Junior
- do 6 godina – Srednja
- više od 6 – Senior
Stranica za traženje zaposlenika nudi:
Administratori sustava:
- Junior - 2 godine - 50 tisuća rub.
- Srednja - 5 godina - 70 tisuća rub.
- Senior - 11 godina - 100 tisuća rub.
DevOps inženjeri:
- Junior - 2 godine - 100 tisuća rub.
- Srednja - 3 godine - 160 tisuća rub.
- Senior - 6 godina - 220 tisuća rub.
Prema iskustvu “DevOpsa”, korišteno je iskustvo koje je barem nekako utjecalo na SDLC.
Iz navedenog proizlazi da zapravo tvrtkama DevOps nije potreban te da bi angažiranjem Administratora mogli uštedjeti barem 50 posto inicijalno planiranih troškova, štoviše jasnije definirati obveze osobe koju traže. i brže zadovoljiti potrebe. Također ne treba zaboraviti da nam jasna podjela odgovornosti omogućuje smanjenje zahtjeva za osobljem, kao i stvaranje povoljnije atmosfere u timu, zbog odsutnosti preklapanja. Velika većina slobodnih radnih mjesta puna je uslužnih programa i DevOps oznaka, ali se ne temelje na stvarnim zahtjevima za DevOps inženjera, već samo na zahtjevima za administratora alata.
Proces obuke DevOps inženjera također je ograničen samo na skup specifičnih radova, pomoćnih programa i ne pruža opće razumijevanje procesa i njihovih ovisnosti. Svakako je dobro kada osoba može implementirati AWS EKS koristeći Terraform, u kombinaciji sa Fluentd sidecar-om u ovom klasteru i AWS ELK stogom za logging sustav za 10 minuta, koristeći samo jednu naredbu u konzoli, ali ako ne razumije princip same obrade logova i za što su oni potrebni, ako ne znate prikupljati metrike na njima i pratiti degradaciju usluge, onda će to i dalje biti isti enikey koji zna koristiti neke pomoćne programe.
Potražnja, međutim, stvara ponudu, a vidimo izrazito pregrijano tržište za DevOps poziciju, gdje zahtjevi ne odgovaraju stvarnoj ulozi, već samo administratorima sustava omogućavaju veću zaradu.
Pa tko su oni? DevOps ili pohlepni administratori sustava? =)
Kako nastaviti živjeti?
Poslodavci bi trebali preciznije formulirati zahtjeve i tražiti upravo one koji su potrebni, a ne razbacivati se etiketama. Ne znate što DevOps rade – u tom slučaju vam ne trebaju.
Radnici – Učite. Konstantno usavršavajte svoje znanje, sagledajte cjelokupnu sliku procesa i pratite put do svog cilja. Možete postati tko god želite, samo morate pokušati.
Izvor: www.habr.com