Što je potrebno za uspjeh IT tvrtke u 2019. godini? Predavači na konferencijama i meet-upovima govore mnogo glasnih i ne uvijek jasnih riječi običnim ljudima. Borba za vrijeme implementacije, mikroservisi, odustajanje od monolita, DevOps transformacija i još mnogo toga. Ako zanemarimo verbalnu ljepotu i pričamo izravno i jasno, sve se svodi na jednostavnu tezu: radite kvalitetan proizvod, a osim toga, radite ga i s udobnošću za tim.
Posljednje je postalo ključno. Poslovanje je nap finally došlo do spoznaje da udoban proces razvoja povećava produktivnost, a ako je sve dobro uređeno i radi kao sat, to također osigurava određeni prostor za manevar u kritičnim situacijama. Nekad je za taj manevar čovjek smislio backup, no industrija se razvija, i došli smo do DevOps inženjera — ljudi koji proces interakcije razvoja i vanjske infrastrukture pretvaraju u nešto prikladno i ne povezano s šamanizmom.
Cjela ova priča o 'modulima' je divna, ali… Tako se dogodilo da je dio administratora naglo preimenovan u DevOps, dok su od samih DevOps inženjera počeli tražiti, najmanje, vještine telepatije i proročanstva.
Prije nego što govorimo o modernim problemima osiguravanja infrastrukture, definirajmo što pod tim pojmom podrazumijevamo. Trenutno je situacija takva da smo došli do dvostrukosti ovog pojma: infrastruktura može biti uvjetno vanjska i uvjetno unutarnja.
Pod vanjskom infrastrukturom smatramo sve ono što osigurava funkcionalnost usluge ili proizvoda čijom se razvojem bavi tim. To su serveri aplikacije ili web stranice, hosting i drugi servisi koji osiguravaju funkcionalnost proizvoda.
Unutarnja infrastruktura uključuje servise i opremu koje koristi sam tim za razvoj i ostali zaposlenici, kojih obično također ima dosta. To su interni serveri sustava za pohranu koda, lokalno postavljen upravitelj zadataka i sve, sve, sve što postoji unutar korporativnog intraneta.
Što to točno radi sistemski administrator u kompaniji? Osim što upravlja korporativnim intranetom, često nosi teret organizacijskih zadataka vezanih uz održavanje uredske opreme. Administrator je onaj tip koji će brzo donijeti novi računar ili spreman rezervni laptop iz skladišta, dati novu tipkovnicu i puzati po uredima, protegnuvši Ethernet kabel. Administrator je lokalni gospodar i vladar ne samo unutarnjih i vanjskih poslužitelja, već i organizacijskih aspekata. Da, neki administratori mogu raditi isključivo na sistemskoj razini, bez hardvera. Njih treba izdvojiti u posebnu podkategoriju "infrastrukturnih sistemskih administratora". Drugi se specijaliziraju isključivo za održavanje uredske opreme, a sreća je ako kompanija broji više od stotinu zaposlenika, posao nikad ne prestaje. No, ni jedni ni drugi nisu DevOps inženjeri.
A tko su DevOps? DevOps inženjeri su ljudi koji se bave interakcijom razvoja softvera s vanjskom infrastrukturom. Točnije, moderni DevOps inženjeri su mnogo dublje uključeni u procese razvoja i implementacije nego što su ikad bili administratori koji su jednostavno uploadali nadogradnje na ftp. Jedan od ključnih zadataka DevOps inženjera danas je osigurati ugodan i učinkovito strukturiran proces interakcije timova za razvoj i infrastrukturu proizvoda. Ove osobe su odgovorne za implementaciju sustava za vraćanje i implementaciju, oni preuzimaju dio opterećenja s programera i maksimalno se koncentriraju na svoju iznimno važnu zadaću. Ipak, DevOps nikad neće provlačiti novi kabel ili dijeliti novi laptop iz skladišta (c) KO
U čemu je caka?
Na pitanje "A tko je DevOps?" polovina radnika u ovoj oblasti počinje odgovarati nešto poput "Pa, to je, ukratko, neki administrator koji..." i nastavljaju dalje. Da, nekada davno, kada se profesija DevOps inženjera tek počela razvijati iz najtalentiranijih administratora u smislu usluge, razlike između njih nisu bile svima očite. No sada, kada se funkcije DevOps-a i administratora u timu radikalno razlikuju, zbunjivati ih ili čak stavljati znak jednakosti među njima – nije prihvatljivo.
Ali što to znači za posao?
Zapošljavanje, to je stvar.
Otvarate natječaj za "Sistemskog administratora", a tu su navedeni zahtjevi „suradnja s razvojem i klijentima“, „CI/CD sustavi“, „održavanje poslužitelja i opreme tvrtke“, „administracija unutarnjih sustava“ i tako dalje; shvaćate da poslodavac iznosi neku glupost. Zamka je u tome što umjesto "Sistemskog administratora" u naslovu natječaja treba stajati "DevOps inženjer", i ako se taj naslov promijeni, sve postaje jasno.
Međutim, kakav dojam ostavlja takav natječaj? Da tvrtka traži svestranog radnika koji će upravljati sustavom kontrole verzija i nadzora, i obaviti isto tako još mnogo toga…
A zapravo, da ne bi povećavali delirij na tržištu rada, dovoljno je zvati natječaje pravim imenima i jasno shvatiti da su DevOps inženjer i sistemski administrator dvije različite entiteta. No, bezobzirna želja nekih poslodavaca da od kandidata traže što širi spektar zahtjeva dovodi do toga da "klasični" sistemski administratori prestaju razumjeti što se događa oko njih. Zar profesija mutira i oni su zakasnili?
Ne, ne i još jednom ne. Infrastrukturni administratori, koji će upravljati unutarnjim poslužiteljima tvrtke, ili zauzimati pozicije L2/L3 podrške i pomagati ostalim zaposlenicima, nisu nestali i ne planiraju otići.
Mogu li ti stručnjaci postati DevOps inženjeri? Naravno da mogu. Naime, to je srodno okruženje koje zahtijeva vještine sistemskog administratora, ali pored toga, uključuje rad s monitoringom, sustavima isporuke i, u cjelini, blisku suradnju s razvojnim i testnim timovima.
Još jedan problem DevOps-a
U stvarnosti, sve se ne završava samo na zapošljavanju i stalnoj zbrci između administratora i devopsa. U nekom trenutku, poslovanje se suočilo s problemom isporuke ažuriranja i suradnje razvojnog tima s krajnjom infrastrukturom.
Možda je to bilo kada je na scenu neke konferencije izašao čovjek s vatrenim očima i rekao: 'Mi to radimo ovako i zovemo to DevOps. Ove ekipe riješit će sve vaše probleme' — i počeo pričati kako dobro žive u kompaniji nakon uvođenja DevOps praksi.
Međutim, nije dovoljno zaposliti DevOps inženjera da bi sve funkcioniralo 'kako treba'. Tvrtka mora proći kroz kompletnu DevOps transformaciju, to jest, uloga i mogućnosti našeg devopsa moraju biti jasno razumljive i s strane razvojnog i testnog tima proizvoda. O tome imamo "divnu" priču koja u potpunosti ilustrira svu tu kataklizmu koja se odvija.
Situacija. Od devopsa se traži da postavi sistem za vraćanje verzija, a da se posebno ne upušta u to kako će to raditi. Pretpostavimo da unutar sistema Users — to su zasebna polja za ime, prezime i šifru. Dolazi nova verzija proizvoda, ali za programere „vraćanje“ je samo čarobna štapica koja će sve popraviti, i oni čak ni ne shvaćaju kako to funkcionira. Primjerice, programeri su u najnovijem patchu spojili polja imena i prezimena, pustili to u produkciju, a verzija usporava iz nekog razloga. Što se događa? Uprava dolazi do devopsa i kaže „Uhvati prekidač!“, odnosno traže od njega da se vrati na prethodnu verziju. Što radi devops? Vraća se na prethodnu verziju, ali pošto programeri nisu htjeli da se dublje zadrže na tome kako se vrati, niko devopsu nije rekao da treba da vrati i bazu. Na kraju, sve nam pada, a korisnici umesto usporene stranice vide grešku „500“, jer stara verzija ne radi s poljima nove baze. Devops o tome nije obavešten. Programeri ćute. Uprava počinje da gubi živce i novac i seća se backup-ova, predlažući da se vrate na njih, kako bi „barem nešto radilo“. Kao rezultat, korisnici gube sve svoje podatke za nekakav vremenski period.
Naravno, devops dobija najviše kritika jer "nije napravio pravi sistem vraćanja", dok je to što su programeri u ovoj priči krivi, nikoga ne zanima.
Zaključak je jednostavan: bez odgovarajućeg pristupa DevOps-u, kao takvom, nije mnogo koristi od njega.
Najvažnije što treba zapamtiti: DevOps inženjer nije čarobnjak, i bez kvalitetne komunikacije i dvosmerne interakcije s razvojem, neće moći da izvrši svoje zadatke. Devopse ne treba ostaviti nasamo sa svojim "problemima" ili im dati direktivu "ne mešaj se s programerima, njihovo je da kodiraju", a onda se nadati da će sve raditi kako treba u kritičnom trenutku. Tako to ne funkcioniše.
U suštini, DevOps su kompetencije na granici između menadžmenta i tehnologije. I to nije očigledno, da bi u ovom kokteilu tehnologija trebalo biti više nego menadžmenta. Ako zaista želite izgraditi brže i efikasnije procese razvoja, morate vjerovati svom DevOps-u. On poznaje potrebne alate, realizovao je slične projekte, zna kako to učiniti. Pomozite mu, slušajte njegove savete, ne pokušavajte ga izolovati u autonomnu jedinicu. Dok administratori mogu raditi sami, DevOps-ovi u tom slučaju postaju beskorisni; ne mogu vam pomoći da postanete bolji ako ne želite prihvatiti tu pomoć.
I posljednje: prestanite vrijeđati administratore-infrastrukturne radnike. Oni imaju svoj, izuzetno važan front rada. Da, administrator može postati DevOps inženjer, ali to se treba dogoditi prema želji same osobe, a ne prisilno. Nema ničeg lošeg u tome što sistemski administrator želi ostati sistemski administrator — to je njegovo odvojeno zanimanje i njegovo pravo. Ako postoji želja za profesionalnom transformacijom, tada se mora imati na umu da će se osim tehnoloških veština morati razvijati i menadžerske. Sve te ljude bi trebalo povezati i naučiti da komuniciraju na istom jeziku, verovatno ste vi kao lider ti koji će to morati učiniti.
Izvor: habr.com
