Što je potrebno da IT tvrtka bude uspješna u 2019. godini? Predavači na konferencijama i susretima govore mnogo glasnih riječi koje normalnim ljudima nisu uvijek razumljive. Borba za vrijeme implementacije, mikroservisi, napuštanje monolita, DevOps transformacija i još mnogo, mnogo više. Ako odbacimo verbalnu ljepotu i govorimo direktno i na ruskom, onda se sve svodi na jednostavnu tezu: napraviti kvalitetan proizvod, i to s ugodnošću za tim.
Ovo posljednje postalo je kritično važno. Posao je konačno došao do zaključka da udoban razvojni proces povećava produktivnost, a ako je sve otklonjeno i radi kao sat, daje i manevarski prostor u kritičnim situacijama. Jednom davno, za potrebe ovog manevra, neka pametna osoba se dosjetila backupa, ali industrija se razvija, a mi smo došli do DevOps inženjera - ljudi koji proces interakcije između razvoja i vanjske infrastrukture pretvaraju u nešto adekvatno i nije vezano za šamanizam.
Cijela ta “modularna” priča je prekrasna, ali... Dogodilo se da su neki admini naglo prozvani DevOps, a od samih DevOps inženjera počelo se tražiti barem vještine telepatije i vidovitosti.
Prije nego počnemo govoriti o suvremenim problemima pružanja infrastrukture, definirajmo što podrazumijevamo pod tim pojmom. U sadašnjem trenutku situacija se razvila na takav način da smo došli do dualnosti ovog koncepta: infrastruktura može biti uvjetno vanjska i uvjetno unutarnja.
Pod vanjskom infrastrukturom podrazumijevamo sve ono što osigurava funkcionalnost usluge ili proizvoda koji tim razvija. To su poslužitelji aplikacija ili web stranica, hosting i druge usluge koje osiguravaju funkcionalnost proizvoda.
Interna infrastruktura uključuje usluge i opremu koju koristi sam razvojni tim i ostali zaposlenici, kojih je obično mnogo. To su interni poslužitelji sustava za pohranu koda, lokalno raspoređeni task manager i sve, sve, sve što postoji unutar korporativnog intraneta.
Što radi sistemski administrator u tvrtki? Uz posao administriranja upravo ovog korporativnog intraneta, on često nosi teret ekonomskih pitanja kako bi se osigurala operativnost uredske opreme. Administrator je isti tip koji će brzo izvući novu sistemsku jedinicu ili rezervni laptop spreman za korištenje iz stražnje sobe, dati novu tipkovnicu i četveronoške puzati kroz urede, rastežući Ethernet kabel. Administrator je lokalni vlasnik i vladar ne samo unutarnjih i vanjskih poslužitelja, već i poslovni rukovoditelj. Da, neki administratori mogu raditi samo u razini sustava, bez hardvera. Trebalo bi ih odvojiti u zasebnu potklasu "administratora infrastrukturnog sustava". A neki su specijalizirani za servisiranje isključivo uredske opreme, srećom, ako tvrtka ima više od sto ljudi, poslu nikad kraja. Ali niti jedan od njih nije devops.
Tko su DevOps? Devops su tipovi koji govore o interakciji razvoja softvera s vanjskom infrastrukturom. Točnije, moderni devops uključeni su u procese razvoja i implementacije mnogo dublje nego što su ikada bili uključeni administratori koji su jednostavno učitavali ažuriranja na ftp. Jedan od ključnih zadataka DevOps inženjera sada je osigurati udoban i učinkovito strukturiran proces interakcije između razvojnih timova i infrastrukture proizvoda. Upravo su ti ljudi odgovorni za implementaciju sustava vraćanja i implementacije; ti ljudi skidaju dio tereta s programera i koncentriraju se što je više moguće na svoj iznimno važan zadatak. U isto vrijeme, devops nikada neće pokrenuti novi kabel ili izdati novi laptop iz stražnje sobe (c) KO
U čemu je kvaka?
Na pitanje "Tko je DevOps?" polovica radnika na terenu počne odgovarati nešto poput “Pa, ukratko, ovo je admin koji...” i dalje u tekstu. Da, nekada davno, dok je profesija DevOps inženjera tek nastajala iz najtalentiranijih administratora u smislu održavanja servisa, razlike među njima nisu bile svima očite. Ali sada, kada su funkcije devopsa i admina u timu postale radikalno različite, nedopustivo ih je međusobno miješati, pa čak i izjednačavati.
Ali što to znači za poslovanje?
Zapošljavanje, sve je u tome.
Otvorite natječaj za “System Administrator”, a tamo su navedeni zahtjevi “interakcija s razvojem i kupcima”, “CI/CD sustav isporuke”, “održavanje servera i opreme tvrtke”, “administracija internih sustava” i sl. na; shvaćate da poslodavac priča gluposti. Kvaka je u tome što bi umjesto “System Administrator” upražnjeno radno mjesto trebalo biti “DevOps Engineer”, a ako se to zvanje promijeni, onda sve sjeda na svoje mjesto.
No, kakav se dojam stječe kad se pročita ovakav natječaj? Da tvrtka traži operatera s više strojeva koji će implementirati i sustav kontrole verzija i nadzora i koji će zubima stiskati twister...
No, kako ne bi povećali stupanj ovisnosti o drogama na tržištu rada, dovoljno je nazvati slobodna radna mjesta pravim imenom i jasno shvatiti da su DevOps inženjer i sistem administrator dva različita entiteta. Ali neukrotiva želja nekih poslodavaca da kandidatu predstave najširi mogući popis zahtjeva dovodi do činjenice da "klasični" administratori sustava prestaju razumjeti što se događa oko njih. Što, profesija mutira, a oni zaostaju za vremenom?
Ne ne i još jednom ne. Administratori infrastrukture koji će upravljati internim poslužiteljima tvrtke, ili zauzimati L2/L3 pozicije podrške i pomagati drugim zaposlenicima, nisu otišli niti će otići.
Mogu li ti stručnjaci postati DevOps inženjeri? Naravno da mogu. Zapravo, ovo je povezano okruženje koje zahtijeva vještine administracije sustava, ali uz to je dodan rad s nadzorom, sustavima isporuke i općenito bliska interakcija s timom za razvoj i testiranje.
Još jedan DevOps problem
Zapravo, nije sve ograničeno samo na zapošljavanje i stalnu zabunu između administratora i devopa. Posao se u jednom trenutku suočio s problemom isporuke ažuriranja i interakcije razvojnog tima s konačnom infrastrukturom.
Možda je to bilo kada je ujak blistavih očiju ustao na pozornici neke konferencije i rekao: “Mi ovo radimo i zovemo to DevOps. Ovi dečki će riješiti sve vaše probleme” - i počeo pričati kako je dobar život u tvrtki nakon implementacije DevOps prakse.
Međutim, nije dovoljno angažirati DevOps inženjera kako bi sve funkcioniralo kako treba. Tvrtka mora proći kroz potpunu DevOps transformaciju, odnosno uloga i mogućnosti našeg DevOpsa također moraju biti jasno shvaćeni od strane tima za razvoj i testiranje proizvoda. Imamo jednu “divnu” priču na ovu temu koja u potpunosti ilustrira svu brutalnost koja se događa na nekim mjestima.
Situacija. DevOps je potreban za implementaciju sustava vraćanja verzije bez stvarnog ulaženja u to kako će funkcionirati. Pretpostavimo da unutar sustava Korisnici postoje odvojena polja za ime, prezime i lozinku. Izašla je nova verzija proizvoda, ali za programere je "vraćanje" samo čarobni štapić koji će sve popraviti, a oni ni ne znaju kako to radi. Tako su, na primjer, u sljedećoj zakrpi programeri spojili polja imena i prezimena, pustili to u proizvodnju, ali je verzija iz nekog razloga spora. Što se događa? Menadžment dolazi devopsu i kaže “Povuci prekidač!”, odnosno traži da se vrati na prethodnu verziju. Što radi devops? Vraća se na prethodnu verziju, ali budući da programeri nisu htjeli shvatiti kako je ovo vraćanje učinjeno, nitko nije rekao devops timu da se baza podataka također mora vratiti na staro. Kao rezultat toga, sve nam se ruši, a umjesto spore web stranice korisnici vide grešku "500", jer stara verzija ne radi s poljima nove baze podataka. Devops ne zna za ovo. Programeri šute. Uprava počinje gubiti živce i novac i sjeća se sigurnosnih kopija, nudeći se vratiti s njih kako bi "barem nešto radilo". Kao rezultat toga, korisnici gube sve svoje podatke tijekom određenog vremenskog razdoblja.
Zaludnici, naravno, idu devopsu, koji "nije napravio pravi sustav vraćanja", a nikoga nije briga što su losovi u ovoj priči programeri.
Zaključak je jednostavan: bez normalnog pristupa DevOps-u kao takvom, od njega nema velike koristi.
Glavna stvar koju treba zapamtiti: DevOps inženjer nije mađioničar i bez kvalitetne komunikacije i dvosmjerne interakcije s razvojem, neće se nositi sa svojim zadacima. Programeri se ne mogu ostaviti sami sa svojim "problemima" ili im se dati naredba "ne petljajte se s programerima, njihov posao je kodiranje", a zatim se nadati da će u kritičnom trenutku sve raditi kako treba. Ne ide to tako.
U biti, DevOps je kompetencija na granici između menadžmenta i tehnologije. Štoviše, daleko je od očitog da bi u ovom koktelu trebalo biti više tehnologije nego menadžmenta. Ako doista želite izgraditi brže i učinkovitije razvojne procese, morate vjerovati svom devops timu. Poznaje prave alate, provodio je slične projekte, zna kako se to radi. Pomozite mu, slušajte njegove savjete, nemojte ga pokušavati izolirati u nekakvu autonomnu jedinicu. Ako administratori mogu raditi sami, onda je devops u ovom slučaju beskoristan; neće vam moći pomoći da postanete bolji ako sami ne želite prihvatiti tu pomoć.
I zadnja stvar: prestanite vrijeđati administratore infrastrukture. Oni imaju svoj, izuzetno važan front rada. Da, administrator može postati DevOps inženjer, ali to bi se trebalo dogoditi na zahtjev same osobe, a ne pod pritiskom. I nema ništa loše u tome što sistemski administrator želi ostati sistemski administrator - to je njegova posebna profesija i njegovo pravo. Ako se želite podvrgnuti profesionalnoj transformaciji, nikada ne smijete zaboraviti da ćete morati izgraditi ne samo tehnološke, već i upravljačke vještine. Najvjerojatnije će na vama kao voditelju biti da okupite sve te ljude i naučite ih komunicirati istim jezikom.
Izvor: www.habr.com